Informational James Kempf Internet Draft Pat Calhoun Document: draft-kempf-beth-ipv6-00.txt Sun Microsystems Expires: December 2001 Gopal Dommety June 2001 Cisco Systems Sebastian Thalanany Ajoy Singh Motorola Peter J. McCann Tom Hiller Lucent Technologies 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, the Mobile Node can use the Fast Mobile IPv6 handover protocol or the original Mobile IPv6 handover protocol to establish a Care of Address. An added benefit of the protocol is that header compression context for real time traffic can be transferred from the old Access Router to the new and reused unchanged, since the headers associated with the traffic to and from the MN over the air do not change. The design stems from a different series of tradeoffs than those that motivated the Fast Mobile IPv6 protocol. Bi-directional Edge Tunnel Handover June 2001 For IPv6 Table of Contents 1.0 Introduction ..................................................2 1.1. Terminology ..................................................4 1.2. Standards Language ...........................................6 2.0 Comparison with the Original FMIPv6 ...........................7 3.0 BETH Protocol ................................................10 3.1. L2 Requirements .............................................10 3.2. Two Party Handover ..........................................13 3.3. Three Party Handover ........................................17 3.4. BET Renewal/Termination .....................................22 3.5. Handover Smoothing ..........................................22 3.6. Message Descriptions ........................................24 3.6.1 Handover Request (HRqst) ...................................24 3.6.2 Handover Reply (HRply) .....................................25 3.6.3 Handover To Third (HTT) ....................................26 3.6.4 Lifetime Option ............................................27 4.0 Security Considerations ......................................27 4.1. MN to AR Connection .........................................27 4.2. AR to AR Connection .........................................27 5.0 Acknowledgements .............................................28 6.0 References ...................................................28 7.0 Authors' Addresses ...........................................29 Appendix A. Latency Estimates for Fast MIPv6 Handover Prototol ...30 A.1 Bandwidth of Radio Connection.................................30 A.2 Actual Message Sequences......................................31 A.3 Other Assumptions.............................................32 A.4 Calculated Message Exchanges..................................32 A.5 L3 Handover Latency...........................................33 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 valid 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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 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 compromise the ITU-recommended delay of 300 ms, beyond which users start to perceive gaps and other artifacts in voice traffic [2]. If IP is ever to become a viable substrate for 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 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 this document, an extension of the FMIPv6 protocol is described. The extension reduces handover latency at L3 to zero. 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. 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. An added benefit of the approach is that it allows the direct use of header compression state from the anchor AR without any change or modification. Existing header compression algorithms for radio links have been developed with the assumption that the header compression engine can handle a limited amount of change in header content due to handover [5]. If the MN continues to use its old CoA, the header on the radio link remains unchanged, and so the compression engine state can be reused, if transferred between ARs using context transfer. Since the compression algorithms typically require between 1 and 3 round trips before full compression is reestablished, being Bi-directional Edge Tunnel Handover June 2001 For IPv6 able to completely reuse the compressor state can reduce the number of header bytes on initial traffic by 99%. The design tradeoffs motivating BETH are somewhat different from those that originally motivated FMIPv6, and these are compared in Section 2. Section 2 also briefly discusses evidence that the latency reduction afforded by FMIPv6 may not be adequate for slow radio links. More details on this can be found in Appendix A. In Section 3, the details of the protocol are presented. The responsibilities of the ARs when a MN changes AR are outlined. Of particular interest is the case where a MN is already using an old CoA and it performs a handover to another new AR. The protocol depends on L2 triggers (see [7]) to inform the AR about the occurrence of a handover and context transfer (see [8]) to move any header compression or other state to the new AR. The protocol completely eliminates any MIP-related signaling over the air. Any remaining latency is due to L2 handover and L3 latency involved in signaling over the wired backbone. Section 4 discusses security considerations. Handover signaling and context transfer must be performed securely; otherwise, routing of the MN's traffic could be disrupted. It should be noted that BETH is applicable primarily to radio protocols with mean data rates that are slow (between 1 and 3 orders of magnitude less) compared to the wired network protocols with which they connect, and which have the capability to handle MNs that are moving rapidly (at vehicular speeds). Protocols used in 3G cellular telephony fall into this category. In a cellular environment the radio links that connect the MN to a wired network may undergo a rapid change in their integrity as a result of radio signal fading, resulting in frequent changes or a loss, of a connection to an access router. Wireless LAN (WLAN) protocols, on the other hand, tend to offer much better aggregate performance, and generally are designed to handle movement at walking speeds. In a WLAN network with slow moving MNs in small cells (and hence few MNs per cell), FMIPv6 or the original Johnson and Perkins algorithm [4] may provide adequate handover performance. 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. Bi-directional Edge Tunnel Handover June 2001 For IPv6 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. 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. 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. 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. bi-casting - The splitting of a stream of packets destined for a MN via its current AR (the oAR) into two streams, and the simultaneous transmission of the streams on the old L2 and to nAR. Bi-casting is a smoothing technique used in conjunction with L2 buffering to reduce packet loss during handover. 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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 of the old CoA without running the risk of ingress or egress filtering. bi-directional edge tunnel with bicasting (BETB) - A BET in with the old AR additionally bicasts packets for the MN onto the old L2 link until the old L2 link is dissolved, or, optionally, until the probability of a ping-pong is minimal. bi-directional edge tunnel handover (BETH) - Handover that involves moving the radio interface end of the BET from oAR to nAR, while keeping aAR unchanged. 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. L2 trigger - Information from L2 that informs L3 of particular events before the initiation of an L2 handover and events before the completion of an L2 handover. 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 [7] 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 [28]. Bi-directional Edge Tunnel Handover June 2001 For IPv6 2. Comparison with the Original FMIPv6 The original Johnson and Perkins handover mechanism in [4] is based on movement detection using IPv6 neighbor discovery [13], although [4] also sanctions the use of optimization mechanisms. Since IPv6 neighbor discovery was really not designed with high speed wireless handover in mind, additional work has gone into defining an optimization mechanism for wireless handover. The result is FMIPv6, described in [3]. Although not explicitly stated in the draft, there are a few underlying principles behind FMIPv6 that have heavily influenced the design. They are: - The MN must have complete control to micromanage the handover process. In particular, the MN must be allowed to veto or change the AR to which it will connect prior to the handover, and any tunneled traffic from oAR after handover must go directly to the MN if the nCoA is valid. Tunneled traffic to nAR is viewed as a corner case, only if the MN can't validate its nCoA prior to moving to nAR. - The MN must have absolutely no control about whether it performs a CoA change or not. If the MN moves to a new subnet, it *must* obtain a new CoA, regardless of how long the MN stays on that subnet. These principles derive from maintaining fidelity with the original principles in Johnson and Perkins [4]. Consistent with these design principles, the FMIPv6 goal is to reduce handover latency by reducing the latency involved in the unavoidable establishment of a nCoA. The design of FMIPv6 optimizes nCoA establishment by allowing the MN to start the process of obtaining a nCoA prior to moving to nAR, in response to an L2 trigger or other signal that L2 handover is about to happen. Because the radio environment and L2 timing during handover are uncertain, however, the process of establishing a nCoA may or may not complete prior to L2 handover. The FMIPv6 protocol is designed to accommodate this uncertainty, at the expense of a certain amount of complexity. The sequence of messages required to establish a nCoA is fixed, whether or not they occur through oAR or nAR. FMIPv6 also provides for continuation of tunneled traffic from oAR when the process of nCoA establishment does not complete prior to L2 handover. While FMIPv6 considerably reduces the amount of messaging over the air and the corresponding latency, it still requires enough L3 messaging that its ability to handle real time traffic without artifacts is in doubt. Appendix A gives some calculated L3 latencies for FMIPv6 message flows. If MIP signaling is done on a traffic channel as is typically the case with 3G radio protocols, the calculations indicate that reduction in latency would require switching to higher data rates during handover. This may be Bi-directional Edge Tunnel Handover June 2001 For IPv6 difficult to achieve given the stochastic nature of radio links, and additionally some 3G radio protocols do not allow dynamic data rate selection. Alternatively, the radio protocol could be changed to do MIP-related signaling in parallel to real-time traffic on a dedicated signaling channel. The message flows are theoretical, but optimistic in that they measure the minimum number of messages required on the radio link at L3 before the MN could start receiving and sending real time packets after a successful L2 handover. The flows do not assume that the MN must use its nCoA. In fact, for most of the sequences, the process of establishing the nCoA does not complete prior to L2 handover. The calculated times neglect the latency due to L2 handover, as well as the latency due to the need to inform the HA and any CNs of the handover (or a hierarchical agent if one of the hierarchical signaling localization schemes are used [9] [10]). In realistic handover situations, because of the stochastic nature of radio links, retransmissions due to lost signaling packets could substantially increase the calculated times in Apppendix A. The underlying principles behind BETH are somewhat different. They are: - The MN gives up the ability to micromanage at the time of handover, in return for reducing MIP-related radio link signaling and the associated latency to zero. - The MN gains the ability to control when it performs CoA change, so that it can time the establishment of a nCoA appropriately with respect to its real time traffic flows. These are rather the opposite of the principles on which the original FMIPv6 was based. By giving up the ability to micromanage handover and gaining the ability to establish a nCoA when it wants, the mobile node gains the following advantages: - The movement of the mobile node at vehicular speeds across the edge network becomes possible. The existing FMIPv6 protocol has no provision for the case where the MN moves rapidly to a third access router prior to the completion of nCoA establishment at nAR, as could happen at a tight, three cell corner junction. - The probability that user-perceptible artifacts will occur in real time traffic is reduced considerably, and is completely independent of any MIP-related signaling on the radio link. The only remaining latency is that involved in signaling across the wired edge network, which is orders of magnitude faster than the radio link, and the unavoidable latency involved in the unavailability of L3 service while L2 is involved in re- establishing link connectivity during a handover. Bi-directional Edge Tunnel Handover June 2001 For IPv6 - The start of real time traffic on nAR is not delayed by the need to re-establish header compression state, and the load across the air link is not increased by tunnel headers if the nCoA is not established prior to handover. Context transfer of the compressor state from oAR allows the compression to rapidly restart without any radio link traffic. The radio link end of the BET terminates on nAR, removing any over the air tunnel overhead related to handover. - The removal of signaling messages from the critical path can enhance the capacity of networks that practice fine-grained power control, for example, 3G cellular networks. If Mobile IP messages are exchanged over an actively power controlled channel, as is typically the case, deteriorating link condition during handover can require extra power in order to overcome the poor radio reception. This can lead to interference with other MNs in the cell. Poor radio conditions during handover may also cause the Mobile IP messages to be dropped, causing additional service disruptions and the need for retransmits at L3. Problems with power are not escaped by transmitting the Mobile IP messages over a dedicated signaling channel, as has been proposed to increase the parallelism of handover, since poor radio conditions during handover would require the signaling channel power to be boosted, thus again increasing the potential for interference. Mobile IP messages over the common signaling channel should be avoided, since they are transmitted at full power. The design principles result from practical consideration of the relationship between an IP host and its default router in existing wired and wireless networks. In existing wired edge networks, the router to which an IP host connects is completely immaterial to the host. The host is typically assigned a Network Access Server (NAS) by dial-in, or a default router by DHCP. Similarly, in existing commercial radio access networks, the radio access points used by a MN is determined by the contract that the user has with the service provider. Consequently, the ability to micromanage handover buys the MN very little in existing networks. One argument for maintaining MN micromanagement of handover is that in the future the MN may want to select an access point based on cost or other considerations. This application could easily be accommodated in BETH by having the MN negotiate preferences for particular kinds of access points during initial admission to the network either dynamically or through static configuration. These preferences then follow the MN through context transfer, and are used by an oAR to determine which nAR to hand the MN over to, given a choice is available. On the MN side, if the MN has dual radio interfaces on different radio technologies (a cellular WAN interface and a PAN or WLAN interface, for example), the MN could process signaling from a second radio interface in parallel and decide to shift to a second interface if a preferred access point is detected Bi-directional Edge Tunnel Handover June 2001 For IPv6 on the new interface. When a preferred access point is detected, the MN would initiate an FMIPv6 handover to the new interface. 3. BETH Protocol Figure 1 illustrates the basic idea behind BETH. +------+ | 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. The MN is in the best position to know when it can afford to pay the latency cost of CoA establishment. 3.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 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. The L2 triggers involved in BETH are similar to those described in [7]. As in [7], the L2 triggers are an abstraction of how many L2 wireless protocols work. They abstract when a trigger can be expected and what information it delivers to a recipient. Bi-directional Edge Tunnel Handover June 2001 For IPv6 Table 1 describes the L2 triggers, when they occur, and what information must be transferred from L2. Bi-directional Edge Tunnel Handover June 2001 For IPv6 L2 Trigger When? Recipient Parameters ---------- ------ --------- ---------- Source Trigger Sufficiently (L2-ST) before L2 handover nAR IP initiation for oAR identifier oAR and nAR; or oAR, nAR; and MN L2 address aAR to exchange HRqst/HRply. Target Trigger Sufficiently (L2-TT) before L2 handover oAR IP completion for nAR identifier oAR and nAR; or oAR, nAR, and MN L2 address aAR; to exchange HRqst/HRply. L2 Handover When L2 handover Start begins oAR or nAR MN L2 address (L2-HS) Mobile Handover When radio Complete conditions are (L2-MHC) OK on nAR for the MN to begin MN nAR L2 address sending L3 traffic. Network When radio Handover conditions on Complete nAR are OK for (L2-NHC) nAR to start forwarding oAR, nAR MN L2 address packets to MN, and for oAR to stop forwarding over the old L2 link. Table 1 - L2 Triggers The protocol also requires that L2 handover be secure. This requirement is similar to that for POST-REGISTRATION handover in [7], and is discussed in more detail in Section 4. L2 buffering support is optionally needed for handover smoothing. Handover smoothing is discussed in Section 3.4. Bi-directional Edge Tunnel Handover June 2001 For IPv6 3.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 [7], and is shown in Figure 2. Message descriptions are given in Section 3.6. 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-NHC ~~~> +------+ 3) HRply +------+ <~~~ 4b) L2-NHC ^ ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c) L2-MHC ---> | MN | ---------> +------+ Figure 2 - Two Party Handover The following describes the progress of a two party handover. 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 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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 lifetime is zero, the oAR is not willing to tunnel any packets for MN. The HRqst(s) should also include extensions containing authentication information and header compression context for the MN [8]. 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. The HRply(t) should also include extensions containing authentication information and header compression context for the MN [8]. 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. 4) Completion of L2 handover is signaled by an L2 trigger at oAR, nAR, and MN. Each handles the trigger in the following way: a) The oAR can terminate bi-casting, or, optionally, continue bi-casting until the probability of a ping-pong event is low. b) The nAR begins delivering packets to the MN, including any packets that were buffered during L2 handover. c) Based on its current traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA as described in [3] or [4]. d) 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. Bi-directional Edge Tunnel Handover June 2001 For IPv6 The actual timing of BET placement depends on the available L2 triggers, which is why it is not discussed in the above description of handover. The BET is placed between oAR and nAR using the IPv6 tunneling procedure described in [15]. With optimal L2 trigger information, the BET and bi-casting can be arranged for optimal handover smoothing, as discussed in Section 3.5. In the absence of optimal L2 trigger information, the HRply acts as the trigger for BET placement and bi-casting start, and the L2-NHC trigger at oAR acts as the trigger for bi-cast termination. The oAR and nAR handle the BET in the following ways: 1) The oAR begins tunneling packets with MN's oCoA as the destination address to nAR. 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 destination address in the encapsulated packet, as if the packet were sent on oAR's subnet. 2) The nAR begins tunneling packets from the MN with oCoA as the source address to oAR. If the nAR receives any tunneled packets from the oAR with the MN's oCoA as the destination address in the encapsulated packet, nAR de-tunnels them and sends them to MN. Once the BET between oCoA and nCoA 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. The lifetime can be renewed by sending an HRqst(r), setting the R bit and including a Lifetime option indicating how long to extend the life of the tunnel service, an IP address option with the MN's home address, and an IP address option with the MN's aCoA. The oAR replies with an HRply(r) having the R bit set, indicating in a Lifetime option how long it is willing to continue tunnel service. 2) The MN begins the process of obtaining an nCoA through nAR. This may include either stateless or stateful address configuration. In this case, nAR sends a HRqst(r) with the MN's home address, oCoA, and the R bit set, and the Lifetime field set to zero, indicating that tunneling service is no longer required. The nAR and aAR may elect to postpone terminating tunneling service for some period of time to allow propogation of the MN's nCoA to the HA and CNs. 3) MN moves to a third AR, in which case the process in Section 3.3 is completed. Figures 3 and 4 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two party handover, respectively. The timing of BETB (BET with bicasting) and the termination of bi-casting is Bi-directional Edge Tunnel Handover June 2001 For IPv6 the least optimal for efficient handover smoothing, improvements are discussed in Section 3.5. MN nAR oAR | | | | | |<~~~ L2-ST | |<------------------| | | HRqst(s) | | | | | |------------------>|<... BETB | | HRply(s) | started | | | --------------------------------------------- L2 Handover --------------------------------------------- | | | |<~~~ L2-MHC |<~~~~ L2-NHC ~~~~>|<... bi-cast | | | terminated | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 3 - Two Party Source Trigger Handover Timing MN nAR oAR | | | | L2-TT ~~~>| | | |------------------>| | | HRqst(t) | | | | | |<------------------|<... BETB | | HRply(t) | started | | | --------------------------------------------- L2 Handover --------------------------------------------- | | | |<~~~ L2-MHC |<~~~~ L2-NHC ~~~~>|<... bi-cast | | | terminated | | | |<------------------->| | | MN's traffic | | | on oCoA | | | | | Figure 4 - Two Party Target Trigger Handover Timing Bi-directional Edge Tunnel Handover June 2001 For IPv6 3.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. +------+ +--->| aAR |<---+ | +------+ | 5) HRqst(r) | | 3) HRqst(t) Hrply(r) | | Hrply(t) | | v 2a) HRqst v 1a) L2-ST ~~~~> +------+ HTT +------+ <~~~ 1b) L2-TT | oAR |<-------->| nAR | 4a) L2-NHC ~~~> +------+ 2b) HTT +------+ <~~~ 4b) L2-NHC ^ HRply ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c) L2-MHC ~~~> | 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 occured 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. 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. Bi-directional Edge Tunnel Handover June 2001 For IPv6 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 oAR 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. The nAR responds with a HRply(s). The HTT should also include extensions containing authentication information and header compression context for the MN [8]. b) The L2 trigger is an L2-TT. The nAR sends HRqst(t) to oAR, exactly as if a two party handover were occuring. 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. The HTT should also include extensions containing authentication information and header compression context for the MN [8]. 3) The nAR performs a target trigger handover with aAR, exactly as in Section 3.2, exchanging a HRqst(t)/HRply(t) pair. 4) Completion of L2 handover is signaled by an L2 trigger at nAR, oAR, and MN. A BET is placed between oAR and nAR using the IPv6 tunneling procedure described in [15]. The aAr and nAR handle the trigger in the following ways: a) The oAR can terminate bi-casting, or, optionally, continue bi-casting until the probability of a ping-pong event is low. b) The nAR begins delivering packets to the MN, including any packets that were buffered during L2 handover. c) Based on its current traffic pattern, MN either defers obtaining a nCoA or begins the process of obtaining an nCoA as described in [3] or [4]. 5) When the L2-NHC trigger occurs at oAR, the oAR sends an HRqst(r) with Lifetime option having a value zero to aAR along with IP address options for the MN's aCoA and the MN's home address to terminate tunneling service. The aAR responds with a HRply(r) and terminates the tunnel to oAR. In the absence of the L2-NHC trigger, the oAR terminates the BET when the lifetime expires. Bi-directional Edge Tunnel Handover June 2001 For IPv6 As with two party handover, the timing of BET establishment and the start and termination of bi-casting depends on the availability of L2 trigger information. Since the aAR obtains no L2 triggers, it must establish the BET to nAR based on L3 events, namely after sending the HRply(t). The oAR can use the L2-NHC trigger to determine when to terminate bi-casting and request termination of tunnel service, or, alternatively, it can wait until the probability of a ping-pong event is low. If additional L2 trigger information is available, handover smoothing can be optimized. Figures 6 and 7 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handover, respectively. As in Figures 3 and 4, the timing of BET establishment between aAR and nAR and bi-casting start and termination on oAR are the least optimal for handover smoothing. Bi-directional Edge Tunnel Handover June 2001 For IPv6 MN nAR oAR aAR | | |................| | | |<-------------->|<---> to/from | | |................| CN | | | BET aAR/oAR | | | | | | | L2-ST ~~~~~> | | | | | | | |<-------------| | | | HTT | | | | | | | |------------->| |<... bi-cast | | HRply(s) | | started | | | | oAR |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| | | bicasting over old L2 | | | | | | | | | | | |------------------------------>| | | HRqst(t) | | | | | | | |<------------------------------|<... BET | | HRply(t) | | started | | | | aAR/nAR ----------------------------------- | | L2 Handover | | ----------------------------------- | | | | | |<~~~~L2-MHC |<~~ L2-NHC ~~>| |<... bi-cast | | | | terminated | | |--------------->| oAR |<-------------->| | HRqst(r) | | MN's traffic | | | | on aCoA | |<---------------|<... BET | | | HRply(r) | terminated | | | (terminate BET | aAR/oAR | | | aAR/oAR) Figure 6 - Three Party Source Trigger Handover Timing Bi-directional Edge Tunnel Handover June 2001 For IPv6 MN nAR oAR aAR | | |................| | | |<-------------->|<---> to/from | | |................| CN | | | BET aAR/oAR | | | | | | |<~~~~ L2-TT | | | | | | | |-------------->| | | | HRqst | | | | | | | |<--------------| |<... bicast | | HTT | | started | | | | oAR | | | | | | | | | | | | | | | | | |------------------------------->| | | HRqst(t) | | | | | |<-------------------------------|<... BET | | HRply(t) | | started | | | | aAR/nAR | | | | | | | | | | | | | | | | | | | | ---------------------------------- | | L2 Handover | | ----------------------------------- | | | | | |<~~~ L2-MHC |<~~~ L2-NHC ~~~>| |<... bi-cast | | | | terminated | | |-------------->| oAR |<--------------| | HRqst(r) | | MN's traffic | | | | on aCoA | |<--------------|<... BET | | | HRply(r) | terminated | | |(terminate BET | aAR/oAR | | | aAR/oAR) | Figure 7 - Three Party Target Trigger Handover Timing Bi-directional Edge Tunnel Handover June 2001 For IPv6 3.4. BET Renewal/Termination Prior to the lifetime of a BET expiring, an AR that is handling the wireless end of the BET 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. Figure 8 illustrates the message exchange that occurs between the AR handling the wireless end of the BET and the aAR to renew or terminate a BET. Termination occurs when the HRqst(r) contains a zero lifetime, extension occurs when the HRqst(r) contains a nonzero (positive) lifetime. HRqst(r) +------+ <-------- +------+ | aAR | ---------> | nAR | +------+ HRply(r) +------+ ^ | wireless link | v +------+ | MN | +------+ Figure 8 - BET Renewal or Termination 3.5. Handover Smoothing Packet loss can occur during handover if packets delivered to oAR are not forwarded to the MN on the old L2 link and the MN is still on the link, or if the packets are not tunneled to nAR for delivery to the MN when it is on the new link. Because the exact timing of L2 handover is probabilistically determined, handover smoothing may be required. Whether handover smoothing is required is partly an implementation issue and partly a deployment issue. If all traffic is real time and the combined latency of wired signaling and L2 handover is less than the minimum ITU recommended bound on latency for human perceptible artifacts, then no smoothing is required because there will be no user perceptible change. If, on the other hand, the variability in L2 handover causes it to reliably exceed the ITU recommended bound, or if data traffic is expected, where no packet loss can be tolerated, then some form of handover smoothing technique should be used. If handover smoothing is required, a standardized framework seems advisable to promote interoperability. There will naturally still be a considerable amount of room for different implementations and deployment options, but a base line recommended smoothing seems appropriate for standardization. Two handover smoothing techniques have been recommended: bi-casting [7] and buffering [18]. Bi-casting is a process by which the oAR sends packets on the old L2 at the same time as it tunnels them through the BET. Bi-casting Bi-directional Edge Tunnel Handover June 2001 For IPv6 allows the MN to continue to receive traffic on the old L2 until the old L2 disappears at a probabilistically uncertain time, and then for the MN to receive traffic with no delay on the new L2 immediately when it attaches, again at an probabilistically uncertain time. In addition, if a ping-pong event occurs, the MN can pick up receiving packets on the old L2. Figures 3, 4, 6, and 7 all show bi-casting for handover smoothing. An issue with bi-casting is that jitter of packet delivery on the oAR/nAR link relative to the old L2 can cause dropping or duplication of packets delivered to the MN. Buffering in the BETH context is implemented by having oAR terminate sending packets to the MN prior to L2 handover when the BET to nAR is placed, and having nAR buffer tunneled packets until the MN arrives on the new L2. When the MN arrives on the new L2, the buffered packets are delivered before current traffic is resumed. An issue with buffering is that it will delay real time traffic on the radio link until the buffer is empty. Bi-casting can be combined with buffering to avoid any dropped or duplicated packets and to avoid clogging the radio link after handover, if the extent of L2 handover can be accurately determined. In order for this to be possible, buffering must be confined to the actual period of time in which the L2 link is unavailable for L3 traffic. In the usual case, the oAR or aAR starts the BET when it sends the HRply(t) or the oAR starts the BET when it receives an HRply(s), rather than exactly when L2 handover begins. If packets are both bi-cast and buffered during the time in which the MN is still on the old L2, the MN can receive duplicate packets. For this reason, an L2 trigger that signals the actual start of L2 handover (L2-HS) at oAR or nAR can help to optimize handover smoothing. If the L2-HS trigger occurs at oAR, oAR can wait until the trigger is received to start the BET, rather than when it sends or receives the HRply. If the trigger occurs at nAR, nAR can start L2 frame buffering when it receives the L2-HS trigger, rather than starting when it receives or sends the HRply. An L2-HS trigger on nAR is the most useful, because it allows nAR to control buffering for both two party and three party handover occurs, whereas a trigger on oAR only works for two party handover. Ideally, a small sliding buffer for L2 frames at nAR, sized to hold enough frames to cover some high percentage, perhaps 90-99%, of the variability in L2 handover latency can help to eliminate any data loss during handover. Similarly, a small sliding L2 buffer on oAR can optionally help to eliminate data loss during ping-ponging. Ping-pong data loss can be prevented by continuing to send packets on the old L2 even after the MN is gone, and buffering L2 frames in a sliding buffer until the probability of a ping-pong event is low. If a ping-pong should occur, the oAR sends the buffered frames to MN and then starts normal packet delivery on the old L2 again. Bi- casting and buffering on the old L2 is terminated when the probability of a ping-pong event becomes insignificant. Bi-directional Edge Tunnel Handover June 2001 For IPv6 3.6. Message Descriptions This section contains message descriptions for the HRqst, HRply, and HTT messages. 3.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 it wants to cancel or extend tunneling service. The following diagram shows how the HI 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 |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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 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 xxx. IP Address Option containing MN's Home Address Present if the H or R bits are set. IP Address Option containing MN's old Care of Address Present if the H or R bits are set. LLA Option containing the MN's L2 address. Present if the H, T, or R bits are set. If the H bit is set, the message SHOULD contain a context transfer extension with authentication information and header compression context for the MN [8]. 3.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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 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. 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 xxx. IP Address Option containing MN's Home Address Present if the T or R bit is set. IP Address Option containing MN's old Care of Address Present if the T or R Bit is set. If the H bit is set, the message SHOULD contain a context transfer extension with authentication information and header compression context for the MN [8]. 3.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 the T bits set. No other bits are sent in HTT. In addition, the HTT MUST contain the following options in the specified order: Valid Options: Bi-directional Edge Tunnel Handover June 2001 For IPv6 IP Address Option containing aAR's Address The IP address of the aAR handling the network end of the BET. LLA Option containing the L2 address of the MN LLA Option containing the L2 address of aAR. 3.6.4. Lifetime Option The following defines the Lifetime option: 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. 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. 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, Bi-directional Edge Tunnel Handover June 2001 For IPv6 and HTT messages MUST contain an IPSEC AH header [17]. 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 Black, U., "Voice Over IP," Prentice Hall,Upper Saddle River, NJ, 2000. 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 Borman, C., ed., "Robust Header Compression (ROHC)", draft-ietf-rohc-rtp-09.txt, a work in progress. 6 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7 El-Malki, K., et. al., "Low Latency Handoff in Mobile IPv4," draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt, a work in progress. 8 Levkowetz, O.H., et. al., "Problem Description: Reasons for Performing Context Transfers Between Nodes in an IP Access Network," draft-ietf seamoby-context-transfer-problem-stat-01.txt, a work in progress. 9 Soliman, H., Castelluccia, C., El-Malki, K., and Bellier, L., "Hierarchical MIPv6 Mobility Management," draft-ietf-mobileip-hmipv6-03.txt, a work in progress. 10 Malinen, J., Le, F., and Perkins, C., "Mobile IPv6 Regional Registrations," draft-malinen-mobileip-regreg6-01.txt, a work in progress. 11 Plummer, D., "An Ethernet Address Resolution Protocol - or Converting Network Protocol Addresses to 48.bit Ethernet Address Bi-directional Edge Tunnel Handover June 2001 For IPv6 for Transmission on Ethernet Hardware", RFC 826, Symbolics,Inc., November 1982. 12 TIA/EIA/IS-95-B 13 Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December, 1998. 14 Perkins, C., ed., "IP Mobility Support," RFC 2002, October, 1996. 15 Conta, A., and Deering, S., "Generic Packet Tunneling in IPv6 Specification," RFC 2473, December, 1998. 16 Patil, B., et. al., "Basic User Registration Protocol (BURP)", draft-ietf-soliman-burp-requirements-00.txt, a work in progress. 17 Kent, S., and Atkinson, R., "IP Authentication Header," RFC 2402, November 1998. 18 Perkins, C. and Johnson, D., "Route Optimization in Mobile IP," draft-ietf-mobileip-optim-10.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 Sun Microsystems 901 San Antonio Rd., MTV29-235 Phone: +1 650 336 1558 Palo Alto, CA Fax: +1 650 691 0893 94043 Email: pat.calhoun@sun.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 Bi-directional Edge Tunnel Handover June 2001 For IPv6 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 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 Appendix A. Latency Estimates for Fast MIPv6 Handover Prototol In this Appendix, some calculated latency estimates for the fast MIPv6 handover protocol described in [3] are presented. While the actual handover latency will naturally depend on the exact message sequences exchanged between the MN and ARs, the calculations in this section make some realistic but simplifying assumptions about what those messages exchanges might be. The assumptions are fairly optimistic in that they seek to define the least possible number of messages in order to establish the MN at the new AR after an L2 handover. Actual times may be longer, particularly if error conditions (such as calculated care of address clashes) occur or for particular link layers without support for L2 triggers. The calculations do not include latency from signaling to the HA, CNs, or any hierarchical agents, nor are L2 handover latency or wired handover latency included. The message sequences are just what is required to get the MN up on the new router after a handover. A.1 Bandwidth of Radio Connection While the number of bytes in the messages exchanges is fixed and known, one of the major sources of uncertainty in the calculations is the actual bandwidth available over the air for IP signaling. The calculations assume that the exchange of bytes over the air is the controlling factor at L3 for when the MN stops getting packets at oAR and starts getting them again at nAR. The calculations are based on an assumption of using the wCDMA radio link protocol [1]. wCDMA uses a rate of 3 kpbs for signaling over the DCCH signaling channel. Currently, it is not possible to do IP signaling over the DCCH signaling channel in wCDMA. While this could be changed, it seems Bi-directional Edge Tunnel Handover June 2001 For IPv6 more likely that any mobile IP signaling in the immediate future will go over a traffic channel. The DPDCH traffic channel has a variable bit rate on a per frame basis between 0 and 2.1 mpbs, and the rate can differ in the uplink and downlink directions. Very few (around 4) users per cell can be supported at the highest data rate, and then only when radio conditions are excellent, typical data rates will be closer to 9.6 kbps. Using a traffic channel has an advantage in that the data rate is higher and can be throttled up or down, but a disadvantage in that any real time bearer traffic will be delayed until the signaling traffic is sent or received. The other disadvantage is that using a higher data rate is expensive. Higher data rates will also require more power during poor radio conditions (such as are typical during handover) and thus will reduce the capacity of the cell. Note that if it were possible to do IP signaling over the DCCH signaling channel, it might be possible to achieve a higher degree of parallelism even given the lower data rate, since DCCH signaling and DPDCH traffic can flow simultaneously. However, DCCH is also used for sending L2 messages. Some multiplexing techniques would be required to support Mobile IP messages over this channel. Additionally, sending Mobile IP messages would delay other L2 signaling messages, so any use of the DCCH channel would need to be carefully engineered so as not to delay L2 handover. In order to take advantage of the multiple data rates, each handover is calculated using data rates of 7.5 kbps (960 bytes/sec), 9.6 kbps (1200 bytes/sec), and 15 kbps (1875 bytes/sec). These data rates were chosen as a cross-section of what might be expected to span the range for realistic deployment scenarios. While higher rates are possible, they lead to a reduction in cell capacity due to the need to boost power in order to overcome deteriorating radio conditions during handover. Lower rates lead to better cell utilization, but lengthen L3 handover latency considerably. A.2 Actual Message Sequences The protocol specification in [3] is somewhat unclear about the exact sequence of messages exchanged, but this is probably to be expected since it is trying to optimize and therefore the exact message sequence is likely to vary as features of particular radio link L2 protocols are leveraged to achieve faster handover times. Therefore, the calculations assume a minimum exchange based on what the draft says MUST occur at L3 before the MN can start sending and receiving packets at L2. These are: - The oAR cannot forward any traffic to the MN through nAR until it receives a Fast Binding Update (F-BU) (pg. 5). This is true for all cases. - The MN cannot send or receive any packets until it does a Neighbor Advertisement (NA) or, at the very least, a Fast Neighbor Advertisement (F-NA) to nAR. Bi-directional Edge Tunnel Handover June 2001 For IPv6 - The MN does not have to receive a Router Advertisement (RtAdv) as a response to the F-NA before it can send packets, it can send them using oCoA (pg. 11). The message exchanges presented below are designed for the fastest possible case in which the MN can start exchanging real time packets after a handover. In some cases, this means that the oAR or MN are not using the nCoA, but rather, that a BET is available between oAR and nAR to tunnel packets through nAR to/from MN. Eventually, MN will confirm its new CoA through nAR and can begin to use it as well, but until that happens, it can still continue a real time stream. A.3 Other Assumptions The other assumptions are: - Prior to handover, the header compressor on the old AR is "hot" enough to compress the basic 48 byte IPv6 header down to 1 byte, but after handover, the header compressor is "cold" and so the full IP header needs to be sent. Currently, there is some debate about whether the compressor could be partially restarted on the new AR using context transfer, so this could introduce an additional optimization. Most thinking is that it would take a minimum of one round trip to re-establish header compressor state, however. - The wired link ARs use Ethernet (48 bit MAC address link layer [11]) and the wireless link is using 15 byte IMSIs (International Mobile Station Identifiers [12]) sent as ASCII digits. A.4 Calculated Message Exchanges The following table gives the calculated message exchanges and the final configuration when real time traffic starts again after handover, indicating which CoA is used by the MN and nAR. The parenthesized (old) and (new) after the message name indicated whether the message is sent through the oAR or nAR. All sizes are in bytes. Bi-directional Edge Tunnel Handover June 2001 For IPv6 Sequence Name Message Sequence Size Final Configuration ------------- ---------------- ---- ------------------- FMIPv6 Network PrRtAdv(old) 51 Full BU F-BU (old) 11 oCoA (FMIPv6-NFB) F-BACK (old) 10 -------> nAR F-NA (new) 98 MN <------ ------------- --- nCoA Total 170 FMIPv6 Network PrRtAdv(old) 51 New BU F-BU (new) 50 oCoA (FMIPv6-NNB) F-NA (new) 98 -------> nAR ------------- --- MN <------ Total 199 oCoA FMIPv6 Network PrRtAdv(old) 51 Old BU F-BU (old) 11 oCoA (FMIPv6-NOB) F-NA (new) 98 -------> nAR ------------- --- MN <------ Total 160 oCoA FMIPv6 Mobile RtSolPrxy(old) 36 Full BU PrRtAdv(old) 51 (FMIPv6-MFB) F-BU (old) 11 F-BACK (old) 10 same as FMIPv6-NFB F-NA (new) 98 ------------- --- Total 206 FMIPv6 Mobile RtSolPrxy(old) 36 New BU PrRtAdv(old) 51 (FMIPv6-MNB) F-BU (new) 50 F-NA (new) 98 same as FMIPv6-NNB ------------- --- Total 235 FMIPv6 Mobile RtSolPrxy(old) 36 Old BU PrRtAdv(old) 51 (FMIPv6-MOB) F-BU (old) 11 F-NA (new) 98 same as FMIPv6-NOB ------------- --- Total 196 A.5 L3 Handover Latency The following table gives handover latencies for the message exchanges in the previous table. The exchanges are indicated by their abbreviations, i.e. FMIPv6-NFB stands for Fast MIPv6 Network Bi-directional Edge Tunnel Handover June 2001 For IPv6 Full Binding update. The rows are sorted by time, from the lowest latency to the highest latency. All times are in milliseconds. Message Exchange 7.5 kbps 9.6 kbps 15 kbps ---------------- -------- -------- ------- FMIPv6-NOB 170 133 85 FMIPv6-NFB 180 141 90 FMIPv6-MOB 208 163 104 FMIPv6-MFB 219 171 109 FMIPv6-NNB 211 165 106 FMIPv6-MNB 250 195 125