[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
    Internet Draft                                       Seok Joo Koh, ETRI
    Internet Engineering Task Force                    Hee Young Jung, ETRI
    Expires May 2004                                          November 2003
   
   
   
   
                          Fast Handover for Regional MIPv4
   
                    <draft-sjkoh-mip4-regional-handover-00.txt>
   
   
   Status of this Memo
   
      This document is an Internet-Draft and is in full conformance with all
      provisions of Section 10 of RFC 2026 [1].
   
      Internet-Drafts are 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 a "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.
   
   
   Abstract
   
      This document addresses how to support fast handover in regional MIPv4
      networks (Regional Hanover). The proposed regional handover scheme is
      designed based on the existing MIPv4 Post-Registration scheme in a
      more effective way that the regional MIPv4 features are exploited. In
      the proposed regional handover scheme, the GFA acts as an anchor FA
      and thus the bi-directional handover tunnels are established between
      GFA and nFA, not between oFA and nFA.
   
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 1]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
   
   
   
   
   
   
   
   
   
   
                                Table of Contents
   
      1. Introduction..................................................3
      2. Terminology...................................................4
      3. Overview of F-HMIPv4..........................................5
         3.1 Reference Architecture....................................5
         3.2 Motivations for F-HMIPv4..................................6
         3.3 Design Principles.........................................7
      4. F-HMIPv4 Operations...........................................9
         4.1 Source Triggered Handover.................................9
         4.2 Target Triggered Handover................................12
      5. Message Format for F-HMIPv4..................................14
         5.1 Handover Request (HRqst).................................14
         5.2 Handover Reply (HRply)...................................15
      6. Further Considerations.......................................16
         6.1 Mobile Triggered Handover in F-HMIPv4....................16
         6.2 When will GFA Start Data Forwarding to nFA...............16
         6.3 How to Use F-HMIPv4 over HMIPv4 Networks.................16
      7. Security Considerations......................................17
      8. Acknowledgement..............................................17
      9. References...................................................18
      Author's Addresses..............................................18
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 2]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
   1. Introduction
   
      The MIPv4 [3] could be benefited from its two extensions: Regional
      Registration for MIPv4 [4] and Low Latency Handover for MIPv4 [5].
      Those two extensional schemes have so far been designed in their own
      ways so as to enhance the MIPv4 in the signaling and handover aspects.
      It is clear that a combination of those two schemes gives the
      harmonized benefit in terms of signaling overhead and latency (by
      Regional MIPv4) as well as fast handover (by Low Latency handover).
   
      This document addresses how to support fast handover in regional MIPv4
      networks. The existing Low Latency handover scheme [5] provides the
      two approaches for fast handover: Pre-Registration and Post-
      Registration.
   
      In the regional MIPv4 networks, the Pre-Registration handover scheme
      seems to be effectively performed compared to the Post-Registration
      scheme. However, in certain environments, e.g., in cases that the L2
      handover is completed too earlier or the MN moves too faster, the
      Post-Registration scheme MAY be preferred. This document focuses on
      how to use the Post-Registration handover scheme over regional MIPv4
      networks.
   
      When applying the MIPv4 Post-Registration to Regional MIPv4 networks,
      a bi-directional tunnel will be established between two FAs (oFA and
      nFA). This simple combination may possibly induce additional
      processing overhead for re-tunneling at oAR, since in regional MIPv4
      networks all the data traffic is routed via GFA between MN and HA/CN.
      This also incurs inefficient usage of network bandwidth.
   
      This document describes 'Regional Handover' (i.e., Fast Handover for
      Regional MIPv4). The proposed regional handover scheme is designed
      based on the existing MIPv4 Post-Registration in a more effective way
      such that the HMIPv4 features could be exploited. In the regional
      handover scheme, the GFA will always act as an anchor FA (aFA), in
      which all the handover tunnels will be established by GFA.
   
      In the regional handover, it is assumed that the GFA has already
      information about the Link Layer Address (LLA) and IP address (CoA) of
      the FAs located in its HMIPv4 domain. This document describes the
      regional handover operations for the Source Triggered and Target
      Triggered handover cases. The proposed regional handover scheme uses
      the two types of messages, Handover Request (HRqst) and Handover Reply
      (HRply) described [5], without defining any new messages.
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 3]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   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 MIPv4 [3],
      regional tunneling for MIPv4 [4], and low latency handover for MIPv4
      [5] documents.
   
      In addition, this document also uses the following abbreviations
      alternately:
   
      HMIPv4:
   
          'Hierarchical Mobile IPv4', which refers to 'Regional Registration
          or Tunneling for MIPv4' [4].
   
      FMIPv4:
   
          'Fast Handover for Mobile IPv4', which refers to 'Low Latency
          Handover for MIPv4' [5].
   
      F-HMIPv4:
   
          'Fast Handover for Hierarchical MIPv4', which is proposed in this
          document.
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 4]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   3. Overview of F-HMIPv4
   
   3.1 Reference Architecture
   
      This document addresses how to support fast handover in hierarchical
      MIPv4 networks (F-HMIPv4). For this purpose, we consider a
      hierarchically configured MIPv4 network, as shown in Figure 1. In the
      figure it is assumed that the MNs and FAs (including GFA) in the
      network are aware of HMIPv4 functionality specified in [4].
   
   
                            +-------+
                            |  HA   |
                            +-------+
                                |           +----+
                                |           | CN |
                                |           +----+
                                +-----+        |
                                      |    +---+
                                      |    |
                                    +-------+
                                    |  GFA  |
                                    +-------+
                                     |     |
                                     |     +--------+
                                     |              |
                                 +-----+         +-----+
                                 | oFA |         | nFA |
                                 +-----+         +-----+
   
                                +----+
                                | MN | -------------->
                                +----+ movement
   
   
                     Figure 1: A Reference Network for F-HMIPv4
   
   
      When an MN enters a new HMIPv4 domain, it will perform Home
      Registration with HA via GFA by sending Registration Request message.
      After that, whenever the MN moves into another FA region, it will
      follow the HMIPv4 Regional Registration procedures [4].
   
      If the MN has an active session during the move, it is required to
      support fast handover for seamless mobility services, in particular
      for the real-time applications, as described in FMIPv4 [5].
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 5]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   3.2 Motivations for F-HMIPv4
   
      It is clear that a combination of FMIPv4 and HMIPv4 gives the
      harmonized benefit in terms of signaling overhead and latency (by
      HMIPv4) as well as fast handover (by FMIPv4).
   
      FMIPv4 provides the two schemes for fast handover: Pre-Registration
      and Post-Registration [5].
   
      The FMIPv4 Pre-Registration seems to be effectively applied in the
      HMIPv4 networks, rather than the Post-Registration scheme, since the
      MN will perform Pre-Registrations with the GFA not HA in the long
      distance. However, the Pre-Registration scheme may not be effective in
      certain environment that the L2 handover is completed too earlier or
      the MN moves too faster. This document focuses on how to apply or
      enhance the Post-Registration over HMIPv4 networks.
   
      The existing FMIPv4 Post-Registration supports the handover using a
      bi-directional tunnel, without performing the HMIP regional
      registration by MN, and hence no registration messages are required
      for handover support. Instead, the Post-Registration utilizes the Bi-
      directional Edge Tunnel (BET) between oFA and nFA for fast handover.
   
      In case of using the FMIPv4 Post-Registration in HMIPv4 networks, a
      BET will be established between two FAs (oFA and nFA) by the FMIPv4
      procedures. This simple combination of FMIPv4 and HMIPv4 may possibly
      induce additional processing overhead for re-tunneling at oAR, since
      in HMIPv4, all the data traffic is routed via GFA between MN and HA/CN.
      This also incurs inefficient usage of network bandwidth.
   
      Figure 2 shows the data flow by the simple integration of FMIPv4 with
      HMIPv4. According to the HMIPv4 operations, the data packets sent by
      CN/HA will arrive at GFA and then be tunneled to MN over oFA.
   
   
                   CN/HA        oFA         GFA         nFA
                     |           |           |           |
                     |         MIPv4         |           |
                     |---------------------->|           |
                     |           |  HMIPv4   |           |
                     |           |<----------|           |
                     |           |        FMIPv4         |
                     |           |---------------------->|
                     |           |           |           |
   
   
              Figure 2: Data flows by FMIPv6 (Post) in HMIPv6 networks
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 6]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
      When the handover is initiated by an L2 trigger, a BET tunnel will be
      established between oFA and nFA according to the FMIPv4 Post-
      Registration procedures. To forward the data packets to the nFA by
      using the tunnel, the oFA must first intercept those data packets
      flowing from the GFA, and then perform the re-tunneling process. This
      may be done by adding a new outer IP header of <Source = oFA,
      Destination = nFA> to the data packets sent by GFA according to the
      HMIPv4 operations.
   
      In the viewpoint of the HMIPv4 operations, the above straightforward
      approach has the following disadvantages:
   
      (1) In HMIPv4, the actual data path of the BET between oFA and nFA may
          come along the GFA (i.e., oFA-GFA-nFA). Accordingly, the data
          packets will flow twice along the path between oFA and GFA. This
          induces inefficiency of network bandwidth usage, especially when
          those FAs are connected to the network through bandwidth-limited
          links.
   
      (2) In this scheme, the handover event of MN from oFA to nFA will not
          be informed to GFA, despite that essentially the HMIPv4 regional
          tunnel to nFA must be established by MAP. Accordingly, the
          benefits of handover anticipation may be depreciated in this
          scheme.
   
      (3) From such detouring feature as described above, 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 FMIPv4 and HMIPv4 as well.
   
   
   3.3 Design Principles
   
   3.3.1 Data Flow Optimization for F-HMIPv4
   
      From the observations described above, it is clear that the fast
      handover for HMIPv4 needs to be designed by considering the data
      transport features of the HMIPv4 (i.e., in HMIPv4, all data packets
      are intercepted by GFA and routed to MN.
   
      This document describes Fast Handover for HMIPv4 (F-HMIPv4), in which
      the GFA establishes the Bi-directional Tunnel (BT) with nFA for fast
      handover instead of oFA. Note that such a tunnel is BT rather than BET,
      since it is established between GFA and FA. Actually such a BT will
      function as the regional tunnel described in [4].
   
      For this purpose, the FMIPv4 Post-Registration is re-designed in this
      document.
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 7]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
      Figure 3 illustrates the data flows by the F-HMIPv4.
   
   
                   CN/HA        oFA         GFA         nFA
                     |           |           |           |
                     |         MIPv4         |           |
                     |---------------------->|           |
                     |           |           |           |
                     |           |           | F-HMIPv4  |
                     |           |           |---------->|
                     |           |           |           |
   
   
                     Figure 3: Data flows by F-HMIPv4 handover
   
   
      Before handover, according to the HMIPv4 operations, the data packets
      destined to MN are tunneled by GFA. When the F-HMIPv4 handover is
      triggered (e.g., by L2 triggers), the GFA will establish a bi-
      directional tunnel with the nFA, and then begin to forward the data
      packets to the nFA over the tunnel.
   
      When receiving the tunneled data packets from the GFA, the nFA will
      de-capsulate and cache the data packets. It then will deliver the
      cached data packets to the MN, as done in FMIPv4, when the MN moves
      into the nFA region.
   
   3.3.2 Assumptions
   
      The F-HMIPv4 is newly designed based on the existing FMIPv4 Post-
      Registration in a more effective manner by exploiting the HMIPv4
      features. In F-HMIPv4, the GFA always acts as an anchor FA (aFA) of
      FMIPv4, in which all the BET tunnels for fast handover will be
      established by GFA.
   
      In F-HMIPv4, it is assumed that the GFA has already information about
      the Link Layer Address (LLA) and IP address (CoA) of the FAs located
      in its HMIPv4 domain. This ensures that in response to the handover
      (or BET establishment) request from an FA, the GFA could identify the
      CoA of the FA concerned with the handover.
   
      Basically the F-HMIPv4 operates over the HMIPv4 networks. Accordingly,
      it is assumed that the FAs and MNs in the domain are aware of the
      HMIPv4 functionality. For handover, the F-HMIPv4 procedures described
      in this document apply to the concerned FAs and MN.
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 8]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   3.3.3 F-HMIPv4 Messages
   
      The F-HMIPv4 uses the two types of messages, Handover Request (HRqst)
      and Handover Reply (HRply), as those defined in the FMIPv4 [5] without
      defining any new messages.
   
      The messages are used with different operation procedures for BT
      establishment between GFA and nFA, which will be described in the next
      section. The two messages are also used differently by the type of L2
      triggers (ST or TT) and by the entity generating the message (FA or
      GFA).
   
      In this context, the following notations for two message types are
      used in this document:
   
          HRqst(s/t/r, FA/GFA) and HRply(s/t/r, FA/GFA),
   
      where s, t, and r represent ST, TT, tunnel removal or renewal,
      respectively, and also the FA or GFA means that the corresponding
      message is transmitted by FA or GFA, respectively.
   
      To indicate who generates the message, a new flag F is added to the
      HRqst and HRply messages defined in FMIPv4 [5]. The detailed message
      format will be discussed in Section 5.
   
   
   4. F-HMIPv4 Operations
   
      In this section, we describe the F-HMIPv4 operations for the Source
      Triggered and Target Triggered handover cases. The Mobile Triggered
      handover is discussed in Section 6.
   
      It is assumed that the MNs and FAs located in the domain are aware of
      the HMIPv4 and also F-HMIPv4 described in this document.
   
      It is assumed in F-HMIPv4 that that the GFA already has the
      information about the LLA and CoA (IP address) for each FA located in
      the HMIPv6 domain. When an MN enters a new HMIPv4 domain and moves
      around in the domain, it will activate the home and regional
      registration procedures defined in HMIPv4 [4].
   
      If the MN has an active session and moves to the other FA in the
      domain, then the F-HMIPv4 applies for supporting fast handover.
   
   4.1 Source Triggered Handover
   
      In this section, we describe the F-HMIPv4 operations for the Source
      Triggered handover. Figure 4 shows overall operations for Source
      Triggered F-HMIPv4 handover.
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>    [Page 9]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
   
                                    +------+
                               +--->| GFA  |<---+
                               | +->+------+    |
               2) HRqst(s,FA)  | |              | 3) HRqst(s,GFA)
               5) HRply(s,GFA) | |6) Redirect   | 4) HRply(s,FA)
                               | |   Request    |
                               v |              v
             1) L2-ST ~~~> +------+          +------+
                           | oFA  |          | nFA  |
             6) L2-LD ~~~> +------+          +------+ <~~~ 7) L2-LU
                               ^                  ^
                       old L2  |                  |  new L2
                               +-----+    +-------+
                                     |    |
                                     |    |
                                     V    V
                                   +-------+  movement
                     7) L2-LU ~~~> |   MN  | --------->
                                   +-------+
   
   
                         Figure 4: Source Triggered Handoff
   
   
      The general idea behind the Source Triggered handover procedure is
      that the oFA provides GFA with the same information it would have
      obtained via an L2-ST, and then the GFA establishes a BT with nFA in
      order to move the BET to nFA. When the L2 handover is complete (by L2-
      LD), oFA sends an HRqst(r,FA) to GFA so as to terminate the previous
      BET.
   
      The following describes the process of the Source Triggered F-HMIPv4
      handover. The numbered items refer to steps in Figure 4.
   
        1) The oFA receives an L2-ST that contains the MN's L2 address (LLA)
           and an IP address or LLA (that can be mapped to IP address) for
           nFA.
   
        2) The oFA sends HRqst(s,FA) to GFA for handover request, which
           contains the MN's home IP address (HoA), the GFA IP address, an
           LLA for the nFA, and an LLA containing the MN's L2 address.
   
        3) Upon receipt of the HRqst(s,FA), the GFA gets the IP address
           (CoA) of nFA from its pre-configured mapping table (which must
           always maintain the mapping between LLA and CoA for all the nFAs).
           The GFA then tries to establish a BT with nFA by sending
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 10]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
           HRqst(s,GFA) to nFA. The HRqst(s,GFA) contains the MN's home IP
           address (HoA) and an LLA containing the MN's L2 address.
   
        4) In response to HRqst(s,GFA), the nFA sends HRply(s,FA) to GFA for
           BT establishment. The HRply(s,FA) contains a code indicating that
           the tunnel is successfully established. The nFA is ready to
           receive and buffer the data packet from GFA over the BT.
   
        5) Upon receipt of HRply(s,FA), the GFA sends HRply(s,GFA) to oFA,
           which contains a code indicating that a BT has been successfully
           established.
   
        6) Once the L2 handover is underway and the MN gets disconnected at
           L2 (by L2-LD), the oFA will request the GFA to start the tunnel
           with nFA by sending an indication message explicitly such as ICMP
           Redirect Request (See 6.2 for further discussion).
   
        7) Completion of L2 handover is signaled by an L2-LU trigger at nFA
           and/or MN. Then the nFA delivers the buffered data packets to the
           MN. From then the nFA provides the data delivery service to the
           MN. The MN either defers or initiates HMIP registration when it
           receives the L2-LU, which will be discussed in Section 6.
   
   
      Based on the description above, Figures 5 shows the timing diagram for
      Source Triggered (L2-ST) F-HMIPv4 handover.
   
   
                  MN               oFA            GFA              nFA
                   |                |              |                |
                   |    L2-ST ~~~~~>|              |                |
                   |                | HRqst(s,FA)  |                |
                   |                |------------->| HRqst(s,GFA)   |
                   |                |              |--------------->|
                   |                |              |<---------------|
                   |                |<-------------|     HRply(s,FA)|
                   |                |  HRply(s,GFA)|                |
                   |                |              |                |
                   |    L2-LD ~~~~~>|Redirect Request               |
                   |                |------------->|                |
                   |                |              |    L2-LU ~~~~~>|
                   |<---------------------------------------------->|
                   |  MN's traffic  |              |                |
   
   
                     Figure 5: Source Triggered F-HMIPv6 Timing
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 11]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
   4.2 Target Triggered Handover
   
      This section describes the F-HMIPv4 operations for the Target
      Triggered handover. Figure 6 shows overall operations for Target
      Triggered F-HMIPv4 handover.
   
   
                                    +------+
                               +--->| GFA  |<---+
                               | +->+------+    |
               3) HRqst(t,GFA) | |              | 2) HRqst(t,FA)
               4) HRply(t,FA)  | | 6) Redirect  | 5) HRply(t,GFA)
                               | |    Request   |
                               v |              v
                           +------+          +------+ <~~~ 1) L2-TT
                           | oFA  |          | nFA  |
             6) L2-LD ~~~> +------+          +------+ <~~~ 7) L2-LU
                               ^                  ^
                       old L2  |                  |  new L2
                               +-----+    +-------+
                                     |    |
                                     |    |
                                     V    V
                                   +-------+  movement
                     7) L2-LU ~~~> |   MN  | --------->
                                   +-------+
   
   
                         Figure 6: Target Triggered Handoff
   
   
      In the Target Triggered handover, the nFA provides GFA with the
      information that would have obtained via an L2-TT. Then the GFA gets
      the information on MN (such as its HoA and LLA) for BT establishment
      from the oFA, as shown as Steps 2 to 5 of Figure 6. The remaining
      procedures (Steps 6 and 7) are identical to those for Source Triggered
      handover.
   
      The following describes the process of Target Triggered F-HMIPv4
      handover for Steps 1 through 5.
   
        1) The nFA receives an L2-TT that contains the MN's L2 address (LLA)
           and an IP address or LLA (that can be mapped to IP address) for
           oFA.
   
        2) The nFA sends HRqst(t,FA) to GFA for handover request, which
           contains the MN' home IP address (HoA), the GFA IP address, an
           LLA for the oFA, and an LLA containing the MN's L2 address.
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 12]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
        3) Upon receipt of the HRqst(t,FA), the GFA checks the IP address
           (CoA) of oFA from its pre-configured mapping table. The GFA then
           send HRqst(t,GFA) to oFA so as to get the information about MN's
           home IP address (HoA) and an LLA containing the MN's L2 address.
   
        4) In response to HRqst(t,GFA), the oFA sends HRply(t,FA) to GFA,
           which contains the information for BET establishment.
   
        5) Upon receipt of HRply(t,FA), the GFA sends HRply(t,GFA) to nFA,
           which contains a code indicating that the handover request has
           been successfully handled. The nFA is now ready to receive and
           buffer the data packet from GFA over the BT.
   
   
      Based on the description above, Figures 7 shows the timing diagram for
      Target Triggered (L2-TT) F-HMIPv4 handover.
   
   
   
                  MN               oFA            GFA              nFA
                   |                |              |                |
                   |                |              |    L2-TT ~~~~~>|
                   |                | HRqst(t,GFA) |<---------------|
                   |                |<-------------|   HRqst(t,FA)  |
                   |                |------------->|                |
                   |                | HRply(t,FA)  |--------------->|
                   |                |              | HRply(t,GFA)   |
                   |                |              |                |
                   |                |              |                |
                   |    L2-LD ~~~~~>|Redirect Request               |
                   |                |------------->|                |
                   |                |              |    L2-LU ~~~~~>|
                   |<---------------------------------------------->|
                   |  MN's traffic  |              |                |
                   |                |              |                |
   
   
                     Figure 7: Target Triggered F-HMIPv6 Timing
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 13]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   5. Message Format for F-HMIPv4
   
      The F-HMIPv6 uses two types of messages: HRqst and HRply. They have
      the same message format as FMIPv4 [5] without defining any new message
      type. Instead, a new flag bit 'F' is added in the message so as to
      indicate the entity (such as FA or GFA) generating the concerned
      message. The messages will be differently handled, depending on the
      flags indicating the L2 trigger type (s or t) and the entity
      generating the message (FA or GFA).
   
   5.1 Handover Request (HRqst)
   
      Figure 8 shows the HRqst message format, in which a new flag 'F' is
      added to that defined in FMIPv4 [5]. This is a Mobile IP message
      carried on UDP (destination port 434) [3]. The UDP header is followed
      by the fields below.
   
   
         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      |H|N|R|M|G|T|B|F|          Reserved             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Lifetime           |          Reserved             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        MN Home Address (HoA)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          GFA Address                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                         Identification                        +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Extensions ...
        +-+-+-+-+-+-+-+-
   
                         Figure 8: Handover Request Message
   
   
        Type              TBD (Handover Request) as in [5]
   
        H,N,R,M,G,T,B     As defined in [5].
   
        F                 Flag to indicate the entity generating this
                          message. If set to '0', it represents that this
                          message is sent by FA. If otherwise set to '1',
                          this is sent by GFA.
   
        Lifetime         As defined in [5].
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 14]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
        MN Home Address   As defined in [5].
   
        GFA Address       IP address of GFA
   
        Identification    As defined in [5].
   
        Extensions        The message MUST include an LLA containing the
                         MN's L2 address and an L2 address that can be
                         mapped to an IP address for the oFA or nFA,
                         appropriately as described in the F-HMIPv4
                         operations of Section 4. This message MUST also
                         contain the FA-FA Authentication Extension for
                         security purpose.
   
   
   5.2 Handover Reply (HRply)
   
      Figure 9 shows the HRply message format, in which a new flag 'F' is
      added to that defined in FMIPv4 [5].
   
         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      |H|N|R|M|G|T|B|F|    Reserved   |  Code         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |            Lifetime           |          Reserved             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        MN Home Address (HoA)                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          GFA Address                          |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                         Identification                        +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Extensions ...
        +-+-+-+-+-+-+-+-
   
                          Figure 9: Handover Reply Message
   
        Type              TBD (Handoff Reply), as in [5]
   
        Code                          A value indicating the result of the corresponding
                         Handover Request (HRqst)
   
      The remaining fields (including the flag 'F') are applied in the same
      way as defined in the HRqst message.
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 15]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   6. Further Considerations
   
   6.1 Mobile Triggered Handover in F-HMIPv4
   
      Basically the F-HMIPv4 operates in the network-initiated fashion by
      using Source or Target Trigger. If a Mobile Trigger (MT) is supported,
      it may be used for MN to request the oFA that the Source Triggered
      handover is initiated. Such a triggering or requesting message may be
      newly defined in the L2 or L3 level, which is for further
      investigation.
   
      Alternatively, the MT may be used for triggering the FMIPv4 Pre-
      Registration process as defined in [5]. In this case, the FAs and MNs
      in the HMIPv4 domain are required to be aware of both FMIPv4 and F-
      HMIPv4.
   
   6.2 When will GFA Start Data Forwarding to nFA
   
      By the F-HMIPv4 operations described in Section 4, the GFA establishes
      a BT with nFA. After that, the GFA will start tunneling packets using
      the BT to nFA, when receiving the ICMP Redirect Request message from
      oFA indicating that the MN has disconnected. Instead of ICMP Redirect
      message, the HRqst(r,FA) MAY be used for such indication, which is for
      further investigation.
   
      As another option, the GFA MAY start tunneling packets using the BT to
      nFA as soon as establishing the BT with nFA, that is, after receiving
      the HRply(s,FA) from the nFA in the Source Triggered handover case, or
      after sending the HRply(s,GFA) to nFA for the Target Triggered
      handover case.
   
   
   6.3 How to Use F-HMIPv4 over HMIPv4 Networks
   
      The F-HMIPv4 operates over HMIPv4 networks. Accordingly, the MN may
      perform the HMIPv4 Regional Registration when it enters a new FA
      region, independently of the F-HMIPv4 operations described in this
      document.
   
      In HMIPv4 [4], the GFA maintains the 'Visitor Entry List' that
      includes the following fields for each MN:
   
        o Current CoA of the MN
        o Remaining Lifetime of the Regional Registration
   
      On the other hand, by F-HMIPv4, GFA will keep the following fields:
   
        o nFA CoA of the MN
        o Remaining Lifetime of the Lifetime of the BT
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 16]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   
      Depending on the design of F-HMIPv4 with HMIPv4, when the GFA obtains
      a new CoA (nFA CoA) of MN, and starts the data forwarding to the BT,
      we have the following two choices for maintenance of the 'Visitor
      Entry List':
   
       (1) GFA updates the corresponding fields of 'Visitor Entry List'.
           That is, the information by Regional Registration is handled in
           the same as that by the F-HMIPv4 handover.
   
       (2) GFA adds the information on BT for handover and maintains it
           additionally. That is, the information by Regional Registration
           is handled differently from that by the F-HMIPv4 handover.
   
      It is for further study which one is a better choice.
   
   
   7. Security Considerations
   
      The security issues of F-HMIPv6 are basically in line with those of
      HMIPv6 [4] and FMIPv4 [5].
   
   
   8. Acknowledgement
   
      The Authors would like to give special thanks to the following people
      for their valuable comments and discussion for enhancing the F-HMIPv4.
   
      Sung Han Kim (ETRI)
      Jun Seob Lee (ETRI)
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 17]


   INTERNET DRAFT     Fast Handover for Regional MIPv4      November 2003
   
   9. References
   
      [1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP,
         RFC 2026, October 1996.
   
      [2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
         Levels", BCP, RFC 2119, March 1997.
   
      [3] C. Perkins, et al., "Mobility Support in IPv4", RFC 3344, August
         2002.
   
      [4] E. Gustafsson, et al., "Mobile IPv4 Regional Registration", draft-
         ietf-mobileip-reg-tunnel-07, October 2002.
   
      [5] K. Malki, et al., "Low Latency Handoffs in Mobile IPv4", draft-
         ietf-mobileip-lowlatency-handoffs-v4-05, June 2003.
   
   
   Author's Addresses
   
          Seok Joo Koh
          sjkoh@etri.re.kr
          Protocol Engineering Center, ETRI
   
          Hee Young Jung
          hyjung@etri.re.kr
          Protocol Engineering Center, ETRI
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   Koh and Jung   <draft-sjkoh-mip4-regional-handover-00.txt>   [Page 18]