對(duì)軟件定義網(wǎng)絡(luò)數(shù)據(jù)面抽象的重新思考

中圖分類號(hào)：TN915.03； TP393.03 文獻(xiàn)標(biāo)志碼：A 文章編號(hào)：1009-6868 （2013） 05-0022-004

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

軟件定義網(wǎng)絡(luò)；數(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)過(guò)多年發(fā)展，軟件定義網(wǎng)絡(luò)（SDN）/OpenFlow的研究和標(biāo)準(zhǔn)化進(jìn)入一個(gè)關(guān)鍵階段。

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

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

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

1 OpenFlow發(fā)展面臨的

問(wèn)題

1.1 OpenFlow最初需要解決的問(wèn)題

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

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

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

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

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

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

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

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

由于OpenFlow標(biāo)準(zhǔn)制訂過(guò)程多由網(wǎng)絡(luò)應(yīng)用提供商主導(dǎo)，設(shè)備制造商參與相對(duì)較少，導(dǎo)致OpenFlow協(xié)議標(biāo)準(zhǔn)難以符合設(shè)備制造商和網(wǎng)絡(luò)運(yùn)營(yíng)商的利益。主要表現(xiàn)在：

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

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

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

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

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

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

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

2.1 SDN與MPLS

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

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

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

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

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

2.2 SDN與多核平臺(tái)

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

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

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

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

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

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

3.1 標(biāo)簽交換原理

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

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

步驟1：在基礎(chǔ)設(shè)施上運(yùn)行體系結(jié)構(gòu)A（例如IPv6體系結(jié)構(gòu)）的程序，該程序向控制器注冊(cè)，注冊(cè)提供的內(nèi)容包括申請(qǐng)標(biāo)簽空間大小，IPv6分組的特征（如以太網(wǎng)幀類型域中IPv6對(duì)應(yīng)的值）等。

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

步驟3：交換機(jī)接收到第一個(gè)IPv6分組，其中標(biāo)簽域?yàn)榭?，此時(shí)交換機(jī)中標(biāo)簽表只有default表項(xiàng)，如圖1（b）所示。

步驟4：由于該分組的標(biāo)簽域?yàn)榭眨粨Q機(jī)將該IPv6分組送控制器；控制器根據(jù)各種體系結(jié)構(gòu)注冊(cè)的分組特征，識(shí)別這是一個(gè)IPv6的分組，將該分組送IPv6程序處理。

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

步驟6：應(yīng)用程序通過(guò)控制器將該標(biāo)簽及其對(duì)應(yīng)的操作寫(xiě)入標(biāo)簽表，如圖1（c）所示。

步驟7：應(yīng)用程序同時(shí)將流與標(biāo)簽L1的映射關(guān)系通知上游節(jié)點(diǎn)。

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

步驟9：應(yīng)用程序從下游接收到標(biāo)簽映射關(guān)系，即下游要求將該流與標(biāo)簽L2綁定。

步驟a：應(yīng)用程序更改標(biāo)簽表，更改后如圖1（c）所示。

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

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

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

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

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

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

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

4 結(jié)束語(yǔ)

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

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

參考文獻(xiàn)

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