Mobile IP Working Group Hee Young Jung, ETRI Internet Draft Seok Joo Koh, ETRI Internet Engineering Task Force Jun Seob Lee, ETRI Expires December 2003 Hesham Soliman, Flarion June 2003 Karim El-Malki, Ericsson Fast Handover for Hierarchical MIPv6 (F-HMIPv6) 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 Fast Handover over HMIPv6 networks. A simple integration of FMIPv6 with HMIPv6 may induce unnecessary processing overhead for re-tunneling at the previous Access Router and inefficient usage of network bandwidth. This document describes the Fast Handover for HMIPv6 (F-HMIPv6), which is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the Mobile Nodes inform the MAP about its movement anticipation and thus the bi- directional tunnels for fast handover are established between MAP and NAR, not between PAR and NAR. The F-HMIPv6 scheme utilizes the existing FMIPv6 messages, without defining any new control messages. Jung, Koh, Lee, Soliman, El-Malki [Page 1] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. Data Flows by F-HMIPv6........................................4 4. Generic Operations for F-HMIPv6...............................7 5. Variants of F-HMIPv6..........................................9 5.1 Network-initiated Handover................................9 5.2 No Anticipation...........................................9 6. Messages for F-HMIPv6.........................................9 6.1 A New Flag in the HMIPv6 MAP Option......................10 6.2 Use of FMIPv6 messages...................................10 7. Enhancement of F-HMIPv6 Operations...........................11 7.1 F-HMIPv6 with Tunnel Extension to MN.....................11 7.2 F-HMIPv6 with Bicasting..................................12 8. Security Considerations......................................13 9. Acknowledgement..............................................14 10. References..................................................14 Author's Addresses..............................................15 Jung, Koh, Lee, Soliman, El-Malki [Page 2] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 1. Introduction The Hierarchical MIPv6 (HMIPv6) facilitates to reduce the delay concerned with the location update, in which an MN sends a local Binding Updates (BU) to the local MAP, rather than the Home Agent and Correspondent Nodes that are typically further away. On the other hand, the Fast Handover for MIPv6 (FMIPv6) uses L2 signals for earlier movement detection and configuration of a new CoA for the new access router in advance, so as to minimize the disruption of services during handover. Both the FMIPv6 and HMIPv6 schemes have been developed to reduce the handover latency in their own ways. This document aims at finding a proper combination of those two schemes to provide better handover performance. This document addresses Fast Handover over HMIPv6 networks in terms of data flows and control operations. 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 data transport of HMIPv6 is based on the tunneling from the MAP to MNs not ARs, while the FMIPv6 uses the tunneling between the previous and new Access Routers for fast handover. This document describes Fast Handover scheme for HMIPv6 (F-HMIPv6), in which a bi-directional tunnels for fast handover is established between MAP and NAR, not between PAR and NAR. For this purpose, the Fast BU (FBU) message is sent to MAP, not PAR, by MN. In addition, we discuss further enhancements of F-HMIPv6 by considering the data transport feature of HMIPv6, which include the tunnel extension from MAP to MN, not NAR, and the bicasting of MAP. The F-HMIPv6 utilizes the well-defined FMIPv6 messages, without defining any new messages. 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 [3], HMIPv6 [4], and FMIPv6 [5] documents. In addition, this document uses the following terms for the on-link Care of Address (LCoA): 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. Jung, Koh, Lee, Soliman, El-Malki [Page 3] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 3. Data Flows by F-HMIPv6 Figure 1 illustrates a reference configuration for fast handover in HMIPv6 networks. In the figure, the MAP acts as an aggregation router in the hierarchical domain. In the domain, a mobile node (MN) moves from the previous AR (PAR) region into the new AR (NAR) region, and the corresponding LCoA will change from PLCoA to NLCoA. +-------+ | HA | +-------+ | | +----+ | | CN | | +----+ +-----+ | | | | +---+ | | +-------+ | MAP | RCoA +-------+ | | | +--------+ | | | | +-----+ +-----+ PLCoA | PAR | | NAR | NLCoA +-----+ +-----+ +----+ | MN | +----+ ------------> Movement Figure 1: Fast Handover in HMIPv6 networks A natural choice for fast handover in HMIPv6 networks may be to apply the existing FMIPv6 scheme over the HMIPv6 networks. In this case, a bi-directional tunnel will be established between PAR and NAR by the FMIPv6 procedures. However, it is noted that such simple integration of FMIPv6 with HMIPv6 may possibly induce additional processing overhead for re- tunneling at PAR and also inefficient usage of network bandwidth. Jung, Koh, Lee, Soliman, El-Malki [Page 4] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 Figure 2 shows the data flow by the simple integration of FMIPv6 with HMIPv6. According to the HMIPv6 operations, the data packets sent by CN will arrive at MAP and then be tunneled to MN over PLCoA. CN PAR(MN) MAP NAR | | | | | MIPv6 | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | FMIPv6 | | |---------------------->| | | | | Figure 2: Data flows by simple integration of FMIPv6 with HMIPv6 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 to the data packets sent by MAP according to the HMIPv6 operations. In the viewpoint of the HMIPv6 operations, the above approach has the following disadvantages: (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 PAR and MAP. This induces inefficiency of network bandwidth usage, especially when ARs are connected to the network through bandwidth-limited links. (3) From such detouring feature, the overall handover latency may possibly increase during the handover period. Jung, Koh, Lee, Soliman, El-Malki [Page 5] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 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). This document describes the scheme of Fast Handover for HMIPv6 (F- HMIPv6), in which the MAP performs the tunneling for fast handover instead of the PAR. 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 by the F-HMIPv6. CN PAR(MN) MAP NAR | | | | | MIPv6 | | | |---------------------->| | | | | | | | HMIPv6 | | | |<----------| | | | | | | | | F-HMIPv6 | | | |---------->| | | | | Figure 3: Data flows by F-HMIPv6 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: o Outer IP header: 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: When receiving the tunneled data packets from the MAP, the NAR will de-capsulate them and then be caching the de-capsulated 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. Jung, Koh, Lee, Soliman, El-Malki [Page 6] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 4. Generic Operations for F-HMIPv6 Figure 4 illustrates the generic procedures for F-HMIPv6 operations. The control messages for F-HMIPv6 are identical to those for FMIPv6, except for the source/destination addresses of IP fields. The Correspondent Node (CN) and Home Agent (HA) operations will not be affected. MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | HMIPv6 Data (before HO) | | | |<===========================>| | | | | | | | | RtSolPr | | | | |------------->| | | | | PrRtAdv | | | | |<-------------| | | | | FBU | | HI | | |---------------------------->|------------->| | | | | HACK | | | | |<-------------| | Disconnect | FBACK | FBACK | | | <--------------------------|-------------------------> | | | |Packet Forward| | | | |=============>| | Connect | | | RS and RA | | | | |<----------->| | | | Packet Delivery| | | | |============>| | | | | | | | | Local BU and BA | | | |<-------------------------->| | | | | | | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 4: F-HMIPv6 Control Flows Basically, the F-HMIPv6 procedures are based on the assumption that each AR has already the necessary information of its neighboring ARs such as the link-layer address and network prefix of the concerned AR. In addition, the control flows of Figure 4 are derived under the following conditions: Jung, Koh, Lee, Soliman, El-Malki [Page 7] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 a) The handover is initiated by MN (mobile-initiated HO). b) The MN can anticipate the handover (anticipated HO). c) The tunnel for HO is established between MAP and NAR. d) DAD optimization (like optimistic DAD) is not supported. A more detailed description for each control flow of F-HMIPv6 is given below: 1) Based on L2 handover anticipation, the MN sends RtSolPr message to PAR. The RtSolPr SHOULD include information about the link layer addresses of the MN and the NAR concerned. 2) In response to the RtSolPr message, the MAP sends the PrRtAdv message to the MN, which SHOULD contain information about the NLCoA for the MN to use in the NAR region. It is assumed that the NAR already knows the network prefix and link layer address of all the neighboring NARs. The NLCoA can be auto-configured using the network prefix of NAR and the link layer address of MN by PAR. In a certain case, the NLCoA may be allocated by a stateful address management scheme. 3) The MN sends Fast Binding Update (FBU) message to MAP. The FBU message contains PLCoA and IP address of the NAR. 4) 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. 5) 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 . The NAR may cache those data packets flowing from the MAP, until it receives the RS (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. Jung, Koh, Lee, Soliman, El-Malki [Page 8] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 Then, the MAP will begin to forward the data packets destined to MN to the NAR by using the established tunnel. 7) The MN exchanges the RS and RA messages with 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 BU to MAP, as done in HMIPv6. The MAP will clear the tunnel for fast handover, when it receives the new Local Binding Update with NLCoA from the MN. 5. Variants of F-HMIPv6 5.1 Network-initiated Handover The generic procedures described in Figure 4 correspond to the case of the mobile-initiated handover. In the network-initiated HO case, the RtSolPr will be omitted. In this case, after detecting that the MN is moving toward the NAR, the PAR will send an unsolicited RA message to the MN, which MUST include the NLCoA for the MN to use in the NAR region. 5.2 No Anticipation When the handover anticipation cannot be supported, the F-HMIPv6 will follow the normal HMIPv6 operation. The MN just sends the Local BU to the MAP. In fact, the fast handover cannot be supported. 6. Messages for F-HMIPv6 The F-HMIPv6 is 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, Koh, Lee, Soliman, El-Malki [Page 9] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 The different usage and format of those control messages will be identified and specified, as the FMIPv6 and HMIPv6 mechanisms are changed. 6.1 A New Flag in the HMIPv6 MAP Option 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 set in the MAP option indicates that the mobile node 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|I|P|V|F| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Global IP Address for MAP + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: A new flag in the MAP option Fields: F When set indicates that the MAP support Fast Handover. 6.2 Use of FMIPv6 messages 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, Koh, Lee, Soliman, El-Malki [Page 10] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 Table 1. Use of FMIPv6 Messages in F-HMIPv6 +--------------+-----------+-------------+---------------------+ | F-HMIPv6 | Source IP | Destination | Usage in FMIPv6 | | Messages | address | IP address | | +--------------+-----------+-------------+---------------------+ | RtSolPr | MN | PAR | Identical | +--------------+-----------+-------------+---------------------+ | PrRtAdv | PAR | MN | Identical | +--------------+-----------+-------------+---------------------+ | FBU | MN | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ | FBACK | MAP | MN | Source = PAR | | | |(via PAR/NAR)| | +--------------+-----------+-------------+---------------------+ | HI | MAP | NAR | Source = PAR | +--------------+-----------+-------------+---------------------+ | HACK | NAR | MAP | Destination = PAR | +--------------+-----------+-------------+---------------------+ 7. Enhancement of F-HMIPv6 Operations In this section, we describe the enhance scenarios for F-HMIPv6, with the help of additional techniques such as a stateful LCoA management scheme and/or a bicasting of MAP by simultaneous binding. 7.1 F-HMIPv6 with Tunnel Extension to MN In F-HMIPv6, the bi-directional tunnel from MAP to NAR could be replaced with the tunnel between MAP and MN, as done in the normal HMIPv6. For this purpose, the HI/HACK messages need to be eliminated in the F-HMIPv6 with the help of an appropriate DAD optimization or LCoA configuration scheme to ensure that the NLCoA confirmation (via the DAD process) is not needed in the NAR. Such the configuration schemes MAY be implemented by using the Optimistic DAD [6], Advance DAD [7]. In addition to these schemes, the other LCoA configuration and allocation schemes (e.g., enhanced DHCPv6) MAY be used, where the pre-configured globally unique LCoAs will be managed between PAR and NARs via the DHCPv6 server. Jung, Koh, Lee, Soliman, El-Malki [Page 11] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 If the tunnel extension to MN is used along with an appropriated LCoA management scheme, the HI/HACK messages and the bi-directional tunnel between MAP and NAR could be eliminated. Furthermore, the Local BU (LBU) message of HMIPv6 will also be able to replace the FBU message. That is, the MN does not need to send the FBU message to MAP. Instead, the MN sends the LBU to the MAP directly. As a result, Figure 4 could be changed as Figure 6 MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | HMIPv6 Data (before HO) | | | |<===========================>| | | | | | | | | RtSolPr | | | | |------------->| | | | | PrRtAdv | | | | |<-------------| | | | | LBU | | | |---------------------------->| | | Disconnect | LBA | LBA | | | <--------------------------|-------------------------> | Connect | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 6: F-HMIPv6 with Tunnel to MN As shown in the figure, as soon as the MAP receives the FBU from the MN, it begins to communicate with MN over NLCoA. 7.2 F-HMIPv6 with Bicasting It is noted that the bicasting along with simultaneous binding [8] 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, when anticipation is used. In addition to the scenario described in the preceding section, the bicasting is applied along with simultaneous binding in F-HMIPv6, as shown in Figure 7. Note in this case that the LBU/LBACK messages are used to indicate when the MAP stops the bicasting. Jung, Koh, Lee, Soliman, El-Malki [Page 12] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 MN(at PAR) PAR MAP NAR MN(at NAR) | | | | | | HMIPv6 Data (before HO) | | | |<===========================>| | | | | | | | | RtSolPr | | | | |------------->| | | | | PrRtAdv | | | | |<-------------| | | | | FBU | | | |---------------------------->| | | Disconnect | FBACK | FBACK | | | <--------------------------|-------------------------> | | | Bicasting | | |<============================|===========================>| Connect | | | | | | | LBU and LBA | | | |<-------------------------->| | | | HMIPv6 Data (after HO) | | | |<==========================>| | | | | | Figure 7: F-HMIPv6 with Bicasting In F-HMIPv6, if the bicasting is enabled, when the packet forwarding to the NAR is indicated, the MAP will also continue to send the data packets to the MN (over PLCoA). That is, after transmitting the FBACK messages, the MAP will send the data packets destined to MN toward the NAR over the established tunnel as well as the MN over the PLCoA. The packet forwarding to the MN over PLCoA will stop, when the MAP receives a new Local Binding Update (by HMIPv6) from the MN that has moved into the NAR. 8. Security Considerations The security issues on F-HMIPv6 are basically the same with those on FMIPv6 and HMIPv6. Noting that the MN and the MAP could have an IPsec SA in the HMIPv6, the PrRtSol and PrRtAdv messages can be protected with IPsec. This feature actually provides an advantage over FMIPv6 where ND messages cannot be secured in its present form. Jung, Koh, Lee, Soliman, El-Malki [Page 13] INTERNET DRAFT Fast Handover for HMIPv6 June 2003 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. Acknowledgement The Authors would like to give special thanks to the following people for their valuable contributions: Sung Han Kim (sh-kim@etri.re.kr), ETRI Jae Hong Min (jhmin@etri.re.kr), ETRI 10. 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] D. Johnson, et al., "Mobility Support in IPv6", draft-ietf- mobileip-ipv6-21, February 2003. [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-07, October 2002. [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf- mobileip-fast-mipv6-06, March 2003. [6] N. Moore, "Optimistic Duplicate Address Detection", draft-moore- ipv6-optimistic-dad-02, February 2003. [7] Y. Han, J. Choi, and S. Park, "Advance Duplicate Address Detection", draft-han-mobileip-adad-00, May 2003. [8] K. ElMalki and H. Soliman, "Simultaneous Bindings for Mobile IPv6 Fast Handoffs", draft-elmalki-mobileip-bicasting-v6-02, Work in progress. Jung, Koh, Lee, Soliman, El-Malki [Page 14] NTERNET DRAFT Fast Handover for HMIPv6 June 2003 Author's Addresses Hee Young Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI Seok Joo Koh sjkoh@etri.re.kr Protocol Engineering Center, ETRI Jun Seob Lee juns@etri.re.kr Protocol Engineering Center, ETRI Hesham Soliman H.Soliman@flarion.com Flarion Karim El Malki Karim.El-Malki@era.ericsson.se Ericsson Radio Systems AB Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." ung, Koh, Lee, Soliman, El-Malki [Page 15]