移動ＩＰｖ６切換方法的研究綜述

［摘 要］ IPv6在下一代互聯網中將被廣泛使用，IPv6支持移動的特性能夠將固定網絡和無線網絡緊密地結合起來。本文介紹了移動IPv6基本工作原理，并在此基礎上詳細介紹了移動IPv6的各種網絡切換方法，并對各種切換方法的優劣進行了分析和比較，最后對移動IPv6技術做出了展望。

［關鍵詞］ 移動IPv6；平滑切換；快速切換；無縫切換

［中圖分類號］F724.6；TP393.03［文獻標識碼］A［文章編號］1673-0194（2008）17-0101-04

1 引 言

隨著移動通信和互聯網行業的全面融合，可以實現在任何地方、任何地點能與任何人進行通信，在移動中享受音樂、視頻和上網等服務。而實現這些服務的核心就是支持移動通信的IPv6協議。

2 移動IPv6的概述

2. 1移動IPv6的目標

IETF所提出的基于IPv6移動通信的目標在于：解決地址短缺的問題，使得所有的移動設備都能夠分配到一個全球有效的IPv6地址；減小路由表的長度；簡化路由協議，提高吞吐量與帶寬的利用；提供比IPv4更好的安全性能；更加關注服務類型，特別是實時數據；通過指定允許范圍幫助實現組播；允許主機不改變地址而實現漫游；協議未來的可擴充性；允許新舊協議共存［1］。

2. 2節點的切換

移動IPv6的特點就是能在不同的網絡間進行切換而保持連接節點的通信。其中的切換主要指的是節點從一個網絡移入到了另一個擁有不同網絡前綴的網絡中，主要包括兩個層面：鏈路層的切換和網絡層的切換。當移動節點進行網絡的切換時首先是鏈路層的切換，包括有線網絡和無線網絡。涉及了底層的通信技術，主要包括無線通信中的鏈路層觸發機制［2］。網絡層的切換主要是通過網絡IP層地址綁定信息的交互來建立隧道，本文所討論的所有網絡切換算法的實現都是基于IP層的。

2. 3切換過程

圖1所示的是移動IPv6的工作模型，根據IETF的移動IPv6工作組對在草案［3］中提出的概念，移動節點在IPv6網絡中移動的過程如下：

移動前：當移動節點(Mobile Node MN)沒有移動時，處于自己的網絡N₁中時擁有本地IPv6地址，即移動前的地址(Previous Care of Address，PcoA)。此時當對等節點(Correspondent Node CN)向MN發送數據時，數據通過MN所在網絡的接入路由( Previous Access Router，PAR)轉發到MN上。當MN從網絡N₁移動到網絡N₂，此時地址PcoA將失效。

獲得轉交地址：當移動節點移動到網絡N₂后，必需在新網絡注冊且要獲得一個能在網絡N₂中有效的唯一的IPv6地址，這時稱為新轉交地址（New Care of Address，NcoA），該地址的獲取算法在文獻［4］中介紹。

注冊：在移動節點獲得了轉交地址NcoA后，就會發送綁定更新消息(Binding Update，BU)向PAR去注冊這個地址， 本地代理也會返回一個(Binding Acknowledgement，BAK)確認數據包信息，表示注冊成功。

攔截轉發：注冊成功后，本地代理即N₁中的默認接入路由器將攔截發往MN的移動前的轉交地址的所有報文，并把這些報文轉發給MN的當前有效地址NcoA。

直接通信：當移動節點接收到本地代理轉發的由CN發送的報文后，移動節點可以發送BU消息給對等節點CN，通知CN自己當前的地址。CN收到后就可以將之后的數據直接發送到MN上，從而實現了路由的優化。

3 平滑切換

3. 1問題的提出

在移動的過程中，當MN移入新的網絡，還未將新地址向PAR和CN綁定時，如果此時正好有CN節點在和MN通信，則從CN發出的數據將到達MN移動前的網絡的接入路由PAR，由于PAR未收到MN的新地址綁定消息而直接將數據流發往MN在PAR中的所用地址PCoA，但由于MN已經移出該網絡，故將導致發出的數據丟失。如果綁定所用的時間過長則會導致丟失過多的數據報文而使通信性能下降。

3. 2切換的控制方式

節點在網絡中平滑切換的控制方式有兩種：移動節點控制切換網絡作為輔助(Mobie Controled Network Assist，MCNA)方式和網絡控制切換移動節點作為輔助(Network Controled Mobile Assistant，NCMA)方式。前者是由移動節點MN進行引導來完成整個切換過程，后者則是由網絡進行引導來完成整個切換過程。

3. 3平滑切換方法

IETF工作組提出了一種為解決移動切換丟失報文問題的平滑切換方法，其思想就是在網絡中的節點移出網絡后且尚未完成對新網絡的注冊的時候或是未完成在PAR上的地址綁定時， 從CN發出的數據報文在到達網絡后將存儲在網絡的接入路由PAR或NAR上，當MN發出了綁定注冊消息后再將AR上緩存中的數據向MN發送。對于不同的切換控制方式，分別有相應的切換算法。

在切換開始的時候移動節點還在PAR網絡中時會進行兩步操作：一是PAR向移動節點MN發送路由通告信息RA，來告訴MN節點自己是否支持平滑切換的路由協議。二是 MN向PAR發送平滑切換的初始化消息，通知PAR進行內存的初始化分配工作。此后PAR將作為代理攔截由CN發往MN的報文，并存入緩存。

在MCNA方式下，MN利用包括像路由通告信息、鏈路層的一些信息等方法來判斷出自己的鏈路的更換信息。當確定更換到了新的網絡后就會向NAR發送內存初始化的消息，要求NAR根據消息進行內存的初始化工作，消息中含有緩存轉發的選項設置。當NAR收到了該消息后會開辟內存空間，并將緩存轉發消息發送至PAR。PAR收到后會返回一個確認消息，然后將緩存數據轉發至NAR，并由NAR發送到MN的新地址。

在NCMA方式下，網絡可以通過各種元素判斷出MN何時在兩個AR之間的交換。這樣做的優點就是NAR可以通過PAR得知切換之前的MN的狀態消息，由此來進行緩存的初始化，進而PAR緩存的報文將直接發送至NAR而不需要MN發送顯示的請求信息。當MN移入NAR網絡，注冊完之后，NAR就將其緩存的數據轉發給MN［5-6］。

平滑切換也存在某些不足之處，比如：高層協議的重傳問題，這樣會導致網絡資源的浪費和性能的不穩定；報文亂序的問題；平滑切換由于沒有考慮到切換的時延，從而使其不適合用于對實時性要求較高的數據通信應用中。

4 快速切換

4. 1問題的提出

IETF在移動IPv4的基礎上增加了路由優化技術到移動IPv6技術中，解決了網絡的三角路由問題從而降低了網絡延遲，但仍然存在一些使數據延遲的因素，包括對節點的行為方向判斷，以及節點在新網絡中新地址的獲得和對HA，CN節點的注冊。過大的延時會導致數據報文的丟

失，使得TCP認為是網絡的擁塞而導致重傳或停止通信。對一些實時性的應用，要求數據傳輸的延時低，否則就會降低整個通信的質量。

4. 2快速切換方法

快速切換能降低網絡切換延時，交換協議開始是從MN向當前所在網絡的接入路由PAR發出代理路由請求消息RtSolPr，這是通告網絡將要進行快速切換，其中包含了新網絡的接入點的鏈路地址。作為回應，PAR將向MN發送一個代理路由通告信息PrRtAdv來告訴MN它所申請的地址是可知的、未知的或是連接PAR的另一條鏈路。如果是連接到同一個路由器上的不同鏈路那么就不需要做切換了，因為MN仍在PAR的網絡中，這種情況往往發生在同一路由中的MN從無線鏈路轉變到有線鏈路。

若RtSolPr消息中申請的鏈路地址是PAR已知的外部網絡信息，MN就會在PAR中完成新網地址的生成和配置，稱之為轉交地址的預先配置。交換的過程將如圖2所示。

這種方式下的PtRtAdv消息中包含了確認的新網絡的地址前綴，MN可以通過該信息來形成在新網絡的有效地址NCoA［4］，這樣MN就會向PAR發送快速切換的地址綁定消息FBU， 該消息使得PAR能夠將MN移動前的有效地址PCoA 和NCoA 地址綁定在PAR上，以便當MN在移入新網絡后PAR可以將發往MN的報文轉發到MN的新地址。在PAR得到NCoA后需要進行地址驗證，這時就會向NAR發送切換初始化消息HI，其中包含了NCoA。當NAR收到這個地址后將會在本網中驗證這個地址是否為有效［4］，然后通過HAck消息告知PAR。若地址無效，NAR將會產生一個有效的IPv6地址在HAck消息中返回。這樣PAR會得到一個最終有效的地址，然后通過FBAck消息通知到MN，同時也向NAR發送一個FBack消息來對最后地址綁定的一個確認。這樣就在PAR和NAR之間建立起了一條隧道，之后發向MN的PCoA地址的數據就會在PAR上通過隧道到達NAR。當MN移入新網絡向NAR發送了通告消息FNA進行地址注冊后，NAR就會知道MN在本網絡，并把從PAR發送過來的數據轉發到MN上。

如果PAR上沒有請求地址信息，或者MN移動得太快，或者是FBACK消息在中途丟失等情況下，MN在移入新網絡之前就收不到FBACK消息。那么切換的方式就會變成如下圖3所示。

當MN完成與PAR之間的RtSolPr和PrRtAdv消息的交換后就直接移到了NAR的網絡里，之后MN就將綁定消息FBU封裝在FNA消息中發向NAR。NAR從FNA消息中取出FBU消息然后將其中的MN的新地址進行驗證，如果新生成的地址已經被使用，則將由NAR返回一個NAACK消息，其中包含了一個由NAR生成的有效地址并且MN將使用此地址。然后NAR將向PAR發送FBU消息， 在PAR處將MN的新舊地址綁定。PAR會向NAR發送一個FBACK來確認消息。PAR就可以將發向MN的PCoA地址的數據立即發向MN的NCoA。這樣就完成了MN的快速切換。

以上討論的是在由移動節點控制的情況下的切換。如果在網絡的控制下進行切換，首先是由網絡判斷出MN即將發生切換，然后PAR就會直接向MN發送PrRtAdv消息，其中有NAR網絡的鏈路信息。MN通過該消息來生成新的轉交地址NCoA， 并會通過FBU消息向PAR進行地址綁定。之后的操作與上述的基本相同［7］。

5 無縫的切換

無縫的切換能夠保證網絡切換的低延時，又能保證切換時的數據不丟失，但這是一種理想的情況，并不能徹底地將兩者完全地結合起來。Robert Hsieh等人提出了一種基于分層結構和快速切換結構下的網絡切換模型S-MIP，這就向無縫切換邁出了更大的一步，其切換的框架如圖4。

整個切換的過程如圖5所示。和快速切換相似，當MN收到外部網絡鏈路信息時會主動向PAR發送RtSolPr消息來表示開始切換，其中包含了網絡的新轉交地址。PAR會向RtSolPr消息中的所有涉及的網絡的AR發送HI消息，并會收到回復的HACK消息并建立隧道。

移動節點在一個網絡中會周期性地將每次收到的所有L2層的鏈路信號的強弱和對應網絡AR的ID號一起通過當前跟蹤狀態消息CTS發送到決策引擎DE中去，DE可以根據該消息確定MN可能移入的網絡。通過設定L2信號閥值及根據信號強弱的變化來確定MN將要移入的網絡。當DE發現MN的移動是隨機的運動時會向PAR和所有與MN有聯系的NAR上發送轉交決策信息HD，讓它們保留地址的綁定消息。這樣可以在MN發生“ping-ponging”運動時，盡量減少PCoA地址的注冊時間。當MN停留在多個AR網絡的交界區時DE將通知MN和各AR之間進行多重的地址綁定。而在MN線性的移動的情況下DE就會將MN要移入的網絡的信息告知MN。HD消息中包含了由DE決策出的MN所要移入網絡中的新轉交地址，并且通過PrRtAdv消息傳送給MN。

當MN收到DE的通過消息后就會向PAR發送地址綁定更新消息FBU。然后PAR會向MAP發送同步播發消息Scast， MAP會將此后從CN發向MN的所有報文打上“s”標志發給所有MN能感應到的網絡的AR路由上，這可以使得一些無法預測的非規則運動如MN在線性移動過程中突然轉向移入別的網絡，造成DE方向判斷失誤的可能。這種同步的報文發送機制可以減少由此引起的報文丟失。在S-MIP中NAR將開辟兩個內存空間，分別存放著從PAR發送過來的帶有“f ”標志的報文的緩存f-buffer和從MAP發送過來的帶有“s”標志的報文的緩存s-buffer。當MN在新的網絡中發送F-NA消息時，NAR就會將f-buffer和s-buffer中的數據依次發給MN，這樣可以減小報文的丟失率，同時也保證了在NAR上不會產生報文亂序問題。當NAR發送完f-buffer中的消息后就會清空其中的內容并向MAP發送Soff消息來結束整個切換過程，之后MAP就直接將報文傳送給MN了［8］。

S-MIP切換模型是一種由節點發起并由網絡控制的切換，在快速切換和分層網絡的基礎上通過增加DE決策機制，報文的同步播送以及在網絡接入路由中進行雙緩存，減少了快速切換時帶來的數據丟失的現象，并保證了沒有報文亂序的問題。比較適合于應用在具有小型蜂窩網絡結構的大型建筑物內。但是整個框架是針對低速的1M/S的移動速度而提出的，對于高速的節點運動則不適用于該模型。

6 總 結

本文對移動IPv6進行切換時產生的問題進行了分析探討，并詳細介紹了解決這些問題的各種切換方法，分析了各自的優劣性，最后提出了一些在移動IPv6切換中值得研究的問題。結合IPv6的很多新特性，建議未來移動網絡應首選移動IPv6協議。從目前的研究情況來看，要能夠實現移動IPv6的商業化的應用，還需要一套完善的切換機制來進行支持，同時也要考慮到不同的應用類型和不同的應用環境，移動IPv6的安全問題也要得到很好的解決。

主要參考文獻

［1］ 李毅，等. 關于移動IPv6技術的探討［J］. 武漢理工大學學報，2005，25(2)：87－90.

［2］ D Johnson，et al. Mobile Support in IPv6［S］. draft-ietf-mobileip-

ipv6-24. June，2003.

［3］ S Thomson，et al. IPv6 Stateless Address Autoconfiguration［S］. RFC2462，December 1998：10-19.

［4］ Rajeev Koodli，et al. A Framework for Smooth Handovers with Mobile IPv6［S］. IETF INTERNET-DRAFT，2000.

［5］ Robert Hsieh.A Seamless Handoff Architecture for Mobile IP［R］.INFOCOM， 2003.

［6］ S Deering，et al.Internet Protocol， Version 6 (IPv6) Specification［S］.RFC 2460， December，1998.

［7］ J Loughney，et al. Context Transfer Protocol［S］. draft-ietf-seamoby-

ctp-05. October，2003.

［8］ Rajeev Koodli. Fast Handovers for MobileIPv6［S］. draft-ietf-mipshop-fast-mipv6-01. January，2004.