解讀SDN核心技術：OpenFlow深刻分析（轉載）

1 OpenFlow簡介

　　OpenFlow是由斯坦福大學的Nick McKeown教授在2008年4月ACM Communications Review上發表的一篇論文OpenFlow: enabling innovation in campus networks首先詳細論述了OpenFlow的原理。由該論文課題可知OpenFlow提出的最初出發點是用於校園內網絡研究人員實驗其創新網絡架構、協議，考慮到實際的網絡創新思想須要在實際網絡上才能更好地驗證，而研究人員又沒法修改在網的網絡設備，故而提出了OpenFlow的控制轉發分離架構，將控制邏輯從網絡設備盒子中引出來，研究者能夠對其進行任意的編程從而實現新型的網絡協議、拓撲架構而無需改動網絡設備自己。該想法首先在美國的GENI研究項目中獲得應用，實現了一個從主機到網絡的端到端創新實驗平臺，HP、NEC等公司提供了GENI項目所需的支持OpenFlow的交換機設備。OpenFlow其架構見下圖：

　

　　▲圖 1.1 OpenFlow概念架構

　　Openflow的思路很簡單，網絡設備維護一個FlowTable而且只按照FlowTable進行轉發，Flowtable自己的生成、維護、下發徹底由外置的Controller來實現，注意這裏的FlowTable並不是是指IP五元組，事實上OpenFlow 1.0定義的了包括端口號、VLAN、L2/L3/L4信息的10個關鍵字，可是每一個字段都是能夠通配的，網絡的運營商能夠決定使用何種粒度的流，好比運營商只須要根據目的IP進行路由，那麼流表中就能夠只有目的IP字段是有效的，其它全爲通配。

　　這種控制和轉發分離的架構對於L2交換設備而言，意味着MAC地址的學習由Controller來實現，V-LAN和基本的L3路由配置也由Controller下發給交換機。對於L3設備，各種IGP/EGP路由運行在Controller之上，Controller根據須要下發給相應的路由器。流表的下發能夠是主動的，也能夠是被動的，主動模式下，Controller將本身收集的流表信息主動下發給網絡設備，隨後網絡設備能夠直接根據流表進行轉發;被動模式是指網絡設備收到一個報文沒有匹配的FlowTable記錄時，將該報文轉發給Controller，由後者進行決策該如何轉發，並下發相應的流表。被動模式的好處是網絡設備無需維護所有的流表，只有當實際的流量產生時才向Controller獲取流表記錄並存儲，當老化定時器超時後能夠刪除相應的流表，故能夠大大節省TCAM空間。當一個Controller同時控制多個交換機/路由器設備時，它們看起來就像一個大的邏輯交換機，各個交換機/路由器硬件就如同這個邏輯網絡設備的遠程線卡，相似的概念在Cisco的Nexus 1000/1000v、ASR9000/9000v和Juniper的Q-Fabric架構中能夠看到影子，Cisco稱之爲nV(Network Virtualization)技術。

　　OpenFlow 1.0的流表分爲Match Fields、計數器和指令集三個部分，Match Fields是報文匹配的輸入關鍵字，計數器是管理所需，指令集是決定報文如何轉發，最基本的轉發行爲包括轉發給某個端口、封裝改寫報文後轉發以及丟棄。OpenFlow 1.1增長了對MPLS以及UDP/SCTP傳輸層協議的支持，同時針對流表開銷過大的狀況設計了多級流表，並增長分組策略功能。

 

2 「Open」仍是」Flow」

　　Nick同窗藉着GENI項目完成了OpenFlow的初始概念實驗後開始向產業界推銷，目前已知Arista Networks, IBM, Juniper Networks, Hewlett-Packard以及NEC等廠商在其部分交換機中支持OpenFlow協議。從其經從來看，其絕非是一個象牙塔中的單純研究者，而是時刻和產業界保持了密切的聯繫。Nick 1986-1989年在HP實驗室從事網絡技術研究，1995年參與了Cisco的GSR12000路由器的架構設計，而且也是CrossBar的設計者之一，而且前後建立了Abrizio和Nemo System公司，後者在2005年以$12.5M賣給Cisco公司。2009年又不甘寂寞，建立了以推廣OpenFlow爲目標的Nicira公司，該公司是開源OpenFlow Controller NOX的維護者。

　　2011年3月21日，由德電、Facebook、Google、微軟、Verizon、Yahoo!發起成立了Open Networking Foundation，旨在推動實現基於OpenFlow的開放網絡，參與者衆多，從交換芯片的博通、Broadcom到網絡設備的提供者Cisco、Juniper、NSN、Force十、Ericsson、NEC以及數據中心解決方案提供者IBM、HP、VmWare、Citrix以及運營商NTT等等。網絡設備提供商中阿朗、華爲、中興缺席，阿朗缺席能夠理解，畢竟數據中心不是其產品方向。

　　除了在Datacenter中的應用外，OpenFlow的擁躉者還提出了採用OpenFlow實現網絡虛擬化的架構，以支持虛擬網絡運營商，其中開源的FlowVisor做爲網絡虛擬控制層(至關於HyperVisor)，將網絡資源根據VLAN、IP分段等各類信息進行切片，分發給上層的Open Flow Controller(至關於Guest OS)進行，在各個VNO(虛擬網絡運營商)的Controller上VNO能夠採用腳本編程來控制其租用的虛擬網絡的各類轉發、QoS策略。該模式也一樣適用於數據中心運營商提供VPC(Virtual Private Cloud，虛擬私有云)業務時將網絡虛擬化和計算存儲打包出售給租戶。

　　雖然Nick同窗忽悠了這麼大的陣勢，仍是有不少人疑惑openflow的價值到底在哪裏，是Open仍是Flow?這個問題首先能夠否定」Flow」的價值，緣由很簡單，是否控制到細粒度的Flow取決於應用，應用沒有控制流的需求，則Flow毫無價值，」Flow」只是Openflow能提供的最大限度的控制能力而已，目前在ONF關注的數據中心交換網中沒有誰打算控制精確到n(n>=5)元組的流，除非是應用在防火牆控制上。

　　那麼」Open」呢?的確包括Nick本人在內一直強調的都是」Open」是價值之所在，Open以後，研究者、運營商能夠採購任意廠商的標準接口設備，本身DIY網絡，甚至能夠採用交換信息廠商提供的公版設計交換機加上OpenFlow Controller就能夠組成本身所需的網絡，而且Controller的開放軟件架構使得網絡控制的實現就像Web編程同樣簡單，採用Python、JAVA Script這樣的腳本加上開源算法庫、一個不須要了解太多網絡協議細節的開發者幾天就能夠實現一個新的網絡拓撲算法開發、部署。這在流量模型尤其複雜運營級數據中心確實很是有吸引力。在這樣的一種場景中，網絡設備市場就變成了如同PC那樣的市場，賣網絡設備硬件的就成了賣大白菜的，你們最後只能比拼價格和工藝設計了。可是，即便這種悲慘的場景成爲事實，誰又會是PC化的網絡市場中提供Windows的微軟呢，Openflow體系的NOS將會誰是贏家?交換網絡相對簡單，可是L3之上各類協議散落在數十年積累的數千篇IETF RFC中，誰可以有實力實現一個如此複雜的網絡操做系統而又讓運營商放心呢?我想仍然多是今天的網絡設備巨頭Cisco、Juniper們，產生意外的可能極小，可是產業鏈已經被家常，競爭的焦點已經發生了轉移

　　從NGN引入控制承載分離架構的經驗來看，沒有一個領先廠家願意開放媒體網關的控制接口，也幾乎看不到商用的開放接口組網案例，所以能夠推斷即便OpenFlow廣爲業界採用，」Open」成爲現實一定困難重重。如此一來Openflow可以留下的就是單廠商本身實現的控制轉發分離架構以及控制器開放軟件架構帶來的下降開發週期、新功能快速麪世能力。控制和轉發分離架構在NGN帶來的好處是兩方面的1)對於設備供應商而言，沒必要爲兩種徹底不一樣的能力塞在一個空間、功耗、成本均受限的一個盒子中而又保證足夠的可擴展性而苦惱，兩種硬件平臺、軟件架構能夠分離發展，分別實現最優設計。2)對於運營商而言，能夠得到部署上的靈活性和管理上的便利，媒體網關因爲要匯聚流量，靠近用戶能夠節省電路資源、減小時延，控制器部署集中在更高位置，與運營商的集中管控戰略一致，方便下降Opex。這些好處在Openflow架構中相似。

　　有人會爭辯說上述好處採用集中網管也可實現，不錯，所謂異曲同工，技術層面上來說沒有一種技術是不可替代的，可是產業鏈、經濟性也就是市場是最終的評判者。若是採用網管來實現的話，實現Openflow同等的能力須要網管服務器參與到轉發的在線決策中，那樣網管服務的可靠性指標要提高几個數量級，而且要定義網管接口能夠將未命中策略的流量引出來，那不過是另一種形態的Openflow，就如同Cisco的nV技術同樣。

3 OpenFlow對產業鏈的影響

　　如上節所述，OpenFlow隱隱約約有將網絡設備市場PC化的可能，但目前尚缺一個相似於相似於微軟的基於OpenFlow的網絡設備操做系統提供商。理論上，運營商會喜歡網絡控制接口，技術流的運營商也樂於DIY本身的網絡，好比數據中心的擁有者Google、Facebook的服務器已經採用大量定製化的廉價服務器搭建本身的計算服務設備，對於網絡，他們也已經開始經過ONF啓動了DIY之旅。

　　DIY以後，網絡設備價值鏈的核心分化，網絡交換芯片，尤爲是FlowTable處理器將是一個核心價值所在，控制器(也就是前述的網絡操做系統)軟件系統也是價值核心，有了這兩個組件，大量廉價網絡設備硬件將涌如今市場之上，這使得硬件市場利潤攤薄。可是這種開放性將使得網絡創新速度加快，尤爲是當這個領域有幸誕生新的執拗摩爾定律的Intel和開源Linux操做系統。

　　通訊領域的產業週期中，創新的功能走的是一條運營商提出需求->設備供應商分析需求->標準組織標準化->設備供應商實現->運營商測試並採用的超長路徑，週期以數年計算，而互聯網業務提供商每每集運營商和供應商於一身，創新功能的採用從需求發現->設計->開發->上線在一個商業實體中完成，而且功能開發過程當中能夠不斷得到用戶的反饋而改進設計，這是所謂的Web業務開發的」永遠是Beta版本」的概念，應用到網絡設計中，運營商能夠自行設計網絡拓撲算法，而且能夠根據網絡性能統計進行迭代調整。因而可知此種OpenFlow的遠景可能結果是將網絡創新從供應商巨頭壟斷轉變爲運營商主導創新。

　　4 OpenFlow面臨的技術難點

　　Openflow的推廣除了面臨上一章所述的產業博弈的問題外，目前還面臨着一些技術的難點。其中之一就是路由器/交換機中廣爲使用的快速查找TCAM存儲器成本的問題。在傳統設備中，須要採用TCAM的表包括FIB、MAC、MPLS Lable和ACL表，每一個表的匹配字段長度不一，分開設計，而且設計了最大容量，以期達到最小的開銷。而在Openflow設備中，再也不區分匹配長度短的FIB、MAC、MPLS Lable表以及較長的ACL表，一概採用最大長度的FlowTable記錄代替，對於OpenFlow1.0而言，Flow table的匹配字段長度長達252比特，而通常IPV4 RIB TCAM匹配字段長度只有60-80個比特，開銷增長了3倍以上，而對於路由器的線卡而言，TCAM成本佔了約20-30%，功耗也佔了很大一部分。所以如何減小FlowTable尺寸將是OpenFlow體系面臨的一個極大問題，此外，TCAM體系下FlowTable記錄的動態插入算法將更爲複雜。

　　OpenFlow1.1設計了多級流表來減小Flowtable的開銷，將流表進行特徵提取，分解成多個步驟，造成流水線處理形式，從而下降總的流表記錄條數，好比原始流表共有10000條，分解成先匹配VLAN+MAC，再匹配IP和傳輸層頭部的兩個獨立流表，每一個流表的數量可能均小於1000條，使得流表總數小於2000條。但流水線式架構使得匹配時延增長，並且流量的生成、維護算法複雜度提升，至今也未見到針對真實網絡的效果評估報告。

　　OpenFlow的關鍵是經過OpenFlow將網絡轉發的原子操做抽象出來，並以流表來驅動流程，咱們所論述的一切好處是創建在OpenFlow FlowTable可以很好地將Primitive和WorkFlow抽象，支持設計新的協議在大部分狀況下的確能夠經過只修改Controller的邏輯來實現這一假定上。在OpenFlow最初應用的Switch領域，OpenFlow已經有殺雞用牛刀的嫌疑了。可是路由網絡，尤爲是包含有大量用戶控制邏輯的邊界路由器，如BRAS、無線網絡的GGSN/PDSN/xGW等設備，OpenFlow須要擴展將用戶控制邏輯抽象爲原子操做和流程，那可能已經不適合叫FlowTable，叫AccessControlTable更合適，轉發操做自己的匹配規則、轉發操做中也須要增長對現存的各類接入協議和表徵接入會話的協議字段的支持，好比PPPoE、GTP-U、PDP激活操做的匹配和轉發封裝支持。

　　5 結論

　　從需求面上講，控制轉發分離、集中控制的確能夠爲運營商帶來好處，對設備上自身的設備軟件架構也有借鑑做用，可是」Open」出來的驅動力不足，面臨產業的博弈，諸多市場後進者可能會借OpenFlow博上位，可是市場既得利益者一定會持反對態度。有人會提出，個人設備自己就是控制、轉發分離的架構了，我將控制功能出來就好了，沒錯，Cisco們看起來就是這麼幹的。

　　從具體細分市場而言，數據中心中OpenFlow處理複雜流量模型、集中管控有優點，並且隨着多租戶數據中心業務的普遍開展，OpenFlow所支持的網絡虛擬化多租戶架構、甚至能夠將Controller和虛擬機管理系統進行水平交互從而實現網絡和計算存儲的聯合調度，其帶來的好處對Datacenter運營商是有必定的吸引力的。而邊緣路由器的應用則是補齊網絡虛擬化這個大的拼圖的一部分，而且邊緣路由器，尤爲是無線網絡的邊緣路由器，需求輸入仍然較多，控制轉發分離架構對於加快產品創新週期、較少市場響應週期有必定的積極意義，可是其主要功能超出目前OpenFlow的範疇，須要進一步的研究。