虛擬化的逆襲：OpenFlow和SDN

云計算的發展，是以虛擬化技術為基礎的。云計算服務商以按需分配為原則，為客戶提供具有高可用性、高擴展性的計算、存儲和網絡等IT資源。虛擬化技術將各種物理資源抽象為邏輯上的資源，隱藏了各種物理上的限制，為在更細粒度上對其進行管理和應用提供了可能性。

近些年，計算的虛擬化技術(主要指x86平臺的虛擬化)取得了長足的發展；相比較而言，盡管存儲和網絡的虛擬化也得到了諸多發展，但是還有很多問題亟需解決，在云計算環境中尤其如此。

OpenFlow和SDN盡管不是專門為網絡虛擬化而生，但是它們帶來的標準化和靈活性卻給網絡虛擬化的發展帶來無限可能。 本文來自公眾賬號“點融黑幫”，作者萬林濤，希望通過本文對OpenFlow/SDN做一個初步介紹，以期幫助大家能夠進一步深入了解和學習OpenFlow/SDN，歡迎批評和指正。

起源與發展

OpenFlow起源于斯坦福大學的Clean Slate項目組 。CleanSlate項目的最終目的是要重新發明英特網，旨在改變設計已略顯不合時宜，且難以進化發展的現有網絡基礎架構。在2006年，斯坦福的學生 Martin Casado領導了一個關于網絡安全與管理的項目Ethane，該項目試圖通過一個集中式的控制器，讓網絡管理員可以方便地定義基于網絡流的安全控制策 略，并將這些安全策略應用到各種網絡設備中，從而實現對整個網絡通訊的安全控制。

受此項目(及Ethane的前續項目Sane)啟發，Martin和他的導師Nick McKeown教授(時任Clean Slate項目的Faculty Director)發現，如果將Ethane的設計更一般化，將傳統網絡設備的數據轉發(data plane)和路由控制(control plane)兩個功能模塊相分離，通過集中式的控制器(Controller)以標準化的接口對各種網絡設備進行管理和配置，那么這將為網絡資源的設計、 管理和使用提供更多的可能性，從而更容易推動網絡的革新與發展。

于是，他們便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM發表了題為OpenFlow: Enabling Innovation in Campus Networks的論文，首次詳細地介紹了OpenFlow的概念。該篇論文除了闡述OpenFlow的工作原理外，還列舉了OpenFlow幾大應用場 景，包括：

1)校園網絡中對實驗性通訊協議的支持(如其標題所示);

2) 網絡管理和訪問控制;

3)網絡隔離和VLAN;

4)基于WiFi的移動網絡;

5)非IP網絡;

6)基于網絡包的處理。當然，目前關于OpenFlow的研究已經遠遠超出了這些領域。

基于OpenFlow為網絡帶來的可編程的特性，Nick和他的團隊(包括加州大學伯克利分校的Scott Shenker教授)進一步提出了SDN(Software Defined Network, 目前國內多直譯為“軟件定義網絡”)的概念--其實，SDN的概念據說最早是由KateGreene于2009年在TechnologyReview網站 上評選年度十大前沿技術時提出。

如果將網絡中所有的網絡設備視為被管理的資源，那么參考操作系統的原理，可以抽象出一個網絡操作系統(Network OS)的概念—這個網絡操作系統一方面抽象了底層網絡設備的具體細節，同時還為上層應用提供了統一的管理視圖和編程接口。這樣，基于網絡操作系統這個平 臺，用戶可以開發各種應用程序，通過軟件來定義邏輯上的網絡拓撲，以滿足對網絡資源的不同需求，而無需關心底層網絡的物理拓撲結構。關于SDN的概念和原 理，可以參考開放網絡基金會(Open NetworkingFoundation)于今年4月份發表的SDN白皮書Software Defined Networking：The New Norm forNetworks 。

從上面的描述中，可以看出OpenFlow/SDN的原理其實并不復雜，從嚴格意義上講也很難算是具有革命性的創新。然而OpenFlow /SDN卻引來了業界越來越多的關注，成為近年來名副其實的熱門技術。目前，包括HP、IBM、Cisco、NEC以及國內的華為和中興等傳統網絡設備制 造商都已紛紛加入到OpenFlow的陣營，同時有一些支持OpenFlow的網絡硬件設備已經面世。

2011年，開放網絡基金會(Open Networking Foundation)在Nick等人的推動下成立，專門負責OpenFlow標準和規范的維護和發展;同年，第一屆開放網絡峰會 (OpenNetworking Summit)召開，為OpenFlow和SDN在學術界和工業界都做了很好的介紹和推廣。

第二屆峰會上，來自Google的Urs H lzle在以OpenFlow@Google為題的Keynote演講中宣布Google已經在其全球各地的數據中心骨干網絡中大規模地使用 OpenFlow/SDN，從而證明了OpenFlow不再僅僅是停留在學術界的一個研究模型，而是已經完全具備了可以在產品環境中應用的技術成熟度。最 近，非死book也宣布其數據中心中使用了OpenFlow/SDN的技術。

OpenFlow標準和規范

自2010年初發布第一個版本(v1.0)以來，OpenFlow規范已經經歷了1.1、1.2以及最近剛發布的1.3等版本。同時，今年年初 OpenFlow管理和配置協議也發布了第一個版本(OF-CONFIG 1.0 & 1.1)。下圖列出了OF和OF-CONFIG規范各個版本的發展歷程及變化，從圖中可以看到目前使用和支持最多的仍然是1.0和1.1版本。

在這里，我們將詳細介紹一下OpenFlow Switch的最新規范(即OF-1.3)。下圖選自Nick等人的論文OpenFlow：EnablingInnovation in Campus Networks 。這張圖常被用來說明OpenFlow的原理和基本架構。其實，這張圖還很好地表明了OpenFlow Switch規范所定義的范圍—從圖上可以看出，OpenFlow Switch規范主要定義了Switch的功能模塊以及其與Controller之間的通信信道等方面。

OF規范主要分為如下四大部分，

1. OpenFlow的端口(Port)

OpenFlow規范將Switch上的端口分為3種類別：

a) 物理端口，即設備上物理可見的端口;

b) 邏輯端口，在物理端口基礎上由Switch設備抽象出來的邏輯端口，如為tunnel或者聚合等功能而實現的邏輯端口;

c) OpenFlow定義的端口。OpenFlow目前總共定義了ALL、CONTROLLER、TABLE、IN_PORT、ANY、LOCAL、 NORMAL和FLOOD等8種端口，其中后3種為非必需的端口，只在混合型的OpenFlow Switch(OpenFlow-hybrid Switch，即同時支持傳統網絡協議棧和OpenFlow協議的Switch設備，相對于OpenFlow-only Switch而言)中存在。

2. OpenFlow的FlowTable(國內有直譯為“流表”的)

OpenFlow通過用戶定義的或者預設的規則來匹配和處理網絡包。一條OpenFlow的規則由匹配域(Match Fields)、優先級(Priority)、處理指令(Instructions)和統計數據(如Counters)等字段組成，如下圖所示。

在一條規則中，可以根據網絡包在L2、L3或者L4等網絡報文頭的任意字段進行匹配，比如以太網幀的源MAC地址，IP包的協議類型和IP地址， 或者TCP/UDP的端口號等。目前OpenFlow的規范中還規定了Switch設備廠商可以選擇性地支持通配符進行匹配。據說，OpenFlow在未 來還計劃支持對整個數據包的任意字段進行匹配。

所有OpenFlow的規則都被組織在不同的FlowTable中，在同一個FlowTable中按規則的優先級進行先后匹配。一個 OpenFlow的Switch可以包含一個或者多個FlowTable，從0依次編號排列。OpenFlow規范中定義了流水線式的處理流程，如下圖所 示。當數據包進入Switch后，必須從FlowTable 0開始依次匹配;

FlowTable可以按次序從小到大越級跳轉，但不能從某一FlowTable向前跳轉至編號更小的FlowTable。當數據包成功匹配一條 規則后，將首先更新該規則對應的統計數據(如成功匹配數據包總數目和總字節數等)，然后根據規則中的指令進行相應操作--比如跳轉至后續某一 FlowTable繼續處理，修改或者立即執行該數據包對應的Action Set等。

當數據包已經處于最后一個FlowTable時，其對應的Action Set中的所有Action將被執行，包括轉發至某一端口，修改數據包某一字段，丟棄數據包等。OpenFlow規范中對目前所支持的 Instructions和Actions進行了完整詳細的說明和定義。

另外，OpenFlow規范中還定義了很多其他功能和行為，比如OpenFlow對于QoS的支持(即MeterTable和Meter Bands的定義等)，對于GroupTable的定義，以及規則的超時處理等。

OpenFlow的通信通道

這一節中，OpenFlow規范定義了一個OpenFlow Switch如何與Controller建立連接、通訊以及相關消息類型等。

OpenFlow規范中定義了三種消息類型：

a) Controller/Switch消息，是指由Controller發起、Switch接收并處理的消息，主要包括Features、 Configuration、Modify-State、Read-State、Packet-out、Barrier和Role-Request等消 息。這些消息主要由Controller用來對Switch進行狀態查詢和修改配置等操作。

b) 異步(Asynchronous)消息，是由Switch發送給Controller、用來通知Switch上發生的某些異步事件的消息，主要包括 Packet-in、Flow-Removed、Port-status和Error等。例如，當某一條規則因為超時而被刪除時，Switch將自動發送 一條Flow-Removed消息通知Controller，以方便Controller作出相應的操作，如重新設置相關規則等。

c) 對稱(Symmetric)消息，顧名思義，這些都是雙向對稱的消息，主要用來建立連接、檢測對方是否在線等，包括Hello、Echo和Experimenter三種消息。

下圖展示了OpenFlow和Switch之間一次典型的消息交換過程，出于安全和高可用性等方面的考慮，OpenFlow的規范還規定了如何為Controller和Switch之間的信道加密、如何建立多連接等(主連接和輔助連接)。

OpenFlow協議及相關數據結構

在OpenFlow規范的最后一部分，主要詳細定義了各種OpenFlow消息的數據結構，包括OpenFlow消息的消息頭等。這里就不一一贅述，如需了解可以參考OpenFlow源代碼中openflow.h頭文件中關于各種數據結構的定義。

OpenFlow的應用

隨著OpenFlow/SDN概念的發展和推廣，其研究和應用領域也得到了不斷拓展。目前，關于OpenFlow/SDN的研究領域主要包括網絡 虛擬化、安全和訪問控制、負載均衡、聚合網絡和綠色節能等方面。另外，還有關于OpenFlow和傳統網絡設備交互和整合等方面的研究。

下面將舉幾個典型的研究案例來展示OpenFlow的應用。

1. 網絡虛擬化 – FlowVisor

網絡虛擬化的本質是要能夠抽象底層網絡的物理拓撲，能夠在邏輯上對網絡資源進行分片或者整合，從而滿足各種應用對于網絡的不同需求。為了達到網絡 分片的目的，FlowVisor實現了一種特殊的OpenFlow Controller，可以看作其他不同用戶或應用的Controllers與網絡設備之間的一層代理。

因此，不同用戶或應用可以使用自己的Controllers來定義不同的網絡拓撲，同時FlowVisor又可以保證這些Controllers之間能夠互相隔離而互不影響。

下圖展示了使用FlowVisor可以在同一個物理網絡上定義出不同的邏輯拓撲。FlowVisor不僅是一個典型的OpenFlow應用案例，同時還是一個很好的研究平臺，目前已經有很多研究和應用都是基于FlowVisor做的。

2. 負載均衡 – Aster*x

傳統的負載均衡方案一般需要在服務器集群的入口處，通過一個gateway或者router來監測、統計服務器工作負載，并據此動態分配用戶請求 到負載相對較輕的服務器上。既然網絡中所有的網絡設備都可以通過OpenFlow進行集中式的控制和管理，同時應用服務器的負載可以及時地反饋到 OpenFlowController那里，那么OpenFlow就非常適合做負載均衡的工作。

Aster*x通過Host Manager和Net Manager來分別監測服務器和網絡的工作負載，然后將這些信息反饋給FlowManager，這樣Flow Manager就可以根據這些實時的負載信息，重新定義網絡設備上的OpenFlow規則，從而將用戶請求(即網絡包)按照服務器的能力進行調整和分發。

3. 綠色節能的網絡服務 – ElasticTree

在數據中心和云計算環境中，如何降低運營成本是一個重要的研究課題。能夠根據工作負荷按需分配、動態規劃資源，不僅可以提高資源的利用率，還可以達到節能環保的目的。

ElasticTree創新性地使用OpenFlow，在不影響性能的前提下，根據網絡負載動態規劃路由，從而可以在網絡負載不高的情況下選擇性地關閉或者掛起部分網絡設備，使其進入節電模式達到節能環保、降低運營成本的目的。

結語

沒有任何一項技術可以解決所有問題，我們相信OpenFlow/SDN也不會是解決現有所有網絡問題的“萬金油”。但是，我們相信 OpenFlow/SDN的確給網絡變革和創新帶了許多機遇—既然網絡問題已經變得可以通過編程來解決的時候，技術宅們該出手了，拯救網絡世界的時候到 了!