Internet Draft Hee Y. Jung Document: draft-jung-mobileip-fastho-chain-00.txt Jae H. Min Expires: November 2002 ETRI Hyon G. Kang Chae Y. Lee KAIST Fast Handoff with Chain Tunneling for Mobile IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 Mobile IP allows a mobile node to send and receive packets regardless of the IP address of its current point of attachment in the Internet. Several handover protocol using Layer 2 information has proposed for fast handover. We propose a modification of the fast handover protocol with simple Layer 2 triggers. For successive handovers of a Mobile Node on real-time service, a chain tunneling handover is proposed. For effective operation of the chain, the chain length threshold is adopted to prevent packet delay due to the successive handovers. Tunnel negotiation is employed to adopt the local resource and security conditions and management policies. Table of Contents 1.0 Introduction...............................................2 2.0 Terminology................................................3 3.0 The Protocol...............................................3 Jung, et al. Individual [Page 1] Internet Draft Chain Tunneling June 2002 3.1 Layer 2 Requirements.....................................3 3.2 Single tunneling Handover................................3 3.3 Chain tunneling Handover.................................5 4.0 Message Format.............................................8 5.0 References.................................................8 6.0 Addresses..................................................8 1.0 Introduction Mobile IP allows a mobile node to send and receive packets with its home IP address, regardless of the IP address of its current point of attachment in the Internet. Only Internet Protocol Version 6 (IPv6) offers enough addresses and features needed for mobile networking. Mobile IPv6 (MIPv6) takes advantage of the IPv6 features to offer seamless roaming. The effective handover algorithms that significantly reduce the amount of service disruption due to the handover have been studied in the Mobile IP working group. In MIPv6 a smooth handover algorithm with buffering packets and transmitting through uni- directional tunnel is proposed [mipv6]. However, no packet is transmitted from the Mobile Node to the Correspondent Node before the binding updates to the Home Agent and the Correspondent Node are completed. Some proposals using Layer 2 information available prior to the handover are considered in the working group. They allow the Mobile Node and Access Routers to prepare for the handover by establishing bi-directional edge tunnel prior to the Layer 2 handover [fmipv6]. The Layer 2 information is the critical factor in achieving good performance for the handover procedure. The information consists of two types of triggers [l2trigger]. Because Link Up and Link Down triggers are generated as the result of the Layer 2 handover, it is usually guaranteed to supply them. However, Source Trigger, Target Trigger, and Mobile Trigger must be generated sufficiently before Layer 2 handover. Since Layer 2 system decides whether offers them or not, they are not guaranteed in the normal system. In this document, a modification of the tunnel-based handover protocol is proposed that allows the construction of a bi- directional edge tunnel between the old Access Router and the new Access Router after Layer 2 handover has been completed. This modification requires the only two triggers, Link Up and Link Down. Therefore, in view of the implementation the proposed protocol is acceptable to usual Mobile IP network. For successive handovers of a Mobile Node on real-time service, we propose a chain tunneling handover instead of anchored tunneling handover in [fmipv6]. Chain tunneling handover has advantages in the implementation and performance for the handover and Jung, et al. Individual [Page 2] Internet Draft Chain Tunneling June 2002 disadvantages in the resource utilization and security. we employ the chain length threshold and tunnel negotiation to eliminate the disadvantages in a certain degree. So, the proposed handover protocol can be used to adopt the local resource and security conditions and management policies. 2.0 Terminology This section introduces some terminology used throughout the draft. All notations except BET have the same definition as [fmipv6]. Bi-directional Edge Tunnel (BET) A bi-directional edge tunnel placed between the old AR where the MN established its old CoA and a new AR where the MN established its new CoA. The keywords "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. 3.0 The Protocol 3.1 Layer 2 Requirements In the proposed chain tunneling protocol two simple triggers of Layer 2 are required. One is the Link Up trigger. MN or new AR receive the Link Up trigger when the MN arrives on the link with the new AR. The Link Up triggers the MN or the new AR to quickly initiate signaling between them to start the process of tunnel establishment. The other is the Link Down trigger. Old AR receives the Link Down trigger when the MN leaves on the link with the old AR. The Link Down makes the old AR buffer packets for the MN. 3.2 Single Tunneling Handover 3.2.1 Mobile Determined Handover for Stateful Address Auto-configuration On receipt of the Link Up trigger, the MN sends a Fast Binding Update (F-BU) message to the new AR. The F-BU includes the MN's interface identifier and the old CoA (oCoA) which is used in the old AR subnet. On receipt of the F-BU, the new AR allocates a new CoA (nCoA) to the MN. After that the new AR sends a Handover Initiate (HI) message to the old AR to establish the tunnel from the old AR to the new AR. Jung, et al. Individual [Page 3] Internet Draft Chain Tunneling June 2002 When the old AR receives the HI message, it deletes the Visitor List entry and creates Binding Cache entry for the MN. Then the tunnel is established and the Handover Acknowledgement (HAck) message is transmitted to the new AR. Packets buffered at the old AR for the MN are tunneled with the nCoA. That is, packets are encapsulated with the source address of the old AR's address and the destination address of the nCoA. After that, all packets for the MN are encapsulated by the old AR in the same manner. On receipt of the HAck, the new AR sends the Fast Binding Acknowledgement (F-BAck) to the MN to inform the tunnel establishment. The above packets are decapsulated at the MN. In the forward direction, therefore, packets are delivered to the MN without offered load on the new AR. In the reverse direction the MN can transmit packets after it receives the F-BAck message. Packets are delivered through the tunnel between the MN and the old AR. The source and destination addresses of inner header are oCoA and CN's address respectively. However, the packets have the outer header with source address of the nCoA and the destination address of the old AR's address. Then, the old AR decapsulates them and delivers them through standard Mobile IPv6 protocol. The following figure illustrates the messaging. MN new AR old AR | | | | | Link Down ~~~>| | | Buffer | | Packets |<~~~ Link UP | | |------ F-BU -------->| | | Allocate nCoA | | |------- HI -------->| | | Update Visitor List | | & Binding Cache | |<----- HAck --------| |<---- F-BAck --------| Deliver |<==================================== Packets | | | Figure 1 - Mobile Determined Handover for Stateful Address Auto-configuration 3.2.2 Mobile Determined Handover for Stateless Address Auto-configuration Jung, et al. Individual [Page 4] Internet Draft Chain Tunneling June 2002 The main difference between stateful and stateless address auto- configuration is that, in stateful configuration, the new AR allocates the nCoA to the MN through address allocation algorithm (e.g. DHCPv6) and in stateless configuration, the MN determines the nCoA and the new AR validates it through the Duplicated Address Detection (DAD). Therefore, the MN MUST send a Fast Neighbor Advertisement (F-NA) to the new AR and receive the prefix information of the new subnet. MN new AR old AR | | | | | Link Down ~~~>| | | Buffer | | Packets |<~~~ Link UP | | |------ F-NA -------->| | | validate nCoA | |<------ RA ----------| | |------ F-BU -------->| | | |------- HI -------->| Figure 2 - Mobile Determined Handover Stateless Address Auto-configuration 3.2.3 Network Determined Handover If network determined handover is being performed, the Link Up triggers the new AR instead of the MN. On receipt of the Link Up trigger, the new AR SHOULD broadcast a Router Advertisement (RA) message to make the MN initiate handover procedure as soon as possible. MN new AR old AR | | | | | Link Down ~~~>| | | Buffer | | Packets | Link UP ~~~>| | |<------ RA ----------| | |------ F-BU -------->| | Figure 3 - Network Determined Handover 3.3 Chain tunneling Handover 3.3.1 Simplicity of Chain Tunneling Handover Jung, et al. Individual [Page 5] Internet Draft Chain Tunneling June 2002 If the MN's movement is so fast that it moves to a third AR, then the tunnel MUST be changed for correct packet delivery. In this document chain tunneling algorithm is employed for this condition. Chain tunneling has simplicity and scalability for implementation. Some additional messages (e.g. Handover To Third (HTT)) which is employed in [fmipv6] do not need for handover. Since the BET in [enhan-beth] uses the oCoA of the MN, the ARs MUST have the ability to force the MN to form a new CoA before the additional tunnel is established. Therefore, in [enhan-beth] the Layer 2 information MUST be needed which is available prior to the handover to the third AR. However, the BET in this document uses the nCoA of the MN instead of the oCoA. Consequently, the chain tunneling can be implemented with simple triggers in this document. Since the reestablishment of packet delivery path spends same amount of time compared to the single tunneling handover in Section 3.2, the chain tunneling SHOULD be employed at the fast handover for the real-time delay-sensitive traffics. The overall procedure of the chain tunneling handover is very simple. The following figure shows the procedure. MN third AR second AR first AR | | | | | | | Deliver |<================================================= Packets | | Link Down ~~~>| | | | Buffer <============| | | Packets | |<~~~ Link UP | | | |------ F-BU ----->| | | | Allocate nCoA | | | |------ HI ------>| | | | Update Visitor List | | | & Binding Cache | | |<---- HAck ------| | |<---- F-BAck -----| Deliver | |<=============================== Packets | | | | | Figure 4 - Chain Tunneling Handover 3.3.2 Chain Length Threshold The chain tunneling may not be desirable due to some disadvantages. One of them is that it increases the latency of packet delivery. Jung, et al. Individual [Page 6] Internet Draft Chain Tunneling June 2002 However, above problem can be resolved by employing chain length threshold. The proper threshold SHOULD be selected to limit the latency of packet delivery. When the chain length becomes the threshold, the MN SHOULD choose whether the MN registers to the HA (or CN) through standard MIPv6 registration process, or it modifies the tunnel through the anchored tunneling at the first AR. The chain length threshold MAY be used for eliminating the potential failure points. 3.3.3 Tunnel Negotiation For the local resource utilization we adopt the tunnel negotiation. When the new AR initiates the tunnel construction process with HI message, the new AR negotiates tunnel attributes with the old AR. The critical attributes are following: - Tunnel Lifetime - Tunnel Renewal Option The new AR sends HI with a certain Lifetime value and Renewal flag based on the local resource conditions. The old AR evaluates the attributes and stores them in the Binding Cache for the MN, if they are acceptable. If the attributes are not acceptable based on the local conditions, the old AR SHOULD respond HAck with a lower value for the Lifetime value. If the old AR has old tunnel with the previous AR, the lifetime of the new tunnel MUST be smaller than that of the old tunnel. The Renewal flag can be reset to indicate that the old AR is not willing to renew the tunnel in the future. On the receipt HAck, the new AR MUST adjust the attributes. Then the negotiation process is completed. When the lifetime of the last tunnel becomes enough small, if the flag is renewable then the current AR sends the Binding Update message to extend the tunnel lifetime through the chain. If the flag is not renewable then the current AR MUST force the MN to register to the HA (or CN) through standard MIPv6 registration process. 3.3.4 old CoAs in F-BU One of the disadvantages is that it may result in routing loops. In chain tunneling handover the MN informs the new AR of the old CoAs through the F-BU message. That is, the new AR gets the information for the old ARs or subnets where the MN has visited. Therefore, if there is a routing loops due to the MN's movement the new AR MUST modify the loop chain. When the new AR finds the routing loop, it updates the Binding Cache and Visitor List entry for the MN. Since the tunnels on the Jung, et al. Individual [Page 7] Internet Draft Chain Tunneling June 2002 intermediate ARs in the loop have lifetime limit, the tunnels are torn down automatically. However, the useless tunnels SHOULD be removed for the system efficiency as soon as possible. The new AR sends HI with Release Extension HI(r) through the chain loop. On the receipt HI(r) the intermediate AR releases Binding Cache entry, tunnel, network resources for the MN. After that it replies HAck(r). 4.0 Message Format The messages used in this document are represented in [fmipv6]. Please see [fmipv6] for more information on the message formats and options. 5.0 References [mipv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6 (work-in progress)", draft-ietf-mobileip-ipv6-17.txt, May 2002. [fmipv6] G. Dommety et al., "Fast Handovers for Mobile IPv6 (work- in progress)", draft-ietf-mobileip-fast-mipv6-04.txt, Mar 2002. [l2trigger] J. Kempf et al., "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", draft-manyfolks- l2-mobilereq-01.txt, Nov 2001. [enhan-beth] S. Faccin et al., "Enhancements to Bi-directional Edge Tunnel Handover for IPv6", draft-sreeman-enhance-beth-ipv6-00.txt, Sep 2001. 6.0 Addresses Hee Y. Jung Protocol Engineering Center Electronics and Telecommunication Research Institute 161 Kajung-Dong, Yusong-Gu, Taejon, 305-350, Korea Phone: +82 42 860 4928 E-mail: hyjung@etri.re.kr Fax: +82 42 861 5404 Jae H. Min Protocol Engineering Center Electronics and Telecommunication Research Institute 161 Kajung-Dong, Yusong-Gu, Taejon, 305-350, Korea Phone: +82 42 860 5805 EMail: jhmin@etri.re.kr Fax: +82 42 861 5404 Jung, et al. Individual [Page 8] Internet Draft Chain Tunneling June 2002 Hyon G. Kang Department of Industrial Engineering KAIST 373-1, Kusung-dong, Yusong-Gu, Taejon, 305-701, Korea Phone: +82 42 869 5916 E-mail: s_kanghg@kaist.ac.kr Fax: +82 42 869 3110 Chae Y. Lee Department of Industrial Engineering KAIST 373-1, Kusung-dong, Yusong-Gu, Taejon, 305-701, Korea Phone: +82 42 869 2916 E-mail: cylee@mail.kaist.ac.kr Fax: +82 42 869 3110 Jung, et al. Individual [Page 9]