劉騰飛，秦雅娟，王利利

(北京交通大學(xué)電子信息工程學(xué)院，下一代互聯(lián)網(wǎng)互聯(lián)設(shè)備國(guó)家工程實(shí)驗(yàn)室，北京100044)

0 引言

隨著信息網(wǎng)絡(luò)技術(shù)的快速發(fā)展，信息的獲取方式更趨多樣化。人們不再滿足使用固定終端或單個(gè)移動(dòng)終端連接到網(wǎng)絡(luò)，而是希望能將某個(gè)屬性范圍內(nèi)的終端組合起來，形成一個(gè)相對(duì)穩(wěn)定的集合，IETF(internet engineering task force)將運(yùn)動(dòng)屬性相同的實(shí)體上的多個(gè)終端的集合稱為一個(gè)移動(dòng)子網(wǎng)(network mobility，NEMO)［1］。這種移動(dòng)子網(wǎng)可以是個(gè)人使用的個(gè)域網(wǎng)(personal area network，PAN)［2］，也可以是部署在飛機(jī)、輪船、火車、公交車、私家車等車輛上的移動(dòng)子網(wǎng)或傳感器網(wǎng)絡(luò)。移動(dòng)IPv6下的子網(wǎng)移動(dòng)方案是一個(gè)基于主機(jī)的移動(dòng)性管理方案［3-4］，需要終端參與移動(dòng)性管理，并由此帶來帶寬資源和信令開銷的浪費(fèi)以及終端復(fù)雜度的增加，尤其是子網(wǎng)在路由器之間切換時(shí)，終端需要改變網(wǎng)絡(luò)地址，從而造成通信中斷。針對(duì)上述問題，本文首先介紹了基于網(wǎng)絡(luò)的移動(dòng)性管理協(xié)議—代理移動(dòng)IPv6，然后分析了3種代理移動(dòng)IPv6下的子網(wǎng)移動(dòng)方案，最后通過對(duì)3種方案的實(shí)現(xiàn)和實(shí)驗(yàn)結(jié)果的驗(yàn)證分析，比較了3種方案的性能［5］。

1 代理移動(dòng)IPv6的基本原理

代理移動(dòng) IPv6(RFC5213［6］)是對(duì)移動(dòng) IPv6 協(xié)議(RFC6275 )的擴(kuò)展。移動(dòng)IPv6是一種基于主機(jī)的移動(dòng)性管理方案，它需要移動(dòng)終端參與相關(guān)的信令交互，并且當(dāng)移動(dòng)終端切換到外地代理時(shí)，需要使用外地轉(zhuǎn)交地址進(jìn)行通信，因而存在改變網(wǎng)絡(luò)地址造成通信中斷和三角路由等問題。代理移動(dòng)IPv6是一種基于網(wǎng)絡(luò)的移動(dòng)性管理方案，它不需要移動(dòng)終端參與任何移動(dòng)信令交互，這樣首先降低了對(duì)終端的要求，其次終端在一個(gè)本地域內(nèi)移動(dòng)的過程中不改變網(wǎng)絡(luò)地址，從而在切換的過程中可以保持通信的連續(xù)性。代理移動(dòng)IPv6為研究基于網(wǎng)絡(luò)的子網(wǎng)移動(dòng)提供了網(wǎng)絡(luò)基礎(chǔ)。

代理移動(dòng)IPv6的核心實(shí)體有2個(gè):本地移動(dòng)錨點(diǎn)(local mobility anchor，LMA)和移動(dòng)接入網(wǎng)關(guān)(mobile access gateway，MAG)。MAG主要負(fù)責(zé)檢測(cè)MN的接入和離開，代理移動(dòng)節(jié)點(diǎn)(mobile node，MN)進(jìn)行代理綁定更新(proxy binding update，PBU)消息的發(fā)送和代理綁定應(yīng)答(proxy binding acknowledgement，PBA)消息的接收，為MN建立和刪除MAG到 LMA之間的隧道［8］、綁定更新列表(binding update list entry，BULE)和路由。LMA負(fù)責(zé)接收PBU消息和發(fā)送PBA消息，給MN分配家鄉(xiāng)網(wǎng)絡(luò)前綴(home network prefix，HNP)，為MN建立和刪除MAG到LMA之間的隧道、綁定緩存(binding cache entry，BCE)和路由。完成代理注冊(cè)后，MAG向MN發(fā)送包含HNP的路由通告消息(router advertisement，RA)。MN收到 RA后，通過獲取其中的HNP，配置相應(yīng)的IPv6地址，進(jìn)而可以與通信對(duì)端進(jìn)行正常通信。當(dāng)MN從MAG1切換到MAG2時(shí)，MAG2會(huì)代理MN進(jìn)行注冊(cè)，當(dāng)LMA檢測(cè)到MN之前已經(jīng)注冊(cè)，會(huì)給MN分配相同的HNP，并更新隧道以及相應(yīng)的路由。在MN接入MAG2的同時(shí)，MAG1也會(huì)檢測(cè)到MN的離開，并為MN進(jìn)行解注冊(cè)。

2 代理移動(dòng)IPv6子網(wǎng)移動(dòng)

與代理移動(dòng)IPv6相比，代理移動(dòng)IPv6子網(wǎng)移動(dòng)引入了一個(gè)新的實(shí)體—移動(dòng)路由器(mobile router，MR)，通過MR來統(tǒng)一管理子網(wǎng)內(nèi)的移動(dòng)網(wǎng)絡(luò)節(jié)點(diǎn)(mobile network node，MNN)。這樣做有以下優(yōu)點(diǎn):①節(jié)省信令資源，大量減少每個(gè)終端都要進(jìn)行切換的信令開銷;②減少切換操作，子網(wǎng)整體移動(dòng)時(shí)，子網(wǎng)內(nèi)所有移動(dòng)終端在MAG之間的切換可以通過單一移動(dòng)路由器在MAG之間的切換來完成。在IETF公布的關(guān)于NEMO的RFC4885［9］中，根據(jù)MNN的活動(dòng)范圍，將MNN分為本地固定節(jié)點(diǎn)(local fixed node，LFN)和訪問移動(dòng)節(jié)點(diǎn)(visiting mobile node，VMN)，LFN只在子網(wǎng)內(nèi)部移動(dòng)，而VMN則可以在子網(wǎng)之間或子網(wǎng)與固定無線路由器之間移動(dòng)。目前，子網(wǎng)移動(dòng)有3種實(shí)現(xiàn)方案:普通子網(wǎng)移動(dòng)(C-NEMO)［10］、基于PMIPv6的網(wǎng)絡(luò)移動(dòng)(N-PMIPv6)［11］和基于網(wǎng)絡(luò)的網(wǎng)絡(luò)移動(dòng)(N-NEMO)［12］。

2.1 普通子網(wǎng)移動(dòng)(C-NEMO)

C-NEMO是一種簡(jiǎn)單的子網(wǎng)移動(dòng)方案，其主要思想是MR攜帶的子網(wǎng)內(nèi)的所有終端獲得相同的子網(wǎng)前綴。MAG在代理MR向LMA注冊(cè)HNP的同時(shí)，也向LMA進(jìn)行移動(dòng)子網(wǎng)前綴(mobile network prefix，MNP)的注冊(cè)，并為MNP在LMA和MAG之間建立隧道和路由。之后，在MAG發(fā)送給MR的RA消息中不僅包含有MR本身的HNP，還有MR所攜帶子網(wǎng)的MNP，MR收到RA后，內(nèi)核自動(dòng)使用HNP配置自己的網(wǎng)絡(luò)地址［13］，并提取出MNP發(fā)送給MNN。MNN接收MNP，自動(dòng)配置完成自己的網(wǎng)絡(luò)地址后即可進(jìn)行通信。

普通子網(wǎng)移動(dòng)方案的信令流程如圖1所示。首先，MR接入MAG，MAG通過MR的MAC地址查找MR對(duì)應(yīng)的mn_id(移動(dòng)路由器的標(biāo)識(shí)符)。MAG為MR建立BULE，然后代理MR向LMA發(fā)送包含有mn_id的PBU進(jìn)行注冊(cè)。LMA收到PBU后，查找mn_id所對(duì)應(yīng)的 HNP和MNP，為 MR建立一個(gè)BCE;然后，將HNP和MNP添加到PBA發(fā)給MAG，并為HNP和MNP建立隧道和路由。MAG收到LMA返回的PBA后，提取MNP和HNP添加到RA消息中發(fā)送給MR，并為HNP和MNP建立BULE、隧道和路由;然后，MNN接入到MR，MR發(fā)現(xiàn)MNN接入后會(huì)檢測(cè)MNN是否為合法用戶，檢測(cè)成功以后給MNN發(fā)送包含MNP的RA消息包，MNN收到RA后使用MNP配置完成本身的網(wǎng)絡(luò)地址即可進(jìn)行通信。這樣所有發(fā)往LFN的消息包都會(huì)通過這個(gè)隧道發(fā)送至MR，然后由MR轉(zhuǎn)交給MNN。

可見，本方案實(shí)現(xiàn)簡(jiǎn)單，通信數(shù)據(jù)包的頭部開銷比較小，在通信過程中只需在LMA和MAG之間建立一層隧道，而不需要在MR上建立隧道。MR在MAG間切換時(shí)，由于只進(jìn)行一次注冊(cè)，并且隧道只建立在MAG和LMA之間，所以MNN和CN之間進(jìn)行數(shù)據(jù)通信的切換時(shí)延損耗［14］較小。C-NEMO中，由于MAG為MR向LMA進(jìn)行注冊(cè)時(shí)，已經(jīng)為其子網(wǎng)里的所有MNN的MNP進(jìn)行了注冊(cè)。在同一個(gè)MR下所有MNN共用同一個(gè)HNP(即MNP)，而當(dāng)MNN在MR與MR之間或者是MR與MAG之間切換時(shí)，則會(huì)接收到帶有不同HNP的RA消息，這將導(dǎo)致網(wǎng)絡(luò)地址變化，造成上層應(yīng)用的中斷，因此，本方案只支持LFN類型的MNN。

圖1 C-NEMO信令流程Fig.1 Communication call-flow in C-NEMO

2.2 嵌套隧道的子網(wǎng)移動(dòng)(N-PMIPv6)

代理移動(dòng)IPv6下隧道嵌套子網(wǎng)移動(dòng)的核心思想是將MR當(dāng)作一個(gè)MAG來使用，MR上運(yùn)行類似于MAG的軟件。與C-NEMO相比，N-PMIPv6取消了MNP，將子網(wǎng)內(nèi)每一個(gè)MNN都視為VMN節(jié)點(diǎn)類型，信令流程如圖2所示。首先，MR接入MAG1，MAG1向LMA進(jìn)行綁定更新請(qǐng)求，然后，LMA為MR分配HNP并將其添加到PBA中發(fā)送給MAG1，發(fā)送成功后為HNP建立LMA到MAG1的隧道和路由。MAG1收到PBA后提取其中的HNP填入到向MR發(fā)送的RA中。這樣MR收到RA后，配置完成自己的IPv6地址。然后，VMN接入MR，MR會(huì)直接向LMA進(jìn)行注冊(cè)，整個(gè)流程和MAG為MR進(jìn)行注冊(cè)時(shí)一樣，建立的隧道為L(zhǎng)MA到MR;然后為VMN分配一個(gè)HNP，所有發(fā)往這個(gè)HNP的數(shù)據(jù)包都會(huì)通過隧道直接從LMA發(fā)到MR，再由MR轉(zhuǎn)交給VMN;數(shù)據(jù)包在LMA和MAG1之間傳輸時(shí)網(wǎng)絡(luò)層頭部為雙層隧道，即LMA為MR建立的隧道和LMA為VMN建立的隧道，MAG1到MR之間為單層隧道。

本方案的優(yōu)點(diǎn)是支持單點(diǎn)移動(dòng)性，即對(duì)MR下的每個(gè)VMN都分配相同的HNP。當(dāng)VMN在MR之間或者在MR和MAG之間進(jìn)行切換時(shí)，網(wǎng)絡(luò)地址始終不變，也就是對(duì)于上層應(yīng)用來說，通信不會(huì)中斷。從流程圖2可以看到，對(duì)于子網(wǎng)下每個(gè)VMN都存在嵌套隧道，即在LMA和MR接入的MAG之間存在雙層隧道，尤其在嵌套子網(wǎng)的情況下，將帶來很大的網(wǎng)絡(luò)層頭部開銷，進(jìn)而浪費(fèi)帶寬資源。另外，本方案只支持VMN節(jié)點(diǎn)類型，不支持LFN。

圖2 N-PMIPv6信令流程Fig.2 Communication call-flow in N-PMIPv6

2.3 基于N-PMIPv6的子網(wǎng)移動(dòng)(N-NEMO)

2.3.1 N-NEMO 概述

在N-PMIPv6的基礎(chǔ)上，采用隧道分離和分層注冊(cè)思想，文獻(xiàn)［12］提出了 N-NEMO，以支持 LFN和VMN 2種節(jié)點(diǎn)類型。在N-NEMO中，LFN接入MR時(shí)，直接為其分配HNP。VMN接入MR時(shí)，需要進(jìn)行本地和全局2次注冊(cè)。MR和LMA之間的隧道也分為本地隧道和全局隧道2部分，以解決NPMIPv6存在的隧道嵌套問題，降低網(wǎng)絡(luò)層數(shù)據(jù)包的頭部開銷。

N-NEMO中，LFN接入流程與C-NEMO相同，這里不再贅述。VMN接入的信令流程如圖3所示。

當(dāng)一個(gè)移動(dòng)節(jié)點(diǎn)接入MAG時(shí)，MAG對(duì)移動(dòng)節(jié)點(diǎn)的類型進(jìn)行識(shí)別。當(dāng)移動(dòng)節(jié)點(diǎn)為一個(gè)MN，MAG則執(zhí)行正常的代理移動(dòng)IPv6的流程;如果移動(dòng)節(jié)點(diǎn)為MR，MAG則向LMA發(fā)送代理綁定更新消息，并在其中添加MNP選項(xiàng)。LMA對(duì)MNP進(jìn)行注冊(cè)，并為HNP和MNP建立隧道和路由。其中，MNP用來針對(duì)性管理MR下面所攜帶LFN的移動(dòng)性。

MR分2種情況處理移動(dòng)節(jié)點(diǎn)的接入。

1)如果檢測(cè)到移動(dòng)節(jié)點(diǎn)為L(zhǎng)FN，則MR直接提取其向MAG注冊(cè)時(shí)分配的MNP，放入RA(路由通告)消息中傳遞給LFN;LFN接收到RA后配置自己的地址，即可以與核心網(wǎng)(core network，CN)開始通信。

圖3 N-NEMO中VMN接入流程Fig.3 Communication call-flow for VMN in N-NEMO

2)如果檢測(cè)到移動(dòng)節(jié)點(diǎn)為 VMN，則 MR為VMN建立LBULE(local BULE)，并向上一級(jí)MAG發(fā)送LPBU(local PBU)消息進(jìn)行本地注冊(cè);MAG接收到 LPBU消息包后，為 VMN建立 LBCE(local BCE)和BULE，向LMA發(fā)送GPBU進(jìn)行全局注冊(cè)。LMA收到 GPBU后，為 VMN分配 HNP，并建立BCE、LMA和MAG之間的隧道和路由，向MAG發(fā)送包含HNP的GPBA。MAG收到GPBA后，提取其中的HNP，更新 VMN的 BULE，為 VMN的 HNP建立MAG到LMA之間的隧道和路由，并向MR發(fā)送包含 HNP的 LPBA。然后，MAG更新 VMN的LBCE，并為HNP添加MAG到MR之間的隧道和路由。MR收到MAG發(fā)送的 LPBA后，提取其中的HNP，并更新自己的LBULE，然后為 HNP添加MR到MAG之間的隧道(隧道的兩端為MR和MAG)和路由。MR將LBULE中的HNP填充到RA消息中發(fā)送給VMN，VMN收到RA配置完成網(wǎng)絡(luò)地址即可通信。

切換情況分以下2種。

1)VMN從MR切換到MAG。當(dāng)VMN從MR切換到MAG時(shí)，MAG會(huì)為VMN建立一個(gè)綁定更新列表，并向 LMA進(jìn)行注冊(cè)，發(fā)送 GPBU。LMA收到GPBU后，提取其中的mn_id，查找是否存在和其對(duì)應(yīng)的BCE。若存在對(duì)應(yīng)的BCE，直接提取其中的HNP放入GPBA發(fā)給MAG，然后更新自己的BCE，將隧道的對(duì)端從原來MR所接入的MAG調(diào)整到新的MAG，如果不存在對(duì)應(yīng)的BCE，則為mn_id進(jìn)行重新注冊(cè)。在MN切換到新的MAG的同時(shí)，MR檢測(cè)到 MN的離開，向 MAG發(fā)送解注冊(cè) LPBU(lifetime=0)。MAG收到解LPBU后，向LMA發(fā)送解注冊(cè)GPBU(lifetime=0)。LMA收到解注冊(cè)GPBU后，向MAG發(fā)送解注冊(cè)GPBA(lifetime=0)。MAG收到GPBA后，刪除原來為MN建立的隧道和路由，發(fā)送解注冊(cè)LPBA(lifetime=0)，以刪除原來為MN建立的本地隧道和路由。MR收到解注冊(cè)LPBA后，刪除之前為MN添加的隧道和路由以及對(duì)應(yīng)的LBULE，完成切換過程。

2)MR在2個(gè)MAG之間切換。當(dāng)MR從MAG1切換到MAG2時(shí)，MR通過接收到的RA消息包中MAG地址的改變確認(rèn)切換的發(fā)生。MR會(huì)為其子網(wǎng)內(nèi)的VMN向 MAG2重新進(jìn)行注冊(cè)，具體流程和VMN接入流程相同。MAG1檢測(cè)到MR的離開后，為MR以及MR下的VMN進(jìn)行解注冊(cè)，并刪除之前為它們建立的隧道和路由。

可見，與前2種方案相比，N-NEMO有以下2個(gè)優(yōu)點(diǎn):N-NEMO同時(shí)支持LFN和VMN;MMN和CN通信時(shí)采用了級(jí)聯(lián)隧道的方法，可以有效避免NPMIPv6中嵌套隧道帶來的網(wǎng)絡(luò)層頭部開銷過大的問題，節(jié)約了網(wǎng)絡(luò)資源。但N-NEMO信令交互比較復(fù)雜，當(dāng)MR進(jìn)行切換時(shí)，VMN的切換時(shí)延較大，其原因有2個(gè)方面:MR切換時(shí)，需要為MN重新注冊(cè);MN與CN通信需要經(jīng)過2段隧道。另外，LMA需要管理的前綴數(shù)量較多，增加了LMA處理信令的負(fù)擔(dān)。

2.3.2 軟件實(shí)現(xiàn)

與代理移動(dòng)IP相比，為了保證級(jí)聯(lián)隧道的成功建立，支持子網(wǎng)移動(dòng)的代理移動(dòng)IP軟件加入了實(shí)體MR，增加了本地代理綁定更新LPBU和本地代理綁定應(yīng)答LPBA 2個(gè)信令。MR為了支持這2個(gè)信令，為VMN建立LBULE，并代理VMN發(fā)送LPBU以及接收LPBA來進(jìn)行本地注冊(cè)，同時(shí)為VMN建立隧道和路由模塊。MAG加入了對(duì)子網(wǎng)移動(dòng)中的移動(dòng)節(jié)點(diǎn)支持的LBCE，為VMN進(jìn)行LPBU的接收和LPBA的發(fā)送，程序模塊之間的流程圖如圖4所示(虛線模塊為新添加部分)。

實(shí)體類型的判斷是通過配置文件來實(shí)現(xiàn)的，如果判斷本實(shí)體為MR，則要進(jìn)行MR的初始化工作，包括任務(wù)隊(duì)列的初始化、移動(dòng)頭套接口的初始化、路由通告接收原始套接字的初始化、隧道控制初始化、本地綁定更新列表初始化、路由規(guī)則初始化以及MR路由通告初始化等。MR上軟件結(jié)構(gòu)分接入檢測(cè)程序和代理移動(dòng)IPv6下主程序2個(gè)部分，兩者之間的消息交互通過消息隊(duì)列來實(shí)現(xiàn)，分別如圖5和圖6所示。

圖4 N-NEMO程序框架Fig.4 Program modules for N-NEMO

圖5 MNN接入偵聽模塊流程圖Fig.5 Flow diagram for MNN connection sense

圖6 MR軟件結(jié)構(gòu)圖Fig.6 Software architecture for MR

接入偵聽程序通過對(duì)AP(access point)發(fā)來syslog消息來判斷MNN的接入和離開，并提取MNN的MAC地址，然后對(duì)MNN的類型進(jìn)行判斷。我們定義18代表節(jié)點(diǎn)類型為VMN，19代表節(jié)點(diǎn)類型為L(zhǎng)FN，20表示節(jié)點(diǎn)類型為MR。然后通過消息隊(duì)列將MNN的信息發(fā)送給MR主程序。

MR的主程序中分3個(gè)大的線程:①移動(dòng)頭部的接收;通過對(duì)接收消息包的判斷，來觸發(fā)信令的交互;②消息隊(duì)列觸發(fā)線程:通過接受接入檢測(cè)程序所發(fā)送的消息隊(duì)列的值，來檢測(cè)MN的切換;③RA消息的接受:通過接受RA消息包，并對(duì)其中的MAG地址進(jìn)行判斷，不變將繼續(xù)監(jiān)聽，改變則為MNN向新的MAG進(jìn)行注冊(cè)。

對(duì)于實(shí)體MAG，MAG首先要進(jìn)行和MR類似的初始化，由于MAG的程序主要分為:移動(dòng)頭部的接受以及消息隊(duì)列觸發(fā)線程，功能和MR中的2個(gè)線程功能類似，代碼結(jié)構(gòu)如圖7所示。

圖7 MAG軟件結(jié)構(gòu)圖Fig.7 Software architecture for MAG

3 代理移動(dòng)IPv6子網(wǎng)移動(dòng)切換時(shí)延分析

3.1 子網(wǎng)移動(dòng)實(shí)驗(yàn)環(huán)境

為了分析代理移動(dòng)IPv6下3種子網(wǎng)移動(dòng)方案的性能，本文搭建了實(shí)驗(yàn)平臺(tái)。實(shí)驗(yàn)平臺(tái)中包括LMA，MAG，MR，MN，CN 5 個(gè)實(shí)體，如圖8 所示。下面將就移動(dòng)子網(wǎng)在2個(gè)MAG之間切換以及MN在MAG和MR之間切換2種場(chǎng)景進(jìn)行時(shí)延分析比較。

3.2 MR在MAG之間的切換時(shí)延

下面分別采用上述3種子網(wǎng)移動(dòng)方案測(cè)試MR在MAG之間切換的時(shí)延。MR在MAG1和MAG2之間共進(jìn)行150次切換，通過ICMPv6 ping和ICMPv6 reply數(shù)據(jù)包測(cè)試MN與CN之間的通信切換時(shí)延的最小值、最大值和平均值，并與代理移動(dòng)IP中MN在MAG之間的切換進(jìn)行對(duì)比，如圖9所示。其中，平均時(shí)延:PMIPv6為1.246 775 s，C-NEMO為1.275 94 s，N-PMIPv6為1.291 202 3 s，N-NEMO為 1.300 398 s。由圖9可見，PMIPv6平均時(shí)延最小，N-NEMO平均時(shí)延最大。實(shí)驗(yàn)結(jié)果與前面的分析吻合。

圖8 PMIPv6子網(wǎng)移動(dòng)的實(shí)驗(yàn)拓?fù)鋱DFig.8 Mobility scenario in PMIPv6

圖9 MR在MAG1和MAG2之間切換時(shí)延性能Fig.9 Handoff delay cost for MR handover between MAG1 and MAG2

3.3 MN在MR和MAG之間的切換時(shí)延

具體的切換場(chǎng)景為:首先MR接入到MAG1，MN接入在MR下面的子網(wǎng)，然后MN和CN進(jìn)行通信的過程中在MR和MAG2之間進(jìn)行150次切換。由于C-NEMO不支持單點(diǎn)的移動(dòng)性，所以這個(gè)場(chǎng)景的實(shí)現(xiàn)里面沒有對(duì)其時(shí)延進(jìn)行分析。我們將后2種方案的切換時(shí)延進(jìn)行測(cè)試分析，圖10中分別顯示了對(duì)2種移動(dòng)切換實(shí)驗(yàn)的最小值、平均值和最大值(其中平均值:N-PMIPv6為1.498 742 s，N-NEMO為1.504 89 s);N-PMIPv6的性能稍優(yōu)于 N-NEMO，不過兩者的時(shí)延相差僅為0.006 148 s，與其所帶來的頭部開銷降低的優(yōu)勢(shì)相比是可以接受的。

圖10 MN在MR和MAG之間切換時(shí)延性能Fig.10 Handoff delay cost for MN handover between MR and MAG

4 子網(wǎng)移動(dòng)方案性能分析

通過3種子網(wǎng)移動(dòng)實(shí)現(xiàn)方案的協(xié)議分析，以及兩個(gè)場(chǎng)景下3種方案的時(shí)延測(cè)試，可以看出，在信令開銷方面，由于N-NEMO采用了分層注冊(cè)，每次MR切換時(shí)都要為其下的移動(dòng)節(jié)點(diǎn)進(jìn)行一次注冊(cè)，因此，N-NEMO信令開銷最大，C-NEMO信令開銷最小。在網(wǎng)絡(luò)層頭部開銷方面，N-PMIPv6的開銷最大，CNEMO和N-NEMO的開銷較小。從支持的節(jié)點(diǎn)類型上看，C-NEMO只能支持LFN節(jié)點(diǎn)，N-PMIPv6只能支持VMN節(jié)點(diǎn)，而N-NEMO可以同時(shí)支持LFN和VMN 2種節(jié)點(diǎn)類型。從切換時(shí)延上看，MR在MAG間切換時(shí)，C-NEMO的切換時(shí)延相對(duì)最小，NNEMO的切換時(shí)延抖動(dòng)較大;而MN在MR和MAG間切換時(shí)，N-PMIPv6和N-NEMO的切換時(shí)延幾乎相等。綜上所述，N-NEMO相對(duì)其他2種方案雖然信令開銷和切換時(shí)延相對(duì)較大，但可以支持各種節(jié)點(diǎn)類型，以及網(wǎng)絡(luò)層頭部開銷較小的優(yōu)勢(shì)，如表1所示。

表1 3種子網(wǎng)移動(dòng)實(shí)現(xiàn)方案對(duì)比Tab.1 Comparison in three NEMO mechanisms

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

本文介紹了代理移動(dòng)IPv6下的3種子網(wǎng)移動(dòng)信令流程和實(shí)現(xiàn)方案，詳細(xì)分析了N-NEMO方案的信令流程和程序的模塊實(shí)現(xiàn)，軟件實(shí)現(xiàn)了3種子網(wǎng)移動(dòng)方案，實(shí)驗(yàn)測(cè)試了各種方案的切換時(shí)延。NNEMO采用隧道分離技術(shù)，在MR和MAG之間以及MAG和LMA之間，為VMN建立隧道，有效地減小了數(shù)據(jù)包在MAG和LMA之間傳輸時(shí)的頭部開銷;同時(shí)，N-NEMO全面支持2種類型移動(dòng)節(jié)點(diǎn)，可滿足移動(dòng)子網(wǎng)中移動(dòng)節(jié)點(diǎn)不同應(yīng)用場(chǎng)景的需求。但由于N-NEMO切換時(shí)延抖動(dòng)相對(duì)較大，因此，N-NEMO適用于對(duì)切換時(shí)延和時(shí)延抖動(dòng)不是很敏感的應(yīng)用。在后續(xù)的研究工作中，將對(duì)N-NEMO子網(wǎng)內(nèi)部多個(gè)MN的塊注冊(cè)［15］進(jìn)行相關(guān)的實(shí)現(xiàn)。

［1］DEVARPALLI D，WAKIKAWA D，PETRESCU A.RFC 3963:Network Mobility(NEMO)Basic Support Protocol［S］.［s.l.］:Network Working Group，2005:2-25.

［2］ZHAO Fei，VIEHLAND D.Key Applications for Success of Personal Area Networks，Mobile Business［C］//Proceeding ICMB＇09 Proceedings of the 2009 Eighth International Conference on Mobile Business.Washington，DC，USA:IEEE Computer Society，2009:227-232.

［3］李雪霞，郜帥，王利利，等.一種基于標(biāo)示分離映射網(wǎng)絡(luò)的子網(wǎng)移動(dòng)性管理方案［J］.重慶郵電大學(xué)學(xué)報(bào):自然科學(xué)版，2012，24(1):83-89.LI Xuexia，GAO Shuai，WANG Lili，et al.A network mobility management scheme based on the locator/ID separating network［J］.Journal of Chongqing University of Posts and Telecommunications:Natural Science Edition，2012，24(1):83-89.

［4］張家波.基于IPV6的快速切換改進(jìn)方案［J］.數(shù)字通信，2009，37(3):20-24.ZHANG Jia.An improved fast handoff scheme based on mibile IPV6［J］.Digital lommunication，2009，37(3):20-24.

［5］QU Zhaowei，LU Tingjie.QoS Management Structure for Mobile IPv6［J］.THE Journal of China Universities of Post and Telecommunications，2005，12(4):6-10.

［6］GUNDAVELLI S，LEUNG K，DEVARAPALLI V，et al.RFC5213:Proxy Mobile IPv6［S］.［s.l.］:Network Working Group，2008:3-24.

［7］PERKINS C，JOHNSON D，ARKKO J.RFC6275:Mobility Support in IPv6［S］.［s.l.］:Network Working Group，2011:8-19.

［8］SIMPSON W.RFC1853:IP in IP Tunneling［S］.［s.l.］:Network Working Group，1995:3-10.

［9］ERNST T，LACH H-Y.RFC 4885:Network Mobility Support Terminology［S］.［s.l.］:Network Working Group，2007:1-20.

［10］李雪霞.代理移動(dòng)IPv6中子網(wǎng)移動(dòng)的研究與實(shí)現(xiàn)［D］.北京:北京交通大學(xué)，2011:26-40.LI Xuexia.Research and Implementation on Network Mobility in PMIPv6［D］.Beijing:Beijing Jiaotong University，2011:26-40.

［11］SOTO I，BERNARDOS C J，CALDERON M，et al.NEMO-Enabled Localized Mobility Support for Internet Access in Automotive Scenarios［J］.IEEE Communications Magazine，2009，47(5):152-159.

［12］YAN Z W，ZHOU H C，YOU I.N-NEMO:A Comprehensive Network Mobility Solution in Proxy Mobile IPv6 Network［J］.Journal of Wireless Mobile Networks，Ubiquitous Computing and Dependable Applications(JoWUA)，2010:52-70.

［13］RICHARD S W.TCP/IP Illustrated［M］.Beijing:China Machine Press，1999:50-60.

［14］ERNST T.RFC4886:Network Mobility Support Goals and Requirements［S］.［s.l.］:Network Working Group，20075-15.

［15］ABINADER F，GUNDAVELLI S，LEUNG K，et al.RFC6602:Bulk Binding Update Support for Proxy Mobile IPv6［S］.［s.l.］:Network Working Group，2012:1-30.