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

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

0 引 言

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

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

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

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

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

1.1 網(wǎng)絡(luò)模型

基于無(wú)人機(jī)自組網(wǎng)的特點(diǎn)，在軟件定義無(wú)人機(jī)自組網(wǎng)中，使任一節(jié)點(diǎn)為控制器節(jié)點(diǎn)，其中含有控制器軟件，計(jì)算并掌握全局網(wǎng)絡(luò)拓?fù)洳⒅芷谙掳l(fā)流表；而無(wú)人機(jī)自組網(wǎng)中其他所有的任意節(jié)點(diǎn)均為交換機(jī)節(jié)點(diǎn)，如圖1所示，使得自組網(wǎng)中每個(gè)節(jié)點(diǎn)都有到整個(gè)網(wǎng)絡(luò)的流表。

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

1.2 流表結(jié)構(gòu)

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

圖2 ofp_flow_mod及ofp_match包格式圖

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

2 問(wèn)題描述

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

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

3 低開(kāi)銷(xiāo)自適應(yīng)流表下發(fā)機(jī)制

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

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

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

圖3 OpenFlow新舊頭部對(duì)比圖

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

本策略基本步驟如下：

Step1 控制器獲取全局拓?fù)洳⒂?jì)算全局路由后，生成相關(guān)匹配域，若滿(mǎn)足組播下發(fā)條件，則給一條鏈路最遠(yuǎn)端(即最大梯度節(jié)點(diǎn))交換機(jī)節(jié)點(diǎn)發(fā)送flow_mod包，將out_ip填充去最遠(yuǎn)端節(jié)點(diǎn)的下一跳地址，同時(shí)攜帶這條鏈路上其他交換機(jī)節(jié)點(diǎn)的ofp_match匹配域和匹配域?qū)?yīng)的屬性，形成flow_mod組播包，然后根據(jù)無(wú)線(xiàn)鏈路的資源進(jìn)行切包發(fā)出，每個(gè)分片都帶有相同的OpenFlow新包頭、 xid、標(biāo)志位和不同的片偏移，以便到達(dá)第一個(gè)交換機(jī)時(shí)進(jìn)行正確的組包。

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

Step3 接下來(lái)此條鏈路上的交換機(jī)節(jié)點(diǎn)皆如第一個(gè)交換機(jī)節(jié)點(diǎn)一樣對(duì)flow_mod包進(jìn)行處理，直到flow_mod包中的ofp_match部分刪完，且flow_mod包到達(dá)最遠(yuǎn)端交換機(jī)節(jié)點(diǎn)結(jié)束。

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

3.2 流表源、目的地址自適應(yīng)壓縮策略

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

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

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

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

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

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

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

Step5 組播包生成完成，流表自適應(yīng)壓縮完成。

通過(guò)以上的步驟，可以實(shí)現(xiàn)流表的自適應(yīng)壓縮，有效地利用有限的無(wú)線(xiàn)資源，減少流表下發(fā)時(shí)的總開(kāi)銷(xiāo)。

4 驗(yàn)證分析

4.1 理論性能分析

在理論性能分析中，主要將OpenFlow v1.5的flow_mod包在無(wú)線(xiàn)網(wǎng)絡(luò)下進(jìn)行單播下發(fā)與本文機(jī)制的流表組播下發(fā)進(jìn)行理論上的開(kāi)銷(xiāo)性能比較，后續(xù)在仿真中對(duì)開(kāi)銷(xiāo)和其他網(wǎng)絡(luò)性能進(jìn)行實(shí)驗(yàn)驗(yàn)證。

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

Lflow_mod=Lattribute+Lofp_match，

(1)

Lattribute為一條流表項(xiàng)的屬性，Lofp_match為匹配域，其中包括OXM格式匹配域頭部(Lmatch_header)與OXM的源(LOXM_SRC)、目的(LOXM_DST)與下一跳IP地址(LOXM_NEXT)這3個(gè)元組。單個(gè)交換機(jī)節(jié)點(diǎn)所接收f(shuō)low_mod包長(zhǎng)如公式(3)所示：

Lofp_match=Lmatch_header+LOXM_SRC+LOXM_DST+LOXM_NEXT，

(2)

L單=N(Lattribute+Lofp_match) 。

(3)

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

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

(4)

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

L組播=N2Lflow_mod-nrfNLflow_mod。

(5)

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

(6)

(7)

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

(8)

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

L單flow_mod=NLattribute+LOXM_SRC+NLOXM_NEXT。

(9)

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

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

nrfL單flow_mod

(10)

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

(11)

由上述分式可推算出加上流表自適應(yīng)壓縮策略的總開(kāi)銷(xiāo)如公式(12)所示：

(12)

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

C單播=38(N3+N2)，

(13)

(14)

(15)

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

(16)

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

圖4 理論開(kāi)銷(xiāo)對(duì)比圖

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

(17)

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

4.2 仿真驗(yàn)證分析

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

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

4.2.1 網(wǎng)絡(luò)控制開(kāi)銷(xiāo)

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

圖5 控制開(kāi)銷(xiāo)仿真對(duì)比圖

4.2.2 平均端到端時(shí)延

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

圖6 端到端時(shí)延仿真對(duì)比

4.2.3 吞吐量

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

圖7 吞吐量仿真對(duì)比圖

4.2.4 丟包率

圖8表明，使用組播下發(fā)流表策略相較于原協(xié)議單播下發(fā)流表丟包更少，且兩種組播下發(fā)方式丟包率相差不大，在節(jié)點(diǎn)數(shù)為25個(gè)時(shí)本機(jī)制相較于原協(xié)議丟包率降低15.33%。原因在于，組播下發(fā)是周期性的，各交換機(jī)節(jié)點(diǎn)無(wú)到指定地址的匹配域的時(shí)間段較少且短，而兩種組播下發(fā)方式丟包率相差不大是因?yàn)樗鼈兒诵臋C(jī)制一樣，只是壓縮組播下發(fā)更加節(jié)省了開(kāi)銷(xiāo)，但是這兩種方式下發(fā)流表的機(jī)制是一樣的，都屬于將單播的flow_mod包進(jìn)行組合切包轉(zhuǎn)發(fā)這種方式，因此兩種組播下發(fā)方式丟包率相差不大；而原協(xié)議單播下發(fā)流表，由于拓?fù)涞淖兓?，交換機(jī)找不到控制器節(jié)點(diǎn)，這樣會(huì)導(dǎo)致隨著節(jié)點(diǎn)數(shù)的增加丟包率上升越快。

5 結(jié)束語(yǔ)

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

下一步將繼續(xù)對(duì)無(wú)線(xiàn)中OpenFlow協(xié)議的控制器尋路算法進(jìn)行深入研究，使其能更快地尋找全局拓?fù)洳p少尋找全局拓?fù)鋾r(shí)的冗余開(kāi)銷(xiāo)。