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傳輸層協議的支持，同時針對流表開銷過大的情況設計了多級流表，并增加分組策略功能。

#p#

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、Force10、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能夠留下的就是單廠商自己實現的控制轉發分離架構以及控制器開放軟件架構帶來的降低開發周期、新功能快速面世能力?？刂坪娃D發分離架構在 NGN帶來的好處是兩方面的1)對于設備供應商而言，不必為兩種完全不同的能力塞在一個空間、功耗、成本均受限的一個盒子中而又保證足夠的可擴展性而苦惱，兩種硬件平臺、軟件架構可以分離發展，分別實現最優設計。2)對于運營商而言，可以獲得部署上的靈活性和管理上的便利，媒體網關由于要匯聚流量，靠近用戶可以節省電路資源、減少時延，控制器部署集中在更高位置，與運營商的集中管控戰略一致，方便降低Opex。這些好處在Openflow架構中類似。

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

#p#

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的范疇，需要進一步的研究。