Standards Track James Kempf Internet Draft Pat Calhoun Document: draft-kempf-beth-ipv6-02.txt Gopal Dommety Expires: March 2002 Sebastian Thalanany September 2001 Ajoy Singh Peter J. McCann Tom Hiller Bidirectional Edge Tunnel Handover for IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This is an individual draft for consideration by the Mobile IP Working Group. 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 discusses an extension to the Fast Mobile IPv6 handover protocol described in draft-ietf-mobileip-fastmipv6-01.txt that reduces the amount of L3 latency in Mobile IPv6 handover to zero. The protocol uses bi-directional edge tunnels and deferred Care of Address establishment to eliminate L3 radio traffic during handover, allowing a Mobile Node to move rapidly across a series of subnets without having to change its Care of Address while a real time session is in progress. Later, when the real time session has completed or the Mobile Node has stopped moving, the Mobile Node can use the Fast Mobile IPv6 handover protocol or the original Mobile IPv6 handover protocol to establish a Care of Address. Table of Contents 1. Introduction ...................................................2 1.1. Terminology ..................................................3 1.2. Standards Language ...........................................5 2. BETH Protocol ..................................................5 2.1. L2 Requirements ..............................................6 2.2. Two Party Handover ...........................................7 [Page 2] Bi-directional Edge Tunnel Handover September 2001 For IPv6 2.3. Three Party Handover ........................................11 2.4. Renewal or Termination of Tunneling Service .................17 2.5. When and How to Obtain a nCoA ...............................17 2.5.1. BET End of Life or Premature BET Termination .............18 2.5.2. MN Decision to Obtain a nCoA .............................19 2.5.3. Failure of BET Handover ..................................20 2.6. Message Descriptions ........................................20 2.6.1. Handover Request (HRqst) .................................20 2.6.2. Handover Reply (HRply) ...................................23 2.6.3. Handover To Third (HTT) ..................................24 2.6.4. Lifetime Option ..........................................24 3. BETH Applicability Statement ..................................25 4. Security Considerations .......................................25 4.1. MN to AR Connection .........................................25 4.2. AR to AR Connection .........................................26 5. Acknowledgements ..............................................26 6. References ....................................................26 7. Authors' Addresses ............................................27 1. Introduction A major impediment to using IPv6 for real time wireless traffic is the performance of Mobile IPv6 (MIPv6) handover. When a Mobile Node (MN) moves between subnets, signaling between the MN and various network elements over the radio link is required before the MN can establish a new Care of Address (CoA) and start using the CoA to send and receive traffic from Corresponding Nodes (CNs) and its Home Agent (HA). MIP-related signaling consists of traffic between the MN and the old and new Access Routers (ARs) to establish and defend the MN's new CoA on the new subnet, and Binding Updates (BUs) to the CNs and HA to inform them of the new CoA. Typically, the radio link is the most performance-constrained part of a wireless network. While wired edge network performance runs on the order of a less than a millisecond to ten milliseconds, wireless link performance for IP traffic in typical 3G networks runs from tens to hundreds of milliseconds [1]. Any reduction in signaling on the wireless link during handover therefore translates directly into improved real time traffic performance. Another source of signaling latency is operating system scheduling. By putting Mobile IP on the critical real time handover path, the choice of mobile operating systems is restricted to those that support hard real time scheduling if real time multimedia traffic is to be supported. Between operating system latency, signaling at L3 over the air to establish and defend a new CoA, and the L2 latency that is unavoidable in handover, latencies involved in performing a full Mobile IP CoA change during handover could easily accumulate beyond the limit at which a user begins to perceive gaps and other artifacts in voice traffic. If IP is ever to become a viable substrate for [Page 3] Bi-directional Edge Tunnel Handover September 2001 For IPv6 handling carrier class real time multimedia traffic over the radio link, the probability of handover related artifacts must be minimized. In [3], the Fast Mobile IPv6 (FMIPv6) protocol is described. The protocol is designed to reduce handover latency below that exhibited by the original MIPv6 movement detection and handover algorithm [4] by allowing the MN to begin (anticipate) the process of new CoA assignment while still attached to its old AR. FMIPv6 requires MIP- related signaling over the air during handover. While FMIPv6 achieves significant reductions in latency, it is still open to a low to moderate probability of human-perceptible artifacts occurring on slow links if L2 handover is lengthy or if the adverse effects of radio signal fading cause signaling traffic to be delayed or dropped. In addition, the FMIPv6 protocol as described in [3] provides minimal support for the case where a fast moving MN moves off an AR before it has completely established a new CoA. In this document, an extension of the FMIPv6 protocol is described. The extension reduces handover latency at L3 to zero, and allows a MN to move off an AR before obtaining a new CoA. The approach can be simply stated as delaying the CoA change until IP traffic, and in particular real time IP traffic, is reduced or is absent, or until the MN is moving slowly enough that it has time to obtain a new CoA. If the MN moves while still using its old CoA, the ARs on its path set up a bi-directional edge tunnel (BET) between an anchor AR and the AR handling the MN to assure that the MN's traffic is routed properly. This approach allows the MN to move rapidly across a connected series of subnets without any MIP-related signaling traffic over the air. Due to its use of BETs, the approach is called the Bi- directional Edge Tunnel Handover (BETH) technique. 1.1. Terminology This section introduces some terminology used throughout the draft. oAR - old Access Router, the AR involved in handling a MN's traffic prior to an L2 handover. nAR - new Access Router, the AR anticipated to be handling a MN's traffic after completion of an L2 handover. aAR - anchor Access Router, the AR that is currently handling the network end of the BET, where the MN originally established its aCoA. oCoA - old Care of Address, the Care of Address prior to the MN's first movement. In this document, it may be reused until the MN determines an appropriate time to change it, even if the MN changes subnet. [Page 4] Bi-directional Edge Tunnel Handover September 2001 For IPv6 nCoA - new Care of Address, the Care of Address in the new subnet. In this document, configuration with a nCoA may be delayed while the MN is engaged in latency-sensitive real time traffic or is rapidly moving across a series of ARs. aCoA - anchor Care of Address, the Care of Address after a MN has moved and elected not to establish a nCoA at nAR. HRqst(s)(resp. HRply(s)) - Designates a Handover Request (resp. Handover Reply) message that results from a source L2 trigger. The HRqst message is a variant of the HI message described in [3], the HRply is a variant of the HACK. HRqst(t) (resp. HRply(t)) - Designates a Handover Request (resp. Handover Reply) message that results from a target L2 trigger. HRqst(r)(resp. HRply(r)) - Designates a Handover Request (resp. Handover Reply) message sent to request (resp. respond to a request for) an extension in the tunnel service time out, or to cancel tunnel service for a particular MN. HTT - Designates Handover To Third. An HTT message is exchanged between an oAR and an nAR (the "third" in the name) when a BET is already established for the MN to an aAR and the MN is using an aCoA. The HTT message instructs the nAR to communicate with the aAR as if the nAR had received a target trigger, in order to move the wireless link end of the BET from oAR to nAR. The HTT sent as a request is a variant of the HI message from [3] while the HTT sent as a reply is a variant of the HACK. bi-directional edge tunnel (BET) - A bi-directional tunnel placed between the AR where the MN first established its current CoA and a new AR to which the MN is attached, where the CoA would be topologically incorrect if used. The new AR tunnels packets from the MN and having the source address as the MN's old CoA to the old AR. The old AR tunnels packets to the MN and having the destination address as the MN's old CoA to new AR. The new AR detunnels the MN-directed packets and sends them over the radio link to the MN (and hence there is no BET tunnel overhead on the air link). The old AR detunnels CN-directed packets and sends them into the subnet where the old CoA is topologically correct. BETs allow use of the old CoA without running the risk of ingress or egress filtering. bi-directional edge tunnel handover (BETH) - Handover that involves establishing a new BET, or moving the radio interface end of the BET from oAR to nAR while keeping aAR unchanged. [Page 5] Bi-directional Edge Tunnel Handover September 2001 For IPv6 L2 handover - Movement of a MN's point of Layer 2 (L2) connection from one wireless access point to another. Depending on the L2, an L2 handover may traverse both a wireless and a wired link, or just a wired link. L3 handover - The process by which a MN obtains a new CoA from the AR, thus updating its routing reachability. L3 handover may occur partially before and partially after L2 handover, or it may occur entirely after L2 handover. L2 trigger - Information from L2 that informs L3 of the detailed events involved in handover sequencing at L2. L2 triggers are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols. See [2] for more detail on L2 triggers. source trigger - An L2 trigger that occurs at oAR, informing the oAR that L2 handover is about to occur. target trigger - An L2 trigger that occurs at nAR, informing the nAR that an MN is about to be handed over to nAR. edge network - A collection of interconnected subnets within a local routing domain that connect directly with the wireless network via wireless access points. IP address identifier - An IP address of a MN or AR, or an L2 identifier that allows an AR to deduce the IP address of a MN or AR. If it is an L2 identifier, the identifier is specific to the L2 technology. ping-ponging - Rapid back and forth movement between two wireless access points due to failure of L2 handover. Ping- ponging can occur if radio conditions for both the old and new access points are about equivalent and less than optimal for establishing a good, low error L2 connection. 1.2. Standards Language 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 [5]. 2. BETH Protocol Figure 1 illustrates the basic idea behind BETH. [Page 6] Bi-directional Edge Tunnel Handover September 2001 For IPv6 +------+ | CN | +------+ ^ | ... | v BET +------+ +------+ | aAR |<@@@@@@@@>| AR | +------+ +------+ ^ | wireless link v movement +------+ ---------> | MN | +------+ Figure 1 - BETH Concept BETH leverages off the BET established during fast handover to remove all MIP-related radio link signaling. Rather than performing signaling to establish the nCoA, the MN defers nCoA establishment and continues to use the BET and the aCoA established at the aAR. If the MN moves to another AR before establishing a nCoA, the AR to which the MN will attach signals aAR to move the wireless link end of the BET to it. The network end of the BET remains anchored at aAR until the MN changes CoA. 2.1. L2 Requirements For maximum performance, the BETH protocol requires an L2 trigger at oAR prior to L2 handover start or an L2 trigger prior to L2 handover completion at nAR, and an L2 trigger at oAR, nAR, and MN immediately upon completion of L2 handover. Without these L2 triggers, the amount of latency involved in L3 messaging would increase as a result of over-the-air L3 signaling and eliminate any gains from BETH. In addition, an L2 trigger at oAR or nAR immediately when L2 handover starts can help to optimize handover smoothing, if smoothing is necessary. The L2 triggers involved in BETH are described in [2]. The following abbreviations are used in message flow diagrams to simplify referring to L2 triggers. [Page 7] Bi-directional Edge Tunnel Handover September 2001 For IPv6 L2 Trigger Abbreviation ---------- ------------ Source Trigger L2-ST Target Trigger L2-TT Link Down L2-LD Link Up L2-LU Table 1 - L2 Triggers The protocol also requires that L2 handover be secure. This requirement is discussed in more detail in Section 3. 2.2. Two Party Handover Two party handover involves handover between oAR and nAR when MN is using a CoA associated with oAR's subnet, and the handover occurs the first time an MN moves after having established a CoA at oAR. In the normal MIPv6 and FMIPv6 cases, this would trigger the MN to establish a nCoA. In BETH, the MN delays establishing a nCoA if latency- sensitive real time traffic is underway. The protocol for two party handover is very similar to the protocol involved in POST- REGISTRATION handover from [6], and is shown in Figure 2. Message descriptions are given in Section 2.6. 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU ^ ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c) L2-LU ---> | MN | ---------> +------+ Figure 2 - Two Party Handover The following describes the progress of a two party handover. The numbered items refer to steps in Figure 2. 1) Either the oAR or nAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: [Page 8] Bi-directional Edge Tunnel Handover September 2001 For IPv6 a) The L2 trigger is a source trigger (L2-ST) at oAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for nAR. b) The L2 trigger is a target trigger (L2-TT) at nAR. The trigger contains the MN's L2 address and an IP identifier for oAR. 2) The AR receiving the trigger sends a Handover Request (HRqst) to the other AR. There two cases: a) If oAR is sending the HRqst, the H bit is set, indicating it is an HRqst(s). The HRqst(s) contains a Lifetime option, an IP address option containing the MN's home address, an IP address option containing the MN's oCoA, and an LLA option containing the MN's L2 address. The LLA for IPv6 is described in [3]. The Lifetime option contains the amount of time the oAR is willing to extend tunnel service to the MN's packets before the nAR must renew the BET. If the lifetime is zero, the oAR is not willing to tunnel any packets for MN. b) If nAR is sending the HRqst, the T bit is set, indicating it is an HRqst(t). The HRqst(t) contains a Lifetime option, and an LLA option containing the MN's L2. Neither the MN's home address nor the MN's oCoA are sent because neither are known. The Lifetime option contains a request for the amount of time the oAR should extend tunnel service for the MN's packets. 3) The AR receiving the HRqst sends a Handover Reply (HRply) to the other AR. There are two cases: a) If oAR is sending the HRply, the T bit is set, indicating that the reply is in response to a HRqst(t), i.e. it is an HRply(t). The HRply(t) contains a Lifetime option, an IP address option containing the MN's home address, an IP address option containing the MN's oCoA, and an LLA containing the MN's L2 address. The Lifetime option contains the amount of time the oAR is willing to extend tunnel service to the MN's packets before nAR must renew the request. If the lifetime is zero, the oAR is not willing to extend tunnel service to the MN. b) If nAR is sending the HRply, the H bit is set, indicating the reply is in response to a HRqst(s), i.e. it is an HRply(s). No additional information is required, the sequence number identifies the reply. [Page 9] Bi-directional Edge Tunnel Handover September 2001 For IPv6 4) Start of L2 handover is signaled by an L2-LD trigger at oAR and MN. Completion of L2 handover is signaled by an L2-LU trigger at nAR and MN. Each handles the trigger in the following way: a) When the oAR receives the L2-LD trigger, it begins forwarding MN-bound packets through the BET to nAR. b) When the nAR receives the L2-LU trigger, it begins delivering packets to the MN and forwards any outbound packets from MN through the BET to oAR. c) Based on its current movement traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA as described in [3] or [4]. 5) The oAR becomes an aAR if MN should move again without having changed CoA to nAR's subnet, oCoA becomes aCoA, and nAR becomes oAR. 6) Should L2 handover fail in Step 4 and a ping-pong situation arise, the oAR can cancel the BET by sending an HRqst(r) to nAR with lifetime zero. In this case, the oAR simply continues delivering packets to MN exactly as if no handover had been pending. The actual timing of BET placement depends on the available L2 triggers. The BET is placed between oAR and nAR using the IPv6 tunneling procedure described in [7]. With optimal L2 trigger information, as described above, the BET can be arranged immediately at the point of L2 handover, when the link to the MN goes down. In the absence of optimal L2 trigger information, the HRply acts as the trigger for BET placement. Particular implementation and deployment scenarios may require that techniques be employed to smooth handover by providing for a means to convey packets arriving during the unavailability of L3 service to the MN. The exact techniques involved in smoothing are currently under discussion in the working group and are outside the scope of this document. The forward and reverse tunnels are established as follows: 1) The forward tunnel is established by oAR, when it begins tunneling packets with MN's oCoA as the destination address to nAR. If the nAR receives any tunneled packets from the oAR with the MN's oCoA as the original destination, nAR de-tunnels them and sends them to MN. 2) The reverse tunnel is establishedby nAR, when it nAR begins tunneling packets from the MN with oCoA as the source address to oAR. If the oAR receives any tunneled packets from nAR with the MN's oCoA as the source address on the encapsulated packet, it de-tunnels the packets and routes them to the original [Page 10] Bi-directional Edge Tunnel Handover September 2001 For IPv6 destination address, as if the packet had been sent on oAR's subnet. Once the BET between aAR and the current AR is in place, it is torn down by one of the following events: 1) The aAR decides to stop tunneling because the lifetime it sent expires and was not renewed, or the aAR or current AR decide to terminate tunnel service for some other reason. 2) The MN completes the process of obtaining an nCoA through nAR. 3) The MN moves to a third AR. Sections 2.4 and 2.5 discuss Cases 1 and 2 in more detail, Case 3 is discussed in Section 2.3. Figures 3 and 4 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two party handover, respectively. MN nAR oAR | | | | | |<~~~ L2-ST | |<------------------| | | HRqst(s) | | | | | |------------------>| | | HRply(s) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 3 - Two Party Source Trigger Handover Timing [Page 11] Bi-directional Edge Tunnel Handover September 2001 For IPv6 MN nAR oAR | | | | L2-TT ~~~>| | | |------------------>| | | HRqst(t) | | | | | |<------------------| | | HRply(t) | | | | --------------------------------------------<~~~ L2-LD L2 Handover --------------------------------------------<~~~ L2-LU | | | | | | | | | | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 4 - Two Party Target Trigger Handover Timing 2.3. Three Party Handover Three party handover occurs when the MN is on aAR, then moves to oAR, then moves to nAR before completing MIP registration at oAR. The lack of MIP registration may result from either a specific decision by the MN due to an ongoing real time media stream, or it may result from rapid movement between oAR and nAR that does not allow enough time for the registration to complete. This situation is shown in Figure 5 below. In this case, oAR must inform nAR to contact aAR about moving the radio directed end of the tunnel. This is performed with the Handover To Third (HTT) message. [Page 12] Bi-directional Edge Tunnel Handover September 2001 For IPv6 +------+ +--->| aAR |<---+ | +------+ | 4b) HRqst(r) | | 3) HRqst(t) HRply(r) | | HRply(t) | | v 2a) HRqst v 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU ^ HRply ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 5b) L2-LU ~~~> | MN | ---------> +------+ Figure 5 - Three Party Handover The general idea behind the three party handover procedure is that the oAR supplies nAR with the same information it would have obtained via an L2-TT if handover had occurred with aAR, then the nAR performs an HRqst(t)/HRply(t) sequence with aAR in order to move the BET to nAR. When the L2 handover is complete, oAR sends an HRqst(r) to aAR to terminate the BET. The following describes the progress of a three party handover. The numbered items refer to steps in Figure 5. 1) Either the oAR or nAR receives an L2 trigger informing it that a certain MN is about to be moved. The two cases are: a) The L2 trigger is a source trigger (L2-ST) at oAR. The trigger contains the MN's L2 address and an IP identifier (L2 address that can be mapped to an IP address or the IP address directly) for nAR. b) The L2 trigger is a target trigger (L2-TT) at nAR. The trigger contains the MN's L2 address and an IP identifier for oAR. 2) The oAR and nAR exchange a HTT/HRply or HRqst/HTT pair. There are two cases: a) The L2 trigger is an L2-ST. The oAR sends HTT to nAR containing the IP address of aAR and two LLAs. The first LLA contains the L2 address of the MN, the second contains [Page 13] Bi-directional Edge Tunnel Handover September 2001 For IPv6 the L2 address of the aAR. This is enough information for nAR to perform a target trigger handover with aAR. The nAR responds with a HRply(s). b) The L2 trigger is an L2-TT. The nAR sends HRqst(t) to oAR, exactly as if a two party handover were occurring. The oAR responds with HTT containing the IP address of aAR and two LLAs. The first LLA contains the L2 address of the MN, the second contains the L2 address of the aAR. This is enough information for nAR to perform a target trigger handover with aAR. 3) The nAR first checks its routing tables to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nAR performs a target trigger handover with aAR, exactly as in Section 2.2, exchanging a HRqst(t)/HRply(t) pair. Because aAR receives no L2 trigger indicating when to start handover, it may place the BET to nAR upon transmission of the HRply(t), or alternatively it may wait to establish the BET with nAR until oAR signals that L2 handover has begun in Step 4. 4) At the start of L2 handover, aAR and oAR exchange messages canceling tunnel service between aAR and oAR and allowing aAR to start the tunnel with nAR. a) The start of L2 handover is signaled at oAR by L2-LD. b) The oAR exchanges a HRqst(r)/HRply(r) pair with aAR with lifetime zero. This cancels tunnel service between oAR and aAR. If aAR has not already placed a BET to nAR, it must do so immediately upon receipt of the HRqst(r). 5) Completion of L2 handover is signaled by an L2-LU trigger at nAR and MN. The nAR and MN handle the trigger in the following ways: a) The nAR begins delivering packets to the MN, and tunnels any CN-bound packets from the MN to aFA. b) Based on its current movement and traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA as described in [3] or [4]. 6) In the special case where nAR and aAR are the same, aAR recognizes that it is tunneling to oAR when it checks its routing tables in Step 3. In this case, there is no need for aAR to send the HRqst(t)/HRply(t) with itself in Step 3. Upon receipt of the L2-LU trigger on handover completion, the aAR begins routing packets to MN and the tunnel to nAR is torn down. The AR still exchanges the HRqst(r)/HRply(r) with oAR in Step 4b because oAR can't know a priori that aAR and nAR are [Page 14] Bi-directional Edge Tunnel Handover September 2001 For IPv6 the same, but aAR need not gate old tunnel tear down or delivery of mobile node packets on this exchange. Unlike two party handover, the timing of BET establishment between aAR and nAR cannot fully depend on the availability of L2 trigger information because aAR does not receive an L2 trigger when L2 handover begins. The two timing extremes at which aAR can place the BET with nAR are: 1) At the earliest, aAR can establish the BET with oAR after sending the HRply(t) to nAR in response to the request for target-triggered handover, 2) At the latest, aAR can establish the BET with nAR and tear down the BET with oAR when receiving the HRqst(r) from oAR indicating the L2 handover has begun. In addition, aAR has the option of continuing tunnel service with oAR if 1) is selected, until the HRqst(r) is received. If 1) is selected and the aAR continues to tunnel to oAR, the result may be duplicated packets at the MN, because the MN will receive packets through oAR on the old L2 until L2 handover begins. If 2) is selected, the additional latency of the HRqst(r) added to the L2 handover latency may result in additional packets being dropped while the MN is not receiving L3 networking service. Of course, aAR can choose to place the BET some time between 1) and 2) if the the network to give reasonable bounds. The exact selection of when to establish the BET is likely to be influenced by network engineering and implementation considerations, including whether a handover smoothing solution is deployed, and is beyond the scope of this specification. Figures 6 and 7 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handover, respectively. [Page 15] Bi-directional Edge Tunnel Handover September 2001 For IPv6 MN nAR oAR aAR | | | | | | L2-ST ~~~~~> | | | | | | | |<-------------| | | | HTT | | | | | | | |------------->| | | | HRply(s) | | | | | | | | | | | |------------------------------>| | | HRqst(t) | | | | | | | |<------------------------------| | | HRply(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HRqst(r) | | | |<---------------| | HRply(r) | | | ----------------------------------<~~~ L2-LU | | | | | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | | | | | Figure 6 - Three Party Source Trigger Handover Timing [Page 16] Bi-directional Edge Tunnel Handover September 2001 For IPv6 MN nAR oAR aAR | | | | | |<~~~ L2-TT | | | | | | | |------------->| | | | HRqst(t) | | | | | | | |<-------------| | | | HTT | | | | | | | | | | | |------------------------------>| | | HRqst(t) | | | | | | | |<------------------------------| | | HRply(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handover | HRqst(r) | | | |<---------------| | HRply(r) | | | ----------------------------------<~~~ L2-LU | | | | | | | | | |<-------------->| | | | MN's traffic | | | | on aCoA | | | | | | | Figure 7 - Three Party Target Trigger Handover Timing [Page 17] Bi-directional Edge Tunnel Handover September 2001 For IPv6 2.4. Renewal or Termination of Tunneling Service Prior to the lifetime of a BET expiring, the MN's current AR must signal the aAR to either renew or terminate the BET. If no such signal is received, the aAR will terminate the BET when the lifetime expires, cutting off the MN's traffic potentially prematurely. In addition, aAR MAY terminate the BET prior to the lifetime expiring, perhaps to shed load or for some other reason. In order to avoid error conditions in which tunnels do not expire even though the MN to which they apply has for some reason disappeared, ARs SHOULD set the tunnel lifetime to some value other that 0xffff, which indicates "good until cancelled". Figure 8 illustrates the message exchange that occurs between the AR needing to terminate or extend the tunnel (designated AR(1) in the figure) and the other AR (designated AR(2) in the figure). Immediate termination occurs when the HRqst(r) contains a zero lifetime. Eventual termination occurs when the HRqst(r) originates with aAR unsolicited and has a lifetime that is shorter than the remaining lifetime known to the MN's current AR. The lifetime value in the HRqst(r) gives the number of seconds until the tunnel will be terminated. Extension occurs when the HRqst(r) originates with the MN's current AR and it contains a nonzero lifetime. The aAR has veto power over a request from the current AR to extend the lifetime of the tunnel. HRqst(r) +------+ <-------- +------+ | AR(2)| ---------> | AR(1)| +------+ HRply(r) +------+ Figure 8 - BET Renewal or Termination Note that, if the current AR or aAR need to terminate the tunnel for some reason (shedding load, going down, etc.) and they have not received definitive notification that the MN has a nCoA, they SHOULD send out a tunnel extension indication (if necessary) or an eventual termination indication, respectively, with enough time left for the process of nCoA establishment to be completed, if that can be determined. The current AR SHOULD then send a RtAdv to the MN, informing the MN that it MUST start the process of nCoA establishment. The current AR and aAR SHOULD NOT send out an immediate termination request unless definitive evidence is available that the MN has a nCoA. The current AR SHOULD NOT send an immediate termination indication unless definitive evidence (L2 trigger, BU, etc.) is available that the MN is no longer reachable on the current AR's link. 2.5. When and How to Obtain a nCoA [Page 18] Bi-directional Edge Tunnel Handover September 2001 For IPv6 There are three possible events that can lead to the need to terminate tunneling service to the MN and therefore require the MN to obtain a nCoA. These three are: 1) The end of life for the BET is pending and a request by the current AR to aAR for renewal has been denied, or, alternatively, the current AR or aAR must terminate the BET prematurely for some other reason (load shedding, etc.). 2) The MN decides, based on its movement and traffic patterns, to establish a nCoA. 3) During a source triggered handover, the oAR attempts to perform BET handover but nAR is not capable of performing it. Note that this situation will never arise during target triggered handover because an HRqst(t) will not be sent to oAR. The nAR will always request a standard FMIPv6 handover, or, if the nAR does not support FMIPv6, the nAR will send a RtAdv to the MN. Each of these is considered in the following subsections. 2.5.1. BET End of Life or Premature BET Termination BET end of life and premature BET termination are both cases where the BET is terminated by the network due to some event unrelated to the MN. There are three possible subcases: 1) BET end of life is pending and aAR has refused a request to extend the life time, 2) The current AR has received a notification from aAR that the BET will terminate prematurely, 3) The current AR must terminate the BET prematurely itself. When it learns of a pending BET termination, the current AR MUST inform the MN enough in advance of the actual termination that the MN can obtain a nCoA without disruption in service. Similarly, if the aAR must prematurely terminate the BET, it SHOULD send an eventual termination notice with enough time remaining so that the MN has an opportunity to establish a nCoA. The aAR SHOULD NOT send an immediate termination notice unless it has been informed by the MN that the MN already has a nCoA. The current AR MUST initiate the process of nCoA establishment by either of the methods described in [3] and [4], that is, by either sending a RtAdv or sending a PrxyRtAdv (even though the AR is sending its own address in this case and is not really proxying). If the current AR MUST also terminate the radio link to the MN for some [Page 19] Bi-directional Edge Tunnel Handover September 2001 For IPv6 reason, it MUST begin the process of FMIPv6 handover to a different AR capable of handling the MN's traffic if possible. In the case where the network terminates the BET, there is no requirement for signaling from the MN to cause tunnel tear-down. 2.5.2. MN Decision to Obtain a nCoA If real time traffic ceases or the MN stops moving quickly, the MN MAY decide that the radio channel is free enough to obtain a nCoA. Although there is no L3 signaling to indicate that the MN has moved ARs, the L2-LD and L2-LU triggers provide that indication, along with the L2 address of the nAR. By comparing the nAR L2 address delivered through the L2 trigger with the L2 address of its oAR, the MN can determine if obtaining a nCoA is necessary. In any event, the MN MUST always keep track of the aAR L2 address where it originally got its aCoA, and SHOULD keep track of the aAR IP address so it can inform the aAR of a change in CoA through a BU. The MN begins the process of establishing a nCoA through the mechanisms outlined in [3] or [4]. If the MN uses the FMIPv6 procedure, it sends a RtSolPr to the current AR (even though, again, the current AR is not proxying). Alternatively, the MN may use the Johnson and Perkins algorithm by sending a RtSol to the current AR. In either case, the MN continues the process of obtaining a nCoA, stateless or stateful address autoconfiguration, sending BUs to the HA and any remaining CNs, etc. When sending BUs to the HA and any CNs, the MN SHOULD set the 'A' (Acknowledge) bit so that it is informed through a BAck from nodes with which it currently does not have an active session when the binding update is complete. The MN MUST also establish a security association with the current AR, sufficient to allow the current AR (which now becomes the aAR) to receive and authenticate a BU from the MN. The exact mechanism for establishing such a security association is currently under discussion in the working group and is beyond the scope of this document. When the MN has completed obtaining a nCoA, it SHOULD wait until it has received the last BAck from the nodes to which it has sent a BU before sending a binding update to the aAR. The BAck will typically arrive as a destination option in the first packet from a CN sent to the nCoA, thereafter, the MN and CN will use the nCoA for communication and no more packets will be sent to the oCoA. At this point, it is safe for oAR and nAR to tear down the tunnel, and the MN can proceed to send the BU, suitably authenticated, to the oCoA. If for some reason, the MN must terminate the radio link, it SHOULD either establish a nCoA on the link prior to terminating it, or, alternatively, cancel the binding at the aAR so the tunnel will be torn down. An example of such a case is if the MN enters dormant [Page 20] Bi-directional Edge Tunnel Handover September 2001 For IPv6 mode. This assures that no tunnel state lingers on the ARs after the MN has disappeared. 2.5.3. Failure of BET Handover It is possible that an AR can attempt to perform source triggered BET handover with a nAR and that handover fails because the nAR does not support BETH. In general, in order for seamless high performance handover to be possible, ARs must be able to discover the identities and capabilities of handover candidate ARs by some means (see [9] for a discussion of issues in candidate AR discovery). This should allow a BETH-capable router to discover whether a candidate AR can support BETH. If the candidate cannot support BETH, then the current AR should initiate FMIPv6 handover if the candidate supports it, or, if the candidate AR does not support FMIPv6, simply allow the MN to do movement detection according to the original Johnson and Perkins algorithm. Failure of an attempt to perform BETH with an AR should be viewed as a network engineering misconfiguration, and steps should be taken by the network administrator to correct the configuration. It may be possible for an oAR to recover from a failed attempt at BETH handover, if the nAR supports FMIPv6, using the following procedure. If the candidate nAR interprets the HI from a BETH capable router as a standard FMIPv6 HI, it will return a standard FMIPv6 HACK to the oAR. The oAR then sends a PrxyRtAdv to the MN to initiate standard FMIPv6 handover. The worst possible consequence is that the oAR loses the time during the HI/HACK exchange that would otherwise not have occurred if the PrxyRtAdv were sent prior to the HI/HACK exchange. This procedure should be viewed as a stopgap only, the real solution is to correct the network misconfiguration so that the ARs can discover the capabilities of handover candidate ARs and perform the appropriate type of handover with them. When handover to a non-BETH capable router is necessary, the oAR terminates the tunnel to the aAR when L2 handover starts by sending an HRqst(r) to aAR with lifetime zero. If detailed handover sequencing information is not available from L2, oAR and aAR can use any other means at their disposal(e.g. BU to aAR or oAR from MN, etc.) to determine when to terminate the BET. In the absence of any other information, oAR can simply allow the BET to time out, though this is discouraged on efficiency grounds. 2.6. Message Descriptions This section contains message descriptions for the HRqst, HRply, and HTT messages. 2.6.1. Handover Request (HRqst) The HRqst message is an extension of the HI message from [3]. It is sent by the recipient of an L2-ST or L2-TT trigger, or by an AR when [Page 21] Bi-directional Edge Tunnel Handover September 2001 For IPv6 it wants to cancel or extend tunneling service. The following diagram shows the modified HI: [Page 22] Bi-directional Edge Tunnel Handover September 2001 For IPv6 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier |S|U|H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The fields have the same meaning as in [3] with the following exceptions: IP Fields: Source Address If H bit is set, the IP address of the AR receiving the L2-ST. If T bit is set, the IP address of the AR receiving the L2-TT. If the R bit is set, the IP address of the AR wishing to extend or cancel tunnel service. Destination Address If the H or T bits are set, the IP address of the AR whose L2 address is contained in the L2 trigger. If the R bit is set, the IP address of the AR extending tunnel service. ICPM Fields: S,U Unset if the H, T, or R bit are set. H Set if the message was triggered by an L2-ST in a two party handover. All other bits are unset. T Set if the message was triggered by an L2-TT. All other bits are unset. R Set if a request to extend or cancel tunnel service. All other bits are unset. Valid Options The message MUST contain the following options in the indicated order if the specified bits are set: Lifetime Option Present if the H, T, or R bits are set. The lifetime, in seconds, for which the requestor would like tunnel service extended. If the field is zero, the request is to cancel tunnel service. If the field is 0xffffffff, the request is for infinity. The lifetime option is described in Section 2.6.4. [Page 23] Bi-directional Edge Tunnel Handover September 2001 For IPv6 IP Address Option containing MN's old Care of Address Present if the H or R bits are set, described in [3]. LLA Option containing the MN's L2 address. Present if the H, T, or R bits are set, described in [3]. 2.6.2. Handover Reply (HRply) The HRply message is an extention of the HACK message from [3]. It is sent by either oAR or nAR in response to an HRqst. The following diagram shows how the HACK is modified: 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++-+-+-+-+-+-+-+-+-+ | Identifier |H|T|R| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The fields have the same meaning as in [3] with the following exceptions: IP Fields: Source Address If T bit is set, the address of oAR or aAR. If H bit is set, the IP address of nAR. If the R bit is set, the IP address of the AR extending tunnel service. Destination Address If the T bit is set, the IP address of nAR. If the H bit is set, the IP address of oAR. If the R bit is set, the IP address of the AR that requested extending or canceling tunnel service. ICPM Fields: S,U Unset if the H, T, or R bit are set. H Set if in response to HRqst(s) in a two party handover. All other bits are unset. T Set if in response to an HRqst(t) in a two party handover, or when sent by aAR in a three party handover. All other bits are unset. [Page 24] Bi-directional Edge Tunnel Handover September 2001 For IPv6 R Set if in response to a HRqst(r). All other bits are unset. Valid Options: The message MUST contain the following options in the indicated order if the specified bits are set: Lifetime Option Present if the H, T, or R bits are set. The lifetime, in seconds, for which the sender is willing to grant tunnel service. If the field is zero, the request for tunnel service is denied. If the field is 0xffffffff, the tunnel service is guaranteed until cancelled. The lifetime option is described in Section 2.6.4. IP Address Option containing MN's old Care of Address Present if the T or R Bit is set, described in [3]. 2.6.3. Handover To Third (HTT) The HTT message is an extension of both HI and HACK. If it is triggered by an L2-ST, then it is an extension of HI. If it is sent in response to an HRqst(t), then it is an extension of the HACK. The message can be distinguished as an HTT because it has both the H and T bits set regardless of whether it is received as a request or sent as a reply. No other bits are sent in HTT. In addition, the HTT MUST contain the following options in the specified order: Valid Options: IP Address Option containing aAR's Address The IP address of the aAR handling the network end of the BET, described in [3]. LLA Option containing the L2 address of the MN, described in [3]. LLA Option containing the L2 address of aAR, described in [3]. 2.6.4. Lifetime Option The following defines the Lifetime option: [Page 25] Bi-directional Edge Tunnel Handover September 2001 For IPv6 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 | Subtype | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: 8 Subtype: TBD Reserved: Must be set to zero. Lifetime: Four octet positive integer giving the lifetime of the BET, in seconds. 3. BETH Applicability Statement BETH is designed for high performance, extremely low latency handover in which the primary concern is quickly switching a MN's traffic from one AR to another with an absolute minimum delay. Any radio signaling on a traffic channel at L3 will tend to compromise this goal, so MN involvement in handover is confined to L2 only, where radio traffic between the MN and radio access points is unavoidable. Consequently, BETH is primarily of interest in handover between ARs that support the same radio access technology. Handover between heterogeneous radio technologies will, of necessity, require interaction between the MN and the network, and so is not a domain of applicability for BETH. 4. Security Considerations There are two areas of possible security concern: the MN to AR connection, and the AR to AR connection. 4.1. MN to AR Connection The intent of the protocol is to eliminate any L3 signaling traffic related to subnet movement in order to eliminate any latency in starting up real time traffic on nAR. This includes any traffic related to authentication. As a consequence, the L2 protocol MUST support some means for an MN to authenticate the radio access point with which it is connecting during an L2 handover, and for the radio access point to authenticate the MN. Furthermore, any authentication or security information involved in providing the MN with L3 service MUST be available to the nAR so that [Page 26] Bi-directional Edge Tunnel Handover September 2001 For IPv6 nAR can determine whether the MN is authorized for such service. The exact mechanism by which this information is made available to the nAR is outside the scope of this document. 4.2. AR to AR Connection Handover involves changing routing for a particular MN, and any compromise of security in the AR to AR connection could result in the MN's traffic being diverted or cut off. As a consequence, a security association MUST exist between ARs, and the HRqst, HRply, and HTT messages MUST contain an IPSEC AH header [8]. In the event the handover messages are routed over a public data network, such as might occur during a handover between two different administrative domains, the messages SHOULD also be encrypted. 5. Acknowledgements This work resulted directly from the urging of Phil Neumiller, of Mesh Networks, to "try something different" for Mobile IP handover. Without Phil's persistence and patient attempts to explain when questions came up, it never would have happened. The authors would also like to thank "the other Phil," Phil Roberts, for a few suggestions that helped to focus the draft. 6. References 1 Holma, H. and Toskala, A., "WCDMA for UMTS," John Wiley and Sons, Chichester, 2000. 2 Kempf, J., et. al., "Requirements for Layer 2 Protocols to Support Optimized Handover for IP Mobility," draft-manyfolks-l2-mobilereq-00.txt, a work in progress. 3 Tsirtsis, G., "Fast Handovers for Mobile IPv6," draft-ietf-mobileip-fast-mipv6-01.txt, a work in progress. 4 Johnson, D., and Perkins, C., "Mobility Support in IPv6," draft-ietf-mobileip-ipv6-13.txt, a work in progress. 5 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6 El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4," draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, a work in progress. 7 Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6 Specification," RFC 2473, December, 1998. 8 Kent, S., and Atkinson, R., "IP Authentication Header," RFC 2402, November 1998. [Page 27] Bi-directional Edge Tunnel Handover September 2001 For IPv6 9 Trossen, et. al., "Issues in Candidate Access Router Discovery for Seamless IP Handoffs," draft-ietf-seamoby-CARdiscovery- issues-00.txt, a work in progress. 7. Authors' Addresses James Kempf Sun Microsystems 901 San Antonio Rd., UMTV29-235 Phone: +1 650 336 1684 Palo Alto, CA Fax: +1 650 691 0893 94043 Email: james.kempf@sun.com USA Pat Calhoun Black Storm Networks 250 Cambridge Ave. Phone: +1 650 617 2932 Palo Alto, CA Fax: +1 720 293 7501 94306 Email: pcalhoun@bstormnetworks.com USA Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA Email: gdommety@cisco.com 95134 USA Sebastian Thalanany Motorola 1475 West Shure Drive Phone: +1 847 435 9296 Arlington Heights, IL Email: sthalan1@email.mot.com 60004 USA Ajoy Singh Motorola 1501 West Shure Drive Phone: +1 847 632 6941 Arlington Heights, IL Email: asingh1@email.mot.com 60004 USA Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Phone: +1 630 713 9359 Naperville, IL 60566-7050 Fax: +1 630 713 4982 USA E-Mail: mccap@lucent.com Tom Hiller Lucent Technologies [Page 28] Bi-directional Edge Tunnel Handover September 2001 For IPv6 Rm 2F-218 263 Shuman Blvd Phone: +1 630 979 7673 Naperville, IL 60566-7050 Fax: +1 630 979 7673 USA E-Mail: tom.hiller@lucent.com