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

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

軟件定義網(wǎng)絡；數(shù)據(jù)面；抽象

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

經(jīng)過多年發(fā)展，軟件定義網(wǎng)絡（SDN）/OpenFlow的研究和標準化進入一個關鍵階段。

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

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

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

1 OpenFlow發(fā)展面臨的

問題

1.1 OpenFlow最初需要解決的問題

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

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

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

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

1.2 OpenFlow現(xiàn)在面臨的問題

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

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

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

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

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

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

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

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

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

2 SDN數(shù)據(jù)面研究

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

2.1 SDN與MPLS

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

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

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

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

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

2.2 SDN與多核平臺

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

2012年Intel公司推出Cave Creek平臺和DPDK，對多核平臺上網(wǎng)絡處理的直接內(nèi)存存取（DMA）、緩沖區(qū)管理、隊列管理等性能進行優(yōu)化，使多核平臺在數(shù)據(jù)面網(wǎng)絡處理的性能大大提升。

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

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

3 新的SDN數(shù)據(jù)面抽象

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

3.1 標簽交換原理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 可編程數(shù)據(jù)平面功能擴展

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

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

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

4 結束語

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

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

參考文獻

[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.