一種低開銷自適應SD-UANET流表下發(fā)機制*

任 智，付澤亮，朱其政，周 楊，張本俊

(重慶郵電大學 通信與信息工程學院，重慶 400065)

0 引 言

無人機自組網(wǎng)(UAV Ad Hoc Network,UANET)是移動自組網(wǎng)的一個特例[1]，具有功能多樣性、靈活性[2]、易于安裝部署和相對較小的運營費用等優(yōu)勢，在軍事和民用領域得到了廣泛應用[3-5]。而軟件定義網(wǎng)絡(Software Defined Network，SDN)是一種新型的網(wǎng)絡體系結(jié)構,其通過OpenFlow技術來實現(xiàn)網(wǎng)絡控制面與數(shù)據(jù)面的分離,從而達到對網(wǎng)絡流量的靈活控制，目前已成為下一代互聯(lián)網(wǎng)的研究熱點，其應用有效彌補了傳統(tǒng)網(wǎng)絡結(jié)構過于扁平化、安全防護手段單一的弊端,在提升網(wǎng)絡安全等級、降低運維管理難度方面優(yōu)勢突出。因此利用SDN中集中控制的思想，將SDN新架構思想引入無人機自組網(wǎng)，以便解決隨著無人機技術的發(fā)展，無人機所擔負的任務的復雜化和多元化時，能更好更快地掌控無人機群網(wǎng)絡狀態(tài)，并同時根據(jù)無人機自組網(wǎng)的特性對SDN中流表下發(fā)機制進行改進，使其網(wǎng)絡性能更加優(yōu)異。

文獻[6]針對UANET 高動態(tài)、不穩(wěn)定的空中無線鏈路和無人機碰撞的特性提出了SD-UANET 架構。文獻[7]提出了一種面向SD-MANET的拓撲發(fā)現(xiàn)方法,利用連通支配集算法生成骨干網(wǎng)絡,由骨干節(jié)點將局部拓撲信息通過上行通路上報給SDN控制器，其通過限制向控制器上報局部拓撲信息的節(jié)點數(shù)量來降低拓撲信息收集過程中產(chǎn)生的額外開銷。文獻[8]嘗試在智能手機的無線自組織網(wǎng)絡上實現(xiàn)軟件定義網(wǎng)絡，使其模塊化的自組織網(wǎng)絡管理結(jié)構易于修改和擴展。文獻[9]提出在網(wǎng)絡規(guī)模較大且網(wǎng)絡拓撲變化劇烈的情況下，引用多控制器的SDWM組網(wǎng)架構，將數(shù)據(jù)平面分割成多個域且每個域都有網(wǎng)絡轉(zhuǎn)發(fā)設備，然后每個控制器掌控一個域，實現(xiàn)域與域之間的聯(lián)通；同時提出了一種具有啟發(fā)性的信道分配算法，通過周期性的利用AP的頻帶利用率為其分配不同帶寬的信道，成功提高了信道利用率，提升了網(wǎng)絡的系統(tǒng)吞吐量。文獻[10]在此背景下，提出了一種基于軟件定義網(wǎng)絡的fanet拓撲管理(簡稱STFANET)。它是一種協(xié)調(diào)協(xié)議，包含了一種高效的基于SDN的無人機通信和一組拓撲管理算法，目標是建立和維護一個FANET拓撲結(jié)構，以便通過中繼單元在執(zhí)行個人或協(xié)作任務的獨立節(jié)點之間提供穩(wěn)定可靠的通信鏈接。

通過研究以上發(fā)現(xiàn)，現(xiàn)有文獻針對OpenFlow v1.5協(xié)議在無人機自組網(wǎng)環(huán)境下的多跳流表下發(fā)機制與flow_mod包結(jié)構的兼容性問題的研究較少且存在如下問題：原協(xié)議流表下發(fā)機制針對拓撲變換平緩的有線網(wǎng)絡，主動流表下發(fā)只是網(wǎng)絡剛建立時觸發(fā)，在運行過程中主要采用向控制器問路的被動流表下發(fā)方式進行尋路，而無人機自組網(wǎng)場景中網(wǎng)絡拓撲復雜多變，被動流表下發(fā)方式增加了流表獲取的時間同時增大了開銷；無人機自組網(wǎng)環(huán)境中節(jié)點繁多，相應的流表項條目也隨之增多，原協(xié)議采用flow_mod消息進行單播下發(fā)，導致冗余的頭部開銷與源、目的元組開銷過多，單播也會導致無線資源利用率下降，從而使網(wǎng)絡吞吐量下降。

為了解決原協(xié)議在無人機自組網(wǎng)中不兼容以及開銷較大的問題，本文提出了一種低開銷自適應軟件定義無人機自組網(wǎng)流表下發(fā)機制，通過流表周期性主動下發(fā)、組播切包去尾與流表項源、目的元組自適應壓縮，在無人機自組網(wǎng)場景下極大減小了流表下發(fā)的開銷，提高了網(wǎng)絡吞吐量。

1 網(wǎng)絡模型與流表結(jié)構

1.1 網(wǎng)絡模型

基于無人機自組網(wǎng)的特點，在軟件定義無人機自組網(wǎng)中，使任一節(jié)點為控制器節(jié)點，其中含有控制器軟件，計算并掌握全局網(wǎng)絡拓撲并周期下發(fā)流表；而無人機自組網(wǎng)中其他所有的任意節(jié)點均為交換機節(jié)點，如圖1所示，使得自組網(wǎng)中每個節(jié)點都有到整個網(wǎng)絡的流表。

圖1 軟件定義無人機自組網(wǎng)網(wǎng)絡模型

1.2 流表結(jié)構

在OpenFlow v1.5中，flow_mod包中的匹配域ofp_match部分共涵蓋了從物理層到運輸層等45個元組，但是比起OpenFlow v1.0中的匹配域ofp_match部分來說，采用的OXM TLV(type-lenth-value)變長形式，可以自適應地使用所需的元組，減少了不必要的開銷，如圖2所示。

圖2 ofp_flow_mod及ofp_match包格式圖

由于在無人機自組網(wǎng)的場景下沒有類似傳統(tǒng)SDN有線網(wǎng)絡中的物理端口，因此將flow_mod包中的出端口out_port改為out_ip，指導flow_mod包的流向；在匹配域ofp_match中，主要使用ETH_DST、ETH_SRC、IPV4_SRC、IPV4_DST這4個元組，而由于無線鏈路條件的限制，應盡量減少開銷，因此舍棄以太網(wǎng)的源、目的元組，同時增設IP地址的下一跳地址來彌補以太網(wǎng)地址的功能。

2 問題描述

在控制器節(jié)點到某交換機節(jié)點存在多跳的情況中，若采取傳統(tǒng)的流表下發(fā)模式，控制器無人機節(jié)點會采用單播的方式，將每個交換機的流表分發(fā)給每一個交換機無人機節(jié)點，這樣會多出許多頭部開銷并使問路消息(Packet-in消息)增多，且各類消息較多會造成無線鏈路環(huán)境不穩(wěn)定。因此考慮采取組播切包的策略，在此種鏈路情況下進行流表下發(fā)。

在組播切包的策略的基礎上，可以發(fā)現(xiàn)組播發(fā)包會導致flow_mod包過大，特別是在一條鏈路上節(jié)點多的情況下會導致切包次數(shù)變多，從而增加了頭部的開銷，也為切包組包增加了困難?？梢园l(fā)現(xiàn)，流表下發(fā)時，每條ofp_match流表匹配域都包含源地址、目的地址等相關信息，然而對于同一交換機節(jié)點來說源地址部分就會產(chǎn)生浪費,同時對于網(wǎng)內(nèi)每一個交換機節(jié)點來說它們到網(wǎng)中的其他節(jié)點的目的元組也重復了一部分。

3 低開銷自適應流表下發(fā)機制

3.1 流表組播下發(fā)切包重組去尾策略

針對控制器節(jié)點到某交換機節(jié)點存在多跳的情況下，原OpenFlow v1.5協(xié)議中flow_mod通過單播逐一為每個交換機下發(fā)流表，會導致無線鏈路的不穩(wěn)定、多余的頭部開銷與無線資源利用率不高的問題，采用組播下發(fā)流表切包重組策略。本策略基本思路為：控制器節(jié)點在將流表主動分發(fā)到網(wǎng)絡中各個交換機的過程中，如果能夠使用組播方式，通過一個控制包向多個交換機發(fā)送流表，則采用組播方式替代原來的單播方式進行流表分發(fā)；在組播分發(fā)的過程中，根據(jù)節(jié)點的梯度(即節(jié)點距離控制器的跳數(shù))，采用由近及遠的分發(fā)原則以便保障在需要時有流表可用，且每經(jīng)過一個節(jié)點都進行去尾工作，盡量減少下一次轉(zhuǎn)發(fā)的開銷；當無線鏈路條件只能裝載部分組播流表時，流表和流表項可以分拆；但分拆后總的控制包的開銷相比于流表單播情況下的控制包的開銷不能增加，如果通過計算發(fā)現(xiàn)總開銷增加則不進行組播下發(fā)，而采取單播下發(fā)的方式。

在組播過程中，由于無線鏈路資源有限，選擇對組播包進行分片切包發(fā)送。為了便于分片后的組播包完整無錯的合成，需要對OpenFlow包頭結(jié)構進行適當?shù)母倪M優(yōu)化。首先OpenFlow包頭結(jié)構所有字段全部保留，不作刪減，但是縮減xid字段的大小由原先的4 B的長度縮為2 B，空余出的2 B用來進行切包組包工作，這樣既不增加頭部開銷同時也具有了切包組包的能力。OpenFlow新舊包頭對比如圖3所示。

圖3 OpenFlow新舊頭部對比圖

OpenFlow包頭結(jié)構最后2個字節(jié)16位為cut-package，其中前三位是標志，標志的最低位記為MF，MF為1，表示后面“還有分片”，MF為0則表示這是若干分片的最后一個；標志字段中間一位記為DF，DF為1代表“不能分片”，DF為0時才允許分片；標志的最后一位暫時不做安排；后13位是片偏移，代表某分片在原包的什么位置。

本策略基本步驟如下：

Step1 控制器獲取全局拓撲并計算全局路由后，生成相關匹配域，若滿足組播下發(fā)條件，則給一條鏈路最遠端(即最大梯度節(jié)點)交換機節(jié)點發(fā)送flow_mod包，將out_ip填充去最遠端節(jié)點的下一跳地址，同時攜帶這條鏈路上其他交換機節(jié)點的ofp_match匹配域和匹配域?qū)膶傩?，形成flow_mod組播包，然后根據(jù)無線鏈路的資源進行切包發(fā)出，每個分片都帶有相同的OpenFlow新包頭、 xid、標志位和不同的片偏移，以便到達第一個交換機時進行正確的組包。

Step2 當flow_mod包所有分片到達第一個交換機時，將所有xid相同的分片通過標志信息和片偏移重新組合成一個完整正確的包。然后，交換機提取匹配域中源地址是本機的ofp_match，并刪除flow_mod包中源地址是本機的ofp_match部分，進行去尾，此時flow_mod包比在控制器時少了一個交換機的流表，計算已經(jīng)去尾的flow_mod包的大小，若無線鏈路資源仍不夠用，置DF為1，表示仍然需要切包轉(zhuǎn)發(fā)；反之，若無線鏈路資源夠用，置DF為0，表示不需再切包。而包的流向out_ip則根據(jù)flow_mod包中剩余的ofp_match中梯度最大的值的地址作為目的節(jié)點，并查找剛剛提取的ofp_match，獲得到最大梯度節(jié)點的下一跳地址，并存入out_ip，最后將剩余重組的flow_mod組播包進行轉(zhuǎn)發(fā)。

Step3 接下來此條鏈路上的交換機節(jié)點皆如第一個交換機節(jié)點一樣對flow_mod包進行處理，直到flow_mod包中的ofp_match部分刪完，且flow_mod包到達最遠端交換機節(jié)點結(jié)束。

通過以上步驟，可以使flow_mod包與OpenFlow包頭在不增加額外開銷的情況下進行切包組包并將各交換機節(jié)點流表下發(fā)。

3.2 流表源、目的地址自適應壓縮策略

針對組播flow_mod消息中ofp_match匹配域中流表信息的重復冗余的問題，在不影響需要發(fā)送的流表完整性的情況下，通過對流表的自適應壓縮，自適應地減少多余的源地址與目的地址元組，從而減少組播包的開銷與組播包在傳輸時的切包次數(shù)。

流表自適應壓縮策略的基本思路為：在組播中，對于一個交換機節(jié)點的多個流表而言，源地址重復占用開銷，因此使匹配域中每個交換機節(jié)點的源地址只有一個，這一個源地址對應其到多個交換機的多個下一跳地址、跳數(shù)與流表屬性，這樣每個交換機節(jié)點都可節(jié)省多個源地址的開銷。對于多個交換機節(jié)點的多個流表而言，目的地址也是一致的，因此只需要一份總的目的地址的信息，這樣又將減少多個目的地址的開銷。

對于一條鏈路上N個交換機節(jié)點、N-1個多跳交換機節(jié)點，流表壓縮與flow_mod組播包生成步驟如下：

Step1 控制器節(jié)點計算全局路由之后，首先存一份所有網(wǎng)絡節(jié)點的地址作為一份目的地址放入組播包的匹配域。

Step2 控制器節(jié)點得知一條多跳鏈路上最遠端節(jié)點梯度為N后，首先將此條鏈路最遠端節(jié)點的源地址存一份到匹配域中，然后將最遠端節(jié)點到自組網(wǎng)內(nèi)其他節(jié)點的下一跳地址對應其屬性按照Step 1中目的地址的順序依次存入組播包中。

Step3 控制器節(jié)點查找全局路由表，找到從自己到最遠端節(jié)點的路由，找到目的節(jié)點的前一跳節(jié)點地址prev_addr，此節(jié)點距控制器節(jié)點梯度為N-1，與Step 2一樣，存一份prev_addr地址到組播包的匹配域中，然后將此節(jié)點到網(wǎng)內(nèi)其他節(jié)點的所有流表對應其屬性依次存入組播包中。

Step4 重復Step 3的流程，找到梯度為N-2一直到梯度為1的節(jié)點，依次存入組播包中。

Step5 組播包生成完成，流表自適應壓縮完成。

通過以上的步驟，可以實現(xiàn)流表的自適應壓縮，有效地利用有限的無線資源，減少流表下發(fā)時的總開銷。

4 驗證分析

4.1 理論性能分析

在理論性能分析中，主要將OpenFlow v1.5的flow_mod包在無線網(wǎng)絡下進行單播下發(fā)與本文機制的流表組播下發(fā)進行理論上的開銷性能比較，后續(xù)在仿真中對開銷和其他網(wǎng)絡性能進行實驗驗證。

理論性能分析中，MTU為無線信道的單次傳輸?shù)淖畲髠鬏攩卧?假設MTU至少大于單個flow_mod包長，不然單播也要切包，沒有意義)；N為此條鏈路上控制器節(jié)點到最遠端所需的跳數(shù)與交換機節(jié)點個數(shù)，也就是表示每個交換機節(jié)點都最少收到N條流表項，包括此交換機節(jié)點到控制器節(jié)點與到此網(wǎng)絡中其他N-1個節(jié)點；Lofp_header為OpenFlow包頭長度，Lflow_mod為flow_mod包長度，

Lflow_mod=Lattribute+Lofp_match，

(1)

Lattribute為一條流表項的屬性，Lofp_match為匹配域，其中包括OXM格式匹配域頭部(Lmatch_header)與OXM的源(LOXM_SRC)、目的(LOXM_DST)與下一跳IP地址(LOXM_NEXT)這3個元組。單個交換機節(jié)點所接收flow_mod包長如公式(3)所示：

Lofp_match=Lmatch_header+LOXM_SRC+LOXM_DST+LOXM_NEXT，

(2)

L單=N(Lattribute+Lofp_match) 。

(3)

給一條鏈路最遠端節(jié)點下發(fā)流表需要先將最遠端節(jié)點鏈路上的前N-1跳節(jié)點全部下發(fā)完畢，才能發(fā)到最遠端，因此流表下發(fā)到最遠端節(jié)點所需的總開銷為給這條鏈路上所有節(jié)點下發(fā)的所有單個節(jié)點的多條流表項的開銷之和。

單播下發(fā)流表總開銷如公式(4)所示：

(4)

流表組播下發(fā)時flow_mod包長如公式(5)所示，nrf為已經(jīng)過的交換機節(jié)點個數(shù)。

L組播=N2Lflow_mod-nrfNLflow_mod。

(5)

流表組播下發(fā)每一跳的切包次數(shù)如公式(6)所示：

(6)

(7)

流表組播下發(fā)到最遠端節(jié)點的總開銷可通過3.1節(jié)策略并考慮切包后的頭部推算出來，如公式(8)所示：

(8)

根據(jù)3.2節(jié)的流表自適應壓縮策略，每個節(jié)點的所有流表總flow_mod包長度如公式(9)所示，包括N條流表項的屬性與下一跳IP地址、1份源IP地址。

L單flow_mod=NLattribute+LOXM_SRC+NLOXM_NEXT。

(9)

自適應流表壓縮flow_mod組播下發(fā)時包長如公式(10)所示，包括N+1個目的地址與1個匹配域包頭，nrf為已經(jīng)過的交換機節(jié)點個數(shù)。

L流表壓縮組播=(NL單flow_mod+(N+1)LOXM_DST+Lmatch_header)-

nrfL單flow_mod

(10)

自適應流表壓縮組播下發(fā)每一跳的切包次數(shù)如公式(11)所示，ncut_packet取值如公式(7)所示。

(11)

由上述分式可推算出加上流表自適應壓縮策略的總開銷如公式(12)所示：

(12)

根據(jù)以上開銷公式，將2.2中流表結(jié)構與包結(jié)構模型的大小代入其中，可以得出計算結(jié)果如下：

C單播=38(N3+N2)，

(13)

(14)

(15)

通過單播流表下發(fā)與組播流表下發(fā)比較可得

(16)

由公式(16)可知，只需比較(MTU-8)(4MTU-304)部分即可。根據(jù)圖4(a)可得出結(jié)論：當MTU小于76 B并大于8 B時原協(xié)議單播開銷比組播流表下發(fā)開銷小,但單個flow_mod包加OpenFlow頭部開銷剛好是76 B，因此，組播流表下發(fā)在開銷方面比原協(xié)議單播下發(fā)有一定的提升。

圖4 理論開銷對比圖

在以上分析的前提下，比較組播流表下發(fā)與流表自適應壓縮的組播下發(fā)可得

(17)

由公式(17)可知，只需比較(-5N2+N+8)部分即可。根據(jù)圖4(b)可得出結(jié)論：當節(jié)點數(shù)(或梯度)N大于等于2個時，流表自適應壓縮后的開銷比正常組播下發(fā)有較大提升。

4.2 仿真驗證分析

使用Windows 7系統(tǒng)平臺上的OPENET 14.5仿真軟件對本文機制進行仿真驗證，仿真參數(shù)設置如表1所示，設置了5個仿真場景，仿真時間為100 s；節(jié)點數(shù)分別為5、10、15、20、25個，節(jié)點在1 500 m×1 500 m的矩形區(qū)域鏈狀分布，節(jié)點移動速度為15 m/s，最大傳輸單元MTU為1 500 B；數(shù)據(jù)包長為512 B，flow_mod包消息周期為10 s，其中hello消息周期為5 s，tc消息周期為15 s，hello消息與tc消息用來進行無人機自組網(wǎng)場景下的鏈路發(fā)現(xiàn)，類似于SDN中的鏈路發(fā)現(xiàn)協(xié)議(Link Layer Discovery Protocol，LLDP)。

表1 主要仿真參數(shù)

4.2.1 網(wǎng)絡控制開銷

圖5表明，使用自適應流表壓縮組播下發(fā)機制在開銷方面比原協(xié)議中單播下發(fā)流表有著明顯改善，在節(jié)點數(shù)為25個時，流表壓縮組播下發(fā)相較于原協(xié)議節(jié)省了33.69%的開銷，且節(jié)點數(shù)越多，節(jié)省的開銷就越多。原因在于，首先是組播策略節(jié)省了部分頭部開銷，且節(jié)點數(shù)越多，節(jié)省的頭部開銷就越多；然后便是源、目的地址自適應壓縮策略，去除了多余源、目的地址的冗余，同樣也是節(jié)點數(shù)越多，自適應壓縮的源、目的地址就越多，節(jié)省了大部分的開銷。

圖5 控制開銷仿真對比圖

4.2.2 平均端到端時延

圖6表明，在節(jié)點為25個時，使用兩種策略的系統(tǒng)相較于原協(xié)議數(shù)據(jù)包平均端到端時延方面降低約12.42%，且節(jié)點數(shù)越多端到端時延減少的越明顯。原因在于，拓撲發(fā)生變化，原協(xié)議找不到路由時需攜帶部分數(shù)據(jù)包或完整數(shù)據(jù)包向控制器節(jié)點問路，但由于拓撲變化，可能找不到去控制器節(jié)點的路由，因此時延大大增加；而組播下發(fā)流表與壓縮流表下發(fā)的方式是周期性的，可減少向控制器問路情況，從而降低時延；且隨著節(jié)點數(shù)的增多，原協(xié)議會更不好問路，導致端到端時延更長；而組播下發(fā)流表與壓縮流表下發(fā)的方式端到端時延幾乎一致，是因為這兩種下發(fā)流表方式的區(qū)別僅在于壓縮組播更節(jié)省下發(fā)流表時的開銷，但是這兩種方式下發(fā)流表的機制是一樣的，都是將單播的flow_mod包進行組播切包轉(zhuǎn)發(fā)。

圖6 端到端時延仿真對比

4.2.3 吞吐量

圖7表明，在節(jié)點為25個時，使用兩種策略的系統(tǒng)相較于原協(xié)議數(shù)據(jù)包吞吐量方面提升約9.29%。原因在于，通過組播下發(fā)流表機制，各節(jié)點擁有到目的節(jié)點的匹配域更長，數(shù)據(jù)包根據(jù)匹配域轉(zhuǎn)發(fā)的次數(shù)也就更多，吞吐量也就越高；且由于網(wǎng)絡規(guī)模的增大與時間的增加，吞吐量也會隨之降低，這就導致單播情況下的吞吐量相對于低時延的無人機場景可能達不到預期，而組播相對于單播有所提升，能更好地適應于無人機場景。

圖7 吞吐量仿真對比圖

4.2.4 丟包率

圖8表明，使用組播下發(fā)流表策略相較于原協(xié)議單播下發(fā)流表丟包更少，且兩種組播下發(fā)方式丟包率相差不大，在節(jié)點數(shù)為25個時本機制相較于原協(xié)議丟包率降低15.33%。原因在于，組播下發(fā)是周期性的，各交換機節(jié)點無到指定地址的匹配域的時間段較少且短，而兩種組播下發(fā)方式丟包率相差不大是因為它們核心機制一樣，只是壓縮組播下發(fā)更加節(jié)省了開銷，但是這兩種方式下發(fā)流表的機制是一樣的，都屬于將單播的flow_mod包進行組合切包轉(zhuǎn)發(fā)這種方式，因此兩種組播下發(fā)方式丟包率相差不大；而原協(xié)議單播下發(fā)流表，由于拓撲的變化，交換機找不到控制器節(jié)點，這樣會導致隨著節(jié)點數(shù)的增加丟包率上升越快。

5 結(jié)束語

本文通過對OpenFlow v1.5中flow_mod包與其所包含匹配域的基礎上，提出了一種低開銷自適應的組播流表下發(fā)機制，使其更加適應于無線自組網(wǎng)絡中多跳復雜的網(wǎng)絡情況。該機制給最遠端節(jié)點下發(fā)流表時，通過連帶的形式將這條鏈路上所有節(jié)點的流表一同組播下發(fā)，并在流表下發(fā)的過程中進行去尾，最后對繁多的匹配域的源地址、目的地址進行自適應壓縮。理論與仿真實驗證明，此機制極大地降低了開銷并提升了無人機自組網(wǎng)的穩(wěn)定性，進一步提升了網(wǎng)絡性能。

下一步將繼續(xù)對無線中OpenFlow協(xié)議的控制器尋路算法進行深入研究，使其能更快地尋找全局拓撲并減少尋找全局拓撲時的冗余開銷。