軟件定義網(wǎng)絡(luò)關(guān)鍵技術(shù)及其實現(xiàn)

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

提出了一種SDN控制器——ZENIC，并給出了其架構(gòu)。在控制、轉(zhuǎn)發(fā)兩個層面上，ZENIC 架構(gòu)主要包括轉(zhuǎn)發(fā)抽象層及驅(qū)動層、網(wǎng)絡(luò)操作系統(tǒng)內(nèi)核層、北向應(yīng)用編程接口。ZENIC采用了統(tǒng)一的轉(zhuǎn)發(fā)抽象層加特定轉(zhuǎn)發(fā)驅(qū)動、接入和內(nèi)聯(lián)網(wǎng)絡(luò)分層控制的特色架構(gòu)設(shè)計，解決了多種設(shè)備接入和復雜網(wǎng)絡(luò)控制的問題。

軟件定義網(wǎng)絡(luò)；OpenFlow協(xié)議；數(shù)據(jù)中心；未來網(wǎng)絡(luò)

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協(xié)議，在2009年業(yè)界正式提出軟件定義網(wǎng)絡(luò)（SDN）以來，業(yè)界已經(jīng)有上百家企業(yè)正式加入到開放網(wǎng)絡(luò)基金會（ONF）。SDN的產(chǎn)品及樣機覆蓋了SDN控制器、交換機、路由、虛擬網(wǎng)絡(luò)功能部件等產(chǎn)品，應(yīng)用場景覆蓋了數(shù)據(jù)中心網(wǎng)絡(luò)、企業(yè)網(wǎng)、校園網(wǎng)、光網(wǎng)絡(luò)及業(yè)務(wù)邊緣網(wǎng)絡(luò)等。迄今為止，SDN的功能架構(gòu)在不同的領(lǐng)域，出于技術(shù)和利益博弈兩個方面的原因，業(yè)界尚無統(tǒng)一的認識。一般來說，ONF定義的轉(zhuǎn)發(fā)、控制、應(yīng)用3層架構(gòu)得到相對廣泛的認同。

1 SDN架構(gòu)

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

遵照傳統(tǒng)通信領(lǐng)域的慣例，在架構(gòu)圖中下方為南，上方為北，因此基礎(chǔ)設(shè)施層和轉(zhuǎn)發(fā)層之間的接口稱為南向接口。ONF標準化的是OpenFlow協(xié)議，互聯(lián)網(wǎng)工程任務(wù)組（IETF）正在制訂路由系統(tǒng)接口（I2RS）協(xié)議?？刂茖雍蛻?yīng)用層之間的接口稱為北向接口，業(yè)界主流實現(xiàn)的是基于超文本傳輸協(xié)議（HTTP）的RESTful接口，具體編程接口隨應(yīng)用場景不同而有所區(qū)別。

在更廣義的SDN架構(gòu)中，控制層之上還有業(yè)務(wù)編排層，主要實現(xiàn)SDN域間資源的統(tǒng)一管理、SDN網(wǎng)絡(luò)和其他資源的統(tǒng)一調(diào)度，比如OpenStack+SDN的數(shù)據(jù)中心解決方案。OpenStack統(tǒng)一調(diào)度計算、網(wǎng)絡(luò)和存儲資源，相當于SDN的業(yè)務(wù)編排層。站在SDN的角度來看，控制層之上如何劃分則是廠商解決方案、應(yīng)用實現(xiàn)的具體行為，就如同傳輸控制協(xié)議/網(wǎng)間協(xié)議（TCP/IP）并不關(guān)心應(yīng)用層進一步如何分層設(shè)計，統(tǒng)稱為應(yīng)用層。

站在整個網(wǎng)路架構(gòu)的層面來看SDN，則業(yè)界存在不同的看法：

（1）SDN只進行區(qū)域性網(wǎng)絡(luò)改造，可將SDN控制域看成一個超級設(shè)備。SDN并不改變原有的網(wǎng)絡(luò)橫向接口，邊界網(wǎng)關(guān)協(xié)議（BGP）/多協(xié)議標簽交換（MPLS）等仍然有效。

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

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

2 ZENIC架構(gòu)及控制面

關(guān)鍵技術(shù)實現(xiàn)

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

本文實現(xiàn)一種SDN控制器——ZENIC，其架構(gòu)如圖2所示。圖2自上而下主要包括協(xié)議棧、驅(qū)動和轉(zhuǎn)發(fā)抽象層、NOS內(nèi)核和應(yīng)用層。

2.1 轉(zhuǎn)發(fā)抽象層及驅(qū)動層

轉(zhuǎn)發(fā)抽象層定義統(tǒng)一的轉(zhuǎn)發(fā)控制接口，包括對抽象轉(zhuǎn)發(fā)面的狀態(tài)、能力、硬件資源、轉(zhuǎn)發(fā)表、統(tǒng)計信息等進行讀取/操作，相當于驅(qū)動的基類。同時轉(zhuǎn)發(fā)抽象層還管理轉(zhuǎn)發(fā)面驅(qū)動的實例，根據(jù)轉(zhuǎn)發(fā)面接入時的基本能力協(xié)商加載不同的驅(qū)動實例，將轉(zhuǎn)發(fā)面的控制連接綁定到相應(yīng)的驅(qū)動實例。

每個具體設(shè)備的驅(qū)動實現(xiàn)轉(zhuǎn)發(fā)抽象層的接口，完成不同接口協(xié)議、不同硬件能力到轉(zhuǎn)發(fā)抽象層的統(tǒng)一適配。從控制面及其上層應(yīng)用的角度來看，F(xiàn)AL提供了一個統(tǒng)一的轉(zhuǎn)發(fā)操縱接口，但是由于各轉(zhuǎn)發(fā)面的能力差別較大，應(yīng)用對于轉(zhuǎn)發(fā)面的操作存在失敗的可能，因此FAL需要向應(yīng)用提供轉(zhuǎn)發(fā)面能力獲取/協(xié)商的接口。

ZENIC已經(jīng)實現(xiàn)對于OpenFlow 1.0/1.2/1.3的自適應(yīng)協(xié)商。

2.2 網(wǎng)絡(luò)操作系統(tǒng)內(nèi)核層

NOS內(nèi)核層是對網(wǎng)絡(luò)、系統(tǒng)資源的管理，包括拓撲管理、主機管理、接口資源管理、轉(zhuǎn)發(fā)表管理等，并管理物理拓撲、虛擬拓撲、轉(zhuǎn)發(fā)表等構(gòu)成的網(wǎng)絡(luò)信息庫?？傮w而言，內(nèi)核層并無預設(shè)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)邏輯處理，而是維護準確的網(wǎng)絡(luò)拓撲、資源狀態(tài)以及轉(zhuǎn)發(fā)表的存儲、合成，接受應(yīng)用對于網(wǎng)絡(luò)、資源狀態(tài)的訂閱以及應(yīng)用對于網(wǎng)絡(luò)資源、轉(zhuǎn)發(fā)邏輯的操作。

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

內(nèi)核層不僅要維護網(wǎng)絡(luò)節(jié)點、拓撲狀態(tài)，而且也需要收集基本的主機位置、狀態(tài)，從而可以給應(yīng)用提供一個完整的網(wǎng)絡(luò)視圖，進一步做轉(zhuǎn)發(fā)、業(yè)務(wù)的決策。

對于SDN控制器而言，網(wǎng)絡(luò)虛擬化應(yīng)該內(nèi)置支持。虛擬化首先是轉(zhuǎn)發(fā)面資源的分區(qū)和隔離，比如按照端口、邏輯端口、主機MAC地址、IP地址段等進行虛擬網(wǎng)絡(luò)的劃分，其次是虛擬拓撲對于其上客戶/應(yīng)用的權(quán)限管理適配。

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

2.3 北向應(yīng)用編程接口

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

（1）專業(yè)網(wǎng)絡(luò)應(yīng)用

訂制化需求高，需要更加細節(jié)的API，對底層網(wǎng)絡(luò)的操作操縱能力強，比如訂制開發(fā)路由協(xié)議、訂制進行精細化的流量調(diào)度。

（2）普通應(yīng)用

將網(wǎng)絡(luò)作為一種服務(wù)，只是請求網(wǎng)絡(luò)為應(yīng)用提供服務(wù)，并不關(guān)心網(wǎng)絡(luò)細節(jié)。

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

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

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

2.4 分布式處理算法

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

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

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

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

3 轉(zhuǎn)發(fā)層面的轉(zhuǎn)發(fā)抽象

技術(shù)實現(xiàn)

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

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

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

4 結(jié)束語

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

參考文獻

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