AODV 函數說明

介紹 AODV 中主要函數的運作與 DARGT 所修改點 4.3 DARGT route discovery 實作

介紹如何實作 DARGT phase 1 中低延遲路徑搜尋。

4.4 DARGT forwarding game 實作

介紹如何實作 DARGT phase 2 中傳輸賽局與信賴度設定。

27

4.1 NS2 模組介紹

圖 4-1：NS2 模組架構圖

Network Simulator 2 是一種以 C++及 OTcl 語言所撰寫的非連續事件引發(discrete-event driven)及物件導向(object oriented)的網路模擬器。NS-2 提供了一個整合性的環境，實現在單一 模擬器中提供多種不同層次的細部模擬。

如圖 4-1 表示，NS2 中主要分成四個階層: application layer (AGT)、routing layer (RTR)、

MAC layer (MAC)及 PHY layer (PHY) 。Application layer 負責處理應用層的要求，如 TCP 及 UBP 等等，都被 NS2 歸類在 application layer 上的應用；routing layer 提供了不同的 routing protocol，例如傳統的 AODV、DSR、DSDV 等等路由協定；在 MAC layer 中，NS2 提供了多 種不同的模組例如 802.11 系列的 802.11b、802.11p 等等，能讓使用者能根據不同的實驗需要 來做應用。在 PHY layer 中，NS2 提供了基礎的有線及無線模組 wireless-phy。由於 NS2 於各 個階層只提供了最基本的模組，若使用者想要在 NS2 中實作自身的方法，那麼就必須針對各 個階層的協定進行修改與新增。由於本論文所提出的 DARGT 方法，屬於 NS2 中的 RTR 層協 定，因此，我們以 NS2 內同階層所提供的 AODV protocol 為基礎來進行修改，以實作出

28

DARGT。

NS2 中經由 agent 處理 packet 的各種要求，封包由 agent 發出並於 agent 接收，agent 可視 為封包的起始點與終點。我們可以自由在 agent 中撰寫程式，設定封包的傳送類型與接收條件 並處理接收到的封包。簡單來說，我們可以將所提出的方法，經由程式碼撰寫於 agent 上，並 利用 TCL 腳本程式來設置模擬環境，並將模擬環境中的節點掛載上我們所撰寫的 agent，就能 順利在 NS2 中進行模擬實驗。

在我們的實驗中，AODV 已經是一個完整且可供節點掛載的 agent，我們不需要從頭去撰 寫一個全新的 agent，只需修改 AODV 內部架構，藉由改變路由路徑判斷依據以及新增各種需 要的函數，來實作出 DARGT phase 1 中提出的最低延遲路徑判斷機制，並進一步新增節點間 信賴值設定，來完成 DARGT phase 2 提出的傳輸賽局(forwarding game)。

29

4.2 AODV 函數說明

由於 DARGT 的方法以 AODV 為基礎進行修改，所以必須要先了解 AODV 各個部位是如何運 作。

圖 4-2：Packet Reception Routines

圖 4-2 為 AODV routing protocol 的基本架構，表示了 AODV 收到封包後的運作流程。首 先，當 AODV 接收到封包時，會經由 AODV::recv() 函數來做處理，第一步會判斷接收到的封 包 Type 是不是 AODV 格式。

001: if(ch->ptype() == PT_AODV) { 002: ih->ttl_ -= 1;

003: recvAODV(p);

004: return;

005: }else if(ch->ptype()==PT_CBR){

006: recvCBR(p);

30

007: }

若收到 ptype()為 AODV 的封包，表示此封包內含路由資訊，節點會把封包接收進來並交 由 recvAODV()函數去做解析，依據封包內容不同，可能會送給 recvHello()、recvError()、

recvRequest()以及 recvReply()等四個不同函數處理。

 recvHello():

若收到的封包內含 Hello message，表示有節點在進行鄰居節點搜尋，節點將會把發送 Hello message 的節點加入鄰居列表；若此節點已經存在於列表內，則更新其節點資訊。

 recvError():

此封包代表路由出現錯誤，可能是路徑中節點移動或是已經離開傳輸範圍，導致路由路徑 中斷。此時節點會廣播 recvError 封包進行處理，清除受到影響的路由表，並丟棄所有受 影響的封包，若是無法到達的節點存在於鄰居列表內，會將其移除並更新鄰居列表。最後 節點會依此反向路徑廣播錯誤訊息給路徑上的所有節點，讓它們把將此無法到達的節點從 路由表上移除，以達到維護路由路徑的功用。

 recvRequest():

此函數與 recvReply()並列 AODV routing 最重要的兩個函數，內含關鍵的 rt_update 路由路 徑選擇，這個部份會在 4.2.2 DARGT 修改的章節談及。當節點收到 recvRequest()要求時，

表示環境中有節點想要發送封包，正在建立路由請求別人幫忙傳送。而收到 Request 的節 點，首先會檢查這個要求是不是自身發出的，如果是，則將要求封包丟棄；若不是自身發 出的封包，則會建立一條到達發送端節點的反向路由，若是反向路由已經存在，則會檢查 序列碼，判斷路由是否需要更新(更新反向路由這個動作為 rt_update 函數進行管轄)。

當反向路由建立後，會依照下列三種不同的情況進行處理:

1. 收到 request 的節點自身即為目的節點，會調用 sendRelply()函數往反向路由發送訊息

31

表示已經成功收到封包。

2. 若是節點不是目的地節點，此時會檢查自身是否有到達目的地節點的路由表，若是知 道到達目的地節點的路由(I am not the destination, but I may have a fresh enough route.)，

會調用 sendRelply()函數

001: sendReply( rq->rq_src, 002: rt->rt_hops + 1, 003: rq->rq_dst, 004: rt->rt_seqno,

005: (u_int32_t) (rt->rt_expire - CURRENT_TIME), 006: rq->rq_timestamp,

007: CURRENT_TIME, 008: rt->rt_dst_timestamp, 009: rt->rt_delaytime );

010: // Insert nexthops to RREQ source and RREQ destination in the 011: // precursor lists of destination and source respectively

012: rt->pc_insert(rt0->rt_nexthop); // nexthop to RREQ source 013: rt0->pc_insert(rt->rt_nexthop); // nexthop to RREQ destination

函數中會將 hopcount 數加 1，並且分別在正向路由 (rt) 與反向路由 (rt0) 插入到達來 源節點以及目的地節點的下一跳位址。

3. 如果節點不是目的節點，也沒有到達目的節點的路由，就沒有辦法直接回應 request，

只好將封包 forward 出去(Can't reply. So forward the Route Request)。此時會將 hopcount 數加 1，並調用 forward()函數來發送封包

32

 recvReply():

節點收到回應封包時會調用 recvReply()來處理，recvReply()內同樣有重要的 rt_update()函 數，只是與 recvRequest()內部不同，recvReply()內的 rt_update()處理正向路由(rt)的更新，

而 recvRequest()內部則用以更新反向路由(rt0)。當節點收到 reply 時，會先檢查到達這個 發送 reply 的節點的正向路由是否存在，若不存在則新建立一條；若是存在，則進一步檢 查是否需要更新(rt_update())。之後，根據封包內含的訊息，同樣有三種情況:

1. 節點自身為來源節點(source node)，表示已經成功建立了到達目的節點的路由，此時 會更新 route discovery 的延遲時間，並將所有緩存在 queue 中的封包送往目的節點 2. 若此 reply 封包並不是給我的，則將封包 forward 下去。這邊是一個關鍵點，此時節

點會一併將自身資訊夾帶在 rrep 封包內廣播出去，下一個接收到的節點就可以知道 上一跳節點的資訊。

001: rp->rp_hop_count += 1;

002: rp->rp_src = index;

003: forward(rt0, p, NO_DELAY);

上列程式碼可看到 rp->rp_hop_count 表示此 rrep 封包總經過的 hop 數，經過此次轉送 所以要加 1。之後將節點自身的編號(index)存入 rp->rp_src 內，當下一跳節點接收到 此 rrep 封包後，就可以得知發送這個封包的節點，也就是它的上一跳節點的編號。

最後將 reply 封包 forward 出去，直到 source 節點收到 rrep 封包。

3. 第三種情況，則是節點自身不是目的節點，同時也不知道該如何將封包 forward 出去，

此時只好將封包丟棄(drop)。這種行動易造成路由的不連續，使整體網路的可靠度下 降。

33

以上為收到的 ptype 為 AODV 的格式，若收到 ptype 不是 AODV 的封包，表示此封包可 能是一般的資料封包(CBR)，節點會先檢查自身有沒有到達封包目的地節點的路由，再將封包 forward 到目的地。

而此時使用的兩個函數為 rt_reslove()以及 forward()。rt_reslove()進行路由解析，首先會檢 查路由表中是否存在目的節點，若是存在則直接調用 forward()來發送封包；若是路由正在修復 中，則暫時緩存封包；若是路由不存在，則丟棄封包，並發送 sendError 訊息。