對軟件定義網絡數據面抽象的重新思考

中圖分類號：TN915.03； TP393.03 文獻標志碼：A 文章編號：1009-6868 （2013） 05-0022-004

提出了一種基于標簽的更加靈活的SDN交換機數據面抽象——LabelCast。LabelCast利用標簽交換機制解決SDN交換機中的復雜規則匹配問題，采用Cast程序擴展機制解決交換機轉發面的功能可編程問題。LabelCast不但可以簡化SDN數據面規則匹配復雜性，還可以通過在數據面加載應用的處理程序支持可編程的數據面功能擴展。

軟件定義網絡；數據面；抽象

In this paper， we propose a flexible data plane abstraction for software-defined networks. This abstraction is called Labelcast. The complex rule-matching problem can be solved by using label switching mechanisms， and programming the functions of the switch-forwarding plane can be simplified using the Cast program extension mechanism. Labelcast decreases complex rule-matching and supports function extensibility in the data plane of SDN switches.

software-defined networks； data plane； abstraction

經過多年發展，軟件定義網絡（SDN）/OpenFlow的研究和標準化進入一個關鍵階段。

一方面，美國計算機協會數據通信專業組（SIGCOMM）上首次出現多篇SDN的論文，標志著SDN正式受到學術界的認可。中國盛科公司推出業界第一款支持OpenFlow多級流表的芯片Bigbelt和支持OpenFlow1.3標準的交換機產品V350。同時，2013年4月OpenFlow 1.3.2標準推出，保持半年更新一個版本的速度。

另一方面，對SDN/OpenFlow的理性思考也逐漸增加，2013年5月SDN技術主要推動者加州大學伯克利分校的Scott Shinker將自己演講的題目定為“Software-Defined Networking at the Crossroads”，認為SDN的發展正處在一個十字路口，重大轉型即將出現。SDN的重要發明人Martín Casado在其論文中認為目前OpenFlow是在網絡核心和網絡邊緣對數據平面需求的一個“An Unhappy Medium”。工業界評論中也越來越多出現了類似“OpenFlow不是網絡演進的唯一路徑”的標題，甚至著名的IT評論網站Network Computing的評論做出了OpenFlow在2014年必死的預測（Prediction： OpenFlow Is Dead by 2014）。設備廠商在2013年也推出了協議無關轉發（POF）技術，將SDN中的OpenFlow演化到更加靈活的編程模型，而不再受預先定義協議類型或轉發規則的限制。報文轉發行為可由控制器上的軟件通過細粒度的轉發指令（包括數據偏移量和長度）定義，而轉發的報文可以不再經過軟件控制器的處理。基于POF，路由器的轉發引擎已經不再與協議類型相關，因此支持更多的應用場景。

本文首先對OpenFlow提出的背景和發展歷程進行了重新審視，重點對OpenFlow標準化中的一些技術上的重要決斷進行討論和對OpenFlow最新的發展動向進行分析，通過分析指出復雜的轉發規則匹配和難以支持新型網絡體系結構的部署是目前OpenFlow發展遇到的重要難題。然后對多協議標簽交換（MPLS）部署的成功進行分析，通過借鑒MPLS體系結構在簡化轉發處理和支持多種協議方面的優點，本文提出了新的SDN網絡數據面抽象——LabelCast，介紹了LabelCast的工作原理，并對實現的相關問題進行了討論。

1 OpenFlow發展面臨的

問題

1.1 OpenFlow最初需要解決的問題

Martin Casado在2008年的文獻[1]中指出，硬件實現轉發要有3個重要的特性：軟硬件接口明確、硬件實現簡單、支持靈活高效的功能實現。

文獻[1]認為目前硬件實現分組轉發的邏輯十分復雜，因此提出了首先由軟件對報文流的第一個分組做出轉發決策，然后由硬件模仿這一決策，對流內后續的分組進行轉發的方案。這種轉發的特點是各種網絡協議實現對硬件沒有限制，即硬件設計不必為支持某種特定的協議而進行專門優化。同時網絡硬件實現對協議也沒有限制，未來出現的各種協議也不會因為硬件平臺的限制而難以部署。

OpenFlow白皮書[2]也提出了OpenFlow設計的4個原則：高性能低成本實現、支持多樣化的網絡實驗、隔離實驗流量和正常流量、支持設備制造商封閉其內部實現方法的需求。由于OpenFlow沒有過于追求可編程性而忽略設備制造商封閉內部實現細節的需求，因此雖然主張開放網絡設備的內部流表接口，但并沒有受到設備制造商的抵制。

上述兩篇論文對OpenFlow的早期發展具有重要影響。隨著OpenFlow得到廣泛研究，其不僅僅是在校園網上支持網絡實驗部署的方法，更為互聯網體系結構的發展帶來新的思路。

1.2 OpenFlow現在面臨的問題

OpenFlow的發展目前面臨很多問題，最重要一點是OpenFlow協議難以滿足SDN內涵不斷發展的需求。SDN近年來得到廣泛研究，其技術內涵也在不斷拓展。特別是軟件定義互聯網體系結構和軟件定義Middlebox聯網等新概念對SDN數據面的需求不斷變化。這使得最初面向實驗網絡部署而設計的OpenFlow協議難以支持。例如文獻[3]提出了網絡體系結構與網絡基礎設施解耦的軟件定義互聯網體系結構（SDIA）的思想，指出互聯網基礎設施（如路由器、交換機和Middlebox等）實現只有與具體網絡體系結構無關，才能在基礎設施不變前提下支持多種網絡體系結構的部署。

然而OpenFlow協議規范制訂時并沒有考慮上述問題。例如為支持靈活的規則匹配，OpenFlow即可采用類型/長度/值（TLV），也可采用偏移量/長度/值（OLV）的匹配方式。從軟件編程角度TLV實現簡單，從硬件設計角度OLV實現簡單。

然而最終選擇TLV還是OLV不僅僅決定規則匹配靈活性、實現復雜度以及與流水線處理模型的匹配能力，還代表是否將網絡體系結構或協議的知識嵌入OpenFlow轉發平面，是OpenFlow協議發展中的重大決策。然而從OpenFlow的Maillist中我們可以發現，由于缺少設備制造商的參與，在規范制訂過程中，對選擇OLV還是TLV的討論十分簡單，只有幾個人參與，最后草草決定支持TLV而放棄OLV。隨著2011年OpenFlow1.2標準的推出，正式宣告OpenFlow無法支持可演進的體系結構基礎設施。

由于OpenFlow標準制訂過程多由網絡應用提供商主導，設備制造商參與相對較少，導致OpenFlow協議標準難以符合設備制造商和網絡運營商的利益。主要表現在：

（1）隨著新版本協議規范的推出，OpenFlow規定的處理模型越來越具體，規則匹配難度越來越大。與現有技術相比，OpenFlow并沒有簡化網絡設備硬件的設計，只在實用性和通用性之間做了折中。例如核心MPLS交換機只要對幾十比特的標簽進行查表，而OpenFlow交換機卻要對幾百比特的規則進行匹配。

（2）OpenFlow破壞端到端的設計原則。傳統互聯網設計哲學認為網絡中交換機和路由器的基本功能是做分組的交換和轉發，是無狀態的。而被認為對網絡體系結構有害的Middlebox設備是有狀態的，因為Middlebox在為互聯網新型服務部署提供平臺的同時，也在影響互聯網端到端的特性。目前研究表明[4]，SDN對提高Middlebox的可管理性具有重要意義，包括實現數據流的按需重定向和負載均衡等。OpenFlow的發展使得網絡路由交換設備（OpenFlow交換機）和Middlebox間的界限變得模糊，例如在OpenFlow郵件列表中使用的典型OpenFlow規則[5]如下：

捕獲從端口1來的報文（可能包含Vlan Tag也可能沒有），目的地址是192.168.1.1的80端口（TCP協議），將該報文的目的IP地址改寫為10.0.0.1，端口號改為8080端口（TCP協議），并把其從端口2發出。

這使得研究人員擔心，隨著OpenFlow技術的應用，OpenFlow的分組處理方式越來越向有狀態的Middlebox靠近，互聯網的端到端原則可能會被進一步破壞。

（3）由于OpenFlow標準制訂過分依賴網絡應用提供商，沒有得到設備制造商和相關芯片設計商的充分支持，因此OpenFlow設備，特別是芯片的研發緩慢。OpenFlow雖然被譽為“網絡的X86指令集”，但目前網絡的基礎設施并不支持OpenFlow，開放網絡基金會也只能成立FAWG工作組，研究如何在傳統網絡設備上支持多流表的OpenFlow。其基本思路是設計一個硬件抽象層（HAL），先支持OpenFlow在傳統硬件上運行，直到能夠支持OpenFlow的網絡設備硬件出現為止。

2 SDN數據面研究

目前關于SDN數據面的研究和反思主要體現在兩個方面：一是如何有效與MPLS結合，利用MPLS在簡化交換規則和多協議支持方面成功的經驗；另一方面是在實現上如何利用飛速發展的多核處理平臺，解決OpenFlow硬件支持不利的問題。

2.1 SDN與MPLS

作為目前SDN主要的數據面抽象，OpenFlow主要面臨規則匹配復雜性等問題，因此可以借鑒MPLS的設計思想。

因為MPLS最初設計主要為在IP中引入了ATM，解決的兩個問題正好是目前OpenFlow發展中遇到的難題，即：（1）提高轉發速度。MPLS只在網絡邊緣分析IP報文頭，而在網絡核心的轉發只需簡單的查找固定長度的標簽表，簡化了處理復雜性。（2）MPLS在無連接網絡中引入連接模式的特性。通過生成標記交換面將選路和轉發分開，因此支持IPv4、IPv6和IPX等多種協議。

隨著專用集成電路芯片（ASIC）技術的發展，路由查找速度已經不是阻礙網絡發展的“瓶頸”。這使得MPLS在提高轉發速度方面不再具備明顯的優勢。但由于MPLS結合了IP網絡三層路由和二層交換的機制，使得其能夠容易地實現IP與ATM、幀中繼等層網絡的無縫融合，并為流量工程（TE）、虛擬專用網（VPN）、服務質量（QoS）等應用提供性能更好的解決方案。

在網絡基礎設施與網絡體系結構分離的思想指導下，網絡基礎設施中的硬件應該簡單，獨立于特定廠商的解決方案并且支持未來新的體系結構（Future-Proof）。文獻[6]指出網絡體系結構設計實際包含3種接口：（1）主機-網絡接口，即主機告訴網絡如何處理其發出的報文，信息主要通過報文頭攜帶，包括目的地址信息，ToS信息等。（2）操作-網絡接口，即網絡管理員向網絡注入策略的接口。（3）報文-交換機接口，即報文告訴交換機如何對其進行交換。傳統網絡沒有區分主機-網絡接口和報文-交換機接口，也沒有專門設計操作-網絡接口，目前SDN實現了獨立的操作-網絡接口，但沒有實現主機-網絡接口和報文-交換機接口分離。MPLS通過網絡邊緣與網絡核心分離，實現了主機-網絡接口和報文-交換機接口的分離，所以在SDN發展中，應該借鑒網絡核心的控制與網絡邊緣的控制解耦的思想，網絡邊緣支持更多的網絡功能，而網絡核心相對簡單。

目前的OpenFlow協議處于十分尷尬的地位，在通用性上無法滿足網絡邊緣的需求，而用在網絡核心則過于復雜。

2.2 SDN與多核平臺

目前網絡技術發展正處在一個轉型的階段，主要特點就是由基于多核平臺的軟件轉發取代由ASIC主導的硬件轉發。多核平臺在近年來發展迅速，基于多核的虛擬機平臺得到廣泛應用。多核平臺Hypervisor實現不同虛擬機之間的數據交換和平臺的IO虛擬化，可作為距端系統最近的第一跳交換機。因此多核是實現主機-網絡接口交換的主要手段，也可以通過軟件編程擴展支持更多的功能。

2012年Intel公司推出Cave Creek平臺和DPDK，對多核平臺上網絡處理的直接內存存取（DMA）、緩沖區管理、隊列管理等性能進行優化，使多核平臺在數據面網絡處理的性能大大提升。

基于上述趨勢，文獻[7]提出未來網絡邊緣功能將由軟件實現，而硬件ASIC主要在網絡核心進行簡單的基于標簽的高速轉發。而實現轉型的使能技術就是逐漸成熟的多核平臺，主要表現在：（1）軟件轉發平臺是穩定的可擴展的，可以支持各種新的轉發操作需求；（2）多核轉發平臺本身的性能在不斷提高；（3）軟件交換已經在目前的網絡中普遍存在，每個虛擬機的Hypervisor實際就是一個軟件交換機。

文獻[7]指出在2012年，軟件交換機的端口數目已經大于硬件交換機的端口數目。因此，在SDN數據面研究時，需要充分考慮多核平臺對數據面實現機制的影響。

3 新的SDN數據面抽象

基于對OpenFlow發展面臨的問題、MPLS成功經驗和多核平臺發展趨勢的分析，我們提出了一種基于標簽（label）的新型SDN數據面抽象——LabelCast。LabelCast的特點是基于標簽的硬件轉發和基于多核平臺的可編程數據平面功能擴展。

3.1 標簽交換原理

受MPLS轉發機制的啟發，我們發現除基于OLV的規則匹配外，使用弱語義定長標簽的匹配也是實現協議無關網絡基礎設施轉發的手段。文獻[1]提出的新型轉發思路為：軟件的轉發決策可以是基于語義分析的，即需要感知協議類型，而硬件轉發可以是無語義的，僅僅根據軟件轉發的決策進行規則匹配即可。基于該思想，LabelCast的轉發硬件只根據報文攜帶的標簽對分組進行轉發。而不關心分組是屬于IPv4、IPv6甚至是未來的其他網絡體系結構的分組。與OpenFlow類似，轉發硬件對標簽表查表不命中的分組送控制器處理。控制器（及其相關軟件）根據分組具體語義決定分組的轉發行為，并將該分組綁定到一個標簽上，與MPLS類似，相同轉發等價類的分組將會綁定到一個標簽，標簽和轉發等價類的綁定通過控制協議傳遞。由于LabelCast的轉發平面并不需要理解報文結構和標簽的含義，因此支持未來新的體系結構。

基于Label的SDN交換的主要步驟如圖1所示：

步驟1：在基礎設施上運行體系結構A（例如IPv6體系結構）的程序，該程序向控制器注冊，注冊提供的內容包括申請標簽空間大小，IPv6分組的特征（如以太網幀類型域中IPv6對應的值）等。

步驟2：基礎設施的控制器根據IPv6程序的要求，向其分配本地IPv6程序的可用的標簽空間。IPv6程序負責該標簽空間標簽的管理，包括分配和回收等。

步驟3：交換機接收到第一個IPv6分組，其中標簽域為空，此時交換機中標簽表只有default表項，如圖1（b）所示。

步驟4：由于該分組的標簽域為空，交換機將該IPv6分組送控制器；控制器根據各種體系結構注冊的分組特征，識別這是一個IPv6的分組，將該分組送IPv6程序處理。

步驟5：IPv6程序根據控制平面行程的轉發規則（IPv6路由協議、配置的轉發策略等），確定該報文的轉發行為和輸出接口。在確定轉發規則時，既可以使用最長前綴匹配、也可以使用OLV和TLV形式的匹配。同時為該流的報文對應分配一個輸入標簽L1。

步驟6：應用程序通過控制器將該標簽及其對應的操作寫入標簽表，如圖1（c）所示。

步驟7：應用程序同時將流與標簽L1的映射關系通知上游節點。

步驟8：該流的第一個報文根據標簽表定義的動作轉發到下一跳，由于輸出標簽為空，因此該報文輸出時不攜帶標簽。

步驟9：應用程序從下游接收到標簽映射關系，即下游要求將該流與標簽L2綁定。

步驟a：應用程序更改標簽表，更改后如圖1（c）所示。

步驟b：從上游接收到該流的第二個報文，該報文已經在頭部插入L1標簽。

步驟c：該報文直接查找標簽表，命中，按照規定的動作處理，最后將標簽替換為輸出標簽L2發出。

LabelCast的交換機制與MPLS的主要區別包括：LabelCast的標簽交換為端到端的處理，而MPLS的標簽交換只在網絡核心實現；LabelCast的標簽分配由SDN的應用（不同體系結構的處理軟件管理）實現，而MPLS由路由器路由系統實現。當然，在標簽分配方面，LabelCast可以完全借鑒MPLS的標簽分配方法，但是否可以直接使用MPLS的LDP協議還有待進一步研究。

3.2 可編程數據平面功能擴展

未來網絡體系結構，如信息中心網絡（ICN），可能要求網絡交換節點支持數據緩存等功能。因此網絡基礎設施的數據平面必須支持可編程的功能擴展。支持數據面可編程功能擴展的實現方法有3種。（1）FPGA，性能高但可編程能力差。（2）網絡處理器，綜合考慮性能和可編程能力，但處理器核支持的數據和程序空間有限，且編程困難。（3）通用多核平臺，可編程性好，支持大的數據和程序空間。

綜合上述分析，我們提出基于通用多核平臺的可編程數據面功能擴展方案，即Cast擴展。

LabelCast和OpenFlow數據面實現方式的對比如圖2所示。OpenFlow只向應用開放復雜的流表，而LabelCast將傳統數據面分解為無狀態的基于Label的快速交換和協議相關的Cast處理，并向應用開放轉發硬件中的label表和多核平臺的計算資源，應用可使用計算資源編寫定義數據面處理行為的Cast程序，實現特定的數據面功能，如數據緩存，DPI、加解密等。當然，如何在數據平面上隔離不同的Cast程序，對每個Cast程序使用的計算、存儲和網絡資源進行有效的計量，是下一步需要研究的問題。

4 結束語

本文對SDN的數據面抽象進行了重新思考，分析了目前OpenFlow協議面臨的問題，通過借鑒MPLS的成功經驗和近年來多核處理平臺在網絡數據面處理應用中取得的進展，提出了一種新的SDN數據面抽象——LabelCast。

LabelCast利用標簽交換機制可以解決復雜規則匹配問題，采用Cast程序擴展機制可以解決轉發面的功能可編程問題。本文的研究工作還是初步的，很多關鍵技術還沒有觸及，我們將在下一步研究中進一步深入分析。

參考文獻

[1] CASADO M， KOPONEN T， MOON D， et al. Rethinking packet forwarding hardware [C]//Proceedings of the 7th ACM Workshop on Hot Topics in Networks （HotNets08）， Oct 6-7， 2008， Calgary， Canada. New York， NY， USA：ACM， 2008：6.

[2] MCKEOWN N， ANDERSON T， BALAKRISHNAN H， et al. OpenFlow： Enabling innovation in campus networks [J]. ACM SIGCOMM Computer Communication Review， 2008， 38（2）：69-74.

[3] RAGHAVAN B， KOPONEN T， GHODSI A， et al. Software-defined Internet architecture： Decoupling architecture from infrastructure [C]//Proceedings of the 11th ACM Workshop on Hot Topics in Networks （HotNets12）， Oct 29-30， 2012， Seattle， WA， USA. New York， NY， USA： ACM， 2012：43-48.

[4] SEKAR V， EGI N， RATNASAMY S， et al. Design and implementation of a consolidated middlebox architecture [C]//Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation （NSDI12）， Apr 25-27， 2012， San Jose， CA， USA. Berkeley， CA， USA： USENIX Association， 2012：24.

[5] OpenFlow-spec：Flexible match， flexible action[EB/OL]. [2013-05-15]. https：//mailman.stanford.edu/pipermail/OpenFlow-spec/2011-April/001715.html.

[6] CASADO M， KOPONEN T， SHENKER S， et al. Fabric： A restrospective on evolving SDN [C]//Proceedings of the 1st workshop on Hot topics in software defined networks （ HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012：85-90.

[7] SHENKER S. Software-defined networking at the crossroads [R]. Berkeley， CA， USA： University of California， Berkeley Colloquium on Computer Systems Seminar Series （EE380）， 2013-05-15.