軟件定義網絡關鍵技術及其實現

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

提出了一種SDN控制器——ZENIC，并給出了其架構。在控制、轉發兩個層面上，ZENIC 架構主要包括轉發抽象層及驅動層、網絡操作系統內核層、北向應用編程接口。ZENIC采用了統一的轉發抽象層加特定轉發驅動、接入和內聯網絡分層控制的特色架構設計，解決了多種設備接入和復雜網絡控制的問題。

軟件定義網絡；OpenFlow協議；數據中心；未來網絡

In this paper， we propose an SDN controller called ZENIC and describe its architecture. In the control and forwarding layers， ZENIC includes forwarding abstract layer， driver layer， network operating system kernel level， and northern application programming interface. A unified abstraction layer and specific forwarding drive combined with hierarchical control of access and Intranet can solve problems related to access of various devices and complex network control.

software-defined networks； OpenFlow； data center； future network

自斯坦福CleanState項目孵化OpenFlow協議，在2009年業界正式提出軟件定義網絡（SDN）以來，業界已經有上百家企業正式加入到開放網絡基金會（ONF）。SDN的產品及樣機覆蓋了SDN控制器、交換機、路由、虛擬網絡功能部件等產品，應用場景覆蓋了數據中心網絡、企業網、校園網、光網絡及業務邊緣網絡等。迄今為止，SDN的功能架構在不同的領域，出于技術和利益博弈兩個方面的原因，業界尚無統一的認識。一般來說，ONF定義的轉發、控制、應用3層架構得到相對廣泛的認同。

1 SDN架構

按照ONF的定義，SDN分為基礎設施層、控制層和應用層[1]，見圖1所示。虛擬化在基礎設施以及控制層兩個層面上實現，前者實現設備級的虛擬化，比如一個物理交換機支持多個邏輯交換機；后者實現網絡級的虛擬化，首先是SDN控制器將整個網絡當成一個邏輯的超級交換機進行管理控制，其次將物理資源進一步根據端口、媒體訪問控制（MAC）地址、IP地址段等信息劃分為多個虛擬網絡

遵照傳統通信領域的慣例，在架構圖中下方為南，上方為北，因此基礎設施層和轉發層之間的接口稱為南向接口。ONF標準化的是OpenFlow協議，互聯網工程任務組（IETF）正在制訂路由系統接口（I2RS）協議。控制層和應用層之間的接口稱為北向接口，業界主流實現的是基于超文本傳輸協議（HTTP）的RESTful接口，具體編程接口隨應用場景不同而有所區別。

在更廣義的SDN架構中，控制層之上還有業務編排層，主要實現SDN域間資源的統一管理、SDN網絡和其他資源的統一調度，比如OpenStack+SDN的數據中心解決方案。OpenStack統一調度計算、網絡和存儲資源，相當于SDN的業務編排層。站在SDN的角度來看，控制層之上如何劃分則是廠商解決方案、應用實現的具體行為，就如同傳輸控制協議/網間協議（TCP/IP）并不關心應用層進一步如何分層設計，統稱為應用層。

站在整個網路架構的層面來看SDN，則業界存在不同的看法：

（1）SDN只進行區域性網絡改造，可將SDN控制域看成一個超級設備。SDN并不改變原有的網絡橫向接口，邊界網關協議（BGP）/多協議標簽交換（MPLS）等仍然有效。

（2）SDN控制域間定義專門/增強的SDN東西向接口，將SDN作為整個網絡的控制平面。

本文認為，第一種方案更加具有現實意義，利于網絡的平滑演進。第二種方案中的東西向接口要么可以通過擴充現有的BGP/MPLS協議實現，要么可以通過北向接口在業務編排層面進行實現，如果要定義更加專用的SDN東西向接口，雖然有可能可以增強整網的能力，但是無疑也為部署增加了難度，業界正在探索之中。

2 ZENIC架構及控制面

關鍵技術實現

現有來自于學術界的開源SDN控制器實現基于OpenFlow協議，整個轉發模型也綁定于某個具體的OpenFlow協議版本[2-3]。對于商用系統而言，必須要考慮整個產品生命周期內協議接口的兼容，還要考慮不同應用場景的區別以及和多廠家、多協議接口的差別，因此SDN控制面必須設置一個兼容多版本OpenFlow、多種控制協議以及不同轉發面能力的抽象層，我們稱之為轉發抽象層（FAL），在此之上為網絡操作系統（NOS）核心以及應用層提供的接口是獨立于具體的協議和硬件能力的。在OpenDaylight中，此層次稱為業務抽象層（SAL）[4]。

本文實現一種SDN控制器——ZENIC，其架構如圖2所示。圖2自上而下主要包括協議棧、驅動和轉發抽象層、NOS內核和應用層。

2.1 轉發抽象層及驅動層

轉發抽象層定義統一的轉發控制接口，包括對抽象轉發面的狀態、能力、硬件資源、轉發表、統計信息等進行讀取/操作，相當于驅動的基類。同時轉發抽象層還管理轉發面驅動的實例，根據轉發面接入時的基本能力協商加載不同的驅動實例，將轉發面的控制連接綁定到相應的驅動實例。

每個具體設備的驅動實現轉發抽象層的接口，完成不同接口協議、不同硬件能力到轉發抽象層的統一適配。從控制面及其上層應用的角度來看，FAL提供了一個統一的轉發操縱接口，但是由于各轉發面的能力差別較大，應用對于轉發面的操作存在失敗的可能，因此FAL需要向應用提供轉發面能力獲取/協商的接口。

ZENIC已經實現對于OpenFlow 1.0/1.2/1.3的自適應協商。

2.2 網絡操作系統內核層

NOS內核層是對網絡、系統資源的管理，包括拓撲管理、主機管理、接口資源管理、轉發表管理等，并管理物理拓撲、虛擬拓撲、轉發表等構成的網絡信息庫。總體而言，內核層并無預設的網絡轉發邏輯處理，而是維護準確的網絡拓撲、資源狀態以及轉發表的存儲、合成，接受應用對于網絡、資源狀態的訂閱以及應用對于網絡資源、轉發邏輯的操作。

拓撲管理的實現目前能夠基于OpenFlow標準化的實現是基于控制器在鏈路上周期下發探測報文實現的，以太網一般是基于鏈路層發現協議（LLDP）實現。這樣實現的好處是轉發面完全無需感知，缺點是鏈路較多、檢測定時器較短時，控制器的開銷較高。另外一種方式是有轉發面維護鏈路檢測定時器，自行檢測，將狀態上報，這一實現方式的優點是控制面開銷小，缺點是需要轉發面具有一定的預設邏輯。

內核層不僅要維護網絡節點、拓撲狀態，而且也需要收集基本的主機位置、狀態，從而可以給應用提供一個完整的網絡視圖，進一步做轉發、業務的決策。

對于SDN控制器而言，網絡虛擬化應該內置支持。虛擬化首先是轉發面資源的分區和隔離，比如按照端口、邏輯端口、主機MAC地址、IP地址段等進行虛擬網絡的劃分，其次是虛擬拓撲對于其上客戶/應用的權限管理適配。

OpenFlow的流表模型以及對于交換機統一、扁平化的管理視圖帶來了很多問題，包括交換機硬件復雜化、不靈活、主機和網絡需緊耦合[5]。在ZENIC系統中，將內聯網絡管理作為內核服務之一，解耦接入網絡和互聯網絡。內核管理互聯網絡的封裝格式，上層應用只需要決策SDN控制域內兩個接入端口的位置和策略。內核計算出完整端到端路徑，并在接入側將轉發決策映射到互聯網絡路徑的封裝標簽。ZENIC支持多種互聯網絡封裝格式，包括MPLS、虛擬局域網（VLAN）等，下一步將支持虛擬擴展的局域網（VXLAN）/通用路由封裝協議（GRE）。這種接入-互聯網絡的模式，應用完全無需感知，專注于主機接入側的策略。同時內連網絡管理本身也可以開放接口，支持應用自定義的路由算法和策略。

2.3 北向應用編程接口

北向應用編程接口（API）在不同的應用場景中需求不同，對于封裝的要求也有區分。如果將網絡的原子能力暴露給應用，是有可能形成統一的API，但是由于缺乏封裝和易用性，應用編程、實現的復雜度較高。比如有廠商實現的設備級開放API多達700多個，涵蓋幾乎所有協議和設備功能，但是對于SDN而言，將會面臨至少兩類應用，需求迥異：

（1）專業網絡應用

訂制化需求高，需要更加細節的API，對底層網絡的操作操縱能力強，比如訂制開發路由協議、訂制進行精細化的流量調度。

（2）普通應用

將網絡作為一種服務，只是請求網絡為應用提供服務，并不關心網絡細節。

對于后者，北向接口最好能封裝幾個模型和交互簡單、易懂的服務接口，如向網絡請求創建從交換機A端口1到交換機B端口2的一條1 Gb/s有帶寬保證的通路，而不是由應用向路徑上的交換機逐個下發轉發表以及相應的隊列配置參數。

還有一種北向接口的思路就是由應用定義自身對網絡的需求和操作接口，網絡廠商提供插件實現應用的網絡接口。比較典型的是OpenStack的Quantum組件，其定義了網絡的API，由各個廠商提供Quantum Plug-In來控制自己的SDN控制器或網絡設備。此架構相當于把SDN的北向接口標準化工作往上推到應用，網絡去適配應用需求。

兩種思路各有利弊，由SDN定義北向接口比較理想化，試圖統一解決所有問題，但是網絡很難一一理解應用的需求，標準化的推進工作相對困難，而且易用性也很難保證；應用驅動的模式使得SDN落地更加容易，但是應用和多廠商網絡之間的互通要較耗費更大代價。ZENIC提供基本的細顆粒度的底層API，同時提供封裝后的虛擬網絡API，目前已經提供OpenStack的Quantum Plug-In接入到OpenStack之中。

2.4 分布式處理算法

控制面本身的分布式架構以及SDN轉發控制分離的架構帶來了狀態同步的額外開銷，準確的SDN全局視圖能夠保證決策的精確性和實時性，對于負載均衡等應用而言可以提升資源利用率，但需更加頻繁的信息同步，這大大降低了系統性能[6]。本文從設計上采用兩種手段：控制器的分布式方案盡可能減少消息的復制；控制轉發之間的狀態同步由用戶根據需求進行配置，只進行必要、夠用的狀態復制。

傳統的集群網絡系統控制面基本上是基于進程的分布式處理，比如各個不同的業務進程分布在不同的CPU上，但是一種進程仍然是單實例或少數實例，并行度受限。在單一業務進程突發負載的情況下，比如自治域間路由調整時的邊界網關協議（BGP）進程就是“瓶頸”。對于SDN而言，由于控制的網絡規模可能遠遠高于集群路由器，對控制面節點數量的要求更高，因此這種方法存在“瓶頸”不太可行。

分布式哈希表（DHT）算法提供了一個可伸縮的分布式數據存儲/路由算法。對于傳統應用不穩定網絡的Log2（N）查找復雜度的算法，在數據中心、電信網絡應用時，業界提出了多種增強的單跳算法，部分基于單跳DHT的增強型結構化查詢語言系統（No-SQL）開源系統也已經過商用考驗，包括Dynamo、Cassandra等，最早公開采用DHT分布式算法的SDN控制器是onix[7]，OpenDaylight項目近期也提出來采用Cassandra作為底層的分布式數據庫系統。作者所在團隊也實現了改良的單跳DHT算法[8]。

DHT算法基于一致性哈希，適用于鍵-值（Key-Value）存儲模型，類結構化查詢語言（SQL）的支持需要進一步封裝。對于SDN控制器而言，拓撲信息是全局性的，不適合于DHT存儲，而是需要進行額外的全局復制。與轉發設備相關的信息組織以交換節點為單位進行分布式儲存，可以滿足基本要求，但是顆粒度較粗，不利于控制節點之間的負載均衡。主機信息可以按IP地址、MAC表兩個維度進行分布化，更加均勻。

3 轉發層面的轉發抽象

技術實現

OpenFlow 1.0提供的是一個單流表的抽象模型[9]，OpenFlow 1.1之后定義了一個多級流表的模型。I2RS以及部分廠商的開放接口給應用暴露的是一個路由信息庫（RIB）之上的多種業務表，表之間隱含了協議規定的各種邏輯。OpenFlow給了應用/控制面對轉發面最大程度的操縱能力，理論上可以完全不受現有網絡協議的限制，轉發面可以是完全傻瓜化指令執行引擎，而其他開放API則是現有協議框架下的開放API，有嚴格的限定條件。

OpenFlow1.0非常簡單，但是需要三態內容尋址存儲器（TCAM）的支持，而TCAM價格相對較昂貴，同時其單表結構使得復雜轉發邏輯的分解很困難。在現有基于專用集成電路芯片（ASIC）的交換機上，OpenFlow 1.0可以很容易地映射到ACL流水線之上，因此目前市場上支持OpenFlow的以太網交換機絕大多數都是只支持OpenFlow 1.0。

OpenFlow 1.x提供了多級流表模型[10-11]，增加了更多的表匹配字段和指令類型，能力越來越強，但是離現有交換機ASIC的能力越來越遠。軟件交換機可以容易地實現OpenFlow 1.x的多表模型。硬件交換機可以通過將自身的傳統ASIC流水線進行一些必要的封裝，形成多級流表上報給控制面，由控制面進行適配，只下發轉發面支持的指令和表結構。這對轉發面和控制器均提出了更高的要求。業界也有少數廠商推出了可配置TCAM流水環節的ASIC，這些將固定寬度的TCAM查表處理單元分解成更小的分片，比如每32比特TCAM是一個基本分片。應用可以靈活定義多個分片構成一級OpenFlow流表，從而支持了OpenFlow的多級流表模型。應用可以將L2交換、L3交換/路由、ACL等分解到不同的流表上實現，從而避免了超長單一流表關鍵字帶來的不必要的TCAM開銷。

4 結束語

SDN通過采用轉發控制分離、集中控制的理念改造網絡，試圖將轉發設備改造為簡單的受控轉發設備，將智能留在純軟件化的SDN控制器之中，使得網絡的創新更加快速、簡單，這帶來了開放的產業鏈和新的技術變革的機會。本文描述了作者及其團隊對于SDN相關關鍵技術的研究成果及SDN控制器產品實現架構，并闡述了各種對比方案的優劣勢。

參考文獻

[1] Open Networking Foundation. Software-defined networking： The new norm for networks [R]. White Paper. ONF， 2012.

[2] GUDE N， KOPONEN T， PETTIT J， et al. NOX： Towards an operating system for networks [J]. ACM SIGCOMM Computer Communication Review， 2008，38（3）：105-110.

[3] NOX [EB/OL]. [2013-02-18]. http：//www.noxrepo.org/

[4] Open daylight project [EB/OL]. [2013-02-18]. www.opendaylight.org

[5] CASADO M， KOPONEN T， SHENKER S， et al. Fabric： A retrospective on evolving SDN [C]//Proceedings of the 1th ACM Workshop on Hot Topics in Software Defined Networks （HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012： 85-90.

[6] LEVIN D， WUNDSAM A， HELLER B， et al， Logically centralized？ State distribution trade-offs in software defined networks [C]//Proceedings of the 1th ACM Workshop on Hot Topics in Software Defined Networks （HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012：1-6.

[7] KOPONEN T， CASADO M， GUDE N， et al. Onix： A distributed control platform for large-scale production networks [C]//Proceedings of the 9th USENIX Conference on Operating Systems Design and Implementation（OSDI10）， Oct 4-6， 2010， Vancouver， Canada. Berkeley， CA， USA： USENIX Association， 2010：1-6.

[8] HU Yongsheng， WANG Jun， HAO Zhenwu， et al. A reliable searching and broadcasting scheme in large-scale structured peer-to-peer system [C]//Proceedings of the 4th IEEE International Conference on Broadband Network and Multimedia Technology （IC-BNMT11）， Oct 28-30，2011， Shenzhen， China. Piscataway， NJ， USA： IEEE， 2011：324-328.

[9] OpenFlow switch specification 1.0.0 [S]. Open Networking Foundation， 2011.

[10] OpenFlow switch specification 1.2 [S]. Open Networking Foundation， 2011.

[11] OpenFlow switch specification 1.3.1 [S]. Open Networking Foundation， 2012.