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

提出了一種SDN控制器——ZENIC，并給出了其架構(gòu)。在控制、轉(zhuǎn)發(fā)兩個(gè)層面上，ZENIC 架構(gòu)主要包括轉(zhuǎn)發(fā)抽象層及驅(qū)動(dòng)層、網(wǎng)絡(luò)操作系統(tǒng)內(nèi)核層、北向應(yīng)用編程接口。ZENIC采用了統(tǒng)一的轉(zhuǎn)發(fā)抽象層加特定轉(zhuǎn)發(fā)驅(qū)動(dòng)、接入和內(nèi)聯(lián)網(wǎng)絡(luò)分層控制的特色架構(gòu)設(shè)計(jì)，解決了多種設(shè)備接入和復(fù)雜網(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項(xiàng)目孵化OpenFlow協(xié)議，在2009年業(yè)界正式提出軟件定義網(wǎng)絡(luò)（SDN）以來，業(yè)界已經(jīng)有上百家企業(yè)正式加入到開放網(wǎng)絡(luò)基金會(huì)（ONF）。SDN的產(chǎn)品及樣機(jī)覆蓋了SDN控制器、交換機(jī)、路由、虛擬網(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ù)和利益博弈兩個(gè)方面的原因，業(yè)界尚無統(tǒng)一的認(rèn)識(shí)。一般來說，ONF定義的轉(zhuǎn)發(fā)、控制、應(yīng)用3層架構(gòu)得到相對廣泛的認(rèn)同。

1 SDN架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZENIC已經(jīng)實(shí)現(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)資源的管理，包括拓?fù)涔芾怼⒅鳈C(jī)管理、接口資源管理、轉(zhuǎn)發(fā)表管理等，并管理物理拓?fù)?、虛擬拓?fù)?、轉(zhuǎn)發(fā)表等構(gòu)成的網(wǎng)絡(luò)信息庫?？傮w而言，內(nèi)核層并無預(yù)設(shè)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)邏輯處理，而是維護(hù)準(zhǔn)確的網(wǎng)絡(luò)拓?fù)?、資源狀態(tài)以及轉(zhuǎn)發(fā)表的存儲(chǔ)、合成，接受應(yīng)用對于網(wǎng)絡(luò)、資源狀態(tài)的訂閱以及應(yīng)用對于網(wǎng)絡(luò)資源、轉(zhuǎn)發(fā)邏輯的操作。

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

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

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

OpenFlow的流表模型以及對于交換機(jī)統(tǒng)一、扁平化的管理視圖帶來了很多問題，包括交換機(jī)硬件復(fù)雜化、不靈活、主機(jī)和網(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)兩個(gè)接入端口的位置和策略。內(nèi)核計(jì)算出完整端到端路徑，并在接入側(cè)將轉(zhuǎn)發(fā)決策映射到互聯(lián)網(wǎng)絡(luò)路徑的封裝標(biāo)簽。ZENIC支持多種互聯(lián)網(wǎng)絡(luò)封裝格式，包括MPLS、虛擬局域網(wǎng)（VLAN）等，下一步將支持虛擬擴(kuò)展的局域網(wǎng)（VXLAN）/通用路由封裝協(xié)議（GRE）。這種接入-互聯(lián)網(wǎng)絡(luò)的模式，應(yīng)用完全無需感知，專注于主機(jī)接入側(cè)的策略。同時(shí)內(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)用編程、實(shí)現(xiàn)的復(fù)雜度較高。比如有廠商實(shí)現(xiàn)的設(shè)備級(jí)開放API多達(dá)700多個(gè)，涵蓋幾乎所有協(xié)議和設(shè)備功能，但是對于SDN而言，將會(huì)面臨至少兩類應(yīng)用，需求迥異：

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

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

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

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

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

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

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

2.4 分布式處理算法

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

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

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

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

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

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

OpenFlow 1.0提供的是一個(gè)單流表的抽象模型[9]，OpenFlow 1.1之后定義了一個(gè)多級(jí)流表的模型。I2RS以及部分廠商的開放接口給應(yīng)用暴露的是一個(gè)路由信息庫（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，有嚴(yán)格的限定條件。

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

OpenFlow 1.x提供了多級(jí)流表模型[10-11]，增加了更多的表匹配字段和指令類型，能力越來越強(qiáng)，但是離現(xiàn)有交換機(jī)ASIC的能力越來越遠(yuǎn)。軟件交換機(jī)可以容易地實(shí)現(xiàn)OpenFlow 1.x的多表模型。硬件交換機(jī)可以通過將自身的傳統(tǒng)ASIC流水線進(jìn)行一些必要的封裝，形成多級(jí)流表上報(bào)給控制面，由控制面進(jìn)行適配，只下發(fā)轉(zhuǎn)發(fā)面支持的指令和表結(jié)構(gòu)。這對轉(zhuǎn)發(fā)面和控制器均提出了更高的要求。業(yè)界也有少數(shù)廠商推出了可配置TCAM流水環(huán)節(jié)的ASIC，這些將固定寬度的TCAM查表處理單元分解成更小的分片，比如每32比特TCAM是一個(gè)基本分片。應(yīng)用可以靈活定義多個(gè)分片構(gòu)成一級(jí)OpenFlow流表，從而支持了OpenFlow的多級(jí)流表模型。應(yīng)用可以將L2交換、L3交換/路由、ACL等分解到不同的流表上實(shí)現(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ù)變革的機(jī)會(huì)。本文描述了作者及其團(tuán)隊(duì)對于SDN相關(guān)關(guān)鍵技術(shù)的研究成果及SDN控制器產(chǎn)品實(shí)現(xiàn)架構(gòu)，并闡述了各種對比方案的優(yōu)劣勢。

參考文獻(xiàn)

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