Internet DRAFT - draft-jung-mipshop-fhmipv6

draft-jung-mipshop-fhmipv6



   Internet Draft         Fast Handover for HMIPv6           October 2005 

    Internet Draft                                      HeeYoung Jung, ETRI 
    Internet Engineering Task Force                 Hesham Soliman, Flarion 
    draft-jung-mipshop-fhmipv6-00.txt                      SeokJoo Koh, KNU 
    Expires April 2006                       Noriaki Takamiya, NTT Software 
                                                               October 2005 
                                           
                  Fast Handover for Hierarchical MIPv6 (F-HMIPv6)  
                                           
   Status of this Memo 
    
      By submitting this Internet-Draft, each author represents that any 
      applicable patent or other IPR claims of which he or she is aware have 
      been or will be disclosed, and any of which he or she becomes aware 
      will be disclosed, in accordance with Section 6 of BCP 79. 
       
      Internet-Drafts are working documents of the Internet Engineering Task 
      Force (IETF), its areas, and its working groups.  Note that other 
      groups may also distribute working documents as Internet-Drafts. 
       
      Internet-Drafts are draft documents valid for a maximum of six months    
      and may be updated, replaced, or obsoleted by other documents at any    
      time. It is inappropriate to use Internet-Drafts as reference material 
      or to cite them other than as "work in progress." 
       
      The list of current Internet-Drafts can be accessed at 
      http://www.ietf.org/ietf/1id-abstracts.txt. 
       
      The list of Internet-Draft Shadow Directories can be accessed at    
      http://www.ietf.org/shadow.html 
    
   Copyright Notice 
       
      Copyright (C) The Internet Society (2005). 
    
    
   Abstract 
    
      This document proposes a scheme to support Fast Handover over HMIPv6 
      networks. The HMIPv6 was developed to reduce the signaling overhead 
      and delay concerned with Binding Update in Mobile IPv6. Therefore 
      HMIPv6 still need a further handover enhancement for supporting the 
      real-time applications. Currently FMIPv6 is the typical protocol to 
      reduce the handover latency. Accordingly it may be straightforward to 
      simply introduce FMIPv6 into HMIPv6 networks. However, it is noted 
      that such simple approach may induce unnecessary processing overhead. 
      F-HMIPv6, described in this document, considers how to integrate these 
      two protocols and provides a scheme for effective integration. 
                                         
                                         
                                         
   Jung, et al.               Expires April 2006                [Page 1] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

                                         
                                         
                                         
                                         
                                         
                                         
                                Table of Contents 
       
      1. Introduction..................................................3 
      2. Terminology...................................................3 
      3. Motivations...................................................4 
      4. Overview of F-HMIPv6..........................................5 
         4.1 Reference Architecture....................................5 
         4.2 Optimized data Flows in F-HMIPv6..........................6 
      5. F-HMIPv6 Operations...........................................7 
         5.1 Mobile-Initiated Handover.................................7 
         5.2 Network-Initiated Handover................................9 
      6. Considerations for F-HMIPv6 Implementations..................10 
         6.1 A New Flag in the HMIPv6 MAP Option......................11 
         6.2 Use of FMIPv6 messages in F-HMIPv6.......................11 
         6.3 AR-based RtSolPr/PrRtAdv.................................12 
         6.4 AR Information Message (ARInfoMsg).......................12 
      7. Variants of F-HMIPv6.........................................14 
         7.1 F-HMIPv6 with Bicasting..................................14 
         7.2 Reactive F-HMIPv6 without Anticipation...................15 
         7.3 Handover support between MAPs............................16 
      8. Security Considerations......................................16 
      9. References...................................................16 
         9.1 Normative References.....................................16 
         9.2 Informative References...................................16 
      Author's Addresses..............................................17 
      Full Copyright Statement........................................17 
      Intellectual Property...........................................17 
       
       
    
       













   Jung, et al.               Expires April 2006                [Page 2] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

   1. 
      Introduction 
       
      The HMIPv6 [4] was developed to reduce the signaling overhead and 
      delay concerned with Binding Update (BU) in Mobile IPv6 [3]. In HMIPv6, 
      when a MN moves within a MAP region, the MN only sends a local BU to 
      the local MAP, rather than the Home Agent (HA) and Correspondent Node 
      (CN), as done in Mobile IPv6. If the distance from the MN to HA/CN is 
      long, this local BU will considerably reduce the time required for the 
      binding update.  
       
      However, the HMIPv6 still need a further enhancement for supporting 
      the real-time applications because HMIPv6 only concern with the 
      latency due to BU and does not touch the latency related to Movement 
      Detection and CoA configuration/Verification. Currently, the FMIPv6 
      [5] is the typical protocol that was designed to reduce the latency 
      due to these two remaining issues. Therefore, if we want to support 
      the fast handover scheme in HMIPv6 network, the simplest approach will 
      be to apply the FMIPv6 to the HMIPv6 in the straightforward way.  
       
      We describe in this document how to use FMIPv6 over HMIPv6 networks so 
      as to provide better handover performance during handover. At a glance, 
      it may be straightforward to simply integrate the FMIPv6 scheme with 
      HMIPv6. However, such simple integration may induce unnecessary 
      processing overhead for re-tunneling at the previous Access Routers 
      and also inefficient usage of network bandwidth. The main reason for 
      this is that the operation of HMIPv6 mainly depends on the 
      functionality of a MAP, while the major functionalities of FMIPv6 are 
      located in Access Routers (AR).   
       
      This document describes a Fast Handover scheme for HMIPv6, named F-
      HMIPv6. In F-HMIPv6, the main operation for handover is accomplished 
      by using MAP, rather than Access Router (i.e. PAR and NAR) like in 
      FMIPv6. For this purpose, the MN exchanges the signaling messages for 
      handover such as RtSolPr, PrRtAdv, FBU, and FBACK with MAP, not PAR. 
      The F-HMIPv6 utilizes the FMIPv6 messages for handover support without 
      further defining any new messages. For the use of F-HMIPv6, it is 
      proposed to define a new flag 'F' in the HMIPv6 MAP option.  
       
       
   2. 
      Terminology 
    
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
      "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
      document are to be interpreted as described in RFC 2119 [2]. 
       
      This document uses all the terminology described in the MIPv6, HMIPv6, 
      and FMIPv6 documents. In addition, this document uses the following 
      terms for the on-link Care of Address (LCoA): 
       

   Jung, et al.               Expires April 2006                [Page 3] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      PLCoA: MN's LCoA valid on the Previous Access Router (PAR). It 
             corresponds to the PCoA of the FMIPv6. 
       
      NLCoA: MN's LCoA valid on the New Access Router (NAR). It corresponds 
             to the NCoA of the FMIPv6. 
       
       
   3. 
      Motivations 
       
      A natural and straightforward choice to combine FMIPv6 with HMIPv6 is 
      to directly apply the FMIPv6 handover scheme in HMIPv6 networks, as 
      they are specified. In this case, a bi-directional tunnel will be 
      established between PAR and NAR via MAP by the FMIPv6 procedures. In 
      this case, it may possibly induce inefficient signaling and data 
      forwarding path. 
       
      Figure 1 shows the data flow during handover by the simple integration 
      of FMIPv6 with HMIPv6.  
       
       
       
                     CN         PAR         MAP        MN(at NAR) 
                     |           |           |           |  
                     |         MIPv6         |           |  
                     |---------------------->|           |  
                     |           |           |           |  
                     |           |  HMIPv6   |           |  
                     |           |<----------|           |  
                     |           |           |           |  
                     |           |        FMIPv6         |  
                     |           |---------------------->|  
                     |           |           |           |  
         
                     Figure 1: Data flows in the simple scheme 
       
       
      According to the HMIPv6 operations, the data packets sent by CN will 
      arrive at MAP and then be tunneled to MN over PLCoA. When the handover 
      is initiated, a bi-directional tunnel will be established between PAR 
      and NAR according to the FMIPv6 procedures. To forward the data 
      packets to the NAR by using the tunnel, the PAR must first intercept 
      those data packets flowing from the MAP, and then perform the re-
      tunneling process. This may be done by adding a new outer IP header of 
      <Source = PAR, Destination = NAR> to the data packets sent by MAP 
      according to the HMIPv6 operations.  
       
      In the viewpoint of the HMIPv6 operations, the above straightforward 
      approach has the following disadvantages: 
       

   Jung, et al.               Expires April 2006                [Page 4] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      (1) The PAR must perform the tunneling operations for fast handover, 
          in addition to the HMIPv6 tunneling from MAP to MN. To do this, 
          the PAR must first intercept the data packets flowing from the MAP, 
          which will be an additional overhead for HMIPv6. It is noted that 
          the data delivery in HMIPv6 is performed based on MAP. 
       
      (2) In HMIPv6, the actual data path of the bi-directional tunnel 
          between PAR and NAR may include the MAP (i.e., PAR-MAP-NAR). 
          Accordingly, the data packets will flow twice along the path 
          between ARs and MAP. This induces inefficiency of network 
          bandwidth usage, especially when ARs are connected to the network 
          through bandwidth-limited links.   
       
      (3) During handover, the possibility that the tunneled packets from 
          PAR to NAR before F-BU arrive later at NAR than the packet sent 
          directly from MAP by F-BU is relatively high. It will be the cause 
          of the reversed sequence packets in NAR and the packets with 
          reversed sequence makes TCP performance worse. 
       
      (4) From such detouring feature, the overall handover latency and 
          tunneling overhead may increase during the handover period. 
          Moreover, it is likely to be difficult to exploit the advantages 
          of FMIPv6 and HMIPv6 as well. 
       
      (5) In hierarchical architecture like HMIPv6, the maintenance of 
          information for neighbor ARs in each AR may be overhead. 
       
      From the observations described above, it is clear that the fast 
      handover for HMIPv6 needs to be designed by considering the data 
      transport features of the HMIPv6 (i.e., in HMIPv6, all data packets 
      are intercepted by MAP and delivered over the tunnel between MAP and 
      MNs). 
       
       
   4. 
      Overview of F-HMIPv6 
       
   4.1 
       Reference Architecture 
    
      Figure 2 illustrates a reference configuration of the F-HMIPv6 network 
      for fast handover support. In the figure, the MAP acts as an 
      aggregation router in the hierarchical domain.  
                 
      When a mobile node (MN) enters a new HMIPv6 domain, firstly it 
      performs the HMIPv6 registrations procedures with HA and MAP, as per 
      MIPv6 and HMIPv6. Also, if the MN moves from a previous AR (PAR) to a 
      new AR (NAR) within the domain, it will follow the Local Binding 
      Update procedures of HMIPv6. At that time, if the fast handover is 
      required for an on-going data session between MN and CN, then the F-
      HMIPv6 scheme will apply to the MN, ARs and MAP. 
                 
   Jung, et al.               Expires April 2006                [Page 5] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

                
                
                            +-------+  
                            |  HA   |      
                            +-------+   
                                |           +----+  
                                |           | CN |      
                                |           +----+  
                                +-----+        |  
                                      |    +---+  
                                      |    |  
                                    +-------+  
                                    |  MAP  | RCoA  
                                    +-------+  
                                     |     |  
                                     |     +--------+  
                                     |              |  
                                 +-----+         +-----+  
                          PLCoA  | PAR |         | NAR | NLCoA 
                                 +-----+         +-----+                             
                        
                                +----+  
                                | MN |  -------------> 
                                +----+  Movement  
       
       
                   Figure 2: Reference Architecture for F-HMIPv6 
       
       
   4.2 
       Optimized data Flows in F-HMIPv6 
       
      By the F-HMIPv6 scheme, the data packets sent by CN will be tunneled 
      by the MAP toward the NAR during the handover. 
       
      Figure 3 illustrates the data flows that F-HMIPv6 is willing to 
      achieve. 
       
       
                     CN         PAR         MAP         MN(at NAR)  
                     |           |           |           |  
                     |   MIPv6   |           |           |  
                     |---------------------->|           |   
                     |           |           |           |  
                     |           |           | F-HMIPv6  |  
                     |           |           |---------->|  
                     |           |           |           |  
        
                     Figure 3: Optimized data flows by F-HMIPv6 
    
    
   Jung, et al.               Expires April 2006                [Page 6] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      Before handover, according to the HMIPv6 operations, the data packets 
      sent by CN are tunneled by MAP to MN with the following IP fields: 
       
        o Inner IP header: <Source = CN, Destination = RCoA of MN> 
        o Outer IP header: <Source = MAP, Destination = PLCoA of MN> 
       
      When the F-HMIPv6 handover is triggered (e.g., by receiving the FBU 
      message from the MN), the MAP will establish a bi-directional tunnel 
      with the NAR, and then begin to forward the data packets to the NAR 
      over the tunnel. By the tunnel, each data packet has an additional 
      outer IP header to the normal HMIPv6 headers with the following IP 
      fields: 
       
        o Additional outer IP header: <S = MAP, Destination = NAR> 
       
      When receiving the tunneled data packets from the MAP, the NAR will 
      de-capsulate them and then be caching the decapsulated data packets. 
      When the MN moves into the NAR region, the NAR will deliver the cached 
      data packets to the MN, as done in FMIPv6. 
       
       
   5. 
      F-HMIPv6 Operations 
    
      In this section, we describe the generic F-HMIPv6 operations. It is 
      assumed that the handover anticipation is supported with appropriate 
      layer 2 triggers; and that the MNs as well as ARs are aware of the F-
      HMIPv6 scheme described in this document. 
       
      The F-HMIPv6 procedures described in this section are based on the 
      assumption that the MAP already has the information necessary for 
      handover support about the ARs located in the HMIPv6 domain. It could 
      be achieved by operators’ manual configuration, or with the help of a 
      signaling operation between ARs and MAP, which will be described in 
      Section 6.4. This information should include the link-layer address 
      (or identifier) and network prefix of each AR.  
       
   5.1 
       Mobile-Initiated Handover 
       
      Figure 4 illustrates the generic procedures for F-HMIPv6 operations.  
    










   Jung, et al.               Expires April 2006                [Page 7] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

       MN(at PAR)       PAR            MAP            NAR        MN(at NAR) 
          |              |              |              |             | 
          |    HMIPv6 Data (before HO)  |              |             | 
          |<===========================>|              |             | 
          | RtSolPr      |              |              |             | 
          |---------------------------->|              |             | 
          | PrRtAdv      |              |              |             | 
          |<----------------------------|              |             | 
          |     FBU      |              |      HI      |             | 
          |---------------------------->|------------->|             | 
          |              |              |     HACK     |             | 
          |              |              |<-------------|             | 
          |              |        FBACK | FBACK        |             | 
          |         <-------------------|------------------->        |  
       Disconnect        |              |              |             |  
          |              |              |Packet Forward|             | 
          |              |              |=============>|             | 
        Connect          |              |         Packet Delivery by FNA  
          |              |              |              |============>|  
          |              |     Stop     |             LBU            | 
          |              |   Forwarding |<---------------------------|         
          |              |    to NAR    |             LBACK          | 
          |              |              |--------------------------->| 
          |              |              |    HMIPv6 Data (after HO)  | 
          |              |              |<==========================>| 
          |              |              |              |             | 
         
                   Figure 4: F-HMIPv6 for Mobile-Initiated Handover 
       
       
      Note that the control messages depicted in Figure 4 have identical 
      format to those in FMIPv6; only the contents (the IP source and 
      destination fields) are different. These values are described more in 
      details in Section 6.  
       
      The detailed description for the control flows are given below: 
       
        1) Based on L2 handover anticipation, the MN sends RtSolPr message 
           to MAP. The RtSolPr SHOULD include information about the link 
           layer address or identifier of the concerned NAR. 
       
        2) In response to the RtSolPr message, the MAP sends the PrRtAdv 
           message to the MN, which SHOULD contain information about NLCoA 
           for the MN to use in the NAR region; i. e, NARs network prefix 
           for stateless auto-configuration or NLCoA for stateful 
           configuration. 
    
        3) Note in F-HMIPv6 that the MAP SHOULD already know the network 
           prefix and link layer address of the associated NAR. 
       
   Jung, et al.               Expires April 2006                [Page 8] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

        4) The MN sends Fast Binding Update (FBU) message to MAP. The FBU 
           message contains PLCoA and IP address of the NAR. 
       
        5) After receiving the FBU message from MN, the MAP will send a 
           Handover Initiate (HI) message to the NAR so as to establish a 
           bi-directional tunnel.  
       
           In response to the HI message, the NAR will set up a host route 
           entry for the MN's PLCoA and then respond with a Handover 
           Acknowledge (HACK) message.  
           
           As a result, a bi-directional tunnel between MAP and NAR will be 
           established. Over the tunnel, the data packets sent by MAP have 
           the additional outer IP header with the following IP fields of 
           <Source = MAP, Destination = NAR>. The NAR may cache those data 
           packets flowing from the MAP, until it receives the RS (possibly 
           with FNA option) message from the newly incoming MN.  
    
        6) The MAP sends Fast Binding ACK (FBACK) messages toward the MN 
           over PLCoA and NLCoA. Then, the MAP will begin to forward the 
           data packets destined to MN to the NAR by using the established 
           tunnel. 
       
        7) The MN sends FNA messages to NAR, when it detects that it is 
           moved in the link layer, and receives the responding RA from the 
           NAR. Then, the NAR delivers the buffered data packets to the MN 
           over NLCoA. 
            
        8) The MN then follows the normal HMIPv6 operations by sending a 
           Local Binding Update (LBU) to MAP, as per HMIPv6. 
       
           When the MAP receives the new Local Binding Update with NLCoA 
           from the MN, it will stop the packet forwarding to NAR and then 
           clear the tunnel established for fast handover.  
    
        9) In response to LBU, the MAP sends Local Binding ACK (LBACK) to MN, 
           and the remaining procedures will follow the HMIPv6. 
       
       
   5.2 
       Network-Initiated Handover 
       
      This section describes the F-HMIPv6 operations for the network-
      initiated handover. In the network-initiated case, it is assumed that 
      the PAR or NAR detects the movement of the MN from the PAR toward the 
      NAR.  
       
      Figure 5 illustrates the F-HMIPv6 operations for the network-initiated 
      handover case.  
    
    
   Jung, et al.               Expires April 2006                [Page 9] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

    
    
    
    
        MN(at PAR)       PAR            MAP            NAR        MN(at NAR) 
           |              |              |              |             | 
           |              |  Trigger(ST) |  Trigger(TT) |             | 
           |              |~~~~~~~~~~~~~>|<~~~~~~~~~~~~~|             | 
           |              |              |              |             | 
           | PrRtAdv      |              |              |             | 
           |<----------------------------|              |             |   
           |              |              |              |             | 
     
                   Figure 5: F-HMIPv6 for Network-Initiated Handover 
       
       
      When the PAR receives a source trigger or the NAR receives a target 
      trigger from the network, it sends a handover indication signal to the 
      MAP, possibly via an out-of-band signaling. Such the signal SHOULD 
      include information about the link layer address and PLCoA of the 
      concerned MN as well as the link layer address or identifier of the 
      associated NAR. 
       
      When a network-initiated handover is indicated, the MAP sends the 
      PrRtAdv message to the concerned MN. The PrRtAdv message SHOULD 
      contain information about NLCoA for the MN to use in the NAR region. 
       
      The remaining procedures are identical to those for the mobile-
      initiated handover case, as shown in Figure 4. 
       
       
   6. 
      Considerations for F-HMIPv6 Implementations 
        
      In this document, it is assumed that the MNs and ARs (including MAP) 
      in the network are aware of the F-HMIPv6 described in this document as 
      well as HMIPv6 [4]. For realizing the F-HMIPv6, the messages and 
      functionality (e.g., triggers and tunnels) defined in FMIPv6 [5] will 
      be used with slightly different procedures.  
       
      The F-HMIPv6 is basically designed to exploit all the messages defined 
      in FMIPv6 and HMIPv6 with the following exceptions: 
       
      - A new flag is defined in the HMIPv6 MAP option, so as to indicate 
        whether the MAP supports the F-HMIPv6 or not within the HMIPv6 
        domain.  
       
      - Some of the FMIPv6 messages have different IP source and destination 
        addresses in the respective IP fields. In particular, the MAP 
        address is used instead of the PAR address. 
       
   Jung, et al.               Expires April 2006               [Page 10] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

       
   6.1 
       A New Flag in the HMIPv6 MAP Option 
       
      Figure 6 shows the MAP option used for HMIPv6. A new flag 'F' is added 
      for F-HMIPv6. 
       
      When a MN moves into a new MAP domain, it receives the Router 
      Advertisement with a MAP option from an access router. When the F bit 
      is set in the MAP option, the MN MAY use F-HMIPv6. If the MN is not 
      aware of F-HMIPv6, or the F bit is not set, it SHOULD NOT use F-HMIPv6.  
         
          
          0                   1                   2                   3   
          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
         |     Type      |    Length     | Dist  | Pref  |R|F| Reserved  |   
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
         |                      Valid Lifetime                           |   
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
         |                                                               |   
         +                                                               +   
         |                                                               |   
         +                  Global IP Address for MAP                    +   
         |                                                               |   
         +                                                               +   
         |                                                               |   
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
          
                        Figure 6: A new flag in the MAP option  
        
          Fields:   
               
                F                  When set indicates that the MAP support  
                                   fast handover by F-HMIPv6.  
         
       
   6.2 
       Use of FMIPv6 messages in F-HMIPv6 
       
      F-HMIPv6 uses the messages for fast handover defined in FMIPv6, with 
      different source and destination IP addresses. Table 1 summarizes the 
      use of these messages. 
       
       
       
       
       
       
       
       
       
   Jung, et al.               Expires April 2006               [Page 11] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

                Table 1. Use of FMIPv6 Messages in F-HMIPv6 
       
      +--------------+-----------+-------------+---------------------+  
      |   F-HMIPv6   | Source IP | Destination |  Usage in FMIPv6    | 
      |   Messages   |  address  |  IP address |                     |  
      +--------------+-----------+-------------+---------------------+  
      |   RtSolPr    |    MN     |    MAP      | Destination = PAR   | 
      |(Mobile-Ini.) |           |             | Source = MN         | 
      +--------------+-----------+-------------+---------------------+ 
      |   RtSolPr    |   PAR     |    MAP      | Destination = PAR   | 
      |(Network-Ini.)|           |             | Source = MN         | 
      +--------------+-----------+-------------+---------------------+  
      |   PrRtAdv    |   MAP     |     MN      |   Source = PAR      |  
      +--------------+-----------+-------------+---------------------+  
      |     FBU      |    MN     |    MAP      | Destination = PAR   | 
      +--------------+-----------+-------------+---------------------+  
      |    FBACK     |   MAP     |     MN      |   Source = PAR      |  
      |              |           |(via PAR/NAR)|                     |  
      +--------------+-----------+-------------+---------------------+  
      |     HI       |   MAP     |    NAR      |   Source = PAR      |  
      +--------------+-----------+-------------+---------------------+  
      |    HACK      |   NAR     |    MAP      | Destination = PAR   | 
      +--------------+-----------+-------------+---------------------+  
       
       
   6.3 
       AR-based RtSolPr/PrRtAdv 
       
      F-HMIPv6 assumes that a MAP has all the necessary information about 
      its serving ARs such as IP address and link layer ID, as seen in the 
      conventional mobile networks hierarchically configured. 
       
      In particular, if an access network supports the information sharing 
      between ARs within its domain, the direct exchange of RtSolPr/PrRtAdv 
      between an MN and an AR may be more effective. It is expected that the 
      shorter signaling path can bring the lower latency.  
       
       
   6.4 
       AR Information Message (ARInfoMsg) 
       
      As previously described, F-HMIPv6 assumes that a MAP has all the 
      necessary information about its serving ARs such as IP address and 
      link layer ID. It can be achieved by a certain signaling procedure 
      between MAP and ARs specified by network operator.   
       
      To facilitate this, a new ICMPv6 message could be defined, named 'AR 
      Information Message (ARInfoMsg)' in this document. When each AR 
      receives the MAP option with the flag 'F' set from the MN, it can send 
      its link information to the MAP using the ARInfoMsg message.  
       

   Jung, et al.               Expires April 2006               [Page 12] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      If the MAP receives an ARInfoMsg message from an AR, the MAP MAY store 
      this information until the lifetime reaches to 0. This information can 
      also be used by AR to send PrRtAdv to the MN. If the MAP can't 
      recognize this message, this message is silently discarded. 
       
      When the AR receives MAP option with 'F' flag set, it MAY send the 
      ICMPv6 ARInfoMsg to the MAP in the following format.  
                                                                                   
       0                   1                   2                   3  
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |     Type      |     Code      |          Checksum             |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |                      Preferred lifetime                       |  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
      |   Options ...                                                 |  
      +-+-+-+-+-+-+-+-+-+-+-  
                                                                                   
                         Figure 7: ICMPv6 ARInfoMsg Message 
                                                                                   
      IP fields:  
                                                                                   
          Source Address  
            The IP address of the AR, which is attached to the access 
            network.  
                                                                                   
          Destination Address  
            The IP address of the MAP.   
                                                                                   
      Type  
            <TBD>  
       
      Code  
            <TBD>  
                                                                                   
      Preferred lifetime  
             
            It is the same value of the preferred lifetime in the Router 
            Advertisement message at the access network.  
                                                                                   
      Options  
             
            AR can include the option defined in the 6.4.3 in [5]. The 
            available options are the same as PrRtAdv:  
            - New Access Point Link-Layer Address  
            - New Router's Link-Layer Address  
            - New Router Prefix Information option 
       
       

   Jung, et al.               Expires April 2006               [Page 13] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

   7. 
      Variants of F-HMIPv6 
       
   7.1 
       F-HMIPv6 with Bicasting  
       
      In this section as a variant of F-HMIPv6, the F-HMIPv6 with bicasting 
      is considered. When a handover is indicated in the F-HMIPv6 domain, 
      the MAP will provide the MN with the bicasting [6] toward both PAR and 
      NAR. This variant could be applied to both mobile-initiated and 
      network-initiated handover cases. 
       
      The bicasting along with simultaneous binding [6] can be used to 
      enhance the handover performance, in particular, for addressing the 
      ping-pong effect. In F-HMIPv6, it is strongly recommended that the 
      bicasting be used for stable handover. 
       
      Figure 8 illustrates the F-HMIPv6 operations with bicasting.  
       
      MN(at PAR)       PAR            MAP            NAR        MN(at NAR) 
         |              |              |              |             | 
         |    HMIPv6 Data (before HO)  |              |             | 
         |<===========================>|              |             | 
         | RtSolPr      |              |              |             | 
         |---------------------------->|              |             | 
         | PrRtAdv      |              |              |             | 
         |<----------------------------|              |             |            
         |             FBU             |              |             | 
         |---------------------------->|              |             |  
         |              |        FBACK | FBACK        |             | 
         |         <-------------------|------------------->        |  
      Disconnect        |              |              |             |  
         |              |         Begin Bicasting     |             | 
         |              |<=============|=============>|             | 
      Connect           |              |              |             | 
         |              |              |Stop          |             | 
         |              |              |Bicasting     |    FNA      | 
         |              |<------------------------------------------| 
         |              |              |              | Forwarding  | 
         |              | Forwarding   |              |============>| 
         |              |==========================================>| 
         |              |              |              |             | 
         |              |              |              |             | 
         |              |              |             LBU            | 
         |              |              |<---------------------------|         
         |              |              |            LBACK           | 
         |              |              |--------------------------->|  
         |              |              |    HMIPv6 Data (after HO)  | 
         |              |              |<==========================>| 
         |              |              |              |             | 
       
                         Figure 8: F-HMIPv6 with Bicasting 
   Jung, et al.               Expires April 2006               [Page 14] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

       
      As shown in the figure, the basic control flows are identical to those 
      for the generic F-HMIPv6 as described in Section 4, except that the 
      bi-directional tunnel for handover is not used.  
       
      On the other hand, the following rules for bicasting support apply to 
      the basic F-HMIPv6 operations. 
         
        1) The PrRtAdv message sent by MAP SHOULD contain a valid NLCoA with 
           the help of an appropriate NLCoA configuration scheme such as 
           optimistic DAD [7] or stateful NLCoA configuration [8]. 
         
        2) The FBU message is used only for triggerring the bicasting by MAP. 
           It is not concerned with the bi-directional tunnel establishment 
           or HI/HACK messages. The FBACK message MAY be omitted. 
    
        3) The MAP begins the bicasting the data packets destined to MN 
           (RcoA) via both PLCoA and NLCoA, as soon as it receives the FBU 
           from the MN. 
    
        4) The MAP stops the bicasting when it receives the FNA message from 
           MN via NAR. 
    
        5) The PAR and NAR forward the buffered packet to MN after receiving 
           FNA message. 
    
      Note in this scheme that a bi-directional tunnel between MAP and NAR 
      is not established, as done in the normal HMIPv6. Note also that the 
      HI/HACK messages are not used. For this purpose, this scheme assumes 
      an appropriate CoA configuration scheme such as 'optimistic DAD' [7] 
      or 'address pool based stateful NLCoA configuration' [8], to ensure 
      that the NLCoA confirmation (via the DAD process) is not needed in the 
      NAR.  
    
    
   7.2 
       Reactive F-HMIPv6 without Anticipation  
       
      When the handover anticipation cannot be supported from the underlying 
      link layer, the F-HMIPv6 will follow the normal HMIPv6 operation. The 
      MN just sends the Local BU to MAP. In fact, the fast handover cannot 
      be supported. 
       
      As an option to recover the data packet loss by handover, when the MAP 
      receives a new Local BU from the MN, it MAY request the corresponding 
      PAR to forward the data packets (destined to the PLCoA and buffered by 
      PAR until then) to the NLCoA. For this purpose, the PAR MAY have 
      queued the data packets that were destined to the PLCoA of MN. 
       
       

   Jung, et al.               Expires April 2006               [Page 15] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

   7.3 
       Handover support between MAPs 
       
      There may be the requirement of handover support for the MN moving to 
      another MAP region. For supporting it, F-HMIPv6 may establish 
      forwarding tunnel from old MAP to new MAP. The forwarding packets are 
      buffered in new MAP and delivered to MN via an AR after new local BU. 
      In this case, the handover latency may higher than it in case of the 
      handover within a MAP. 
       
       
   8. 
      Security Considerations 
       
      The security issues of F-HMIPv6 are basically in line with those of 
      FMIPv6 and HMIPv6.  
       
      Note that the MN and MAP could have an IPsec security association in 
      HMIPv6, thus the RtSolPr and PrRtAdv messages can also be protected 
      with IPsec. This feature actually provides an advantage over FMIPv6 
      where ND messages cannot be secured in its present form. 
       
      In addition, the MAP MUST ensure that the RtSolPr and FBU packets 
      arrived from an MN that legitimately owns the RCoA. Otherwise, a bogus 
      node could attempt to disrupt packets meant for the MN and redirect 
      them to some access router.  
       
      Further security issues will be identified, as the F-HMIPv6 work is 
      progressing. 
       
       
   9. 
      References 
    
   9.1 
       Normative References 
       
      [1] S. Bradner, " Intellectual Property Rights in IETF Technology", 
         BCP 79, RFC 3668, February 2004.  
       
      [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement 
         Levels", BCP, RFC 2119, March 1997.  
       
   9.2 
       Informative References 
       
      [3] D. Johnson, et al., "Mobility Support in IPv6", RFC 3775, June 
         2004. 
       
      [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management 
         (HMIPv6)", RFC 4140, August 2005.  
       
      [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draftRFC 4068, 
         July 2005. 
       
   Jung, et al.               Expires April 2006               [Page 16] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      [6] K. ElMalki and H. Soliman, "Simultaneous Bindings for Mobile IPv6 
         Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-03, June 2003. 
       
      [7] N. Moore, "Optimistic Duplicate Address Detection for IPv6", 
         draft-ietf-ipv6-optimistic-dad-05, February 2005. 
       
      [8] H. Jung, et al., "Address Pool based Stateful NCoA Configuration 
         for FMIPv6", draft-jung-mipshop-stateful-fmipv6-00, August 2003. 
       
       
   Author's Addresses 
           
          Hee Young Jung 
          hyjung@etri.re.kr 
          Protocol Engineering Center, ETRI 
           
          Hesham Soliman 
          H.Soliman@flarion.com 
          Flarion 
           
          Seok J. Koh 
          sjkoh@knu.ac.kr  
          Kyungpook National University     
           
          Noriaki Takamiya 
          takamiya@po.ntts.co.jp 
          NTT Software  
    
   Full Copyright Statement  
       
      Copyright (C) The Internet Society (2005).  This document is subject 
      to the rights, licenses and restrictions contained in BCP 78, and 
      except as set forth therein, the authors retain all their rights.  
        
      This document and the information contained herein are provided on an  
      "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
      OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
      ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
      INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
      INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
      WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.  
           
   Intellectual Property  
    
     
     
       
      The IETF takes no position regarding the validity or scope of any    
      Intellectual Property Rights or other rights that might be claimed to    
      pertain to the implementation or use of the technology described in    
      this document or the extent to which any license under such rights    
      might or might not be available; nor does it represent that it has    
      made any independent effort to identify any such rights.  Information    
   Jung, et al.               Expires April 2006               [Page 17] 
    
   Internet Draft         Fast Handover for HMIPv6           October 2005 

      on the procedures with respect to rights in RFC documents can be    
      found in BCP 78 and BCP 79.  
           
      Copies of IPR disclosures made to the IETF Secretariat and any    
      assurances of licenses to be made available, or the result of an    
      attempt made to obtain a general license or permission for the use of    
      such proprietary rights by implementers or users of this   
      specification can be obtained from the IETF on-line IPR repository at    
      http://www.ietf.org/ipr.  
           
      The IETF invites any interested party to bring to its attention any    
      copyrights, patents or patent applications, or other proprietary    
      rights that may cover technology that may be required to implement    
      this standard.  Please address the information to the IETF at ietf-   
      ipr@ietf.org.  
           


































   Jung, et al.               Expires April 2006               [Page 18]