顧 強(qiáng),張慶順,臧 軍(山東省郵電規(guī)劃設(shè)計院有限公司,山東濟(jì)南250101)
現(xiàn)正在運(yùn)行的互聯(lián)網(wǎng)體系構(gòu)架已經(jīng)有40 多年的歷史,在技術(shù)發(fā)展日新月異的現(xiàn)代社會已經(jīng)可稱得上是一個奇跡。隨著網(wǎng)絡(luò)規(guī)模的急速膨脹和業(yè)務(wù)類型的不斷豐富,數(shù)據(jù)平面和控制平面緊密耦合這一特點成了網(wǎng)絡(luò)發(fā)展的瓶頸,導(dǎo)致網(wǎng)絡(luò)管控難度日益增加,新功能難以快速部署。云計算、云存儲的快速發(fā)展對網(wǎng)絡(luò)可編程控制能力提出了異常迫切的需求,由于現(xiàn)有網(wǎng)絡(luò)設(shè)備多由廠家封閉的系統(tǒng)實現(xiàn),對網(wǎng)絡(luò)可編程控制能力的支持也極為有限。這促使人們開始思考網(wǎng)絡(luò)體系構(gòu)架的變革,可編程網(wǎng)絡(luò)成為網(wǎng)絡(luò)體系構(gòu)架變革的主要方向,特別是軟件定義網(wǎng)絡(luò)(SDN),作為一種全新的網(wǎng)絡(luò)構(gòu)架,將控制平面和數(shù)據(jù)平面分離,大大提高了網(wǎng)絡(luò)管控的靈活性,便于新業(yè)務(wù)的快速部署。
IETF和IRTF等標(biāo)準(zhǔn)化組織在SDN方面已經(jīng)開展了一些卓有成效的工作。近幾年ONF 提出的Open?Flow協(xié)議[1]和以O(shè)penFlow協(xié)議為基礎(chǔ)的SDN[2]引起了學(xué)術(shù)界與產(chǎn)業(yè)界的極大關(guān)注。
本文以SDN 發(fā)展歷程為主線,介紹了SDN 的構(gòu)架、最新進(jìn)展和面臨的挑戰(zhàn)。
20 世紀(jì)60 年代出現(xiàn)的互聯(lián)網(wǎng)迅速獲得了廣泛應(yīng)用,其盡力而為的理念和受限的帶寬一直影響著用戶體驗。90 年代異步傳輸模式(ATM)的廣泛應(yīng)用為互聯(lián)網(wǎng)提供了有保障的連接和相對充裕的帶寬,互聯(lián)網(wǎng)也因此獲得了快速發(fā)展,同時也凸顯了傳統(tǒng)互聯(lián)網(wǎng)封閉網(wǎng)絡(luò)構(gòu)架的局限性,促使學(xué)者對互聯(lián)網(wǎng)構(gòu)架重新審視和思考,提出了控制平面和數(shù)據(jù)平面解耦、可編程網(wǎng)絡(luò)的概念,集中出現(xiàn)了一些可編程網(wǎng)絡(luò)實踐的案例。
2.1.1 Open Signaling
Open Signaling 工作組(OPENSIG)成立于1995年,致力于通信硬件設(shè)備和相應(yīng)的控制軟件分離來促進(jìn)ATM 網(wǎng)、互聯(lián)網(wǎng)、移動網(wǎng)更加開放,更具擴(kuò)展性,可編程[3]。這一想法得到了IETF的支持,在IETF內(nèi)部成立了專門的工作組負(fù)責(zé)通用交換機(jī)管理協(xié)議(GSMP)建議文檔的起草。隨著ATM技術(shù)的落伍,這個工作組被關(guān)閉,最新協(xié)議為2002年6月制定的GSMP V3。
2.1.2 Active Networking
同樣在20 世紀(jì)90 年代中期,Active Networking 這一概念被提出,其首創(chuàng)性地提出網(wǎng)絡(luò)基礎(chǔ)設(shè)施通過可編程來適應(yīng)定制化的業(yè)務(wù)需求[4]。這種網(wǎng)絡(luò)有2個概念引起了大家的注意。
a)用戶可編程的網(wǎng)絡(luò)設(shè)備,設(shè)備配置有帶內(nèi)或者帶外的控制信道。
b)帶有控制信息的數(shù)據(jù)包,數(shù)據(jù)包內(nèi)帶有路由器或交換機(jī)可以執(zhí)行的指令。
這樣用戶就可以通過帶內(nèi)或帶外專門的控制信道來對業(yè)務(wù)經(jīng)過的網(wǎng)絡(luò)設(shè)備編程,以便網(wǎng)絡(luò)更好地適配業(yè)務(wù)。由于安全和性能表現(xiàn)等方面的原因這種網(wǎng)絡(luò)沒能獲得廣泛的應(yīng)用。
2.1.3 DCAN
為加強(qiáng)對ATM 網(wǎng)絡(luò)的管理和增強(qiáng)其擴(kuò)展性,DCAN(Devolved Control of ATM Networks)也在20世紀(jì)90 年代中期應(yīng)運(yùn)而生[5]。其主張ATM 網(wǎng)絡(luò)的管理功能從ATM 設(shè)備中解耦出來,成為獨立的功能實體,DCAN 定義了這2 個功能實體之間的通信協(xié)議。SDN轉(zhuǎn)發(fā)、控制平面分離的理念也來源于此,目前的SDN實現(xiàn)方案仍然通過這種方式實現(xiàn)對ATM 和其他異構(gòu)網(wǎng)絡(luò)的管理和控制。
進(jìn)入21 世紀(jì),隨著千兆以太網(wǎng)技術(shù)的廣泛應(yīng)用,ATM技術(shù)也逐漸沒落,傳統(tǒng)互聯(lián)網(wǎng)的局限性因為新技術(shù)的支撐而被暫時弱化,但是人們對可編程網(wǎng)絡(luò)的研究仍在繼續(xù)。
IETF 在完善現(xiàn)有網(wǎng)絡(luò)體系構(gòu)架理念指導(dǎo)下繼續(xù)進(jìn)行可編程網(wǎng)絡(luò)研究,2003年開始的轉(zhuǎn)發(fā)與控制分離(ForCES)的路由器體系結(jié)構(gòu)[6]研究已經(jīng)完全具備了SDN 的理念;2006 年,IETF 網(wǎng)絡(luò)配置協(xié)議工作組提出了NETCONF[7]協(xié)議,其主要實現(xiàn)對網(wǎng)絡(luò)設(shè)備配置的修改,利用這組協(xié)議,網(wǎng)絡(luò)設(shè)備通過標(biāo)準(zhǔn)的API來接收和發(fā)送設(shè)備配置。NETCONF 協(xié)議也是目前SDN 南向接口協(xié)議之一,最新協(xié)議于2011年6月出版。
寬帶接入和移動通信業(yè)務(wù)需求持續(xù)增長,網(wǎng)絡(luò)創(chuàng)新研究也日趨活躍,人們認(rèn)識到傳統(tǒng)互聯(lián)網(wǎng)的固有問題很難在原有體系下解決,美國國家自然基金會(NSF)在網(wǎng)絡(luò)體系創(chuàng)新理念指導(dǎo)下資助了一些研究,提出了重塑互聯(lián)網(wǎng)的思路,這些研究直接促使基于OpenFlow協(xié)議為基礎(chǔ)的SDN產(chǎn)生。
2.2.1 4D Project
2004 年4D Project 開始實施,倡導(dǎo)重新設(shè)計的理念,強(qiáng)調(diào)把路由決策邏輯與調(diào)節(jié)網(wǎng)元之間交互的協(xié)議分開[8]。其強(qiáng)調(diào)4 個平面:決策平面用于處理網(wǎng)絡(luò)控制;擴(kuò)散平面提供1個連接路由器或交換機(jī)的健壯、高效的通信基礎(chǔ)結(jié)構(gòu);發(fā)現(xiàn)平面用于在網(wǎng)絡(luò)中發(fā)現(xiàn)物理網(wǎng)元并創(chuàng)建邏輯標(biāo)識識別它們;數(shù)據(jù)平面基于決策平面產(chǎn)生的狀態(tài)來處理報文。這一理念直接影響著后續(xù)的一些研究工作,如NOX 所提出的用于OpenFlow網(wǎng)絡(luò)中的網(wǎng)絡(luò)操作系統(tǒng)。
2.2.2 SANE/Ethane
NSF 資助啟動了重塑互聯(lián)網(wǎng)的項目——Clean-Slate Design for Internet,該項目擯棄傳統(tǒng)的漸進(jìn)疊加和向前兼容的原則,重新設(shè)計互聯(lián)網(wǎng)體系構(gòu)架。這一計劃由斯坦福大學(xué)主導(dǎo),研究目的定位于實現(xiàn)控制和轉(zhuǎn)發(fā)分離并加快網(wǎng)絡(luò)創(chuàng)新,一個名為SANE/Ethane 的項目[9-11]成果意義非凡。2006年這個項目定義了一種用于企業(yè)網(wǎng)的新型網(wǎng)絡(luò)構(gòu)架,采用集中式的控制器來管理網(wǎng)絡(luò)中的策略和安全,并對接入的設(shè)備進(jìn)行身份認(rèn)證。就像現(xiàn)在的SDN構(gòu)架,有集中式的控制器來決定如何進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā),有內(nèi)置流表只進(jìn)行數(shù)據(jù)包轉(zhuǎn)發(fā)的交換機(jī),交換機(jī)和控制器之間通過安全通道連接。這一項目被認(rèn)為是目前基于OpenFlow 協(xié)議SDN的直接原型。
經(jīng)過多年持續(xù)不斷的研究,SDN 取得了巨大進(jìn)展,作為一種全新的網(wǎng)絡(luò)構(gòu)架,其具備2 個特點:把執(zhí)行轉(zhuǎn)發(fā)的硬件部分從控制決策部分中分離出來,成為只完成數(shù)據(jù)包轉(zhuǎn)發(fā)的數(shù)據(jù)平面,控制決策部分成為獨立的控制平面;控制平面和數(shù)據(jù)平面之間通過開放的接口進(jìn)行編程控制[12]。控制平面和數(shù)據(jù)平面分離大大提高了網(wǎng)絡(luò)管控的靈活性,便于新業(yè)務(wù)的快速部署。傳統(tǒng)互聯(lián)網(wǎng)和SDN構(gòu)架的區(qū)別如圖1所示。
圖1 傳統(tǒng)互聯(lián)網(wǎng)和SDN構(gòu)架對比
目前體系構(gòu)架比較完整的是IETF 提出的ForCES路由器體系結(jié)構(gòu)和ONF 提出的以O(shè)penFlow 協(xié)議為基礎(chǔ)的體系結(jié)構(gòu),下面對2 種比較有代表性的SDN 進(jìn)行簡略介紹和比較。
ForCES 的路由器體系結(jié)構(gòu)由IETF 提出及標(biāo)準(zhǔn)化,網(wǎng)絡(luò)設(shè)備內(nèi)部分為控制單元(CE)和數(shù)據(jù)轉(zhuǎn)發(fā)單元(FE),CE 和FE 通過ForCES 協(xié)議進(jìn)行通信。在FE 中定義了邏輯功能模塊(LFB),LFB 及其屬性都是由CE通過ForCES協(xié)議進(jìn)行控制,各LFB之間通過數(shù)據(jù)通道相互連接,該連接關(guān)系也由CE通過ForCES協(xié)議定義,以形成不同的LFB 拓?fù)浣Y(jié)構(gòu),進(jìn)而實現(xiàn)資源動態(tài)配置,完成各種不同類型的網(wǎng)絡(luò)服務(wù)[13]。這個體系便于現(xiàn)有的控制平面能對新加入的第三方數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備進(jìn)行控制,實現(xiàn)現(xiàn)有網(wǎng)絡(luò)對沒有控制平面的數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備的兼容。雖然控制功能和數(shù)據(jù)轉(zhuǎn)發(fā)功能是分開的,但是仍然緊密耦合在同一個設(shè)備實體中。
從2003 年開始有關(guān)ForCES 體系結(jié)構(gòu)標(biāo)準(zhǔn)化的文檔陸續(xù)發(fā)布,主要包括:ForCES需求(RFC3654)、ForC?ES 框架(RFC3746)、ForCES 協(xié)議及擴(kuò)展(RFC5810、RFC791)、ForCES 模型及擴(kuò)展(RFC5812、RFC7408)、ForCES適用性聲明(RFC6041)、ForCES邏輯功能模塊庫(RFC6956)[13]。目前ForCES 工作組仍然在對ForC?ES體系結(jié)構(gòu)相關(guān)標(biāo)準(zhǔn)進(jìn)行研究。
ONF提出的SDN構(gòu)架如圖2所示。所有業(yè)務(wù)邏輯均部署在應(yīng)用平面,并通過開放的API 與控制平面相連;控制平面由集中設(shè)置的軟件控制器組成;數(shù)據(jù)平面由數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備組成;為保證網(wǎng)絡(luò)的擴(kuò)展性,南向接口除OpenFlow協(xié)議外也提供了對其他協(xié)議的支持。
圖2 ONF提出的SDN構(gòu)架
OpenFlow 協(xié)議作為目前成熟度最高的南向接口協(xié)議得到了產(chǎn)業(yè)界廣泛支持。OpenFlow 交換機(jī)規(guī)范明確定義了交換機(jī)組成和OpenFlow 協(xié)議在交換機(jī)中的實現(xiàn)方式。OpenFlow 規(guī)范中定義的交換機(jī)結(jié)構(gòu)如圖3 所示。OpenFlow 交換機(jī)內(nèi)包含1 個或多個流表(Flow Table)和1 個組表(Group Table),以及與Open?Flow 控制器進(jìn)行通信的安全通道接口。為避免單流表過度膨脹,在OpenFlow 協(xié)議1.1 以后的版本引入了多級流表機(jī)制。
圖3 OpenFlow交換機(jī)結(jié)構(gòu)圖
OpenFlow 協(xié)議1.0[14]、1.1[15]、1.2[16]版本中每個流表項包含匹配域、計數(shù)器及1組指令,每個數(shù)據(jù)包包頭的信息與匹配字段匹配,如果匹配則執(zhí)行這個流表后面定義的指令。如果這個交換機(jī)里所有流表均不能匹配,則把這個數(shù)據(jù)包的包頭或整個數(shù)據(jù)包通過安全通道上交給OpenFlow 控制器,由OpenFlow 控制器決定這個數(shù)據(jù)包如何轉(zhuǎn)發(fā),并生成流表通過安全通道下發(fā)到相應(yīng)OpenFlow交換機(jī),OpenFlow交換機(jī)就可以正確轉(zhuǎn)發(fā)這個數(shù)據(jù)包了。計數(shù)器對經(jīng)過交換機(jī)的數(shù)據(jù)包進(jìn)行分類計數(shù),以滿足各種統(tǒng)計管理。在OpenFlow協(xié)議1.3[17]、1.4[18]版本中流表又增設(shè)了優(yōu)先級、超時設(shè)定、保留字段等參數(shù)。OpenFlow 協(xié)議流表結(jié)構(gòu)如表1所示。
在OpenFlow協(xié)議1.0版本中流表匹配域共包含12個字段:輸入端口、MAC 源地址、MAC 目的地址、以太網(wǎng)類型、VLANID、VLAN 優(yōu)先級、IP 源地址、IP 目的地址、IP、IP ToS 位,TCP/UDP 源端口和TCP/UDP 目標(biāo)端口。OpenFlow協(xié)議1.1版本中增加了對VLAN和MPLS標(biāo)簽的處理。OpenFlow協(xié)議1.2版本中規(guī)定下發(fā)流表的匹配字段不再通過固定長度的結(jié)構(gòu)來定義,而是采用TLV(Type、Length、Value)結(jié)構(gòu)定義,稱為OpenFlow擴(kuò)展匹配(OXM),這樣在增加更多關(guān)鍵字匹配字段的同時也節(jié)省了流表空間。OpenFlow協(xié)議1.3版本中流表支持的匹配字段已經(jīng)增加到40 個。這樣就可以跨越物理層、介質(zhì)層、網(wǎng)絡(luò)層、應(yīng)用層4 個層級對字段進(jìn)行匹配,每個字段都可以通配,字段之間可以任意組合,數(shù)據(jù)報文以流為基礎(chǔ)進(jìn)行匹配轉(zhuǎn)發(fā),而不是像傳統(tǒng)互聯(lián)網(wǎng)以數(shù)據(jù)包為基礎(chǔ)進(jìn)行匹配轉(zhuǎn)發(fā),大大提高了轉(zhuǎn)發(fā)效率,而且更加靈活。
表1 OpenFlow協(xié)議流表結(jié)構(gòu)
OpenFlow 控制器利用OpenFlow 標(biāo)準(zhǔn)通過安全通道對OpenFlow交換機(jī)內(nèi)的流表進(jìn)行添加、修改、刪除、查詢等操作,最終完成各種網(wǎng)絡(luò)行為。
以上2 種體系結(jié)構(gòu)都遵循了SDN 基本的原則:控制平面和數(shù)據(jù)平面相分離;控制平面與數(shù)據(jù)平面之間通過開放的接口和標(biāo)準(zhǔn)的協(xié)議進(jìn)行交互。雖然2種網(wǎng)絡(luò)的目標(biāo)是一致的,而且實現(xiàn)的功能也比較相似,但是兩者之間在應(yīng)用場景、控制平面和數(shù)據(jù)平面內(nèi)部結(jié)構(gòu)、接口協(xié)議、轉(zhuǎn)發(fā)模型等方面存在很大差異。
以ForCES 為基礎(chǔ)的體系結(jié)構(gòu)得益于傳統(tǒng)網(wǎng)絡(luò)設(shè)備制造商的支持,標(biāo)準(zhǔn)化工作起步較早,目前已經(jīng)具備了較為完善的標(biāo)準(zhǔn)體系,其目的是兼容新的網(wǎng)絡(luò)構(gòu)架,對現(xiàn)有網(wǎng)絡(luò)的影響短期難以顯現(xiàn)。以O(shè)penFlow協(xié)議為基礎(chǔ)的體系結(jié)構(gòu)是一種嶄新的構(gòu)架,激發(fā)了研究機(jī)構(gòu)、新興網(wǎng)絡(luò)設(shè)備制造商的濃厚興趣,2009 年發(fā)布的可用于商業(yè)化產(chǎn)品的OpenFlow協(xié)議1.0版本至今已經(jīng)取得了令人矚目的成果,在網(wǎng)絡(luò)實驗測試平臺、校園網(wǎng)、數(shù)據(jù)中心、流量工程、無線接入網(wǎng)絡(luò)、光網(wǎng)絡(luò)等場景均有優(yōu)異表現(xiàn),以至于很多人把以O(shè)penFlow協(xié)議為基礎(chǔ)的體系結(jié)構(gòu)認(rèn)為是SDN的事實標(biāo)準(zhǔn)。
OpenFlow 協(xié)議的出現(xiàn)和發(fā)展帶動SDN 研究進(jìn)入新的階段,但在諸多方面仍面臨巨大挑戰(zhàn)。
近幾年業(yè)界對SDN表現(xiàn)出極大熱情,綜合來看其發(fā)展仍然在完善標(biāo)準(zhǔn)制定、典型應(yīng)用開發(fā)測試階段,以O(shè)penFlow 協(xié)議為基礎(chǔ)的SDN 如何在完善自有協(xié)議體系的基礎(chǔ)上兼容傳統(tǒng)互聯(lián)網(wǎng)仍是一個難題[19]。
盡管支持OpenFlow 協(xié)議的ASIC 芯片設(shè)計廣受關(guān)注,但是目前仍然沒有一款專用芯片出現(xiàn)。一方面是SDN 的技術(shù)標(biāo)準(zhǔn)尚未成熟,另一方面是芯片生產(chǎn)廠商并不完全認(rèn)可學(xué)術(shù)界對支持OpenFlow 協(xié)議ASIC芯片的設(shè)計。這些原因都決定了芯片生產(chǎn)廠家暫時不會對SDN 專用芯片的開發(fā)投入太多,而是采取折中方案,在傳統(tǒng)芯片的基礎(chǔ)上增加支持SDN 的功能[20-21]。這就造成目前OpenFlow交換機(jī)流表容量、流表學(xué)習(xí)速度、流表轉(zhuǎn)發(fā)速率、轉(zhuǎn)發(fā)時延等關(guān)鍵指標(biāo)總體表現(xiàn)不佳,不同廠商的設(shè)備差異極大,難以達(dá)到商用標(biāo)準(zhǔn)。
人們把SDN中的數(shù)據(jù)平面、控制平面和應(yīng)用平面分別類比成計算機(jī)中的硬件平臺、操作系統(tǒng)和應(yīng)用軟件。操作系統(tǒng)的重要性不言而喻,SDN 控制平面作為網(wǎng)絡(luò)操作系統(tǒng)面臨著可擴(kuò)展性、處理能力和安全性等方面的挑戰(zhàn)[20,22]。作為控制器之間交互的東西向接口標(biāo)準(zhǔn)仍在研究制定過程中,只有東西向的接口標(biāo)準(zhǔn)成熟后才能使SDN從數(shù)據(jù)中心、企業(yè)校園網(wǎng)等有限場景應(yīng)用走向全網(wǎng)普遍應(yīng)用;連接應(yīng)用平面的北向接口仍然沒有形成廣泛認(rèn)可的標(biāo)準(zhǔn),業(yè)界雖然希望以REST?ful作為北向接口,采用模型、模板的方式,通過每個廠商公布自己的模型,實現(xiàn)互通和控制[19],但是這種思路必須在規(guī)模應(yīng)用測試后才能明朗。
SDN 研究進(jìn)展得如火如荼,得到網(wǎng)絡(luò)設(shè)備生產(chǎn)商、網(wǎng)絡(luò)運(yùn)營商以及互聯(lián)網(wǎng)服務(wù)商的廣泛關(guān)注,這將改變網(wǎng)絡(luò)設(shè)備廠商的競爭格局,導(dǎo)致整個網(wǎng)絡(luò)設(shè)備產(chǎn)業(yè)的變革。目前SDN相關(guān)技術(shù)還不夠成熟,不同利益集團(tuán)仍在博弈,但可以預(yù)見的是,以往那種封閉的技術(shù)路線肯定會改變,網(wǎng)絡(luò)系統(tǒng)構(gòu)架肯定會變得更加靈活,以便能夠支持日益豐富的網(wǎng)絡(luò)應(yīng)用。
[1] OpenFlow[EB/OL].[2015-06-12]. https://www.opennetworking.org/sdn-resources/openflow.
[2] ONF White Paper Software-Defined Networking:The New Norm for Networks[EB/OL].[2015-06-12]. https://www.opennetworking.org/component/content/article/46- sdn- resources/sdn- library/whitepa?pers/816-software-defined-networking-the-new-norm-for-net?works.
[3] A.T.Campbell,I.Katzela,K.Miki,et al. Open signaling for atm,inter?net and mobile networks(opensig’98)[J].ACM SIGCOMM Comput?er Commun.Review,1999,29(1):97-108.
[4] D.L.Tennenhouse,J.M.Smith,W.D.Sincoskie,et al. A survey of ac?tive network research[J].IEEE Commun.Mag.,1997,35(1):80-86.
[5] Devolved Control of ATM Networks[EB/OL].[2015-06-12].http://www.cl.cam.ac.uk/research/srg/netos/old-projects/dcan/#pub.
[6] RFC 5810 Forwarding and Control Element Separation(ForCES)Pro?tocol Specification[S/OL].[2015-06-12]. http://tools.ietf.org/htm l/rfc5810.
[7] A.Greenberg,G.Hjalmtysson,D.A.Maltz,et al. A clean slate 4d ap?proach to network control and management[J]. ACM SIGCOMM Computer Commun.Review,2005,35(5):41-54.
[8] RFC 4741 NETCONF Configuration Protocol[S/OL].[2015-06-12].http://tools.ietf.org/html/rfc4741.
[9] M.Casado,M. J.Freedman,J. Pettit,et al. Ethane:Taking control of the enterprise[J]. ACM SIGCOMM Computer Commun.Review,2007,37(4):1-12.
[10]黃韜,劉江,魏亮,等. 軟件定義網(wǎng)絡(luò)核心原理與應(yīng)用實踐[M].北京:人民郵電出版社,2014.
[11]Azodolmolky,Siamak.軟件定義網(wǎng)絡(luò)——基于Openflow 的技術(shù)揭秘[M]. 徐磊,譯.北京:機(jī)械工業(yè)出版社,2014.
[12]Nunes,Bruno,Manoel Mendonca,et al.A survey of software-defined networking:Past,present,and future of programmable networks[J].Communications Surveys & Tutorials,IEEE 16,2014(3):1617-1634.
[13]RFC 6956 Forwarding and Control Element Separation(ForCES)Log?ical Function Block(LFB)Library. June 2013[S/OL].[2015-06-12].http://www.ietf.org/rfc.htm l.
[14]OpenFlow Switch Speci_cationVersion 1.0.0(Wire Protocol 0x01)De?cember 31,2009[S/OL].[2015-06-12].http://archive.openflow.org/documents/openflow-spec-v1.0.0.pdf.
[15]OpenFlow Switch Speci_cationVersion 1.1.0 Implemented(Wire Pro?tocol 0x02)February 28,2011[S/OL].[2015-06-12].http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf.
[16]OpenFlow Switch SpecificationVersion 1.2(Wire Protocol 0x03)De?cember 5,2011[S/OL].[2015-06-12]. http://archive.openflow.org/documents/openflow-spec-v1.2.pdf.
[17]OpenFlow Switch SpecificationVersion 1.3.4(Protocol version 0x04)March 27,2014[S/OL].[2015-06-12].http://archive.openflow.org/documents/openflow-spec-v1.3.4.pdf.
[18]OpenFlow Switch SpecificationVersion 1.4.0(Wire Protocol 0x05)Oc?tober 14,2013[S/OL].[2015-06-12]. http://archive.openflow.org/documents/openflow-spec-v1.4.0.pdf.
[19]趙慧玲,史凡. SDN/NFV 的發(fā)展與挑戰(zhàn)[J]. 電信科學(xué),2014,30(8):13-18.
[20]Kreutz,Diego,F(xiàn)ernando MV Ramos,et al.Software-defined network?ing:A comprehensive survey[J]. proceedings of the IEEE 103,2015(1):14-76.
[21]宋菲,侯樂青. SDN 技術(shù)挑戰(zhàn)及發(fā)展趨勢[J]. 信息通信技術(shù),2015(2).
[22]Sezer,Sakir,Sandra Scott-Hayward,et al.Are we ready for SDN?Im?plementation challenges for software-defined networks[J].Communi?cations Magazine,IEEE 51,2013(7):36-43.