SDN關鍵技術綜述

1、SDN關鍵技術及趨勢摘 要：隨著信息通信技術中大量新型業(yè)務(如移動互聯(lián)網(wǎng)、社交網(wǎng)絡、云計算和大數(shù)據(jù))的出現(xiàn)，未來網(wǎng)正面臨著新的挑戰(zhàn),而隨時訪問性,高帶寬,動態(tài)管理是至關重要的。然而,基于專有設備手動配置的傳統(tǒng)方法是繁瑣且易出錯的,而且他們不能充分利用網(wǎng)絡基礎設施的能力。最近,軟件定義網(wǎng)絡(SDN)已經(jīng)被稱為未來互聯(lián)網(wǎng)最有前途的解決方案之一。SDN具有兩個顯著的特點,包括控制平面從數(shù)據(jù)平面中解耦并且為網(wǎng)絡應用程序開發(fā)提供了可編程性。因此,SDN被認為能提供更有效的配置,更好的性能和更高的靈活性以適應創(chuàng)新的網(wǎng)絡設計。本文總結了SDN活躍研究領域的最新進展。我們首先通過介紹SDN的起源提出一個普遍接

2、受的SDN定義。然后我們簡要的介紹了SDN邏輯架構及其技術特征。接著詳細介紹了SDN關鍵技術及其相關領域的研究成果。最后我們描述了我們將來面臨的挑戰(zhàn)和SDN的發(fā)展趨勢。 關鍵詞：軟件定義網(wǎng)絡； OpenFlow；關鍵技術；Key technologies and Development of SDNAbstract: Emerging mega-trends (e.g., mobile, social, cloud, and big data) in information and communication technologies (ICT) are commanding new chal

3、lenges to future Internet, for which ubiquitous accessibility, high bandwidth, and dynamic management are crucial. However, traditional approaches based on manual configuration of proprietary devices are cumbersome and error-prone, and they cannot fully utilize the capability of physical network inf

4、rastructure. Recently, software-defined networking (SDN) has been touted as one of the most promising solutions for future Internet. SDN is characterized by its two distinguished features, including decoupling the control plane from the data plane and providing programmability for network applicatio

5、n development. As a result, SDN is positioned to provide more efficient configuration, better performance, and higher flexibility to accommodate innovative network designs. This paper surveys latest developments in this active research area of SDN. We first present a generally accepted definition fo

6、r SDN with introducing the origin of SDN. We then briefly present its logical architecture and technical characteristics. We then dwell on its key technologies, and the related research results. Finally, we describe the challenges we face and discuss future research directions of this technology.Key

7、 words: Software-defined networking, OpenFlow. Key technologies9引言隨著社交網(wǎng)絡、移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)、云計算1等業(yè)務領域的快速發(fā)展，大數(shù)據(jù)34正日益成為當前的焦點，其面向的海量數(shù)據(jù)處理也對網(wǎng)絡提出了更高的要求。大數(shù)據(jù)應用依賴于預先定義好的計算模式，在集中化的管理架構下運行，存在著大量的數(shù)據(jù)批量傳輸及相關的聚合/劃分操作。數(shù)據(jù)的聚 合和劃分通常發(fā)生在一臺服務器和一個擁有眾多服務器的服務器組之間，這也是大數(shù)據(jù)應用中最典型的網(wǎng)絡流量模式。例如，在用于大數(shù)據(jù)處理的MapReduce算法的執(zhí)行過程2中，來自眾多mapper服務器的中間結果需

8、要集中匯總到一臺reducer服務器上進行歸約（Reduce）操作，而MapReduce的洗牌（Shuffle）過程更是由mapper和reducer之前的多次數(shù)據(jù)聚合組合而成。大數(shù)據(jù)處理過程中的每一次聚合都將導致大量服務器之間的海量數(shù)據(jù)交換，從而需要極高的網(wǎng)絡帶寬支持，而如果按照超額認購（oversubscribe）帶寬的方式為每臺服務器預留網(wǎng)絡資源，將導致網(wǎng)絡成為瓶頸，同時造成資源浪費。因此，對于大數(shù)據(jù)業(yè)務而言，他更需要對網(wǎng)絡進行快速、頻繁的實時配置，按需調(diào)用網(wǎng)絡資源。但是，傳統(tǒng)的網(wǎng)絡卻難以滿足云計算、大數(shù)據(jù)，以及相關業(yè)務提出的靈活的資源需求，這主要是因為它已經(jīng)過于復雜從而只能處于靜態(tài)的運

9、作模式。當前，網(wǎng)絡中存在著大量各種各樣的互不相干的協(xié)議，它們被用于在不同間隔距離、不同鏈路速度、不同拓撲結構的網(wǎng)絡主機之間建立網(wǎng)絡連接。因為歷史原因，這些協(xié)議的研發(fā)和應用通常是彼此分離的，每個協(xié)議通常只是為了解決某個專門的問題而缺少對共性的抽象，這就導致了當前網(wǎng)絡的復雜性。正是因為上述的復雜性，傳統(tǒng)網(wǎng)絡通常都是維持在相對靜態(tài)的狀態(tài)，網(wǎng)絡管理員通常都要盡可能地減少網(wǎng)絡的變動以避免服務中斷的風險。正是在這一背景下，業(yè)內(nèi)形成了“現(xiàn)在是創(chuàng)新思考互聯(lián)網(wǎng)基本體系結構、采用新的設計理念的時候”的主流意見3，并對未來網(wǎng)絡的體系架構提出了新的性質(zhì)和功能需求4。軟件定義網(wǎng)絡5(Software-Defined N

10、etworking，SDN)的出現(xiàn)為人們提供了一種嶄新的思路。本文從SDN起源和概念出發(fā)，分析了SDN的邏輯架構與關鍵技術，在此基礎上提出了SDN技術在未來的發(fā)展中面臨的挑戰(zhàn)并總結了可能的研究方向。1SDN起源與概念1.1 SDN起源SDN起源于斯坦福6大學啟動的名為Clean Slate Design for the Internet項目。Clean Slate項目的最終目的是要重新發(fā)明英特網(wǎng)，旨在改變設計已略顯不合時宜，且難以進化發(fā)展的現(xiàn)有網(wǎng)絡基礎架構。在2006年，斯坦福的學生Martin Casado領導了一個關于網(wǎng)絡安全與管理的項目Ethane7，該項目試圖通過一個集中式的控制器，讓

11、網(wǎng)絡管理員可以方便地定義基于網(wǎng)絡流的安全控制策略，并將這些安全策略應用到各種網(wǎng)絡設備中，從而實現(xiàn)對整個網(wǎng)絡通訊的安全控制。受此項目(及Ethane的前續(xù)項目Sane)啟發(fā)，Martin和他的導師Nick McKeown教授(時任Clean Slate項目的Faculty Director)發(fā)現(xiàn)，如果將Ethane的設計更一般化，將傳統(tǒng)網(wǎng)絡設備的數(shù)據(jù)轉發(fā)(data plane)和路由控制(control plane)兩個功能模塊相分離，通過集中式的控制器(Controller)以標準化的接口對各種網(wǎng)絡設備進行管理和配置，那么這將為網(wǎng)絡資源的設計、管理和使用提供更多的可能性，從而更容易推動網(wǎng)絡的革

12、新與發(fā)展。于是，他們便提出了OpenFlow的概念，并且Nick McKeown等人于2008年在ACM SIGCOMM發(fā)表文獻8，首次詳細地介紹了OpenFlow的概念。該篇論文除了闡述OpenFlow的工作原理外，還列舉了OpenFlow幾大應用場景，其核心思想是將傳統(tǒng)網(wǎng)絡設備的數(shù)據(jù)轉發(fā)（Data Plane）面和路由控制（Control Plane）面相分離，通過集中控制器（controller）以標準化接口對各種網(wǎng)絡設備進行配置管理。這種網(wǎng)絡架構為網(wǎng)絡資源的設計、管理和使用提供了更多的可能性，從而更容易推動網(wǎng)絡的革新與發(fā)展。由于OpenFLow 開放了網(wǎng)絡編程能力，因此 Ethane

13、被認為是 SDN技術8的起源。1.2 概念SDN的產(chǎn)生與OpenFlow協(xié)議密切相關?，F(xiàn)在業(yè)界普遍將基于OpenFlow協(xié)議的SDN視為狹義SDN。這一概念也是業(yè)界的默認概念。隨著SDN的發(fā)展，越來越多的廠商加入SDN的研究行列。由于不同行業(yè)、不同應用對SDN有著各自不同的需求，出現(xiàn)了許多各具特征的SDN定義9-13。在網(wǎng)絡科研領域，利用SDN快速地部署和試驗創(chuàng)新的網(wǎng)絡架構與通信協(xié)議；大型互聯(lián)網(wǎng)公司希望SDN提供掌握網(wǎng)絡深層信息的可編程接口以優(yōu)化和提升業(yè)務體驗；云服務提供商希望SDN提供網(wǎng)絡虛擬化和自動配置，以適應其擴展性和多租戶需求；ISP希望利用SDN簡化網(wǎng)絡管理以及實現(xiàn)快速靈活的業(yè)務提供

14、；企業(yè)網(wǎng)用戶希望SDN實現(xiàn)私有云的自動配置和降低設備采購成本?；谶@些需求，在思科等廠商的推動下，IETF、IEEE等標準組織去除了SDN OpenFlow的必然聯(lián)系，保留了可編程特性，從而擴展出SDN的廣義概念。即泛指基于開放接口實現(xiàn)軟件可編程的各種基礎網(wǎng)絡架構，進而將具備控制轉發(fā)分離、邏輯集中控制、開放API 3個基本特征的網(wǎng)絡納入SDN的廣義概念中。2. SDN邏輯架構及技術特點2.1 SDN邏輯架構開放網(wǎng)絡基金會（ONF）14是一家非營利的組織機構，成立于2011年。OFN致力于SDN的發(fā)展和標準化，是當前業(yè)界最活躍、規(guī)模最大的SDN標準組織。ONF提出的SDN架構如圖1所示。圖1 S

15、DN 的邏輯架構圖 1 為 SDN 的邏輯架構14。該邏輯架構分為3層?；A設施層（Infrastructure Layer）主要由網(wǎng)絡設備（Network Device）即支持0penFlow協(xié)議的SDN交換機組成，它們是保留了傳統(tǒng)網(wǎng)絡設備數(shù)據(jù)面能力的硬件，負責基于流表的數(shù)據(jù)處理、轉發(fā)和網(wǎng)絡狀態(tài)收集?？刂茖樱–ontrol Layer）主要包含0penFlow控制器及網(wǎng)絡操作系統(tǒng)(network operation system，NOS)，負責處理數(shù)據(jù)平面資源的編排、維護網(wǎng)絡拓撲、狀態(tài)信息等；控制器是一個平臺，該平臺向下可以直接與使用OpenFlow協(xié)議的交換機(以下簡稱SDN交換機)進行會

16、話；向上，為應用層軟件提供開放接口，用于應用程序檢測網(wǎng)絡狀態(tài)、下發(fā)控制策略。位于頂層的應用層（Application Layer）由眾多滿足用戶需求的應用軟件構成，這些軟件能夠根據(jù)控制器提供的網(wǎng)絡信息執(zhí)行特定控制算法，并將結果通過控制器轉化為流量控制命令，下發(fā)到基礎設施層的實際設備中。從而完成動態(tài)接入控制、無縫切換、負載均衡和網(wǎng)絡虛擬化等功能。SDN 網(wǎng)絡控制器與網(wǎng)絡設備之間通過專門的控制面和數(shù)據(jù)面接口連接，該接口是支持 SDN 技術實現(xiàn)的關鍵接口。目前，SDN 的研究重點之一是對該接口的定義和規(guī)范，很多研究將該接口等同于現(xiàn)有網(wǎng)絡中用于管理不同廠商設備的南向接口（Southbound Inte

17、rface），但重新定義了其需要承擔的功能，如網(wǎng)絡編程、資源虛擬化、網(wǎng)絡隔離等；同時，在應用層與網(wǎng)絡基礎設施層之間定義了類似于傳統(tǒng)網(wǎng)絡設備上用于設備制造商或網(wǎng)絡運營商進行設備接入和管理的北向接口（North-bound Interface），并明確了該接口在路由、網(wǎng)絡設備管理、網(wǎng)絡策略管理等方面的能力要求。此外，為支持不同的網(wǎng)絡控制系統(tǒng)之間的互通，有研究還定義了支持網(wǎng)絡控制系統(tǒng)之間互聯(lián)的東西向接口（East-west Interface）和其在支持網(wǎng)絡域間控制、互操作、網(wǎng)絡部署等方面的功能需求1516。根據(jù)上述論述，OpenFlow協(xié)議、網(wǎng)絡虛擬化技術和網(wǎng)絡操作系統(tǒng)是SDN區(qū)別于傳統(tǒng)網(wǎng)絡架構的

18、關鍵技術。2.2 技術特點SDN 的出現(xiàn)打破了傳統(tǒng)網(wǎng)絡設備制造商獨立而封閉的控制面結構體系，將改變網(wǎng)絡設備形態(tài)和網(wǎng)絡運營商的工作模式，對網(wǎng)絡的應用和發(fā)展將產(chǎn)生直接影響。從技術層面分析，SDN的特點主要體現(xiàn)在以下幾個方面17：Ø 數(shù)據(jù)面與控制面的分離，簡化了網(wǎng)絡設備，通過控制面功能的集中和規(guī)范數(shù)據(jù)面和控制面之間的接口，實現(xiàn)對不同廠商的設備進行統(tǒng)一、靈活、高效的 管理和維護。Ø 開放網(wǎng)絡編程能力，以API 的形式將底層網(wǎng)絡能力提供給上層，實現(xiàn)對網(wǎng)絡的靈活配置和多類型業(yè)務的支持，提高對網(wǎng)絡和資源控制的精細化程度。 Ø 支持業(yè)務的快速部署，簡化業(yè)務配置流程，具有靈活的網(wǎng)絡

19、擴展能力，降低設備配置風險，提高網(wǎng)絡運營效率。Ø 更好地支持用戶個性化定制業(yè)務的實現(xiàn)，為網(wǎng)絡運營商提供便捷的業(yè)務創(chuàng)新平臺。Ø 實現(xiàn)網(wǎng)絡的虛擬化，將傳輸、計算、存儲等能力融合，在集中式控制的網(wǎng)絡環(huán)境下，有效調(diào)配網(wǎng)絡資源支持業(yè)務目標的實現(xiàn)和用戶需求，提供更高的網(wǎng)絡效率和良好的用戶體驗。3. SDN關鍵技術3.1 OpenFlowOpenFlow標準的名稱是OpenFlow Switch Specification，因此它本身是一份設備規(guī)范，其中規(guī)定了作為SDN基礎設施層轉發(fā)設備的OpenFlow交換機的基本組件和功能要求，以及用于遠程控制器對交換機進行控制的OpenFlow協(xié)議

20、。本文主要以OpenFlow v1.0 為主介紹OpenFlow協(xié)議的基本架構，OpenFlow協(xié)議搭建SDN的設計思想和整體架構如圖2所示。圖2 OpenFlow交換機的設計思想和整體架構如圖2所示，OpenFlow交換機利用基于安全連接的OpenFlow協(xié)議與遠程控制器相通信18。其中，流表（Flow Table）是OpenFlow交換機的關鍵組件，負責數(shù)據(jù)包的告訴查詢和轉發(fā)。另外，OpenFlow交換機還需要通過一個安全通道與外部的控制器進行通信，這個安全通道上傳輸?shù)氖荗penFlow協(xié)議，它將負責傳遞控制器和交換機之間的管理和控制信息。因此，流表、安全通道、及OpenFlow協(xié)議是Op

21、enFlow v1.0的核心部分。3.1.1 流表所謂流表，其實可被視為是OpenFlow對網(wǎng)絡設備的數(shù)據(jù)轉發(fā)功能的一種抽象。在傳統(tǒng)網(wǎng)絡設備中，交換機和路由器的數(shù)據(jù)轉發(fā)需要依賴設備中保存的二層MAC地址或者三層IP地址路由表，而OpenFlow交換機中使用的流表也是如此，不過在它的表項中整合了網(wǎng)絡中各個層次的網(wǎng)絡配置信息，從而在進行數(shù)據(jù)轉發(fā)時可以使用更豐富的規(guī)則。OpenFlow流表的每個表項由3部分組成：用于數(shù)據(jù)包匹配的包頭域（Header Fields），用于統(tǒng)計匹配數(shù)據(jù)包個數(shù)的計數(shù)器（Counters），用于展示匹配的數(shù)據(jù)包如何處理的動作（Actions）。隨著OpenFlow的演進，匹

22、配域的覆蓋范圍越來越廣，以滿足更靈活的轉發(fā)策略。隨著版本的升級，匹配域的數(shù)量不斷增加，應用方式也進行了調(diào)整。其相應變化如表1所示。表1 OpenFlow流表匹配域的變化示意規(guī)范版本匹配域數(shù)量匹配域主要變化v1.012入端口以太網(wǎng)：源，目的，類型，VLANIPv4:源，目的，協(xié)議，ToS位TCP/UDP:源端口，目的端口v1.115元數(shù)據(jù)，SCTP, VLAN標記MPLS:標簽，數(shù)據(jù)類型v1.236OpenFlow擴展匹配(OXM)IPv6：源，目的，流標簽，ICMPv6v1.339PBB，IPv6擴展字段v1.443-如表所示,每個版本的OpenFlow規(guī)范引入了新的匹配字段，包括以太網(wǎng),IP

23、v4 / v6,MPLS,TCP / UDP等19-23。然而,只有部分匹配字段是必選的。同樣,許多動作和端口類型是可選的。通過一個基于type-length-value(TLV)格式的OpenFlow擴展匹配(OXM)在OpenFlow version 1.2中引入可擴展性功能后使得不再需要添加更多新的匹配字段20。為了提高整體協(xié)議的可擴展性,OpenFlow version 1.4中，TLV格式也已經(jīng)添加到端口、流表和隊列中23。3.1.2 安全通道OpenFlow采用的是集中控制方式，控制器需要利用OpenFlow協(xié)議對交換機進行流標的配置，因此在它們之間傳送信息的通道非常重要。通道是連

24、接OpenFlow交換機到控制器的接口，控制器通過這個接口管理和控制OpenFlow交換機，同時也通過這個接口接收來自OpenFlow交換機的消息。在具體的通道實現(xiàn)中，OpenFlow v1.0要求承載OpenFlow協(xié)議傳送的通道必須是安全的，并規(guī)定通道需要采用TLS（Transport Layer Security，安全傳輸協(xié)議）技術。3.1.3 OpenFlow協(xié)議OpenFlow協(xié)議是用來描述控制器和OpenFlow交換機之間交互所用的信息接口標準，其核心是OpenFlow協(xié)議信息的集合。OpenFlow協(xié)議支持三種消息類型：controller-to-switch、asynchron

25、ous（異步）和symmetric（對稱）。而每一類消息又可以擁有多個子消息類型。其中，controller-to-switch消息由控制器發(fā)起，用來管理或獲取OpenFlow交換機狀態(tài)；asynchronous消息由OpenFlow交換機發(fā)起，用來將網(wǎng)絡事件或交換機狀態(tài)變化更新到控制器；symmetric 消息可由交換機或控制器發(fā)起。3.2 SDN交換機及南向接口技術SDN的核心理念之一就是將控制功能從網(wǎng)絡設備中剝離出來，SDN交換機只負責網(wǎng)絡高速轉發(fā)，保存的用于轉發(fā)決策的轉發(fā)表信息來自控制器，SDN交換機需要在遠程控制器的管控下工作，與之相關的設備狀態(tài)和控制指令都需要經(jīng)由SDN的南向接口傳

26、達，從而實現(xiàn)集中化統(tǒng)一管理、資源的優(yōu)化利用，提升網(wǎng)絡管控效率。工作在基礎設施層的SDN交換機雖然不再需要對邏輯控制進行過多考慮，但作為SDN網(wǎng)絡中負責具體數(shù)據(jù)轉發(fā)處理的設備，為了完成高速數(shù)據(jù)轉發(fā)，還是要遵循交換機工作原理。本質(zhì)上看，傳統(tǒng)設備中無論是交換機還是路由器，其工作原理都是在收到數(shù)據(jù)包時，將數(shù)據(jù)包中的某些特征域與設備自身存儲的一些表項進行比對，當發(fā)現(xiàn)匹配時則按照表項的要求進行相應處理。SDN交換機也是類似的原理，但是與傳統(tǒng)設備存在差異的是，設備中的各個表項并非是由設備自身根據(jù)周邊的網(wǎng)絡環(huán)境在本地自行生成的，而是由遠程控制器統(tǒng)一下發(fā)的，因此各種復雜的控制邏輯(例如鏈路發(fā)現(xiàn)、地址學習、路由計

27、算等等)都無需在SDN交換機中實現(xiàn)。SDN交換機可以忽略控制邏輯的實現(xiàn)，全力關注基于表項的數(shù)據(jù)處理，而數(shù)據(jù)處理的性能也就成為評價SDN交換機優(yōu)劣的最關鍵指標。另外，考慮到SDN和傳統(tǒng)網(wǎng)絡的混合工作問題，支持混合模式的SDN交換機也是當前設備層技術研發(fā)的焦點。同時，隨著虛擬化技術的出現(xiàn)和完善，虛擬化環(huán)境將是SDN交換機的一個重要應用場景，因此SDN交換機可能會有硬件、軟件等多種形態(tài)。例如，OVS(Open vSwitch，開放虛擬交換標準)交換機就是一款基于開源軟件技術實現(xiàn)的能夠集成在服務器虛擬化Hypervisor中的交換機，具備完善的交換機功能，在虛擬化組網(wǎng)中起到了非常重要的作用。3.3 S

28、DN控制器及北向接口技術控制層是SDN的大腦，負責對底層轉發(fā)設備的集中統(tǒng)一控制，同時向上層業(yè)務提供網(wǎng)絡能力調(diào)用的接口，在SDN架構中具有舉足輕重的作用，SDN控制器也是SDN關注的焦點。從技術實現(xiàn)上看，控制器除了南向的網(wǎng)絡控制和北向的業(yè)務支撐外，還需要關注東西的擴展，以避免SDN集中控制導致的性能和安全瓶頸問題，SDN控制器也在南向、北向、東西向上引入了相應的核心技術，有效解決與各層通信以及控制集群橫向擴展的難題。當前，業(yè)界有很多基于OpenFlow控制協(xié)議的開源的控制器實現(xiàn)，例如OMNI 24, Trema 25, Ryu26, Floodlight 27, NOX 28, 29, and

29、OpenDaylight30等，它們都有各自的特色設計，能夠?qū)崿F(xiàn)鏈路發(fā)現(xiàn)、拓撲管理、策略制定、表項下發(fā)等支持SDN網(wǎng)絡運行的基本操作。雖然不同的控制器在功能和性能上仍舊存在差異，但是從中已經(jīng)可以總結出SDN控制器應當具備的技術特征，從這些開源系統(tǒng)的研發(fā)與實踐中得到的經(jīng)驗和教訓將有助于推動SDN控制器的規(guī)范化發(fā)展。另外，用于網(wǎng)絡集中化控制的控制器作為SDN網(wǎng)絡的核心，其性能和安全性非常重要，其可能存在的負載過大、單點失效等問題一直是SDN領域中亟待解決的問題。當前，業(yè)界對此也有了很多探討，從部署架構、技術措施等多個方面提出了很多有創(chuàng)見的方法。文獻31-33通過不同SDN控制器部署策略來避免單點失

30、效問題。但是仍存在三個主要限制因素。針對文獻31-33存在的問題，文獻34提出了Survivor，一個新穎的控制器部署策略。SDN控制器對網(wǎng)絡的控制主要是通過南向接口協(xié)議實現(xiàn),包括鏈路發(fā)現(xiàn)、拓撲管理、策略制定、表項下發(fā)等，其中鏈路發(fā)現(xiàn)和拓撲管理主要是控制其利用南向接口的上行通道對底層交換設備上報信息進行統(tǒng)一監(jiān)控和統(tǒng)計;而策略制定和表項下發(fā)則是控制器利用南向接口的下行通道對網(wǎng)絡設備進行統(tǒng)一控制。SDN北向接口是通過控制器向上層業(yè)務應用開放的接口，其目標是使得業(yè)務應用能夠便利地調(diào)用底層的網(wǎng)絡資源和能力。通過北向接口，網(wǎng)絡業(yè)務的開發(fā)者能以軟件編程的形式調(diào)用各種網(wǎng)絡資源;同時上層的網(wǎng)絡資源管理系統(tǒng)可以

31、通過控制器的北向接口全局把控整個網(wǎng)網(wǎng)絡的資源狀態(tài)，并對資源進行統(tǒng)一調(diào)度。因為北向接口是直接為業(yè)務應用服務的，因此其設計需要密切聯(lián)系業(yè)務應用需求，具有多樣化的特征。同時，北向接口的設計是否合理、便捷，以便能被業(yè)務應用廣泛調(diào)用，會直接影響到SDN控制器廠商的市場前景。文獻35設計了新的網(wǎng)絡編程語言和配置腳本，實現(xiàn)對SDN網(wǎng)絡的自動化管理；文獻36研究了如何在與云控制器集成中給出統(tǒng)一的云編排系統(tǒng)實踐方案。與南向接口方面已有OpenFlow等國際標準不同，北向接口方面還缺少業(yè)界公認的標準，因此，北向接口的協(xié)議制定成為當前SDN領域競爭的焦點，不同的參與者或者從用戶角度出發(fā)，或者從運營角度出發(fā)，或者從產(chǎn)

32、品能力角度出發(fā)提出了很多方案。據(jù)悉,目前至少有20種控制器,每種控制器會對外提供北向接口用于上層應用開發(fā)和資源編排。雖然北向接口標準當前還很難達成共識，但是充分的開放性、便捷性、靈活性將是衡量接口優(yōu)劣的重要標準，例如REST API就是上層業(yè)務應用的開發(fā)者比較喜歡的接口形式。部分傳統(tǒng)的網(wǎng)絡設備廠商在其現(xiàn)有設備上提供了編程接口供業(yè)務應用直接調(diào)用，也可被視作是北向接口之一，其目的是在不改變其現(xiàn)有設備架構的條件下提升配置管理靈活性，應對開放協(xié)議的競爭?？刂破髫撠熣麄€SDN網(wǎng)絡的集中化控制，對于把握全網(wǎng)置資源視圖、改善網(wǎng)絡資源交付都具有非常重要的作用。但控制能力的集中化，也意味著控制器局的安全性和性能

33、成為全網(wǎng)的瓶頸;另外，單一的控制器也無法應對跨多個地域的SND網(wǎng)絡問題，需要多個SDN控制器組成的分布式集群，以避免單一的控制器節(jié)點在可靠性、擴展性、性能方面的問題。目前，用于多個控制器之間溝通和聯(lián)系的東西向接口還沒定義標準，但專家表示，一些非常成熟的集群技術可以被運用到SDN網(wǎng)絡中來解決上述難題。3.4 網(wǎng)絡虛擬化技術隨著服務器、桌面、應用、存儲等虛擬化技術的廣泛應用，網(wǎng)絡虛擬化成為云計算和數(shù)據(jù)中心技術發(fā)展的迫切需求。網(wǎng)絡虛擬化的目的是為了在共享的同一物理網(wǎng)絡資源上劃出邏輯上獨立的網(wǎng)絡，以滿足多租戶、流量隔離和邏輯網(wǎng)絡自由管控的應用趨勢。開源項目FlowVisor3738從Network H

34、ypervisor角度出發(fā)實現(xiàn)網(wǎng)絡虛擬化，通過劃分流表空間產(chǎn)生獨立的網(wǎng)絡分片。各個網(wǎng)絡分片上的網(wǎng)絡流量是相互隔離的，用戶可在各個分片上進行互不干擾的各種流量模型和協(xié)議創(chuàng)新等實驗研究?，F(xiàn)在FlowVisor已經(jīng)被廣泛應用到多個研究機構的實驗平臺上，并在全球OpennetSummit(開放網(wǎng)絡峰會)上為各種SDN創(chuàng)新應用提供了共享同一套物理網(wǎng)絡資源的演示環(huán)境。Koponen et al.基于SDN技術提出了一個網(wǎng)絡虛擬平臺（network virtualization platform，NVP）39實現(xiàn)多用戶共享數(shù)據(jù)中心。3.5 應用編排和資源管理技術SDN網(wǎng)絡的最終目標是服務于多樣化的業(yè)務應用創(chuàng)

35、新。因此隨著SDN技術的部署和推廣，將會有越來越多的業(yè)務應用被研發(fā)，這類應用將能夠便捷地通過SDN北向接口調(diào)用底層網(wǎng)絡能力，按需使用網(wǎng)絡資源。SDN推動業(yè)務創(chuàng)新已經(jīng)是業(yè)界不爭的事實，它可以被廣泛地應用在云數(shù)據(jù)中心、寬帶傳輸網(wǎng)絡、移動網(wǎng)絡等種種場景中，其中為云計算業(yè)務提供網(wǎng)絡資源服務就是一個非常典型的案例。眾所周知，在當前的云計算業(yè)務中，服務器虛擬化、存儲虛擬化都已經(jīng)被廣泛應用，它們將底層的物理資源進行池化共享，進而按需分配給用戶使用。相比之下，傳統(tǒng)的網(wǎng)絡資源遠遠沒有達到類似的靈活性，而SDN的引入則能夠很好地解決這一問題。SDN通過標準的南向接口屏蔽了底層物理轉發(fā)設備的差異，實現(xiàn)了資源的虛擬化

36、，同時開放了靈活的北向接口供上層業(yè)務按需進行網(wǎng)絡配置并調(diào)用網(wǎng)絡資源。云計算領域中知名的OpenStack40就是可以工作在SDN應用層的云管理平臺，通過在其網(wǎng)絡資源管理組件中增加SDN管理插件，管理者和使用者可利用SDN北向接口便捷地調(diào)用SDN控制器對外開放的網(wǎng)絡能力。當有云主機組網(wǎng)需求(例如建立用戶專有的VLAN)被發(fā)出時，相關的網(wǎng)絡策略和配置可以在OpenStack管理平臺的界面上集中制定并進而驅(qū)動SDN控制器統(tǒng)一地自動下發(fā)到相關的網(wǎng)絡設備上。因此，網(wǎng)絡資源可以和其他類型的虛擬化資源一樣，以抽象的資源能力的面貌統(tǒng)一呈現(xiàn)給業(yè)務應用開發(fā)者，開發(fā)者無需針對底層網(wǎng)絡設備的差異耗費大量開銷從事額外的

37、適配工作，這有助于業(yè)務應用的快速創(chuàng)新。4. 總結與展望雖然SDN相對傳統(tǒng)網(wǎng)絡具有諸多優(yōu)勢，代表著網(wǎng)絡發(fā)展的方向，但目前仍存在一系列尚待解決的問題。4.1 SDN面臨的挑戰(zhàn)(1)運算壓力大、軟件復雜度高、系統(tǒng)穩(wěn)定性存在隱患SDN架構下控制器需要為每一條流制定優(yōu)化的路由策略其運算壓力之大可想而知，且這一壓力會隨控制網(wǎng)元數(shù)量的增加呈幾何級上升。此外，由于不同應用會在SDN系統(tǒng)建立不同的邏輯網(wǎng)絡，各應用程序彼此會妨礙對方的功能資源競爭將會非常激烈。而從計算機程序的發(fā)展歷史來看，為了協(xié)調(diào)各程序的運行，提高資源利用效率，往往會導致資源分配算法的復雜度和運算量呈指數(shù)級上升，進而存在成為系統(tǒng)瓶頸的可能。同時，

38、為了實現(xiàn)網(wǎng)絡的可編程性。應用程序會被賦予大量對環(huán)境的控制權，而這很容易導致系統(tǒng)崩潰。因此，如何在軟件復雜度和運算效率之間取得平衡是SDN面臨的一大挑戰(zhàn)。(2)控制器接口尚未標準化目前，ONF僅定義了控制器連接交換機的南向接口，而尚未定義控制器之間的接口及控制器開放給應用程序的北向接口。原因是該組織認為現(xiàn)在標準化這些接口為時尚早，且可能會扼殺網(wǎng)絡基礎架構中關鍵組件的創(chuàng)新。但這也無疑增加了各廠商設備間互通的難度，一定程度上延緩了SDN的商用化進程。(3)網(wǎng)絡集中控制固有的安全性隱患由于SDN采取集中控制架構，因此必然面臨著集中所帶來的“單點失效”等固有缺陷。(4)從現(xiàn)有硬件平臺向虛擬化網(wǎng)絡的平滑演

39、進、兼容性和長期共存的挑戰(zhàn)由于SDN采用OpenFlow協(xié)議相對簡單，因此在與網(wǎng)絡上長期留下來的、多廠商的、多種類的系統(tǒng)、設備在兼容性方面的性能還有待實踐檢驗。(5)市場利益復雜化成為SDN發(fā)展的一大阻力由于SDN尚處于發(fā)展的初級階段，且各參與方有著不同的利益和目的，對SDN的看法也存在著巨大的差異。目前業(yè)界各家廠商發(fā)布的SDN策略、解決方案之間也是千差萬別，市場上已經(jīng)呈現(xiàn)出一些廠商各行其是的現(xiàn)象。業(yè)界要做到統(tǒng)一SDN標準。實現(xiàn)各廠商產(chǎn)品相互兼容。還需要一個長期的過程。4.2 SDN的發(fā)展趨勢鑒于存在上述復雜的原因，要預測SDN的發(fā)展趨勢變得十分困難。但可以從兩個角度進行考察。從SDN設備發(fā)展

40、的角度來看，由于存在明確的標準且功能相對簡單，大部分廠商都已推出了支持OpenFlow的交換機產(chǎn)品?？梢灶A見下一階段，多數(shù)廠商以及標準組織會將關注重點轉移到更加復雜的控制器上，推動SDN向進一步商用化發(fā)展。從SDN的應用領域角度來看，數(shù)據(jù)中心無疑是SDN第一階段商用的重點。數(shù)據(jù)中心由于具有流量大、流量模型簡單、與其他網(wǎng)絡相對隔離等特點，非常適于SDN技術特點的發(fā)揮。而且目前大部分數(shù)據(jù)中心正面臨“云”化變革，這為SDN推廣提供了難得的機遇。因此，業(yè)界普遍將數(shù)據(jù)中心視為SDN目前最主要的應用領域。參考文獻1 P.Mell and T. Grance, “The NIST definition of

41、 cloud computing (draft),”NIST Special Publication, vol. 800-145, p. 7, 2011.2 J. Dean and S. Ghemawat, “MapReduce: Simplified data processing on large clusters,” Commun. ACM, vol. 51, no. 1, pp. 107113, Jan. 2008.3 J. Gantz and D. Reinsel, “Extracting value from chaos,” IDC, Framingham, MA, USA, Wh

42、ite Paper, Jun.2011.Online.Available: collateral/analystreports/idcextracting-valuefrom-chaos-ar.pdf4 J. Manyika et al., “Big data: The next frontier for innovation, competition, and productivity,” McKinsey Global Inst., Mumbai, India, pp. 1137, 2011.5 “Software-defined networking: The new norm for

43、networks,” Palo Alto, CA, USA, White Paper, Apr. 2012.Online.Available:https:/www.Opennetwork /images/stories/down-loads/white-papers/wp-sdnnewnorm.Pdf6 K. Greene, 10 Breakthrough Technologies: Software-defined Networking MIT Technol. Rev., 2009.Online.Available:7 M. Casado et al., “Ethane: T

44、aking control of the enterprise,” in Proc.Conf. SIGCOMM Appl., Technol., Archit., Protocols Comput. Commun.,2007, pp. 1128 MeKEOWN N，ANDERSON T，BALAKRISHNAN H，et alOpenFlow：enabling innovation in campus networksJACM SIGCOMM Computer Communication Review，2008，88(2)：69-759 “Software-defined networking

45、: The new norm for networks,” Palo Alto,CA, USA, White Paper, Apr. 2012. Online. Available: https:/www.opennetwork /images/stories/downloads/white-papers/wp-sdnnewnorm.pdf10 T. Nadeau and P. Pan, Software Driven Networks Problem Statement,Oct. 2011, Internet Draft. Online. Available:11 Open N

46、etworking Summit. Online. Available: /archives/oct11/site/tutorials.html12 Hot Topics in Software Defined Networking (HotSDN). Online. Available: http:/conferences. /sigcomm/2012/hotsdn.php13 European Workshop on Software Defined Networks. Online. Available:http

47、:/www.ewsdn.eu /previous/ewsdn12.html14 Open Networking Foundation (ONF). Online. Available: /15 H. Yin et al., SDNi: A Message Exchange Protocol for Software Defined Networks (SDNS) across Multiple Domains, Jun. 2012, Internet draft.Online.Available:16 H. Xie et al. “So

48、ftware-defined networking efforts debuted at IETF 84,”IETF J., Oct. 2012. Online. Available:/fr/node/457017 袁廣翔. 軟件定義網(wǎng)絡技術發(fā)展與應用研究J.現(xiàn)代電信科技,2013(4):45-50.18 N. McKeown et al., “OpenFlow: Enabling innovation in campus networks,”SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, p

49、p. 6974, Mar.200819 OpenFlow Switch Specification, Version 1.0.0 (Wire Protocol 0x01).Online. Available: /documents/openflowspec-v1.0.0.pdf20 OpenFlow Switch Specification, Vrsion 1.1.0 Implemented(Wire Protocol 0x02). Online. Available: /documents/openflo

50、w-spec-v1.1.0.pdf21 OpenFlow Switch Specification, Version 1.2 (Wire Protocol 0x03).Online. Available: /images/stories/downloads/openflow/openflow-spec-v1.2.pdf22 OpenFlow Switch Specification, Version 1.3.0 (Wire Protocol 0x04).Online. Available: https:/www.opennetworki

51、/images/stories/downloads/specification/openflow-specv1.3.0.pdf23 OpenFlow Switch Specification, Version 1.4.0 (Wire Protocol 0x05).Online. Available: /images/stories/downloads/specification/openflow-specv1.4.0.pdf24 D. Mattos et al., “OMNI: OpenFlow management inf

52、rastructure,” in Proc. Int. Conf. NOF, 2011, pp. 5256.25Trema.Online.Available: /trema/26Ryu.Online.Available: /ryu/27Floodlight.Online.Available:/28 N. Gude et al., “NOX: Towards an operating system for networks,”SIGCOMMComput.Commun. Rev.vol. 38, no. 3, pp. 105110, Jul. 2008.29NOX.O