軟件定義廣域網(wǎng)絡(luò)控制平面抗毀研究

李吉良,婁 陽,張學敏

(中國電子科技集團公司第五十四研究所，河北 石家莊 050081)

0 引言

互聯(lián)網(wǎng)的快速發(fā)展促使了傳統(tǒng)網(wǎng)絡(luò)在功能和結(jié)構(gòu)上變得愈加復雜，傳統(tǒng)網(wǎng)絡(luò)存在的問題也逐漸暴露出來。軟件定義網(wǎng)絡(luò)(Software Defined Networking，SDN)[1]將數(shù)據(jù)面與控制面分離，采用集中控制方式，具有可編程、整網(wǎng)控制、業(yè)務(wù)部署快捷及成本低等優(yōu)勢，不僅提升了網(wǎng)絡(luò)的安全性與服務(wù)質(zhì)量、降低了網(wǎng)絡(luò)運營與維護的成本，而且使新的服務(wù)與應(yīng)用可以更加快捷地部署到網(wǎng)絡(luò)中，縮短了新產(chǎn)品的開發(fā)周期。

SDN網(wǎng)絡(luò)中控制器實現(xiàn)控制平面功能，控制面是SDN架構(gòu)的核心層，負責收集網(wǎng)絡(luò)狀態(tài)、計算路由以及下發(fā)控制信息給數(shù)據(jù)平面的數(shù)據(jù)轉(zhuǎn)發(fā)設(shè)備，因此，研究控制平面的可靠性、可擴展性和抗毀性十分重要[2-4]。為解決網(wǎng)絡(luò)管控規(guī)模大帶來的路由計算量大、資源管控量大的問題，控制器一般采用分布式集群系統(tǒng)。分布式集群系統(tǒng)一般分為垂直分布和水平分布兩種方式，把不同的功能部署在不同的分布式節(jié)點中并進行并行處理稱為垂直分布，相同功能部署在不同的分布式節(jié)點中形成一個集群稱為水平分布?？刂破鞑捎么怪狈植己突旌戏植蓟旌鲜褂玫姆绞?，拓撲管理等采用垂直分布方式，網(wǎng)絡(luò)設(shè)備管理、協(xié)議處理等功能使用水平分布方式。

當前，基于SDN的廣域網(wǎng)技術(shù)是一個比較前沿的研究領(lǐng)域，與數(shù)據(jù)中心網(wǎng)絡(luò)不同，廣域網(wǎng)的SDN化面臨最大的問題是大規(guī)模組網(wǎng)以及網(wǎng)絡(luò)動態(tài)變化而導致的網(wǎng)絡(luò)可靠性降低、抗毀能力差等問題[5-6]。傳統(tǒng)SDN控制器(如OpenDaylight[7-8]、ONOS[9]等)采用控制器集群化方式[10]，主要為滿足數(shù)據(jù)中心需求而設(shè)計，并不適用于廣域網(wǎng)中，主要原因如下：

① 數(shù)據(jù)中心網(wǎng)絡(luò)為專用網(wǎng)，地域、邏輯較為集中，傳輸帶寬大，因此在大帶寬小地域的數(shù)據(jù)中心網(wǎng)絡(luò)中控制器之間能夠進行大量集群信息的收發(fā)。而廣域網(wǎng)具有地域覆蓋廣泛、網(wǎng)絡(luò)帶寬情況復雜等特點，傳統(tǒng)SDN控制器并不適用。

② 數(shù)據(jù)中心網(wǎng)絡(luò)為滿足虛擬機遷移等需求一般采用大二層等技術(shù)，沒有控制器分級、網(wǎng)絡(luò)分域的需求。而廣域網(wǎng)網(wǎng)絡(luò)規(guī)模大、范圍廣、流表數(shù)量巨大，因此，一般根據(jù)區(qū)域進行分級分域管理，這樣不僅減少了域內(nèi)的流表信息，而且使得整個網(wǎng)絡(luò)更便于管理。

③ 傳統(tǒng)SDN控制器通過集群冗余方式進行抗毀，由于沒有進行分域控制，需要對全網(wǎng)拓撲進行路由計算與網(wǎng)絡(luò)狀態(tài)監(jiān)控，當出現(xiàn)集群節(jié)點不可用等情況，其他控制節(jié)點的計算與流量負載會產(chǎn)生成倍的增加，不適用于廣域網(wǎng)抗毀情況使用。

④ 傳統(tǒng)SDN網(wǎng)絡(luò)控制器與交換機之間控制通道采用帶外控制方式，控制器通過專用控制網(wǎng)絡(luò)與交換機相連，并利用該網(wǎng)絡(luò)完成與交換機的南向通信。這種帶外方式構(gòu)建的控制通道不僅成本高，而且只適用于數(shù)據(jù)中心等地域集中的網(wǎng)絡(luò)，不適用廣域網(wǎng)的情況。

綜上，現(xiàn)有SDN控制方式并不適用于廣域網(wǎng)，為實現(xiàn)SDN在廣域網(wǎng)的使用，本文提出基于帶內(nèi)控制方式的分級分域控制器組網(wǎng)架構(gòu)，并研究在此架構(gòu)下控制器抗毀[11]組網(wǎng)方法。

1 SDN分級分域控制器組網(wǎng)架構(gòu)

SDN分級分域控制器組網(wǎng)架構(gòu)如圖1所示。該架構(gòu)采用垂直分層水平分域的方式將網(wǎng)絡(luò)控制層分為兩層：上層為域間控制器(Inter Area Controller，IAC)，底層為區(qū)域控制器(Area Controller，AC)。其中AC負責管理區(qū)域(Area)內(nèi)設(shè)備，完成區(qū)域內(nèi)業(yè)務(wù)轉(zhuǎn)發(fā)；上層的IAC則負責對AC進行協(xié)同，完成區(qū)域間的網(wǎng)絡(luò)管理和控制工作。AC與IAC之間的東西向接口(AC-IAC)使用控制器互聯(lián)協(xié)議進行通信，AC通過南向接口(Southbound Interface，SBI)管理區(qū)域內(nèi)交換機。每個AC管理網(wǎng)絡(luò)的一個區(qū)域，在一個區(qū)域的邊緣交換機上既有區(qū)域內(nèi)鏈路(Area Link，AL)，也有區(qū)域間鏈路(Inter Area Link，IAL)。AC通過LLDP協(xié)議[12]完成區(qū)域內(nèi)拓撲信息探測并同步至IAC，同時接收IAC執(zhí)行區(qū)域間轉(zhuǎn)發(fā)策略；IAC通過AC搜集各區(qū)域內(nèi)拓撲信息，通過LLDP協(xié)議探測區(qū)域間鏈路構(gòu)建全局網(wǎng)絡(luò)拓撲，為AC控制器提供區(qū)域間轉(zhuǎn)發(fā)策略。

圖1 SDN分級分域控制器組網(wǎng)架構(gòu)

1.1 帶內(nèi)控制

在廣域網(wǎng)絡(luò)中，節(jié)點數(shù)量大，節(jié)點地域分布廣，物理鏈路種類多，一般不會搭建類似數(shù)據(jù)中心網(wǎng)絡(luò)的SDN物理專用控制網(wǎng)絡(luò)，考慮到南向控制通道承載業(yè)務(wù)帶寬需求相對較小，采用在控制器與交換機中運行傳統(tǒng)IP路由協(xié)議組建邏輯獨立的帶內(nèi)控制網(wǎng)絡(luò)是可行方式，通過路由方式可以在數(shù)據(jù)傳輸網(wǎng)絡(luò)中隔離出相對獨立的控制域Areai，該思路既能保證網(wǎng)絡(luò)邏輯上集中控制，也能保證網(wǎng)絡(luò)控制與轉(zhuǎn)發(fā)分離。如圖1所示，SBI、AC-IAC交互報文在邏輯獨立的控制網(wǎng)絡(luò)中傳輸，IAC與各AC之間，AC控制器與所轄交換機之間通過傳統(tǒng)路由協(xié)議建立控制通道連接，它們在邏輯上還是星型關(guān)系，控制通道SBI、AC-IAC與轉(zhuǎn)發(fā)數(shù)據(jù)業(yè)務(wù)共用一張物理網(wǎng)絡(luò)。

1.2 區(qū)域控制器(AC)

AC完成本區(qū)域內(nèi)的鏈路發(fā)現(xiàn)、主機信息管理以及區(qū)域內(nèi)的轉(zhuǎn)發(fā)策略計算，并通過控制器互聯(lián)協(xié)議(AC-IAC)協(xié)助IAC完成區(qū)域間數(shù)據(jù)轉(zhuǎn)發(fā)。

① 鏈路信息發(fā)現(xiàn)

AC通過發(fā)送包含交換機ID、端口號、控制器ID和對外端口號信息的LLDP包發(fā)現(xiàn)鏈路。如果AC收到來自另一個區(qū)域的LLDP包，那么這個AC會將收到這個包的端口標記為對外端口，并分配一個在區(qū)域內(nèi)唯一的對外端口號。同時AC也需要向IAC轉(zhuǎn)發(fā)從其他區(qū)域發(fā)來的LLDP包，使IAC發(fā)現(xiàn)區(qū)域間鏈路與端口關(guān)系并記錄。

② 主機信息管理

AC負責一個區(qū)域的管理，為了能夠轉(zhuǎn)發(fā)數(shù)據(jù)包，AC需要收集包括MAC地址、IP地址和子網(wǎng)掩碼等主機信息。另外AC還需要異步地向IAC發(fā)送主機信息，使IAC能夠根據(jù)主機信息進行編排和協(xié)同決策。

③ 轉(zhuǎn)發(fā)策略計算

當出現(xiàn)轉(zhuǎn)發(fā)層面無法通過流表正常轉(zhuǎn)發(fā)的數(shù)據(jù)時，該數(shù)據(jù)會被PacketIn到控制平面進行路徑計算。當AC通過區(qū)域內(nèi)信息能夠計算出轉(zhuǎn)發(fā)路徑時，則為區(qū)域內(nèi)數(shù)據(jù)傳輸，AC將轉(zhuǎn)發(fā)路徑以流表形式下發(fā)到數(shù)據(jù)平面進行數(shù)據(jù)轉(zhuǎn)發(fā)；當AC無法通過區(qū)域內(nèi)信息計算出轉(zhuǎn)發(fā)路徑時，通過AC-IAC上報到IAC進行跨域路徑轉(zhuǎn)發(fā)計算。

④ 控制器互聯(lián)協(xié)議

AC需要通過AC-IAC向IAC發(fā)送區(qū)域內(nèi)節(jié)點信息、鏈路信息、主機信息以及與其他區(qū)域相連的對外端口等信息，幫助IAC形成全網(wǎng)網(wǎng)絡(luò)拓撲；并接收IAC的跨域轉(zhuǎn)發(fā)策略，實現(xiàn)跨域轉(zhuǎn)發(fā)中的本區(qū)域數(shù)據(jù)轉(zhuǎn)發(fā)。

1.3 域間控制器(IAC)

IAC負責管理AC之間的編排和協(xié)同，通過收集區(qū)域拓撲信息和域間鏈路(IAL)信息生成全網(wǎng)拓撲，此外還需要收集主機位置信息以保證能夠完成全網(wǎng)范圍內(nèi)的業(yè)務(wù)處理。

① 全局拓撲收集

IAC通過AC-IAC從AC獲得區(qū)域拓撲信息，并將多區(qū)域拓撲信息整合為全網(wǎng)拓撲信息。

② 跨域轉(zhuǎn)發(fā)策略計算

接收區(qū)域控制器的跨域轉(zhuǎn)發(fā)請求，并根據(jù)全局拓撲計算跨域轉(zhuǎn)發(fā)策略，如圖2所示。當能夠計算出跨域轉(zhuǎn)發(fā)策略時，IAC將跨域轉(zhuǎn)發(fā)策略分解成多個區(qū)域的區(qū)域轉(zhuǎn)發(fā)策略，通過AC-IAC將跨域轉(zhuǎn)發(fā)策略下發(fā)對應(yīng)的AC中；當不能夠計算出跨域轉(zhuǎn)發(fā)策略時，IAC通告請求的AC目的不可達，將數(shù)據(jù)丟棄。

圖2 跨域業(yè)務(wù)實現(xiàn)

SDN分級分域控制器組網(wǎng)架構(gòu)將網(wǎng)絡(luò)根據(jù)區(qū)域進行了劃分,將整網(wǎng)的路由計算劃分到不同的區(qū)域中。首先，采用帶內(nèi)的控制通道組建方式，解決了廣域SDN網(wǎng)絡(luò)集中控制的問題，使得SDN網(wǎng)絡(luò)能夠在大規(guī)模、跨地域的廣域網(wǎng)進行應(yīng)用。其次，分域?qū)⒙酚捎嬎闩c網(wǎng)絡(luò)狀態(tài)采集分解到每個域內(nèi)，單一域內(nèi)的路由計算量與網(wǎng)絡(luò)狀態(tài)變化量相對全網(wǎng)較少，一個或幾個區(qū)域控制節(jié)點失效,不會造成本域中其他集群控制器的負載過大，甚至整個區(qū)域所有控制節(jié)點均失效，也只影響此區(qū)域的數(shù)據(jù)通信，因此能夠有效地降低網(wǎng)絡(luò)故障影響。另外，本架構(gòu)中AC只需要掌握本區(qū)域網(wǎng)絡(luò)信息，無需直接與其他區(qū)域的AC通信，減少了控制器間的信息交換，提高了SDN在廣域網(wǎng)應(yīng)用的可靠性。

2 控制器失聯(lián)情況下的抗毀組網(wǎng)

由于SDN將控制面與數(shù)據(jù)面分離，為實現(xiàn)控制面對數(shù)據(jù)面的控制，在OpenFlow協(xié)議中增加了控制通道，控制通道的斷開會導致數(shù)據(jù)面失去控制不能進行有效的轉(zhuǎn)發(fā)。在SDN分級分域控制器組網(wǎng)架構(gòu)下，當一個交換機相連的所有AC均失聯(lián)后交換機便不能進行有效的數(shù)據(jù)轉(zhuǎn)發(fā)。為解決此問題，提高SDN分級分域控制器組網(wǎng)架構(gòu)在廣域網(wǎng)應(yīng)用的抗毀性，數(shù)據(jù)面采用OpenFlow-hybrid交換機(此種SDN交換機既支持傳統(tǒng)IP路由轉(zhuǎn)發(fā)，同時也支持OpenFlow協(xié)議流表轉(zhuǎn)發(fā))，保證在控制通道斷開情況下交換機仍有部分路由計算能力，當OpenFlow-hybrid交換機與控制器失聯(lián)后，采用切換到傳統(tǒng)IP路由模式的方法實現(xiàn)其自身的抗毀組網(wǎng)。

2.1 傳統(tǒng)區(qū)域自組網(wǎng)

在SDN分級分域控制器組網(wǎng)架構(gòu)下，OpenFlow-hybrid交換機與控制器失聯(lián)后應(yīng)獨立為單獨的一個區(qū)域，方便整網(wǎng)進行分級分域控制。

當失聯(lián)原因為控制器正常、控制鏈路阻塞等情況導致的控制通道斷開時，失聯(lián)交換機為獨立的單個或幾個交換機。若有失聯(lián)交換機相連，失聯(lián)交換機會自動通過傳統(tǒng)路由協(xié)議(包括OSPF[13]、IS-IS[14]、RIP[15]協(xié)議等路由協(xié)議)進行協(xié)議交互，實現(xiàn)之間的自動組網(wǎng)，兩個獨立區(qū)域便合并為一個區(qū)域，如圖3所示。當失聯(lián)原因為控制器失效，整個域內(nèi)交換機均產(chǎn)生失聯(lián)情況下，整個區(qū)域的交換機均會切換至傳統(tǒng)路由協(xié)議方式下運行，并整體組成一個傳統(tǒng)IP路由區(qū)域。其中，失聯(lián)交換機之間鏈路變?yōu)閰^(qū)域內(nèi)鏈路，失聯(lián)交換機與未失聯(lián)交換機相連鏈路變?yōu)橛蜷g鏈路(IAL)。AC可通過下發(fā)的LLDP包，動態(tài)識別與失聯(lián)交換機相連的域間鏈路(IAL)。如果AC收到來自另一個區(qū)域的LLDP包，那么這個AC會將收到這個包的端口更改為對外端口，并能根據(jù)LLDP包的計數(shù)計算是否經(jīng)過失聯(lián)交換機，以及經(jīng)過幾個失聯(lián)交換機。當計算得到經(jīng)過失聯(lián)交換機時，AC更新接收到該LLDP包端口為連接失聯(lián)交換機的對外端口。

圖3 傳統(tǒng)IP路由區(qū)域自組網(wǎng)

2.2 跨域數(shù)據(jù)傳輸

為實現(xiàn)失聯(lián)交換機組成的傳統(tǒng)IP路由區(qū)域與SDN區(qū)域之間的數(shù)據(jù)互通，IAC需要通過傳統(tǒng)IP路由協(xié)議獲得傳統(tǒng)區(qū)域內(nèi)的拓撲與路由情況。因此，AC需要通過AC-IAC將路由協(xié)議包發(fā)送至IAC進行協(xié)議交互與解析。

① 區(qū)域控制器(AC)

AC需要向與傳統(tǒng)IP路由區(qū)域相連的交換機下發(fā)路由協(xié)議PacketIn到AC的流表，并通過AC-IAC將PacketIn的數(shù)據(jù)包轉(zhuǎn)發(fā)到IAC上，再通過AC-IAC接收IAC發(fā)送的傳統(tǒng)協(xié)議數(shù)據(jù)包，并轉(zhuǎn)發(fā)到接收路由協(xié)議的對外端口上。

② 域間控制器(IAC)

IAC通過AC-IAC接收AC上傳的路由協(xié)議數(shù)據(jù)包，通過路由協(xié)議模塊、路由表解析模塊進行處理，將處理結(jié)果反饋至拓撲管理模塊，方便路徑計算模塊進行路徑計算，如圖4所示。

圖4 跨域控制器(IAC)路由協(xié)議處理

路由協(xié)議模塊接收路由協(xié)議報文生成路由表，路由表解析模塊根據(jù)路由表將傳統(tǒng)域內(nèi)網(wǎng)絡(luò)信息附加到對應(yīng)的對外端口上，完成整網(wǎng)拓撲網(wǎng)絡(luò)信息的更新。如圖5所示，傳統(tǒng)路由協(xié)議模塊從SW1上PacketIn的路由協(xié)議中獲得路由表(目標網(wǎng)絡(luò)：10.223.223.0/24、20.223.221.0/24 接口：1)，從SW2上PacketIn的路由協(xié)議中獲得路由表(目標網(wǎng)絡(luò)：10.223.223.0/24、20.223.223.0/24 接口：2)。解析分析得到通過SW1的1接口和SW2的2接口可達10.223.223.0/24網(wǎng)絡(luò)，將網(wǎng)絡(luò)拓撲信息上傳并存儲到拓撲管理中。當路徑計算模塊需要計算到10.223.223.0/24網(wǎng)絡(luò)時，可通過拓撲管理模塊得到通過SW1的1接口或SW2的2接口到達，跨域控制器只需要下發(fā)流表將數(shù)據(jù)轉(zhuǎn)發(fā)至SW1的1接口或SW2的2接口，SW3收到通過1接口或2接口收到數(shù)據(jù)包后根據(jù)傳統(tǒng)路由協(xié)議轉(zhuǎn)發(fā)至目的網(wǎng)絡(luò)。

圖5 路由信息解析

路由表解析模塊從拓撲管理模塊獲得域內(nèi)網(wǎng)絡(luò)信息，并將區(qū)域網(wǎng)絡(luò)信息轉(zhuǎn)換為路由信息添加到路由協(xié)議模塊中。圖5中路由表解析模塊根據(jù)SDN區(qū)域內(nèi)拓撲信息生成SW1路由表(目標網(wǎng)絡(luò)：20.223.222.0/24 接口：2)和SW2路由表(目標網(wǎng)絡(luò)：20.223.224.0/24 接口：1)，兩條路由信息通過路由協(xié)議模塊與交換機SW3進行路由協(xié)議交互，SW3最終生成路由表(目標網(wǎng)絡(luò)：20.223.221.0/24、20.223.222.0/24 接口：1；目標網(wǎng)絡(luò)：20.223.223.0/24、20.223.224.0/24 接口2；目標網(wǎng)絡(luò):10.223.223.0/24 接口：3)，其中路由(目標網(wǎng)絡(luò)： 20.223.222.0/24 接口：1；目標網(wǎng)絡(luò)：20.223.224.0/24 接口2)為學習到的新路由表項。當傳統(tǒng)域中數(shù)據(jù)包請求SDN域A中20.223.224.0/24網(wǎng)絡(luò)時，可通過路由協(xié)議轉(zhuǎn)發(fā)至SW3交換機的2接口上，之后通過控制器計算下發(fā)流表將數(shù)據(jù)包轉(zhuǎn)發(fā)至SW2的1接口上，最終到達目的網(wǎng)絡(luò)。

通過以上IAC學習傳統(tǒng)IP路由區(qū)域中路由表、IP路由交換機學習AC中SDN區(qū)域網(wǎng)絡(luò)信息實現(xiàn)兩個區(qū)域之間的雙向通信。當控制通道恢復后，OpenFlow-hybrid交換機通過檢查，自動恢復為OpenFlow交換機，脫離所在傳統(tǒng)IP路由區(qū)域，恢復到相連AC所控制的SDN區(qū)域中進行流表轉(zhuǎn)發(fā)。本抗毀組網(wǎng)方法能夠解決控制通道斷開造成的交換機轉(zhuǎn)發(fā)失效的問題，提高了SDN在廣域網(wǎng)應(yīng)用的抗毀性。

2.3 實驗驗證

實驗驗證平臺由控制面和數(shù)據(jù)面組成，控制面包括3個運行在Ubuntu系統(tǒng)上的控制器，控制器采用擴展了分級分域模塊與抗毀模塊的ONOS控制器。3個控制器節(jié)點，即1個IAC與2個AC組成2層控制網(wǎng)絡(luò)，如圖6所示。數(shù)據(jù)面由6臺OpenFlow-hybrid交換機組成，交換機由改造的OpenVSwitch與Quagga進行仿真，每個AC控制3個仿真交換機。

圖6 實驗平臺拓撲

抓取主機A到主機B的流量，在抓包過程中關(guān)閉AC B，觸發(fā)AC B控制的3個交換機與控制失連。在啟用與不啟用抗毀模塊兩種情況下進行流量抓取，得到對比數(shù)據(jù)如圖7所示。 通過對比發(fā)現(xiàn)，抗毀模塊能在失連后繼續(xù)保證SDN域與傳統(tǒng)域之間的互通，滿足控制器失連下的抗毀要求。

圖7 實驗數(shù)據(jù)對比

3 結(jié)束語

本文提出了面向廣域網(wǎng)的SDN分級分域控制器組網(wǎng)架構(gòu)，解決了SDN在廣域網(wǎng)組織運用時控制規(guī)模大、計算量大導致的網(wǎng)絡(luò)不穩(wěn)定問題，以及控制面和數(shù)據(jù)面分離導致網(wǎng)絡(luò)抗毀能力差等問題。該架構(gòu)將網(wǎng)絡(luò)控制層分為區(qū)域控制層與跨域控制層，提出區(qū)域控制器控制域內(nèi)業(yè)務(wù)轉(zhuǎn)發(fā)，域間控制器控制跨域業(yè)務(wù)轉(zhuǎn)發(fā)的控制策略，采用帶內(nèi)方式承載東西向和南向接口報文的方法，較好地解決了SDN廣域網(wǎng)控制通道問題。為提高此架構(gòu)在廣域網(wǎng)應(yīng)用的抗毀性，研究控制器失聯(lián)情況下的抗毀組網(wǎng)方法，通過使用OpenFlow-hybrid交換機，將失聯(lián)OpenFlow交換機臨時切換到傳統(tǒng)IP路由交換機，通過失聯(lián)域與SDN域控制器的路由信息交互，完成兩域間數(shù)據(jù)的雙向通信，實現(xiàn)分級分域架構(gòu)下的抗毀組網(wǎng)，對進一步開展基于SDN的廣域網(wǎng)研究具有借鑒意義。

[1] ONF White Paper.Software-Defined Networking: The New Norm for Networks,Open Networking Foundation[R],2012.

[2] Baskett P,Shang Y,Zeng W,et al.SDNAN:Software-defined Networking in Ad Hoc Networks of Smartphones[C]∥2013 IEEE Consumer Communications and Networking Conference (CCNC),2013:861-862.

[3] Yeganeh S H,Ganjali Y.Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications[C]∥Proceedings of the First Workshop on Hot Topics in Software Defined Networks.ACM,2012: 19-24.

[4] McCauley J,Panda A,Casado M,et al.Extending SDN to Large-scale Networks[J].Open Networking Summit,2013: 1-2.

[5] Tootoocian A,Ganjali Y.HyperFlow: A Distributed Control Plane for OpenFlow[C]∥In Proc.ACM INM/WREN,2010:3.

[6] McCauley J,Panda A,Casado M,et al.Extending SDN to Large-Scale Networks[C]∥In Proc.ONS,2013:75-79.

[7] Hildrum K,Kubiatowicz J D,Rao S,et al.Distributed

Object Location in a Dynamic Network[J].Theory of Computing Systems,2004,37(3): 405-440.

[8] Medved J,Varga R,Tkacik A,et al.Opendaylight:Towards a Model-driven Sdn Controller Architecture[C]∥2014 IEEE 15th International Symposium on.IEEE,2014: 1-6.

[9] Berde P,Gerola M,Hart J,et al.ONOS: Towards an Open,Distributed SDN OS[C]∥Proceedings of the Third Workshop on Hot Topics in Software Defined Networking.ACM,2014: 1-6.

[10] Demers A,Greene D,Hauser C,et al.Epidemic Algorithms for Replicated Database Maintenance[C]∥Proceedings of the Sixth Annual ACM Symposium on Principles of Distributed Computing.ACM,1987: 1-12.

[11] XIONG Xiaoping.Reliability Analysis and Optimal Design of Wide Area Communication Network in Power System [D].Guangxi：Guangxi University,2013.

[12] HUANG Wunyuan,HU Jenwei,LIN Shucheng. Design and Implementation of Automatic Network Topology Discovery System for International Multi-Domain Future Internet Testbed[J].Journal of Internet Technology,2013 ,14(2):181-183.

[13] OSPF Version2,RFC 2328[DB/OL].Available: https:∥tools.ietf.org/html/rfc2328.

[14] IS-IS Protocol Specification (IETF),RFC 1142[DB/OL].Available:http:∥tools.ietf.org/html/rfc1142.

[15] RIP Version2,RFC 2453[DB/OL].Available: https:∥tools.ietf.org/html/rfc2453.

[16] Dixit A,Hao F,Mukherjee S,et al.Towards an Elastic Distributed SDN Controller[C]∥In Proc.ACM SIGCOMM HotSDN,2013：7-12.

[17] McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow: Enabling Innovation in Campus Networks[J].ACM SIGCOMM Computer Communication Review,2008,38(2): 69-74.