OLSRv2壓縮機制在自組織網絡中的應用

翟 巍，李大雙，姜永廣

(中國電子科技集團公司第三十研究所，四川成都610041)

0 引言

鏈路狀態路由與距離矢量機制相比由于開銷相對較大，不適合于低速移動戰術Ad Hoc網絡。但是，鏈路狀態路由協議具有一定的優勢，例如，能夠通過路由協議建立的全局拓撲表為指揮員提供全局的戰術單位連通拓撲態勢信息，能夠通過鏈路狀態信息更好地支持服務質量(QoS)的控制機制，能夠更好地支持戰術網絡的拓撲控制，在定向波束通信網絡中針對不同方向鏈路分別實施功率控制，通過全局最短代價計算在解決與避免路由環路方面比距離矢量路由機制更有優勢等。隨著傳輸速率達到幾Mb/s甚至幾十Mb/s的寬帶戰術電臺、定向波束傳輸電臺的出現與部署應用［1］，現代高速電臺幾乎都實現了基于多點中繼(MPR)的優化鏈路狀態路由協議(OLSRv1)［2］。

盡管戰術無線網絡在向帶寬高速的方向發展，但戰術應用的需求增長更快，其帶寬資源仍然不夠使用。傳統的鏈路狀態路由開銷較大，并且隨著戰術網絡規模的擴大鏈路狀態路由泛洪開銷仍然是一個嚴重的問題。因此，OLSRv2［3］所采取的地址塊格式壓縮機制對于鏈路狀態路由機制在大規模戰術網絡中的應用十分重要。

與OLSRv1相比，OLSRv2的主要進步是采取了先進的消息壓縮格式和更優化的MPR算法，這種路由消息壓縮機制能夠大大地降低路由泛洪的開銷。IETF MANET(移動Ad Hoc網絡)論壇對OLSR的工作機制進行了功能上的分割與剝離，分別拆解為移動Ad Hoc網絡分組與消息的通用格式(RFC5444)即、移動Ad Hoc網絡多值時間表示(RFC5497)以及移動Ad Hoc網絡鄰節點發現協議(RFC6130)3個基礎性 RFC 規范與 OLSRv2草案［4－6］。目前，已提出了單獨的路由MPR優化改進算法草案，并且OLSRv2草案已進展到最后版本狀態，等待IETF分配正式的規范編號，預計很快成為正式的RFC規范(即OLSRv2 RFC文檔)。

1 RFC5444的壓縮格式

OLSRv2路由協議實現路由泛洪開銷壓縮的主要方法是高壓縮效率的地址塊表示格式。此外，也采取了使拓撲消息泛洪范圍(連通控制集合(CDS))更小的、更優化的多點中繼算法。文中主要研究如何充分利用地址塊壓縮格式來減小路由泛洪開銷的組網方法，對于比OLSRv1更先進的MPR算法，不是文中研究的重點。

1.1 地址塊壓縮格式

RFC5444的分組與消息格式壓縮能力主要由地址塊壓縮機制體現。分組除了包含分組頭以外，還可以包含一個或多個消息。一個消息包含有一個消息頭、一個消息TLV(類型－長度－值)塊、零個或更多個的地址塊以及一個地址塊TLV塊。

一個地址由長度為地址長度(address－length)個字節、以Head:Mid:Tail形式表示的一個序列指示。Head、Mid或Tail不與任何語義相關聯，Head指示了地址塊內所有地址相同的頭部字節內容，Mid指示了地址塊內這些地址中間部分的字節內容，Tail指示了地址塊內所有地址相同的尾部字節內容。這種獨特的表示法使地址能夠聚合，它通常具有相同的部分。一個地址塊包含了多個地址按順序排列的一個集合，這些地址共享相同的Head和相同的Tail，但各自具有單獨的Mid。Head和Tail各自都可以獨自為空，使其能夠表示不具有相同的Head或相同的Tail的多個地址對象。

將一個地址描述為具有Head:Mid:Tail的形式、具有地址長度個字節的一個序列。一個地址塊內將含有一組按順序排列的多個地址，這些地址具有相同的首部與尾部字節，并且各自的中間部分(Mid)不相同。一個地址塊＜地址塊＞的定義為:

其中:

＜地址數＞為一個8比特無符號整數域，含有在該地址塊中描述的那些地址的數量(num－addr)，它絕不能為0。

＜地址標志＞為一個8比特域，它規定了該地址塊的余下部分應如何解釋:

bit0:如果bit0=“0”，則＜地址塊＞中將不具有＜相同頭部的長度＞與＜相同頭部＞域。如果bit0=“1”，則＜地址塊＞中包含了＜相同頭部的長度＞域，并且只要相同頭部的長度＞域的值不為0，＜地址塊＞中也包含了＜相同的頭部＞域。

bit1與bit2:按表1來解釋，該表中未給出的組合絕不允許使用。

bit3和bit 4:按表2來解釋，絕不允許使用該表中未給出的組合使用。

表1 bit 1與bit 2的定義Table 1 Definition of bit1 and bit2

表2 bit 3和bit 4的定義Table 2 Definition of bit3 and bit4

bit5:如果bit5=“0”，則在＜地址塊＞中不含有＜鏈路代價＞域。如果bit5=“1”，則＜地址塊＞中包含了＜鏈路代價＞域。

bit6:如果bit6=“0”，則在＜地址塊＞中不含＜字節2＞域。如果bit6=“1”，則指示所有地址的第2字節都是相同的，則＜地址塊＞中將含有＜字節2＞域。

bit7:如果bit7=“0”，則在＜地址塊＞中不含有＜字節3＞域。如果bit7=“1”，則指示所有地址的第3個字節都是相同的，則＜地址塊＞中將含有＜字節3＞域。

表1解釋了bit 1與bit2的組合定義，表2解釋了bit 3和bit 4的組合定義。

＜相同頭部的長度＞域占用{＜相同頭部的長度＞＜相同尾部長度＞}域的高4比特，如果存在，將為一個8比特無符號整數域，它將包含所有地址的相同頭部的字節數。

相同頭部的長度(head－length)為一個變量，若＜相同頭部的長度＞域存在，將等于＜相同頭部的長度＞的值，否則等于0。

＜尾部長度＞域占用{＜相同頭部的長度＞＜相同尾部的長度＞}域的低4比特，如果存在，為一個8比特無符號整數域，含有所有地址公共的尾部的字節數。

尾部長度(tail－length)為一個變量，若＜相同尾部的長度＞域存在則等于＜相同尾部的長度＞的值，否則等于0。

＜相同頭部的長度＞域在相同頭部的長度=0的情況下將予以省略，否則指示了所有地址相同的頭部的長度那么多個最左邊字節的一個域。

＜相同的尾部＞域在尾部長度=0或bit2=“1”的情況下將被省略，否則為含有所有地址公共的尾部長度個最右邊字節的一個域。如果bit2=“1”，則所有地址公共的尾部長度那么多個最右邊字節應該全部為0。

地址中間部分的長度(mid－length)是一個變量，其值不能小于零，其定義為:

地址中間部分的長度:=地址長度－相同的頭部長度－相同的尾部長度

＜地址中間部分＞域在mid－length=0的情況下將予以省略，否則每個＜地址中間部分＞為長度為mid－length字節的一個域，描述與該地址塊中對應的每個各不相同的地址的mid。當不能忽略時，代表＜num－addr＞個＜mid＞

＜前綴長度＞為一個8比特無符號整數域，含有一個地址前綴的比特長度。如果bit3=“1”，那么在該地址塊內唯一的一個＜前綴長度＞域中，將含有所有地址共用的前綴長度(prefix－length)。如果bit4=“1”，則＜地址數＞個＜前綴長度＞域中的每一個，都包含了該地址塊內對應地址的各不相同的前綴長度(以相同的順序排列)。否則bit 3和bit 4都將為“0”，將不存在任何＜前綴長度＞域;則每個地址對象都將含有一個等于8*地址長度比特(IPv4為20，IPv6為128)的前綴長度。如果任何一個＜前綴長度＞域的值大于8*地址長度，則這個地址塊有錯。

＜鏈路代價＞是一個8比特無符號整數域，表示一個1－跳直達的鄰節點鏈路的代價。＜鏈路代價＞域的重復個數，由＜地址塊＞域含有的地址數量決定。當含有多個1－跳直達的鄰節點鏈路的代價時，這些鏈路代價的出現順序即使那個分別與該地址塊中鄰節點地址出現的順序一一對應。當不包含＜鏈路代價＞域時，每條1－跳直達的鄰節點鏈路的鏈路代價都為1－跳，將采用TC消息經過的跳數作為路徑代價。

1.2 地址塊壓縮舉例

下面給出幾個地址塊壓縮的實例，它們包含了不同情況的多種地址塊類型。

1)為了包含地址 a.b.c.d、a.b.e.f以及 a.b.g.h，則head－length=2，尾部長度 =0，mid－length=2，＜地址標志＞域設置了bit0標志(其值為128)，＜尾部長度＞和＜相同的尾部＞域被省略，則該地址塊的字節內容為3、128、2、a、b、c、d、e、f、g、h，共11 字節長。

2)為了包含地址 a.b.c.g 和 d.e.f.g，則 head－length=0，尾部長度 =1，mid－length=3，＜地址標志＞域設置了bit1標志(其值為64)，＜headlength＞和 ＜head＞域被省略，則該地址塊的字節內容為 2、64、1、g、a、b、c、d、e、f，共 10 字節長。

3)為了包含地址 a.b.d.e 和 a.c.d.e，則 head －length=1，尾部長度 =2，mid－length=1，＜地址標志＞域設置了bit0和bit1標志(其值為192)。則該地址塊的字節內容為2、192、1、a、2、d、e、b、c，共9 字節長。

4)為了包含地址 a.b.0.0、a.c.0.0 及 a.d.0.0，則head－length=1，尾部長度 =2，mid－length=1，＜地址標志＞域設置了標志bit0和bit2(其值為160)，＜tail＞域被省略，則該地址塊的內容為3、160、1、a、2、b、c、d，共 8 字節長。

5)為了包含地址 a.b.0.0 和 c.d.0.0，則 head－length=0，尾部長度 =2，mid－length=2，＜地址標志＞域設置了標志bit2(其值為32)，＜head＞和＜tail＞域被省略，則該地址塊的字節內容為2、32、2、a、b、c、d，共 7 字節長。

6)為了包含地址 a.b.0.0/n 和 c.d.0.0/n，則 head－length=0，尾部長度=2，mid－length=2，＜地址標志＞域設置了標志bit2和bit3(其值為48)，則該地址塊的字節內容為2、48、2、a、b、c、d、n，共8 字節長。

7)為了包含地址 a.b.0.0/n 和 c.d.0.0/m，則head－length=0，尾部長度 =2，mid－length=2，＜地址標志＞域設置了標志bit2和bit4(其值為40)，則該地址塊的字節內容為 2、40、2、a、b、c、d、n、m，共9字節長。

2 利用地址塊壓縮機制的方法

當在戰術Ad Hoc網絡中部署應用OLSRv2時，必須考慮和設計如何充分利用這種地址塊壓縮的組網機制，便于最大化地降低鏈路狀態路由協議運行的開銷。

在OLSRv2協議運行時，將周期地產生Hello消息和拓撲控制(TC)這兩種消息。

Hello消息僅限制在節點的1－跳范圍內，不需要轉發傳遞。網絡密度越大時，則節點的1－跳鏈路就越多，使得Hello消息內包含的1－跳鏈路信息(鏈路兩端節點ID的列表)數量就越多。因此對Hello消息的鏈路表進行壓縮能縮短Hello消息的總長度，進而降低無線信道的帶寬開銷。Hello消息中含有的1－跳鏈路，包括單向(即入向)鏈路、對稱雙向鏈路、MPR選擇信息以及鏈路代價。

網絡內的每個節點周期地產生TC消息，并且由其選取的MPR鄰節點中繼轉發進行泛洪，每個TC消息將在由MPR節點組成的連通控制集合的范圍內進行多跳泛洪，非MPR節點不轉發TC消息。要充分發揮地址塊壓縮機制的效率，必須在戰術自組織網絡的地址規劃上需要盡量配合，才能充分發揮其壓縮機制的效果。節點周期產生的每個TC消息中，包含了該節點當前的所有雙向的(對稱的)1－跳鏈路信息，每條鏈路信息以鏈路兩端節點的ID來表示。

我們建議在作戰術網絡規劃部署時，戰術節點采用類似于IP地址的節點ID編址，不規劃無線接口的IP子網地址［7－8］。將每個戰術子網內各節點的ID都規劃在相同的IP網段內，便于Hello和TC消息實現高效率的地址塊壓縮。

如上所述，只要對戰術網絡中各節點ID的規劃得當，比如規劃在同一IP網段內，則Hello消息和TC消息中的所有1－跳鏈路信息的對端節點都屬于同一個IP網段，這就能夠利用地址塊壓縮機制進行消息長度壓縮。這些消息內包含的1－跳鏈路的本端ID都是相同的，在設計的消息格式中可以僅由一個ID來表示。因而所有的1－跳鏈路信息只需要列出對端節點的ID即可，這就為充分利用地址塊壓縮機制創造了極好的條件。

下面分別介紹基于上述節點ID(4字節)規劃設計時Hello消息和TC消息的壓縮格式表示。

(1)Hello消息壓縮格式

當不采用壓縮機制時，假設一個節點具有M條1－跳鏈路，則其原始的Hello消息格式如圖1所示。

圖1 非壓縮的Hello消息格式Fig.1 Uncompressed of the hello message format

其中，鏈路標志比特含有單/雙向指示、MPR選擇指示。

采取地塊壓縮格式時，可以將所有鄰節點鏈路的標志比特和鄰節點分別聚集在一起，對鄰節點地址塊采取地塊壓縮機制來縮短Hello消息的總長度。其壓縮格式如圖2所示。

圖2 壓縮的Hello消息格式Fig.2 Compression of the hello message format

在圖2中，假設為各節點規劃設計的ID前3字節都相同，僅第4字節不同。

在鏈路標志域內，每條鏈路用2 bit作指示標志。D1和S1分別為鏈路1的方向特性和MPR選擇指示，D1=“0”表示單向(即入向)鏈路，D1=“1”表示對稱雙向鏈路。其余鏈路的標志bit定義相同。

2字節可承載8條鏈路的標志信息，當具有更多的鄰節點鏈路時，可以根據鏈路總數動態擴展鏈路標志域的字節長度。

(2)TC消息壓縮格式

當不采用壓縮機制時，一個節點具有M條1－跳對稱雙向鏈路，則其原始的TC消息格式如圖3所示。

圖3 非壓縮的TC消息格式Fig.3 Uncompressed of the TC message format

采取地塊壓縮格式時，各節點在構造其TC分組時，可以針對它周期產生的TC消息和接收到的新TC消息，采取聚類封裝的方法，即將所有TC消息中的發送節點ID和對稱雙向鏈路總數聚集為一個數據塊，將所有TC消息中的對稱雙向鏈路鄰節點ID聚集為一個地址塊，采取地塊壓縮機制來壓縮該地址塊，從而縮短TC消息的總長度。假設網絡中共有N個節點，TC消息中的所有TC消息總共含有K條鏈路，假設為各節點規劃設計的ID前3字節都相同，僅第4字節不同，其壓縮格式如圖4所示。

圖4 壓縮的TC消息格式Fig.4 Compression of the TC message format

地址塊壓縮的效率是比較高的，當一個戰術自組織子網內的所有節點ID的掩碼長度為24時，則總長為40個字節的10個ID地址的地塊塊壓縮格式長度僅為16字節長，壓縮效率接近60%。

3 采用OLSRv2實現戰術網絡IP多跳組網的機制

OLSRv2將鄰節點發現機制和地址塊壓縮機制分離為獨立的RFC規范，OLSRv2協議的重點是對TC消息進行高效率的多點中繼泛洪。目前IETF MANET論壇針對經典MPR優化算法已經提出了新的草案。此外，OLSRv2協議文本中還建議將泛洪算法與模糊視野鏈路狀態(FSLS)等先進的路由思想相結合，以進一步降低其泛洪開銷。

對運行OLSRv2協議的整個戰術網絡采取統一的節點ID規劃設計，盡量規劃在同一個IP網段內，使各節點的ID都具有相同的頭部字節。這樣就給采取地址塊壓縮格式對OLSRv2協議發送的Hello消息和TC消息進行信息聚類壓縮提供了基礎的必要條件。

傳統的標準IP路由在單個IP子網(點到點鏈路或以太網上)內都為1－跳傳輸，邏輯上不存在同一IP子網內消息多跳轉發的情況。而自組織組網要求實現同一IP子網內的消息多跳轉發。若基于標準的IP路由技術，則相同子網內的多跳轉發必須由位于IP路由層之下的自組織路由墊層實現轉發。因此必須采用和實現相同IP子網內的IP層多跳轉發技術，需要基于IP協議進行適應自組織特性的設計，既不違反標準的IP路由原則，又能實現同一IP子網內的多跳轉發路由。

節點ID可以作為無線接口的IP地址，便于實現基于標準IP路由機制的自組織多跳路由。各節點附屬的IP子網信息，既可以通過ID－IP子網映射表預先加載到各個節點，也可以通過TC消息泛洪到各個節點，建立節點ID－IP子網路由映射表，進而建立IP核心路由層的IP子網路由表。

網絡規劃軟件可以預先生成節點ID與其接入/附屬IP子網的映射表，加載到各個戰術自組織網絡節點中。各層子網內通過交換自組織的ID路由信息，建立基于ID的自組織節點路由表，進而在IP層的核心路由表中建立IP子網路由表。

將無線接口定義為標準的廣播型IP子網接口，將節點ID作為其6字節MAC地址的低4個字節，其最高(即第1和第2)兩個字節采用相同的值，無線子網內各節點的MAC地址僅第6個字節不相同。既可以在初始化建立整個無線子網的靜態ARP表，也可以基于動態建立的群節點拓撲表信息來建立整個無線子網的動態ARP表。

實現同一個IP子網內多跳IP路由，可以采用兩種方法。

方法一。基于OLSRv2建立的動態路由表，動態建立IP層的標準IP子網路由表，在IP層建立標準IP子網路由表中，下一跳為物理上的下一跳鏈路鄰節點的無線接口IP地址。將接收到的所有IP分組都上傳到IP層，由IP層進行標準的(物理上)下一跳IP選路，進而實現多跳中繼。由自組織路由協議驅動建立與刪除IP層建立基于下一跳鏈路鄰節點的核心路由表，對于相同子網內的多跳(≥2跳)遠的目的地，將以某個1－跳鄰節點為下一跳IP路由;

方法二。IP層選路確定的“下一跳”地址為連接目的IP子網的節點的無線接口IP地址，由自組織墊層來“潛水”實現多跳中繼轉發，直到到達邏輯上的真正“下一跳”才上傳到IP層進行標準的IP路由轉發。在自組織墊層執行的這種多跳中繼過程對于IP層是不可見的。由自組織路由協議驅動建立與刪除IP層建立基于邏輯上的“下一跳”節點的核心路由表，對于相同子網內的多跳(≥2跳)遠的目的地，將以連接目的IP子網的節點的無線接口IP地址作為下一跳IP路由。

采用這種自組織組網路由技術，可以實現戰術網絡節點的隨遇接入、自動重構、動態組網。

4 結語

文中圍繞與OSLRv2草案密切相關的地址塊壓縮格式(RFC5444)規范如何在戰術自組織網絡中的應用進行了闡述。論文以地址塊壓縮的多個實例展示了其壓縮機制的具體使用方式，當為所有節點的ID規劃的掩碼長度等于24時，其地址塊壓縮效率達到60%。由于OLSRv2拓撲控制報文主要由各節點的地址塊構成，因而對于OLSRv2路由分組的壓縮效率也將接近60%。需要特別指出的是，OLSRv2并未提出解決移動Ad Hoc網絡路由安全的具體方法，與OLSRv2安全設計相關的配套RFC草案正在制定當中，在設計基于OLSRv2的戰術路由協議時，對其安全性也應該做進一步的一體化考慮。

［1］王瑩，王中武，莫嫻.定向Ad Hoc網絡鄰節點發現與跟蹤技術［J］.通信技術，2013，46(02):82 －85.WANG Ying，WANG Zhong － wu，MO Xian.Study on Neighbor Discovery and Tracking in Ad Hoc Network with Directional Antenna［J］.Communications Technology，2013，46(02):82 －85.

［2］Clausen T，Jacquet P，Adjih C，etal.Optimized Link State Routing Protocol［EB/OL］.(2003 － 10 － 5)［2013.12.20］.http://www.ietf.org/rfc/rfc3626.txt.

［3］Clausen T，Dearlove C，Jaquet P.The Optimized Link State Routing Protocol version 2［EB/OL］.(2013.03.27)［2013.12.20］.http://www.ietf.org/rfc/draft－ ietf－ manet－ olsrv2 －19.txt.

［4］Clausen T，Dearlove C，Dean J，etal.Generalized Mobile Ad Hoc Network(MANET)Packet/Message Format［EB/OL］.(2009 －2 －16)［2013.12.20］.http://www.ietf.org/rfc/rfc5444.txt.

［5］Clausen T，Dearlove C.Representing Multi－ Value Time in Mobile Ad Hoc Networks(MANETs)［EB/OL］.(2009 －3 －19)［2013.12.15］.http://www.ietf.org/rfc/rfc5497.txt.

［6］Clausen T，Dearlove C，Dean J.Mobile Ad Hoc Network(MANET)Neighborhood Discovery Protocol(NHDP)［EB/OL］.(2011 －03 －27)［2013.12.19］.http://www.ietf.org/rfc/rfc6130.txt.

［7］王中武，李大雙，胡薇.OSPF向移動Ad Hoc網絡擴展的一種新方法［J］.通信技術，2013，46(02):35 －37.WANG Zhong － wu，LI Da － shuang，HU Wei.A New Method for Extension of OSPF to MANET［J］.Communications Technology，2013，46(02):35 －37.

［8］姜慶，李大雙.OLSR在廣義AD－HOC網絡中的擴展應用研究［J］.信息安全與通信保密，2007(02):149－150.JIANG Qing，LI Da － shuang.Application Research of OLSR in Generalized AD － HOC Network［J］.Information Security and Communications Privacy，2007(02):149 －150.