楊帆，李呈，黃韜

（北京郵電大學網(wǎng)絡與交換技術國家重點實驗室，北京 100876）

OXP：一種面向SDN移動自組網(wǎng)的東西向協(xié)議

楊帆，李呈，黃韜

（北京郵電大學網(wǎng)絡與交換技術國家重點實驗室，北京 100876）

在SDN移動自組網(wǎng)絡中，有限的控制平面的可拓展性限制了網(wǎng)絡規(guī)模的發(fā)展，而目前的解決方案存在不同控制器間無法直接共存和接口協(xié)議效率低下的問題。為解決上述問題，本文設計了高效的、多模式、支持異構控制器協(xié)同工作的SDN控制平面東西向協(xié)議：開放性可變長協(xié)議。實驗結果證明，OXP可顯著降低通信開銷，為SDN移動自組網(wǎng)絡提供了高效的東西向協(xié)議，提高了SDN移動自組網(wǎng)的可拓展性。

軟件定義網(wǎng)絡； 控制平面；東西向協(xié)議；開放性可變長協(xié)議

1 簡介

隨著軟件定義網(wǎng)絡技術［1］的普及，基于SDN的移動自組網(wǎng)［2～4］成為研究熱點，例如基于SDN的車載移動自組網(wǎng)［5］，軍事移動自組網(wǎng)等。在SDN移動自組網(wǎng)中，控制器通過南向協(xié)議對數(shù)據(jù)平面移動設備進行集中管控，不僅可以簡化數(shù)據(jù)層面的轉(zhuǎn)發(fā)管理，而且還能提高無線資源利用率。當網(wǎng)絡規(guī)模增大時，由于控制器的可拓展性不足，單控制器無法滿足需求。為管理大規(guī)模網(wǎng)絡，需要部署協(xié)同工作的多控制器，這就對控制器間的通信接口提出了需求。

目前解決多控制器協(xié)作問題的解決方案主要有兩類：分布式控制器集群和東西向接口協(xié)議。對于第一類解決方案，目前主要有ONIX［6］、ONOS［7］等分布式控制器實現(xiàn)。然而分布式控制器的接口均為私有設計，所以彼此之間無法直接共存。對于第二類解決方案，目前主要有SDNi［8］、West-East Bridge［9］等幾種實現(xiàn)。然而SDNi提交的草案中并沒有詳細描述其工作流程，僅定義了基礎的概念。West-East Bridge可實現(xiàn)異構控制器之間的協(xié)同工作。在West-East Bridge中，當網(wǎng)絡視圖發(fā)生改變時，則需在所有同類節(jié)點中同步數(shù)據(jù)，導致消耗大量帶寬，效率低下。然而移動狀態(tài)下的控制器間的無線鏈路資源不充足，這對控制器東西向協(xié)議的效率提出了嚴格的要求，而現(xiàn)有的東西向協(xié)議無法滿足該場景的需求。

針對上述的問題，本文提出了一種面向SDN自組網(wǎng)的、高效的、支持異構控制器的東西向協(xié)議：OXP（Open eXchange， 開放性可變長協(xié)議）。OXP采用分層的控制平面來解決SDN網(wǎng)絡規(guī)模受限的問題，其將控制平面分為域間控制層和域內(nèi)控制層。其中域間控制器負責域間通信，而域內(nèi)控制器負責域內(nèi)通信。全網(wǎng)跨域路徑計算被劃分為域內(nèi)路徑計算和域間路徑計算兩部分，進而降低了全網(wǎng)路徑計算的復雜度。

OXP還設計了網(wǎng)絡抽象機制，通過將域內(nèi)網(wǎng)絡抽象成一個邏輯交換機，從而隱藏了域內(nèi)網(wǎng)絡內(nèi)部的細節(jié)。域內(nèi)控制器僅向域間控制器同步抽象邏輯交換機的信息，而無需同步真實網(wǎng)絡拓撲信息。通過網(wǎng)絡抽象機制，OXP不僅減少了通信開銷，更提高了網(wǎng)絡安全性。

此外，為適應復雜多樣的網(wǎng)絡場景，OXP還設計了高級、簡單、 壓縮和普通等多種模式。根據(jù)不同的網(wǎng)絡需求，可將OXP設置在合適模式，從而達到優(yōu)化的部署效果。例如，對于如移動自組網(wǎng)等鏈路資源不足的網(wǎng)絡環(huán)境，可使用OXP的壓縮模式，從而減少OXP通道的通信量，使其更滿足場景對資源的嚴格要求。

目前，OXP已經(jīng)被部署到了C-LAB［10］實驗網(wǎng)，并完成了下列兩個對比實驗：OXP和ONOS［7］開銷對比以及基于OXP部署跨域流量工程的對比實驗。實驗結果證明了（1）OXP支持多控制器協(xié)作，可通過設置不同模式去適應復雜多樣的網(wǎng)絡場景；（2）OXP是ONOS開銷的0.044倍，更適合于如移動自組網(wǎng)等鏈路資源不足的移動自組網(wǎng)絡場景；（3）基于OXP可實現(xiàn)跨域業(yè)務流量工程部署，可將域間鏈路利用率提升至99.8%。

2 OXP協(xié)議

OXP是一個高效的SDN控制平面東西向協(xié)議，其支持異構控制器協(xié)同工作、支持多模式、可被部署于鏈路資源不足的網(wǎng)絡環(huán)境。OXP采用分層架構，將SDN控制平面分為域間控制器和域內(nèi)控制器兩層。其中域內(nèi)控制器管理域內(nèi)網(wǎng)絡，而域間控制器管理域間網(wǎng)絡，圖1為OXP分層架構。

出于效率、隱私性和安全性等方面考慮，在OXP架構中，每個域內(nèi)網(wǎng)絡被抽象成一個邏輯交換機。域內(nèi)網(wǎng)絡僅僅向外界暴露其邊緣端口，而隱藏所有內(nèi)部網(wǎng)絡細節(jié)。對域間控制器而言，全局網(wǎng)絡拓撲僅由抽象邏輯交換機和域間鏈路組成。

當跨域請求到來時，域內(nèi)控制器將其發(fā)送給域間控制器。域間控制器將基于全局拓撲信息計算跨域路徑，并將回復報文發(fā)送給轉(zhuǎn)發(fā)路徑上途徑的邏輯交換機（即域內(nèi)網(wǎng)絡）。邏輯交換機收到轉(zhuǎn)發(fā)回復報文之后，需將其翻譯成對應南向報文并安裝到數(shù)據(jù)層面設備，從而完成跨域路徑通信。通過層級化管理的架構，跨域通信的路徑計算被分為：域內(nèi)路徑計算和域間路徑計算兩部分。

為支持多種復雜網(wǎng)絡場景，設計了高級、簡單、壓縮和普通4種主要的模式。當OXP控制通道的鏈路資源不充足時，可將OXP設置為簡單模式，從而減少對鏈路資源的消耗。反之，則可以將其設置為高級模式，從而換取最佳的跨域路徑計算結果。在壓縮模式下，業(yè)務報文將會被簡化成更簡單的報文，從而進一步減少通信數(shù)據(jù)量。因此，壓縮模式更適合如移動自組網(wǎng)等鏈路資源不足的網(wǎng)絡。反之，可使用簡單模式進行通信，從而保留全部的南向協(xié)議編程能力，使得可部署更復雜的跨域業(yè)務。

2.1域內(nèi)控制

圖1　OXP架構

在OXP架構中，域內(nèi)控制器需管理域內(nèi)網(wǎng)絡。每個域內(nèi)控制器均由唯一的域號來標識。建立OXP通道之后，域內(nèi)控制器需完成域內(nèi)網(wǎng)絡的抽象工作。此外，域內(nèi)控制器還需要根據(jù)OXP通道的設置，向域間控制器上傳特定的拓撲信息和主機信息。

2.1.1網(wǎng)絡抽象

網(wǎng)絡抽象不僅可以減少OXP的通信開銷，還可以提高域內(nèi)網(wǎng)絡的安全性。在OXP架構中，域內(nèi)網(wǎng)絡將被抽象為一個邏輯交換機。網(wǎng)絡抽象示意圖如圖2所示。域內(nèi)網(wǎng)絡的邊緣端口映射成邏輯交換機的虛擬端口，而邊緣端口之間的域內(nèi)路徑映射成邏輯交換機的端口之間的內(nèi)部通道。當OXP處于高級模式時，域內(nèi)控制器需要上傳邊緣端口之間的內(nèi)部通道信息，而在簡單模式時，則僅需上報邊緣端口的信息即可。

2.1.2鏈路發(fā)現(xiàn)

OXP架構中，鏈路分為域內(nèi)鏈路和域間鏈路兩種。域內(nèi)鏈路指的是域內(nèi)網(wǎng)絡的邊緣外向端口之間的域內(nèi)路徑，而域間鏈路則是不同域之間的鏈路。鏈路能力方面，OXP定義了跳數(shù)、帶寬和時延3種參數(shù)?？苫谝陨?種參數(shù)，進行跨域路徑計算。

域內(nèi)控制器通過發(fā)送含有鏈路號、 端口號、 域號、跨域端口號信息的LLDP報文來發(fā)現(xiàn)鏈路。若某端口收到包含其他域號的LLDP報文，域內(nèi)控制器則使用唯一的虛擬端口號標記該端口為邊緣外向端口。域內(nèi)控制器需將來自外向端口的LLDP報文上報給域間控制器，用于域間控制器發(fā)現(xiàn)域間鏈路。

2.2域間控制

在OXP架構中，域間控制器管理域間通信。網(wǎng)絡管理員可通過域間控制器主動或者被動地部署全局業(yè)務。域間控制器需收集邏輯交換機和域間鏈路的信息，從而構建抽象的全局拓撲。此外，為完成全局業(yè)務部署，域間控制器還需收集主機的位置信息。

2.2.1拓撲抽象

為管理跨域通信，域間控制器需要收集全局的抽象拓撲信息。經(jīng)過網(wǎng)絡抽象之后，全局網(wǎng)絡被簡化為由邏輯交換機和域間鏈路組成的抽象拓撲。拓撲信息如表1所示，其包含了域內(nèi)網(wǎng)絡和域間網(wǎng)絡鏈路的信息。域內(nèi)網(wǎng)絡包含域號， 域間鏈路和跨域端口等信息，而域間鏈路信息則包含了源域號，目的域號和域間鏈路容量三項數(shù)據(jù)。當OXP通道為簡單模式時，域內(nèi)網(wǎng)絡拓撲信息僅包含域號和跨域端口兩種信息及內(nèi)容。而當OXP通道為高級模式時，則包含表1中的全部信息及其內(nèi)容。

表1　拓撲抽象

2.2.2主機信息

圖2　OXP網(wǎng)絡抽象

為了定位目的主機的所屬域，域間控制器需收集全部的主機信息，其包括IP地址、MAC地址、掩碼和主機狀態(tài)。當域內(nèi)控制器發(fā)現(xiàn)新主機時，域內(nèi)控制器不僅會記錄其接入位置，還會將其信息同步給域間控制器。域間控制器將按照域號將其存儲在相應的數(shù)據(jù)結構中，方便計算路徑時查找。

2.3OXP通道

OXP通道是介于域間控制器和域內(nèi)控制器之間的通道，其支持簡單、高級、壓縮和普通等模式。各模式之間的功能差異如表2所示。根據(jù)特定的網(wǎng)絡場景，可將OXP通道設定為不同的模式。例如，當鏈路資源不足時，可設置為更加節(jié)省帶寬的簡單模式。而當資源充足時，可置于高級模式，從而換取更優(yōu)的路徑計算結果。

表2　OXP通道工作模式

簡單： 在簡單模式下，域內(nèi)控制器不記錄域間通路，也不會將其同步到域間控制器。在此模式中，域間控制器僅僅收集基礎的網(wǎng)絡信息，從而減少了通信數(shù)據(jù)量，簡化了路徑計算的流程，進而使得OXP更適用于如移動自組網(wǎng)等鏈路資源不足的網(wǎng)絡場景。

高級： 在高級模式下，域內(nèi)控制器不僅需要計算域間通路的能力，還需要將其異步上報給域間控制器。在此模式下，域間控制器收集了全局網(wǎng)絡信息，從而可以完成最佳的跨域路徑計算。但由于同步數(shù)據(jù)增多，高級模式對鏈路資源提出了更高的要求。

此外，OXP還為業(yè)務信息交換設計了壓縮模式和普通兩種模式。當鏈路資源不充足時，可將OXP 通道設置為壓縮模式，從而使用簡化的報文傳遞信息，進而降低了通信開銷。否則，可直接使用南向協(xié)議進行信息交換，從而保留全部的編程能力。

壓縮：在壓縮模式下，業(yè)務報文將被簡化為僅攜帶基本信息的簡單報文。比如，轉(zhuǎn)發(fā)請求將被簡化為僅攜帶｛源IP地址、目的IP地址、端口、掩碼、協(xié)議類型，QoS｝的簡單報文，而不使用類似于packet_in的南向報文。域間控制器也將回復僅攜帶 ｛源IP地址、目的IP地址、源跨域端口、目的跨域端口、掩碼、協(xié)議類型、QoS｝的簡單報文。因此，在此模式下同步數(shù)據(jù)得到了明顯的減少，從而顯著降低了鏈路資源的消耗，進而使得OXP可以被部署到對帶寬要求非常嚴格的場景。

普通：在此模式下，業(yè)務信息可直接通過南向協(xié)議的報文進行傳輸。出于安全性等方面考慮，域內(nèi)在發(fā)送報文之前，需要將報文的相關字段重寫成抽象之后的虛擬數(shù)據(jù)。由于普通模式下使用南向協(xié)議進行通信，所以保留了南向協(xié)議的全部編程能力。因此，在此模式下，可通過域間控制器部署更復雜業(yè)務。

3 仿真分析

3.1仿真部署

目前，OXP已經(jīng)在SDN控制器Ryu基礎上部署實現(xiàn)。為驗證OXP的可行性，本文將OXP部署在C-LAB［10］實驗網(wǎng)上，并進行了如下兩個實驗：（1）OXP與分布式控制器ONOS的通信開銷對比實驗；（2）基于OXP部署流量工程對比實驗。實驗拓撲包括由Mininet創(chuàng)建的4個域網(wǎng)絡，每個域網(wǎng)絡均由5個交換機和10個主機組成，分別由4個域內(nèi)控制器管理。并部署了域間控制器1臺。圖3為OXP仿真部署拓撲。

3.2結果分析

3.2.1OXP與分布式控制器ONOS通信開銷對比

圖3　OXP仿真部署拓撲

此實驗在同樣網(wǎng)絡拓撲上部署了4個ONOS實例去和OXP進行對比。實驗記錄了拓撲啟動階段和流量生成之階段的通信開銷數(shù)據(jù)，其實驗數(shù)據(jù)結果如下：在拓撲啟動階段，ONOS的通信開銷為1 355.07 kbyte，而OXP多模式平均數(shù)據(jù)為12.08 kbyte，最小開銷4.89 kbyte；在流量產(chǎn)生階段，ONOS的通信開銷為3 937.07 kbyte，而OXP多模式平均為222.23 kbyte，最小開銷89.33 kbyte。實驗結果證明：在拓撲啟動階段，ONOS的開銷平均是OXP的112.22倍。而在流量產(chǎn)生階段，ONOS平均是OXP的17.72倍， 是OXP最小開銷模式的44.07倍。在實驗總體通信開銷方面，ONOS是OXP平均的22.58倍。拓撲啟動階段的巨大差距主要原因是OXP采用了網(wǎng)絡抽象機制，從而減少了大量的域內(nèi)網(wǎng)絡內(nèi)部信息。而流量產(chǎn)生階段的差距原因在于OXP的分層架構以及壓縮模式等模塊的高效設計。此外，大量的心跳包是導致ONOS開銷過大的原因之一。由于分布式控制器通信開銷過大，所以其無法被部署在鏈路資源貧乏的網(wǎng)絡場景。相比之下，由于OXP高效的設計，更適合于部署在對通信開銷要求嚴格的網(wǎng)絡場景。

3.2.2基于OXP的跨域流量工程

本實驗完成了基于OXP部署了流量工程，其目的是驗證OXP可實現(xiàn)跨域流量優(yōu)化功能。在實驗中，域1啟動了5個主機作為Iperf客戶端去產(chǎn)生流量，并發(fā)送給域 4上的Iperf測試服務器。實驗記錄了流量傳輸過程中的跨域鏈路利用率，其實驗結果如圖4所示。當沒有部署任何流量工程時，數(shù)據(jù)流僅通過1條跨域路徑轉(zhuǎn)發(fā)，其域間鏈路利用率僅為49.8%。相比之下，當部署流量工程時，兩個域之間的兩條跨域路徑均被使用，其跨域路徑的鏈路利用率被提高到了99.8%，從而實現(xiàn)了跨域流量優(yōu)化。

實驗的結果表明OXP不僅可以實現(xiàn)多控制器的協(xié)同合作，還降低了通信開銷，是一種更高效的解決方案，適用于對開銷敏感的網(wǎng)絡場景；OXP的多模式設計使得OXP可以被應用于復雜多樣的網(wǎng)絡場景，甚至是極端惡劣的網(wǎng)絡環(huán)境；基于OXP可實現(xiàn)跨域業(yè)務的部署，完成跨域流量優(yōu)化。此外，網(wǎng)絡管理人員可以通過域間控制器輕易地部署主動的或者被動的跨域業(yè)務，從而降低全局網(wǎng)絡管理的難度。

圖4　跨域流量優(yōu)化對比

4 結論及未來工作

本文提出了面向SDN移動自組網(wǎng)的支持高效傳輸、支持異構控制器的東西向協(xié)議OXP，描述了OXP協(xié)議的設計目的、架構、實驗部署和性能分析。OXP通過提供豐富網(wǎng)絡的傳輸模式和網(wǎng)絡抽象能力，從而使得OXP可適應復雜多樣的網(wǎng)絡場景，尤其適合于如移動自組網(wǎng)等鏈路資源不充裕的網(wǎng)絡場景。實驗部署和性能對比分析證明了OXP的可行性和高效性。未來計劃將OXP部署到如ONOS等其他控制器上。此外，還計劃將OXP部署到如CENI等更大型的網(wǎng)絡上。

［1］ McKeown N. Keynote talk： Software-defined networking［J］. In Proc. of IEEE INFOCOM， 2009， 17（2）：30-32.

［2］ Yap K K， Kobayashi M， Sherwood R， et al. OpenRoads： Empowering research in mobile networks［J］. ACM SIGCOMM Computer Communication Review， 2010， 40（1）：125-126.

［3］ Murthy C S R， Manoj B S. Wireless networks： Architectures and protocols［M］. London： Pearson education， 2004.

［4］ Baskett P， Shang Y， Zeng W， et al. SDNAN： Software-defined networking in ad hoc networks of smartphones［C］. Las Vegas： Consumer Communications and Networking Conference （CCNC）， 2013：861-862.

［5］ Ku I， Lu Y， Gerla M， et al. Towards software-defined VANET：Architecture and services［C］. Los Angeles： Ad Hoc Networking Workshop （MED-HOC-NET）， 2014 13th Annual Mediterranean IEEE，2014： 103-110.

［6］ Koponen T， Casado M， Gude N， et al. Onix： A Distributed Control Platform for Large-scale Production Networks［C］. Vancouver：Operating Systems Design and Implementation （OSDI）， 2010：1-6.

［7］ Berde P， Gerola M， Hart J， et al. ONOS： towards an open，distributed SDN OS［C］. Chicago： Proceedings of the third workshop on hot topics in software defined networking ACM， 2014：1-6.

［8］ Yin H， Xie H， Tsou T， Lopez D， Aranda P A， Sidi R. SDNi： A message exchange protocol for software defined networks （SDNs） across multiple domains. IETF Internet-Draft， 2012.

［9］ Lin P， Bi J， Chen Z， et al. WE-bridge： West-East Bridge for SDN inter-domain network peering［C］. Toronto： IEEE Conference on Computer Communications Workshops （INFOCOM WKSHPS）， 2014：111-112.

［10］ C-lab test bed ［OL］. Available： http：//www.fnlab.org/.

OXP: An efficient west-east protocol for SDN in Ad hoc

YANG Fan， LI Cheng， HUANG Tao
（State Key Laboratory of Networking and Switching Technology， Beijing University of Posts and Telecommunications，Beijing 100876， China）

The limit scalability of control plane restrict the scale of Software-defi ned Ad Hoc. The current solutions neither coexist with different controllers nor provide hightransmission effi ciency. Thus， we propose an effi cient West-East protocol for software defi ned Ad hoc: Open eXchange protocol（OXP）， which supports heterogeneous controllers to cooperate together. We implemented OXP on the test bed to evaluate the performance. The result shows that OXP is a more effi cient protocol， which is more suitable for SDN in Ad Hoc.

software defi ned network； controller； est-east protocol； OXP

TN929.5

A

1008-5599（2016）09-0032-06

2016-08-23