Internet Draft HeeYoung Jung, ETRI Internet Engineering Task Force Hesham Soliman, Flarion draft-jung-mobopts-fhmipv6-00.txt Seok Joo Koh, KNU Expires October 2005 Jae Yong Lee, CNU April 2005 Fast Handover for Hierarchical MIPv6 (F-HMIPv6) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668 [1]. 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. Abstract This document proposes a scheme to support Fast Handover over HMIPv6 networks. The MIPv6 mobility could be more enhanced by combining FMIPv6 with HMIPv6, in which MIPv6 is benefited from all the advantages of the respective schemes. This document describes how to use FMIPv6 for HMIPv6 (F-HMIPv6). The F-HMIPv6 is designed to be friendly with the data transport feature of HMIPv6. In F-HMIPv6, the tunnel for fast handover is established between MAP and NAR, rather than between PAR and NAR. For this purpose, the MN exchanges the FMIPv6 messages with MAP, not PAR. The F-HMIPv6 utilizes the FMIPv6 messages for handover support without further defining any new messages. For the F-HMIPv6, it is proposed to define a new flag 'F' in the HMIPv6 MAP option. Jung, et al. Expires October 2005 [Page 1] Internet Draft Fast Handover for HMIPv6 April 2005 Table of Contents 1. Introduction..................................................3 2. Terminology...................................................3 3. A Simple FMIPv6-to-HMIPv6 Scheme..............................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 5.3 AR based RtSolPr/PrRtAdv.................................10 6. Messages for F-HMIPv6........................................10 6.1 A New Flag in the HMIPv6 MAP Option......................11 6.2 Use of FMIPv6 messages in F-HMIPv6.......................12 7. Security Considerations......................................12 8. Acknowledgement..............................................13 9. References...................................................13 Author's Addresses..............................................13 Full Copyright Statement........................................14 Intellectual Property...........................................14 Jung, et al. Expires October 2005 [Page 2] Internet Draft Fast Handover for HMIPv6 April 2005 1. Introduction The HMIPv6 [3] was developed to reduce the signaling overhead and delay concerned with Binding Update (BU) in Mobile IPv6. 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 [4] 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 October 2005 [Page 3] Internet Draft Fast Handover for HMIPv6 April 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. A Simple FMIPv6-to-HMIPv6 Scheme A natural and straightforward choice to combine FMIPv6 with HMIPv6 is to directly apply the FMIPv6 handover scheme in the HMIPv6 networks, as per their own specifications. In this case, a bi-directional tunnel will be established between PAR and NAR 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 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 to the data packets sent by MAP according to the HMIPv6 operations. In the viewpoint of the HMIPv6 operations, the simple straightforward approach has the following disadvantages: Jung, et al. Expires October 2005 [Page 4] Internet Draft Fast Handover for HMIPv6 April 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 Jung, et al. Expires October 2005 [Page 5] Internet Draft Fast Handover for HMIPv6 April 2005 required for an on-going data session between MN and CN, then the F- HMIPv6 scheme will apply to the MN, ARs and MAP. +-------+ | 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 October 2005 [Page 6] Internet Draft Fast Handover for HMIPv6 April 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: 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 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. 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 October 2005 [Page 7] Internet Draft Fast Handover for HMIPv6 April 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. 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 October 2005 [Page 8] Internet Draft Fast Handover for HMIPv6 April 2005 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. 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 (possibly with FNA option) message from the newly incoming MN. 5) 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. 6) The MN sends FNA messages to NAR, when it detects that it is moved in the link layer. Then, the NAR delivers the buffered data packets to the MN over PLCoA. 7) 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. 8) 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 October 2005 [Page 9] Internet Draft Fast Handover for HMIPv6 April 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. 5.3 AR based RtSolPr/PrRtAdv F-HMIPv6 assumes that a MAP has necessary information about its serving ARs such as IP address and link layer ID. It seems to be natural if we refer convenient mobile networks that are hierarchically configured. If an access system provides the information sharing between ARs, 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. This kind of approach was already touched in the HMIPv6 (Appendix A). In this case, the procedure that described in the draft could be used for remaining procedure as shown in Figure 4. 6. Messages for F-HMIPv6 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. Jung, et al. Expires October 2005 [Page 10] Internet Draft Fast Handover for HMIPv6 April 2005 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. 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 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 6: A new flag in the MAP option Fields: F When set indicates that the MAP support fast handover by F-HMIPv6. Jung, et al. Expires October 2005 [Page 11] Internet Draft Fast Handover for HMIPv6 April 2005 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. 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 | +--------------+-----------+-------------+---------------------+ 7. 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. Jung, et al. Expires October 2005 [Page 12] Internet Draft Fast Handover for HMIPv6 April 2005 8. Acknowledgement The Authors would like to give special thanks to the following people for their valuable comments and discussion for enhancing the F-HMIPv6. Jun Seob Lee (ETRI) Bryan Hartwell (Ashnet) 9. 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. [3] D. Johnson, et al., "Mobility Support in IPv6", RFC 3775, June 2004. [4] H. Soliman, et al., "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-04, December 2004. [5] R. Koodli, et al., "Fast Handovers for Mobile IPv6", draft-ietf- mipshop-fast-mipv6-03, October 2004. Author's Addresses HeeYoung 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 Jae Yong Lee jyl@cnu.ac.kr Chungnam National University Jung, et al. Expires October 2005 [Page 13] Internet Draft Fast Handover for HMIPv6 April 2005 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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 October 2005 [Page 14]