Internet Draft HeeYoung Jung, ETRI Internet Engineering Task Force HongSeok Jeon, ETRI draft-jung-mipshop-nsfho-00.txt Expires February 2006 August 2005 Network Side Fast Handover in Mobile IPv6 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document addresses a network side solution of fast handover in Mobile IPv6. Existing FMIPv6 basically assumes the involvement of mobile nodes in handover procedure. However, in some cases, it may not be easy to realize fast handover function into all mobile nodes. In the case, a network operator may want to provide fast handover service to users by using only networks entities. To achieve network side fast handover, this document basically uses bi-directional tunnel between a previous access router and new access router. The proposed fast handover scheme has simpler procedure than the existing FMIPv6 and mostly uses the existing messages. Jung, et al. Expires February 2006 [Page 1] Internet Draft Network Side Fast Handover June 2005 Table of Contents 1. Motivation....................................................3 2. Terminology...................................................3 3. Protocol overview.............................................4 3.1 Assumptions...............................................4 3.2 Design considerations.....................................5 4. Protocol Operations...........................................5 5. Changes from FMIPv6...........................................7 6. Security Considerations.......................................8 7. Acknowledgement...............................................8 8. References....................................................9 Author's Addresses...............................................9 Full Copyright Statement.........................................9 Intellectual Property...........................................10 Jung, et al. Expires February 2006 [Page 2] Internet Draft Network Side Fast Handover June 2005 1. Motivation Mobile IPv6 [3] was developed to support mobility in IPv6 network. Mobile IPv6 can provide service continuity across subnets to mobile nodes (MN) through binding update (BU) to HA/CN. However it was being reported that Mobile IPv6 may have difficulty with supporting real- time services because of its latency during handover. Considering the requirements of next generation IP network, the support for the real- time services like VoIP would be a crucial requirement. Accordingly some protocols are being suggested to address this problem. FMIPv6 [4] is a typical solution to solve the handover latency problem of Mobile IPv6. FMIPv6 realizes the fast handover by using link layer triggers, new CoA pre-configuration, and tunneling. However it is noted that FMIPv6 essentially assumes the involvement of mobile nodes in handover procedure. That is, in FMIPv6, a mobile node should performs several works related to handover such as the awareness of link layer triggers, solicitation of proxy RA, new CoA pre- configuration, sending of F-BU to PAR and FNA to NAR as specified in [4]. However, in some cases, it may not be easy for network operators to implement the handover function into all mobile nodes in economical or practical way. In this case, it will be very hopeful if we can realize the fast handover by using only network side entities, e.g. PAR and NAR, etc. This document provides a solution to support the fast handover by using only network entities as the name of NS-FMIPv6. To achieve it, this document basically uses a bi-directional tunnel between PAR and NAR. This approach is very similar to the post-registration method described in [5] and additionally some schemes considering IPv6 characteristics are added. Note that NS-FMIPv6 does not require handover functionalities except those in Mobile IPv6 and optionally op-DAD [6] for mobile nodes. Moreover the procedure of NS-FMIPV6 is much simpler than it of the existing FMIPv6 because it does not require the involvement of MNs. It is expected that the simpler procedure may result in lower handover latency. 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 the same terminologies described in the MIPv6 [3] and FMIPv6 [4] documents. Jung, et al. Expires February 2006 [Page 3] Internet Draft Network Side Fast Handover June 2005 3. Protocol overview 3.1 Assumptions This document basically assumes followings. - Pre-handover trigger (PRE-HO), which indicates imminent layer 2 handover, and link up trigger (LU) are available - Network entities such as PAR and NAR can aware these triggers but MNs may not - Mobile nodes have only the handover functions specified in Mobile IPv6 and optionally optimistic DAD - Collision probability is low enough to use optimistic DAD This document also assumes following the same reference architecture as in FMIPV6. +-----+ +----+ | HA | | CN | +-----+ +----+ | | +-----+ +-----+ | | +============+ | | | IP Network | | | +============+ | | +-------+ +------+ | | +-----+ +-----+ Pre-HO ~> | PAR | | NAR |<~ LU +-----+ +-----+ +----+ | MN | ----------> +----+ Movement Figure 1: Reference Architecture Jung, et al. Expires February 2006 [Page 4] Internet Draft Network Side Fast Handover June 2005 3.2 Design considerations In NS-FMIPv6, the first consideration is to make the handover support to MNs possible even if only Mobile IPv6 and optionally op-DAD are implemented in them. This consideration may be one of important requirements in the deployment aspect for fast handover schemes in Mobile IPv6. In FMIPv6, the handover latency of Mobile IPv6 was classified into three main delay factors such as movement detection, CoA configuration and binding update. Basically NS-FMIPv6 follows the approach specified in FMIPv6. However the process regarding CoA configuration is a little different because the process highly requires the involvement of MNs. The considerations on each delay factor in NS-FMIPv6 are described in the followings. o Movement detection delay NS-FMIPv6 uses the same approach as FMIPv6. That is, it needs pre- handover trigger (PRE-HO), which indicates imminent link layer handover, and link up trigger (LU), which informs the establishment of new link at NAR for quick movement detection. However networks entities aware these trigger but MNs may not. o CoA configuration delay NS-FMIPv6 does not support new CoA pre-configuration in order to keep the independency with MNs. Therefore additional schemes may be needed to support fast CoA configuration in NAR. o Binding update delay Bi-directional tunnel will be used to prevent service interruption during link change and binding update like specified in FMIPv6. However the HI/HACK messages are a little different from them of the existing FMIPv6 because these messages are used just for the exchange of information of MN and possibly for tunnel establishment. 4. Protocol Operations Figure 2 shows the handover procedure in NS-FMIPv6. Jung, et al. Expires February 2006 [Page 5] Internet Draft Network Side Fast Handover June 2005 MN PAR NAR HA/CN(or MAP) | | | | | Pre-HO| | | | ==>| | | | | HI | | | |---------->| | | | | | | | HACK | | | |<----------| | | | | | | | Forwarding| | | |==========>| | | | | | | | |<== LU | | fast RA & | | | Packet delivery | | |<----------------------| | | | | | @@@ op-DAD(optional) | | | | | | | BU | | | |---------------------------------->| | | | | | | | | Figure 2: Handover Procedure The descriptions for each step are given as follows. (1) PAR receives pre-ho trigger. The trigger indicates that link layer handover of an MN is imminent and includes the link layer address (e.g. MAC address) of the MN and NAR. It is assumed that PAR already has the mapping between link layer address and IP address of the MN and NAR. (2) PAR sends HI message to NAR to negotiate bi-directional tunnel with NAR for the MN. The HI message includes link layer address of the MN and previous CoA (PCoA) as specified in FMIPv6. (3) NAR replies with HACK which includes the result for bi-directional tunnel negotiation. Also NAR creates host routing entry for the PCoA of the MN. (4) If PAR received HACK and its result is successful, it starts forwarding the packet destined to the MN toward NAR. Jung, et al. Expires February 2006 [Page 6] Internet Draft Network Side Fast Handover June 2005 (5) When NAR is informed that new link to the MN is established after the completion of link layer handover through LU trigger, NAR immediately unicasts (or muticasts) RA to the MN. Note that the RA is different from existing fast RA [7] in the point that it is unsolicited router advertisement. The unicast of RA is chosen for air resource efficiency. If an air interface naturally supports broadcast, Multicast RA also can be used. Simultaneously, the NAR deliveries the buffered packet to the MNs using the host entry for the MN. (6) If the network is being well managed and the probability of address collision is very low, then the MN can configure new address using the fast RA without DAD procedure. Optionally, Op- DAD could be used to enhance the stability of operation. (7) After configuring new CoA, the MN performs binding update to HA/CN according to normal Mobile IPv6 procedure. 5. Changes from FMIPv6 NS-FMIPv6 basically follows the procedures and message formats of FMIPv6. However, several changes are needed to achieve network only solution. o Triggering of HI message In FMIPv6, HI message is normally triggered by FBU message. On the other hand, the HI message in NS-FMIPv6 is sent from PAR to NAR if PRE-HO trigger is informed to PAR because it does not assume the triggering message from MNs. o Tunneling point in NAR In FMIPv6, the tunnel end point in NAR is NCoA. However, it is noted that NCoA is not pre-configured in NS-FMIPv6. Therefore the end point in NS-FMIPv6 should be changed to NAR. To deliver the packets destine to PCoA, NAR also has to prepare host routing entry for the PCoA in advance. o NAR's awareness of attaching of MN In FMIPv6, NAR is aware of attaching of MN by FNA message from the MN. On the other hand, since it is assumed in NS-FMIPv6 that the NAR can quickly recognize the attachment through LU trigger, the NAR sends unsolicited fast RA to the MN. o Changed in HI/HACK messages NS-FMIPv6 uses HI/HACK messages only for the information exchange for the moving MN and the tunnel establishment for packet forwarding, not for the verification of pre-configured NCoA. Therefore some minor changes are required in the existing HI/HACK messages. Jung, et al. Expires February 2006 [Page 7] Internet Draft Network Side Fast Handover June 2005 - Handover Initiate (HI) message The HI message for NS-FMIPv6 is identical to FMIPv6 HI excepting Code value. The HI for NS-FMIPv6 newly defines a code value of 2 in order for PAR to inform NAR that NS-FMIPv6 is now working. Code 0: when PAR processes an FBU with PCoA as source IP address. 1: when PAR processes an FBU whose source IP address is not PCoA. 2: When PAR processes NS-FMIPv6, not pure FMIPv6. Also, two flags should be set as follows. S: This flag MUST be 0 because HI of NS-FMIPv6 does not include NCoA. U: This flag MUST be 1 in order NAR starts to buffer packets addressed to MN. Valid Option: Link-layer address of MN Previous Care of Address New Care of Address (it is not necessary in NS-FMIPv6) It might be required that the lifetime of bi-directional tunnel is conveyed by HI, since there is not FBU message in NS-FMIPv6. - Handover Acknowledge (HAck) The HAck for NS-FMIPv6 is the same as that of FMIPv6. However the consideration on the following option should be given. Valid Options: New Care of Address (Hack of S-FMIPv6 does not include this option because 'S' bit in HI is not set.) 6. Security Considerations The security issues of NS-FMIPv6 are basically in line with it of FMIPv6. Note that the security of NS-FMIPv6 could be simpler than FMIPv6 because it does not need the security consideration over air interface like in FMIPv6. 7. Acknowledgement The Authors would like to give special thanks to JungHoon Jee for his valuable comments and discussion for enhancing the NS-FMIPv6. Jung, et al. Expires February 2006 [Page 8] Internet Draft Network Side Fast Handover June 2005 8. 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] R. Koodli, et al., "Fast Handovers for Mobile IPv6," RFC 4068, July 2005. [5] K. El Malki, "Low Latency Handoffs in Mobile IPv4," IETF draft draft-ietf-mobileip-lowlatency-handoffs-v4-09.txt, June 2004 [6] N. Moore, "Optimistic Duplicate Address Detection for IPv6," draft-ietf-ipv6-optimistic-dad-05, February 2005. [7] Mohamed Khalil et al., "Fast Router advertisement," IETF draft draft-mkhalil-ipv6-fastra-06.txt, Feburay 2005 Author's Addresses HeeYoung Jung hyjung@etri.re.kr Protocol Engineering Center, ETRI HongSeok Jeon jeonhs@etri.re.kr Protocol Engineering Center, ETRI 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. Jung, et al. Expires February 2006 [Page 9] Internet Draft Network Side Fast Handover June 2005 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 February 2006 [Page 10]