Internet Draft Seok Joo Koh, ETRI Internet Engineering Task Force Hee Young Jung, ETRI Expires May 2004 November 2003 Fast Handover for Regional MIPv4 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 [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 [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 [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 [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 [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 [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 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 [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 [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 [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 [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 [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 [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 [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 [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 [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 [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 [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 [Page 18]