Mobile IP Working Group MIPv4 Handoffs Design Team INTERNET-DRAFT Karim El Malki (Editor) Expires: November 2001 Pat R. Calhoun Tom Hiller James Kempf Peter J. McCann Ajoy Singh Hesham Soliman Sebastian Thalanany May 2001 Low Latency Handoff in Mobile IPv4 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is a product of the Mobile IP WG. Abstract Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs between subnets served by different Foreign Agents. In certain cases, the latency involved in these handoffs can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low- latency Mobile IP handoffs. In addition, a combination of these two methods is described. The described techniques allow greater support MIPv4 handoffs design team [Page 1] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 for real-time services on a Mobile IPv4 network by minimising the period of time when a Mobile Node is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. TABLE OF CONTENTS 1. Introduction.....................................................3 1.1 Terminology .................................................3 1.2 The Techniques ..............................................5 1.3 L2 triggers .................................................6 1.4 Requirements language .......................................8 2. Requirements.....................................................9 3. The PRE-REGISTRATION Handoff Method..............................9 3.1 Operation .................................................10 3.2 Network-Initiated Handoff .................................11 3.3 Mobile-Initiated Handoff ..................................13 3.4 Obtaining and Proxying nFA Advertisements .................15 3.4.1 Inter-FA Solicitation.................................15 3.4.2 Tunneled nFA Advertisements...........................15 3.4.3 Piggy-backing Advertisements on L2 messaging.........16 3.5 Caching Router Advertisements .............................16 3.6 Movement Detection and MN Considerations ..................17 3.7 Simultaneous Bindings .....................................17 3.8 L2 Address Considerations .................................18 3.9 Applicability of PRE-REGISTRATION Handoff .................19 4. The POST-REGISTRATION Handoff Method............................20 4.1 Operation .................................................20 4.2 Role of BETs ..............................................23 4.3 Foreign Agent Considerations ..............................24 4.4 Handoff Request Message ...................................26 4.5 Handoff Reply Message .....................................27 4.6 Applicability of POST-REGISTRATION Handoff Method..........29 5. Combined Handoff Method.........................................30 6. Reverse Tunneling Support.......................................30 7. Generalized Link Layer Address Extension........................31 7.1 IMSI Link Layer Address Extension .........................31 7.2 Ethernet Link Layer Address Extension .....................32 7.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..33 7.4 Solicited IP Address Extension ............................33 7.5 Solicited Access Point Identifier Extension ...............34 8. IANA Considerations.............................................34 9. Security Considerations.........................................35 9.1 AAA Considerations for Security ...........................36 10. References.....................................................37 11. Authors' Addresses.............................................38 12. Full Copyright Statement.......................................40 Appendix A - Gateway Foreign Agents................................41 Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......44 El Malki (Editor) et. al. [Page 2] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 1. Introduction Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer handoff between subnets served by different Foreign Agents (FAs). In certain cases, the latency involved in handoff can be above the threshold required for the support of delay-sensitive or real-time services. The aim of this document is to present two methods to achieve low-latency Mobile IP handoff during movement between FAs. The presented techniques allow greater support for real-time services on a Mobile IPv4 network by minimising the period of time when a MN is unable to send or receive IP packets due to the delay in the Mobile IP Registration process. In the rest of this section, terminology used throughout the document is presented, the handoff techniques are briefly described, and the use of link layer information is outlined. In Section 2, a brief description of requirements is presented. Section 3 describes the details of the PRE-REGISTRATION handoff technique, while Section 4 describes the details of the POST-REGISTRATION handoff technique. In Section 5, ways to use both handoff techniques together are presented. Section 6 discusses reverse tunneling support, while Section 7 describes the protocol extensions required by the handoff techniques. Sections 8 and 9 discuss IANA and security considerations. Two appendicies discuss additional material related to the handoff techniques. Appendix A describes how Regional Registration [2] and simultaneous bindings can be used together with low latency handoff. Appendix B discusses low latency handoff when a MN has multiple wireless L2 interfaces, in which case the techniques in this document may not be necessary. 1.1 Terminology This section presents a few terms used throughout the document. oFA - old Foreign Agent, the FA involved in handling a MN's care of address prior to an L3 handoff. nFA - new Foreign Agent, the FA anticipated to be handling a MN's care of address after completion of an L3 handoff. L2 handoff - Movement of a MN's point of Layer 2 (L2) connection from one wireless access point to another. L3 handoff - Movement of the FA handling a MN's care of address at Layer 3 (L3) from oFA to nFA. L2 trigger - Information from L2 that informs L3 of particular events before and after L2 handoff. The descriptions of L2 triggers in this document are not specific to any particular L2, but rather represent generalizations of L2 information available from a wide variety of L2 protocols. El Malki (Editor) et. al. [Page 3] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 source trigger - An L2 trigger that occurs at oFA, informing the oFA that L2 handoff is about to occur. target trigger - An L2 trigger that occurs at nFA, informing the nFA that an MN is about to be handed off to nFA. low latency handoff - L3 handoff in which the period of time during which the MN is unable to receive packets is minimized. low loss handoff - L3 handoff in which the number of packets dropped or delayed is minimized. Low loss handoff is often called smooth handoff. seamless handoff - L3 handoff that is both low latency and low loss. bicasting - The splitting of a stream of packets destined for a MN via its current FA (the oFA) into two or more streams, and the simultaneous transmission of the streams to oFA and one or more nFA. Bicasting is a handoff smoothing technique used to reduce packet loss during handover. bi-directional edge tunnel (BET) - A particular kind of bicasting in which the oFA bicasts packets destined for a MN to both nFA and the L2 on which the MN previously resided. The packets to nFA are tunneled. The tunnel is bi- directional because nFA tunnels packets from MN while it is using its old care of address back to oFA, so the packets appear on a topologically correct network. If the packets were not tunneled back to the oFA, they might be dropped by egress filtering. Bi-directional edge tunnels are only needed in POST-REGISTRATION handoff. ping-ponging - Rapid back and forth movement between two wireless access points due to failure of L2 handoff. 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. network-initiated handoff - L3 handoff in which oFA or nFA initiates the handoff. mobile-initiated handoff - L3 handoff in which the MN initiates the handoff. IP address identifier - An IP address of a MN or FA, or an L2 identifier that allows an FA to deduce the IP address of a MN or FA. If the IP address identifier is an L2 identifier, it may be specific to the L2 technology. El Malki (Editor) et. al. [Page 4] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 1.2 The Techniques Mobile IP was originally designed without any assumptions about the underlying link layers over which it would operate so that it could have the widest possible applicability. This approach has the advantage of facilitating a clean separation between L2 and L3 of the protocol stack, but it has negative consequences for handoff latency. The strict separation between L2 and L3 results in the following built-in sources of delay: - The MN may only communicate with a directly connected FA. This implies that a MN may only begin the registration process after an L2 handoff to nFA has completed. - The registration process takes some non-zero time to complete as the Registration Requests propagate through the network. During this period of time the MN is not able to send or receive IP packets. This document presents techniques for reducing these built-in delay components of Mobile IP. The techniques can be divided into two general categories, depending on which of the above problems they are attempting to address: - Allow the MN to communicate with the nFA while still connected to the oFA. - Provide for data delivery to the MN at the nFA even before the formal registration process has completed. The first category of techniques allows the MN to "pre-build" its registration state on the nFA prior to an underlying L2 handoff. The second category of techniques allow for service to continue uninterrupted while the handoff is being processed by the network. Three methods are presented in this draft to achieve low-latency L3 handoff, one for each category described above and one as a combination of the two: - PRE-REGISTRATION handoff method, - POST-REGISTRATION handoff method, - combined handoff method. The PRE-REGISTRATION handoff method allows the MN to be involved in an anticipated IP-layer handoff. The MN is assisted by the network in performing an L3 handoff before it completes the L2 handoff. The L3 handoff can be either network-initiated or mobile-initated. Accordingly, L2 triggers are used both in the MN and in the FA to trigger particular L3 handoff events. The PRE-REGISTRATION method El Malki (Editor) et. al. [Page 5] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 coupled to L2 mobility helps to achieve seamless handoffs between FAs. The basic Mobile IPv4 concept involving advertisement followed by registration is supported and the PRE-REGISTRATION handoff method relies on Mobile IP security. No new messages are proposed, except for an extension to the Agent Solicitation message in the mobile- initiated case. The POST-REGISTRATION handoff method proposes extensions to the Mobile IP protocol to allow the oFA and nFA to utilize L2 triggers to set up a registration on the nFA prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment to minimize the impact on real-time applications. The MN must eventually perform a formal Mobile IP registration after L2 communication with the new FA is established. Security is handled by standard Mobile IP mechanisms, and both intra-domain and inter-domain handoff are supported. The technique can be used for inter-technology handoff but it requires the active involvement by the mobile to switch from one network interface to another. The combined method involves running a PRE-REGISTRATION and a POST- REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can be completed before the L2 handoff completes, the combined method resolves to a PRE-REGISTRATION handoff. However, if the PRE- REGISTRATION handoff does not complete within an access technology dependent time period, the oFA starts forwarding traffic destined to the MN to the nFA as specified in the POST-REGISTRATION handoff method. This provides for a useful backup mechanism when completion of a PRE-REGISTRATION handoff cannot always be guaranteed before the L2 handoff completion. It should be noted that the methods described in this document may be applied to MNs having a single interface (e.g. Wireless LAN interface) or multiple interfaces (e.g. two WLAN interfaces, one WLAN and one cellular interface). However, the case of multiply-interfaced MNs needs special consideration, since the handoff methods described in this document may not be required in all cases (see Appendix B). 1.3 L2 triggers An L2 trigger is used to signal some event during the process of L2 handoff. One possible event is early notice of an upcoming change in the L2 point of attachment of the mobile node to the access network. Another possible event is the completion of relocation of the mobile node's L2 point of attachment to a new L2 access point. This information comes from L2 programmatically or is derived from L2 messages. Although the protocols outlined in this document make use of specific L2 information, Mobile IP should be kept independent of any specific L2. L2 triggers are an abstraction mechanism for a link technology specific trigger. Therefore, an L2 trigger that is made El Malki (Editor) et. al. [Page 6] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 available to the Mobile IPv4 stack is assumed to be generic and technology independent. The precise format of these triggers is not covered in this document, but the information required to be contained in the L2 triggers for low latency handoffs is specified. In order to properly abstract from the L2, it is assumed that one of the three entities - the MN, oFA, or nFA - is made aware of the need for an L2 handoff, and that the nFA or MN can optionally also be made aware that an L2 handoff has completed. A specific L2 will often dictate when a trigger is received and which entity will receive it. Certain L2s provide advance triggers on the network-side, while others provide advance triggers on the MN. Also, the particular timing of the trigger with respect to the actual L2 handoff may differ from technology to technology. For example, some wireless links may provide such a trigger well in advance of the actual handoff. In contrast, other L2s may provide no or little information in anticipation of the L2 handoff. An L2 trigger may be categorized according to whether it is received by the MN, oFA, or nFA. Table 1 gives such a categorization along with information expected to be contained in the trigger. The methods presented in this document operate based on different types of L2 triggers as shown in Table 1. Once the L2 trigger is received, the handoff processes described in Sections 3 or 4 is performed. El Malki (Editor) et. al. [Page 7] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 +-------------+----------------------+------------------------------+ | L2 trigger | mobile | source | | | pretrigger | trigger | | | (L2-MPT) | (L2-ST) | +-------------+----------------------+------------------------------+ | Recipient | MN | oFA | +-------------+----------------------+--------------+---------------+ | Method | PRE | PRE | POST | | | mobile- | network- | source | | | initiated | initiated | trigger | +-------------+----------------------+--------------+---------------+ | When? | sufficiently before | sufficiently | sufficiently | | | the L2 handover | before L2 | before L2 | | | so that MN can | handover for | handover for | | | solicit ProxyRtAdv | FA to send | oFA & nFA to | | | from oFA. | proxyRtAdv | exchange | | | | to MN. | HRq/HRy. | +-------------+----------------------+--------------+---------------+ | Parameters | nFA IP address | nFA IP address identifier | | | identifier | MN IP address identifier | | | | | +-------------+----------------------+------------------------------+ +------------+------------------------+-------------+---------------+ | L2 trigger | target | mobile | network | | | trigger | handoff | handoff | | | (L2-TT) | complete | complete | | | | (L2-MHC) | (L2-NHC) | |------------+------------------------+-------------+---------------+ | Recipient | nFA | MN | nFA | |------------+------------+-----------+-------------+---------------+ | Method | PRE | POST | POST | POST | | | network | target | (optional) | (optional) | | | initiated | trigger | | | |------------+------------------------+-------------+---------------+ | When? | | when radio | when radio | | | same as | conditions | conditions | | | source trigger | are OK for | are OK for | | | | MIP register| MIP register | |------------+------------------------+-------------+---------------+ | Parameters | oFA IP address id | none | none | | | MN IP address id. | | | |------------+------------------------+-------------+---------------+ Table 1 - L2 Triggers 1.4 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [3]. El Malki (Editor) et. al. [Page 8] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 2. Requirements The following requirements are applicable to low-latency handoff techniques and are supported by the methods in this document: - provide low-latency and low loss handoff for real time services, - minimize the effects at L3 of ping-ponging, - no dependence on a wireless L2 technology, - support inter- and intra-access technology handoffs, - limit wireless bandwidth usage. 3. The PRE-REGISTRATION Handoff Method The PRE-REGISTRATION handoff method is based on the original concept of Mobile IP handoff as specified in [1], in which: - an advertisement for an FA is received by an MN, - the advertisement allows the MN to perform movement detection, - the MN registers with the FA. The PRE-REGISTRATION method allows both the MN and FA to initiate handoff. In both cases, abiding by the basic Mobile IP handoff concept allows the MN to choose with which FA to register. The PRE- REGISTRATION method can make use of L2 triggers on either the FA or MN side, depending on whether network-initiated or mobile-initiated handoff occurs. PRE-REGISTRATION does not require any new messages to be defined in the network-initiated case and specifies one new extension to ICMP Solicitations for the mobile-initiated case. The PRE-REGISTRATION method supports handoff for a single network interface or between multiple network interfaces on the MN. The rest of this section discusses single interface handoff, Appendex C describes how multiple interface handoff is supported. PRE- REGISTRATION also supports both the normal Mobile IP model [1] in which the MN is receiving packets from a Home Agent (HA) and the Regional Registration model [2] in which the MN receives packets from a Gateway Foreign Agent (GFA). Finally PRE-REGISTRATION supports movement to a new domain, in which a new AAA transaction must occur to authenticate the MN with the new domain. El Malki (Editor) et. al. [Page 9] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 3.1 Operation The overall PRE-REGISTRATION Handoff mechanism is summarised in Figure 1 below: +---------+ | HA (GFA)|<---------+ +---------+ | 4. (Reg)RegReq | 5. (Reg)RegReply v +-----+ 1a. RtSol +-----+ | | -----------------> | nFA | | oFA | 1b. RtAdv | | +-----+ <----------------- +-----+ ^ | ^ (2a. ProxyRtSol) | | 2b / | | ProxyRtAdv / 3. (Reg)RegReq | | / | v --------------- +-----+ / | MN | +-----+ - - - - - -> Movement Figure 1 - PRE-REGISTRATION Handoff Protocol The following steps provide more detail on the protocol: 1. Messages 1a and 1b contain a solicitation of a Router Advertisement by oFA from nFA and a reply Router Advertisement from nFA. These messages SHOULD occur in advance of the PRE-REGISTRATION Handoff in order to not delay the handoff. For this to occur, oFA MAY solicit and cache advertisements from the nFA, thus decoupling the timing of this exchange from the rest of the PRE-REGISTRATION Handoff. When the L3 handoff is initiated by a target L2 trigger at nFA, message 1b is sent unsolicited directly to MN rather than relayed by oFA. 2. The presence of message 2a indicates that the handoff is mobile- initated and its absence means that the handoff is network-initiated. In mobile-initiated handoff, message 2a occurs if there is an L2 trigger in the MN to solicit for a Proxy Router Advertisement. When message 2a is received by the oFA, the oFA returns the Proxy Router Advertisement in message 2b. In network-initiated handoff, the L2 trigger occurs at oFA and oFA relays the Router Advertisement in message 2b without the need for MN to solicit. Note that it is also possible for nFA to advertise directly to the MN in the network- El Malki (Editor) et. al. [Page 10] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 initiated target-trigger case (section 3.2). In all cases message 2b is simply nFA's router advertisement. 3. The MN performs movement detection upon receipt of either a solicited or unsolicited Router Advertisement and, if appropriate, it sends a Registration Request message [1] [2] in message 3 to nFA requesting a simultaneous binding. Message 3 is routed through oFA since the MN is not directly connected to nFA prior to the L2 handoff. 4. Messages 3, 4 and 5 constitute a standard Mobile IP Registration [1] or Regional Registration [2]. The Registration Reply in message 5 MUST be copied by nFA to the MN both through oFA and directly on- link. This is necessary, unless the L2/L3 interaction is engineered such that the MN may not detach from oFA until it has received the Reply. Since this will not always be the case, the Reply SHOULD be tunneled by nFA to oFA and sent directly on-link. Figures 2 and 3 illustrate this tunneling, though it is not shown in Figure 1. Tunneling can take place either at L3 or L2. The MN's L2 address may be obtained using the extensions in Section 7, as described in 3.5. 5. Because of the uncertainty as to when the L2 connection between the MN and the nFA becomes fully established and can be used for L3 traffic, simultaneous bindings with the GFA or the HA are used to allow traffic for the MN to be sent to both the oFA and the nFA. Between the time when the Registration Reply is sent from HA or GFA to nFA and when the MN's connection on L2 at the nFA is fully established, the HA or GFA bicasts traffic for the MN to both oFA and nFA. The MN is able to receive traffic independently of the exact L2 handoff timing. Also, should the L2 handoff procedure fail, terminate abruptly, or ping-pong, the use of simultaneous bindings allows the MN to maintain L3 connectivity with the oFA, smoothing the handoff. PRE-REGISTRATION is not dependent on Regional Registration extensions [2]. However if the HA is at a distance (in terms of delay) from the nFA, the use of a local GFA reduces the time required for the handoff procedure to complete. Figures 2, 3, and 4 contain message timing diagrams for both the network-initiated and mobile-initiated PRE-REGISTRATION handoff procedures. 3.2 Network-Initiated Handoff As described in Table 1, a PRE-REGISTRATION handoff can be initated El Malki (Editor) et. al. [Page 11] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 at oFA by a source trigger or at nFA by a target trigger. A source- triggered network-initiated handoff occurs when an L2 trigger is received at the oFA informing it of a certain MN's upcoming movement from oFA to nFA. The L2 trigger will contain information such as the MN's IP address identifier (i.e. MN's IP address or identifier which can be resolved by the oFA to the MN's IP address) and the nFA's IP address identifier. An identifier may be specific to the wireless technology (e.g. Access Point ID). A target-triggered network- initiated handoff occurs when an L2 trigger is received at the nFA informing it of a certain MN's upcoming movement from oFA. This type of trigger is also shown in Table 1. The L2 trigger contains information such as the MN's IP address identifier and the oFA's IP address identifier. In a source-triggered handoff, message 2b, the Proxy Router Advertisement, is sent by oFA to the MN. Messages 1a and 1b are exchanged by oFA and nFA before the L2 trigger is received. Message 2a is not used. In a target-triggered handoff, nFA tunnels an Agent Advertisement directly to the MN to initiate the L3 handoff. The inner Advertisement is unicast by nFA to MN, thus nFA treats the target-trigger as a Router Solicitation. This Advertisement is tunneled to oFA which functions as a normal router, decapsulating the Advertisement and forwarding it to the MN. Figures 2 and 3 contain message timing diagrams describing the PRE- REGISTRATION network-initiated handoff for source and target triggers. MN oFA nFA HA/GFA | |<~~~~~~ L2-Source | | | | Trigger | | |<--------------------| | | | ProxyRtAdv | | | | | | | |---------------------------------------->| | | HA Reg. or | | | | RegReg (routed | |------------------->| | via oFA if pre | | HA reg or RegReg | | L2 Handoff) | | | | | |<-------------------| | | | Reg Reply | | | | | |<----------------------------------------| | |<--------------------|<------------------| | | | Reg Reply | | | |(sent to MN through| | oFA and directly) Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram (Network-Initiated, Source Trigger) El Malki (Editor) et. al. [Page 12] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN oFA nFA HA/GFA | | L2-Target~~~~~~~~>| | | | Trigger | | | | | | | |...................| | |<--------------------------------------- | | | (ProxyRtAdv) |...................| | | | Tunneled Agent | | | | Advertisement | | | | | | |---------------------------------------->| | | HA Reg. or | | | | RegReg (routed | |------------------->| | via oFA if pre | | HA reg or RegReg | | L2 Handoff) | | | | | |<-------------------| | | | Reg Reply | | | | | |<----------------------------------------| | |<--------------------|<------------------| | | | Reg Reply | | | |(sent to MN | | tunneled through oFA and directly on-link) Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram (Network-Initiated, Target Trigger) 3.3 Mobile-Initiated Handoff As shown in Table 1, a mobile-initiated handoff occurs when an L2 trigger is received at the MN informing it that it will shortly move to nFA. The L2 trigger contains information such as the nFA's IP address identifier (i.e. nFA's IP address or an identifier which can be resolved by MN to the nFA's IP address). The message timing diagram is shown in Figure 4. As a consequence of the L2 trigger, the MN issues message 1a, the Proxy Router Solicitation. The message is either: - Unicast to nFA's IP address, in which case the procedure is a normal agent solicitation, apart from having a TTL greater than 1. - Unicast to oFA, in which case the solicitation is for a Proxy Router Advertisement. This solicitation MUST have a TTL=1 as in [1]. Proxy Router Advertisement solicitation is required because the amount of topological distance between nFA and MN could preclude a Router Advertisement sent in reply prior to an L2 handoff. This is different from [1], where a TTL of 1 is mandated. El Malki (Editor) et. al. [Page 13] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN oFA nFA HA/GFA |<~~~~~ L2-Trigger | | | | | | | |-------------------->| | | | ProxyRtSol | | | | | | | |<--------------------| | | | ProxyRtAdv | | | | | | | |---------------------------------------->| | | HA Reg. or | | | | RegReg (routed | |------------------->| | via oFA if pre | | HA reg or RegReg | | L2 Handoff) | | | | | |<-------------------| | | | Reg Reply | |<----------------------------------------| | |<--------------------|<------------------| | | | Reg Reply | | | |(sent to MN through| | oFA and directly) Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram (Mobile-Initiated) The Proxy Router Advertisement solicitation is an agent solicitation with a special extension. The solicitation MUST have an extension containing an IP address idenfifier because the MN is soliciting a specific FA's advertisement from the oFA. This specific FA is the one which will be its nFA. The IP address identifier contains the IP address of the nFA or an identifier that can be used by the oFA to resolve to nFA's IP address. If the identifier is not an IP address, it may be specific to the underlying wireless technology, for example, an Access Point or Base Station ID. The extension is a subtype of the Generalised Link-Layer Address extension described in Section 7. Two subtypes have been defined to contain the nFA's IP address and an access point identifier They are called the Solicited Agent IP Address Extension and the Access Point Identifier Extension, and are described in Sections 7.4 and 7.5. Only one of the two should be present in the MN's solicitation. As a result of the MN solicitation message, the oFA sends message 2b, the Proxy Router Advertisement, to the MN. The Proxy Router Advertisement contains the agent advertisement for the requested nFA. In order to expedite the handoff, the actual nFA advertisement SHOULD be cached by the oFA following a previous exchange with nFA, shown in messages 1a and 1b, and specified in Section 3.5. El Malki (Editor) et. al. [Page 14] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 3.4 Obtaining and Proxying nFA Advertisements If L2 triggers are involved in initiating PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged such that a full L3 PRE- REGISTRATION handoff can complete before L2 handoff initiates. That is, the L2 handoff should be initiated after the MN's Registration with the nFA completes and produces a simultaneous binding at the GFA/HA. The Registration MAY be transmitted more than once to reduce the probability that it is lost due to errors on the wireless link. A PRE-REGISTRATION handoff in this case requires the MN to receive agent advertisements from the nFA through the old wireless access point, and to perform a registration with the nFA through the old wireless access point. Three ways of performing this are discussed in the following subsections. 3.4.1 Inter-FA Solicitation Inter-FA solicitation assumes that oFA has access to the IP address of the nFA. The IP address of nFA is obtained either by means of an L2 trigger at oFA in the network-initiated case (see Section 3.2) or by means of the extension to the Proxy Router Solicitation from the MN in the mobile-initiated case (see Section 3.3). Conceptually, once the oFA has access to the address of the nFA for a specific MN, it MUST send a unicast agent solicitation to nFA. The nFA replies to the oFA by unicasting an Agent Advertisement with appropriate extensions. This method removes the TTL limitation of [1] for Mobile IP messages (i.e. TTL=1). The TTL limitation cannot be applied since oFA and nFA may be more than one hop away and is unnecessary for a unicast message in any case. Security between oFA and nFA should be in place to ensure that agent solicitations and advertisements are protected and to enable nFA to determine that oFA is authorised to solicit agent advertisements. As a practical matter, oFA SHOULD pre-solicit and cache advertisements from known FAs topologically near it, in order to prevent having to perform the above solicitation during an actual handoff procedure (see Section 3.5). 3.4.2 Tunneled nFA Advertisements Tunneling nFA advertisments assumes that nFA is aware of the IP address for oFA and the MN. These IP addresses are obtained either by means of the IP address identifiers in an L2 trigger at nFA in the network-initiated case (see Section 3.2) or by means of the Proxy Router Solicitation from the MN in the mobile-initiated case (see Section 3.3). A solicitation from MN directly to nFA must reach nFA and identify the oFA, so the solicitation must include an extension containing an IP address identifier. This can be either oFA's IP address or an Access Point identifier which may be specific to the El Malki (Editor) et. al. [Page 15] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 underlying wireless technology. As a result of the tunneled solicitation, the nFA sends a Router Advertisement tunneled to the MN through oFA. This message is effectively message 2b, coming from nFA instead and only routed through oFA. However in [1] the MN cannot solicit an Advertisement from the nFA directly (Mobile-Initiated Handoff) since it is not on the same link as the MN. This restriction applies if the TTL must be 1 on Router Solicitations. The same would apply to Router Advertisements from the nFA, which also affects the Network-Initiated Handoff case. Therefore tunneling advertisements is only applicable where the TTL limitation of [1] can be relaxed. This should be the case for unicast messages. 3.4.3 Piggy-backing Advertisements on L2 messaging Piggy-backing advertisements on L2 messaging involves utilizing the L2 messaging involved in L2 handoff to transmit the Router Advertisement from the nFA to the MN or oFA. When the first L2 handoff messages are exchanged, it may be possible to transmit a Router Advertisement piggybacked onto L2 messages. Alternatively, the L2 at oFA may cache nFA's advertisements and not need to receive Router Advertisements upon every L2 handoff initiation. Whether this technique is possible depends on the particulars of the L2 technology and is outside the scope of this document. 3.5 Caching Router Advertisements If done during a handoff, message exchange 1 in Figure 1 imposes an additional latency penalty on the L3 handoff process. In order to remove this source of latency, the inter-FA Router Solicitation and Advertisement exchange SHOULD be performed in advance of handoff. A process SHOULD be in place at the oFA to solicit its neighbouring nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT be set too small to avoid unnecessary consumption of network bandwidth and nFA processing resources. The minimum value of MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response mechanism in [11] is used then the MIN_SOLICITATION_INTERVAL must be set to a value smaller or equal to the CHALLENGE_WINDOW (in nFA) so that the nFA challenge does not expire before the MN issues the Registration Request. The oFA SHOULD cache the most recent advertisements from its neighbouring nFAs. These advertisements should be sent to the MN in message 2b with a TTL=1. The oFA SHOULD also have a mechanism in place to create a list of neighbouring nFAs. The minimum support is to manually configure a list of nFAs for each FA in the network with which an L3 handoff is possible. The list will depend on deployment and radio coverage. It is also possible to specify another protocol to achieve nFA discovery, but it is outside the scope of this document. El Malki (Editor) et. al. [Page 16] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 3.6 Movement Detection and MN Considerations When the MN receives an Agent Advertisement with a Mobility Agent extension, it should perform actions according to the following movement detection mechanisms. The MN MUST be: - "Eager" to perform new bindings, - "Lazy" in releasing existing bindings. The above means that the MN MUST perform Registrations with any new FA from which it receives an advertisement (i.e. MN is Eager), as long as there are no locally-defined policies in the MN that discourage the use of the discovered FA. For example, the MN may have a policy based on the cost of service. The method by which the MN determines whether the FA is a new FA is described in [1] and may make use of an FA-NAI extension. However the MN MUST NOT release existing bindings until it no longer receives advertisement from the old FA and the lifetime of its existing binding expires (i.e. MN is Lazy). If the MN has at least one existing binding with an FA, additional simultaneous Registrations are performed requesting a short lifetime. This is done to limit the lifetime of temporary bindings and therefore limit bandwidth usage. Temporary bindings occur when the MN is moving between FAs and uses PRE-REGISTRATION handoff to achieve low loss IP mobility. By limiting the lifetime, the Registrations time out quickly avoiding the need for the MN to cancel the registration. Temporary bindings are also useful to support ping- ponging between FAs. 3.7 Simultaneous Bindings Simultaneous bindings are used by a GFA or HA to decouple L3 handoff from L2 handoff and to reduce packet loss. Simultaneous bindings allow a GFA or HA to bicast packets destined to the MN to multiple potential future MN locations before the MN actually moves there. Simultaneous bindings and bicasting are also useful to support ping- ponging. Using normal Mobile IP with an HA only and no GFA, the MN MAY perform registrations with the HA using simultaneous bindings. This is described in [1] and the method to anticipate MN movement by interacting with the wireless L2 is described in Section 3.6. However, having multiple simultaneous bindings for the MN at the HA causes the HA to send multiple copies of data packets towards mutliple FAs that may be topologically distant. Bicasting from the HA is not efficient unless the HA is close to the FAs in question. Also, if the round-trip time between the HA and FAs is not negligible, the MN's new Registration and therefore L3 handoff can be delayed. El Malki (Editor) et. al. [Page 17] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 If a GFA is present, low loss handoff is achieved by bicasting traffic from the GFA to the oFA and the nFA while the MN is moving between them. The MN sets the "S" bit in the Registration Request [2]. When a Regional Registration Request has the "S" bit set, the receiving regional FA or GFA that has an existing binding with the MN adds the relevant new binding for the MN but also maintains any existing bindings it has for the MN, bicasting traffic to the MN at both FAs. If the MN has simultaneous active bindings with FAs, it could (but preferably should not) receive multiple copies of the same traffic directed to it. The use of simultaneous bindings does not mean that the MN is receiving packets contemporarily from multiple sources. This depends on the characteristics of the access (L2) technology. The bicasting of packets involves sending a copy of the data to the FA which the MN is moving to. Until the MN actually completes the L2 handoff to the new FA and fully establishes the new L2 link, the new FA MAY receive packets for a MN to which it does not have a direct link layer connection. The FA MAY: - drop all packets for the MN, or - buffer packets for the MN. The choice of which action to take may depend on the type of traffic involved, but this is outside the scope of this document. The MN MAY also in parallel attempt to establish a link-layer connection with the MN. An FA MUST NOT send ICMP Destination Unreachable messages if it drops packets or is unable to deliver the received IP packets due to unavailability of direct layer connection with the MN. Appendix A contains more information about GFA considerations for the PRE-REGISTRATION handoff. 3.8 L2 Address Considerations If a wired backbone network connects wireless access points and the wireless network is not bridged (i.e. the wireless access points are not acting as routers) so that the FA is not directly on the same link as the MN, the MN MAY use an L2 address extension to the Registration message when the MN is performing a registration. Because the MN is registering with an FA that is not its first-hop router, the L2 address of the frame containing the MN's registration packet is not MN's address. The MN must use some means to communicate its L2 address other than the frame address, which is the method specified in [1]. To communicate its L2 address, the MN includes a Generalised Link Layer Extension (see Section 7) with its registration. The FA uses the L2 address in the extension to communicate with the MN. If a particular wireless L2 technology has defined a special L2 interface to the wireless network that allows the FA to resolve the mapping between an MN IP address and an L2 El Malki (Editor) et. al. [Page 18] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 address without the need to use the extension, the extension is not needed. 3.9 Applicability of PRE-REGISTRATION Handoff Security for the PRE-REGISTRATION handoff method is based on the same security model as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION is that the FA or MN are able to obtain an L2 trigger informing them of a pending L2 handoff procedure. The target of the L2 handoff is another access point or radio network which is in the coverage area of a new FA. The L2 trigger information may be in the form of IP address identifiers which may need to be resolved to IP addresses using methods that may be specific to the wireless network and are not considered here. If, for example, the FA determines that the IP address of the new FA is within its coverage area (i.e. is its own address) the PRE-REGISTRATION handoff should not be initiated. The L2 trigger must allow enough time for the PRE-REGISTRATION handoff procedure to be performed. In many wireless L2 technologies, the L2 handoff procedure involves a number of message exchanges before the effective L2 handoff is performed. For such technologies, PRE-REGISTRATION handoff can be initiated at the beginning of the L2 handoff procedure and completed before the L2 handoff is completed. It may be necessary to engineer the network such that this succession of events is ensured. The PRE-REGISTRATION Handoff method is applicable in the following cases: - when the MN has locally defined policies that determine a preference for one access over another, for example service cost, within the same or different technology, etc., and therefore where it is necessary to allow the MN to select the appropriate FA with which to connect, - when L3 cannot rely upon L2 security between the MN and the FA to make modifications to IP routing and therefore authenticated Mobile IP messages are required, - when the trigger to initiate the handoff is received at the MN. In the first case it is necessary to involve eventual local MN policies in the movement detection procedure as described in 3.2. El Malki (Editor) et. al. [Page 19] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 4. The POST-REGISTRATION Handoff Method The POST-REGISTRATION handoff method is based on a network-initiated model of handoff. The technique does not require any MN involvement until the actual L2 connection with nFA is completed. The oFA and nFA perform a message exchange that allows the MN to establish a temporary registration on the nFA until the MN performs a formal Mobile IP FA registration. The technique derives its name because the registration occurs after L2 handoff is complete. POST-REGISTRATION makes use of bi-directional edge tunnels (BETs) to smooth packet delivery while the MN is in transition between oFA and nFA. If the FA determines that there is no change in the FA, based on the L2 trigger information, then the POST-REGISTRATION handoff procedures are not initiated. POST-REGISTRATION depends on standard AAA-based Mobile IP security [13], but for true low-latency handoff, pre-established security associations between FAs are necessary. In summary, POST- REGISTRATION handoff covers new cases that are not addressed by the framework in [1]. 4.1 Operation In the POST-REGISTRATION method, the FA issues handoff messages on behalf of the Mobile Node, acting as a surrogate of sorts. The FA becomes aware that a handoff is about to occur at L2 through the use of an L2 trigger. An FA can receive two types of triggers, a source trigger at oFA and a target trigger at nFA. Section 1.1 and Table 1 contain more details about source and target triggers. Figures 5 and 6 contain message sequences for source and target triggered POST-REGISTRATION handoff, respectively. Figures 7 and 8 contain message timing diagrams for the message sequences in Figures 5 and 6. In Figure 5, a source trigger is obtained by oFA when L2 detects that the MN is about to depart its coverage area. In Figure 6, a target trigger is obtained by the nFA when L2 detects that the MN has just arrived in the coverage area of the nFA prior to the completion of the L2 handoff. Note that both triggers are available before the actual completion of the link layer handoff. +-----+ 1. Handoff Request +-----+ | | -----------------> | | 0. Source ~~~> | oFA | | nFA | Trigger | | 2. Handoff Reply | | +-----+ <----------------- +-----+ ^ | 3. Reg Request | | 4. Reg Reply | v +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 5 - Source Trigger POST-REGISTRATION Handoff El Malki (Editor) et. al. [Page 20] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 +-----+ 1. Handoff Request +-----+ | | <----------------- | | | oFA | | nFA |<~~~~ 0. Target | | 2. Handoff Reply | | Trigger +-----+ -----------------> +-----+ ^ | 3. Reg Request | | 4. Reg Reply | v +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 6 - Target Trigger POST-REGISTRATION Handoff The message sequences between oFA and nFA depicted in Figures 5 and 6 are very similar. The main difference is in the initiator of the Handoff Request message. In both the source and target trigger cases, an FA obtains link-layer information that indicates the necessity of a handoff to the nFA. In the event of a source trigger, oFA transmits a Handoff Request message to nFA. The Handoff Request MUST include the MN's home address, HA address, remaining registration lifetime, and a Generalized Link-Layer Address Extension (see Section 7) with the MN's L2 address. Upon receipt of the message, nFA MUST create the MN's visitor entry, and respond with the Handoff Reply message. In the event of a target trigger, the trigger occurs on nFA, and nFA transmits a Handoff Request to oFA. The Handoff Request message MUST include the MN's L2 address in a Generalized Link-Layer Address Extension (see Section 7) in order for oFA to correctly identify the MN. The request message MAY include additional MN information, if such information was provided by the L2. Upon receipt of the request, oFA MUST respond with the Handoff Reply message, including the MN's home address, HA address, remaining registration lifetime and a Generalized Link-Layer Address Extension with the MN's link layer address. El Malki (Editor) et. al. [Page 21] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN oFA nFA HA/GFA | | | | | | |<~~~~~~~ L2-TT | | |<------------------| | | | HReq(t) | | | | | | | |------------------>| | | | HRply(t) | | | | | | | |...................| | | |<----------------->| | | |...................| | |<--------------------------------------->| | | | Tunneled Traffic | | | | to/from MN | | |<~ ~ ~ ~ L2-MHC | | | | (optional) | | | | | | | |- - - - - - - - - - - - - - - - - - - - >| | | RtSol | | | | | |<~ ~ ~ ~ L2-NHC | |<- - - - - - - - - - - - - - - - - - - - | (optional) | | | RtAdv | | | | | | |------------------------------------------------------------->| | HA Reg or RegReg | | | | | | | Figure 7 - POST-REGISTRATION Handoff Message Timing Diagram (Target-Trigger) Completion of POST-REGISTRATION handoff requires MN to perform a full FA and HA/GFA registration. A trigger that signals the completion of the handoff, designated as L2-NHC (Layer-2 Network Handoff Complete) or L2-MHC (Layer-2 Mobile Handoff Complete) in Figures 7 and 8, performs this function. If the MN receives an L2-MHC trigger, it SHOULD send a Router Solicitation message. The Router Solicitation causes nFA to send a Router Advertisement, allowing the MN to perform a complete Mobile IP or Regional Registration. Alternatively, if the nFA receives the L2-NHC trigger, nFA SHOULD send a Router Advertisement, allowing the MN to perform a complete Mobile IP or Regional Registration. The L2-MHC and L2-NHC triggers are optional. If they are not available, the MN MUST wait until nFA sends a periodic Agent Advertisement and MUST respond by registering with nFA. El Malki (Editor) et. al. [Page 22] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN oFA nFA HA/GFA | |<~~~~~~ L2-ST | | | | | | | |------------------>| | | | HReq(s) | | | | | | | |<------------------| | | | HRply(s) | | | |...................| | | |<----------------->| | | |...................| | |<--------------------------------------->| | | | | | | | Tunneled Traffic | | | | to/from MN | | | | | | |<~ ~ ~ ~ L2-MHC | | | | (optional) | | | | | | | |- - - - - - - - - - - - - - - - - - - - >| | | RtSol | | | | | |<~ ~ ~ ~ L2-NHC | |<- - - - - - - - - - - - - - - - - - - - | (optional) | | | RtAdv | | | | | | |------------------------------------------------------------->| | HA Reg or RegReg | | | | | | | Figure 8 - POST-REGISTRATION Handoff Message Timing Diagram (Source Trigger) 4.2 Role of BETs Bi-directional edge tunnels, or BETs, are used to achieve low loss of traffic to and from the MN during a handoff and to smooth handoff when an MN undergoes ping-ponging. The tunnel from nFA back to oFA allows the MN to use its old care of address prior to registering with nFA. If this tunnel is not established, the old care of address cannot be used because it is topologically incorrect and may trigger egress filtering in nFA's subnet, resulting in the MN's packets being dropped. Figure 9 provides an example of a BET. The BET is placed when the oFA issues a successful Handoff Reply to nFA, or receives a successful Handoff Reply from nFA. This causes oFA to forward the MN's traffic to the nFA. The nFA forwards the traffic further to the MN if an L2 connection exists. In the reverse direction, as soon as MN comes up on the L2 connection with nFA, it can start sending packets with the old care of address, and nFA tunnels them to nFA, where they are detunneled and forwarded as if they originated through oFA. El Malki (Editor) et. al. [Page 23] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Data +-----+ Data +----+ +------------>| oFA |<--------------------------| HA | | +-----+ +----+ v ^ ^ +----+ Handoff | | Data | MN | Request | | +----+ | | ^ v v | +-----+ +------------>| nFA | Data +-----+ Figure 9 - Bi-Casting by the Foreign Agent 4.3 Foreign Agent Considerations Upon receipt of a trigger event, an FA SHOULD issue a Handoff Request message to the FA to which or from which the mobile is being handed off. If the message is the result of a target trigger, the Type Of Trigger bit in the Handoff Request message MUST be set and the Generalized Link-Layer Address Extension (see Section 7) MUST be present. The sender of the Handoff Request is nFA and the handoff is target triggered. The message's home address and HA address fields MAY be set to NULL if this information is not known at the time the message is transmitted. Upon receipt of a Handoff Request message with the Type Of Trigger bit set, the oFA MUST respond with the Handoff Reply message. The Handoff Reply MUST include both the MN's home address and HA address. The MN's remaining registration lifetime MUST be included in the Handoff Reply's lifetime field. Furthermore, the oFA issuing the Handoff Reply MAY include any security associations that were dynamically created. The oFA that issues a Handoff Reply with the Code field set to success (zero value) MUST bi-cast all packets destined to the MN to both the L2 to which the MN is currently connected and by tunneling to the nFA.The oFA must also be prepared to receive tunneled packets from the nFA in which the MN's packets appear with the old care of address. The nFA that receives a Handoff Reply message with a zero value in the Code field creates a visitor entry with the information found in the message. The FA MUST be prepared to deliver packets to the MN prior to receiving a Registration Request [1] from the MN, and it MUST be prepared to tunnel packets sent by the MN under the MN's old care of address to oFA. Note that it is possible for the encapsulation method used between oFA and nFA to be different from the one requested by the MN during El Malki (Editor) et. al. [Page 24] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 its Registration process. When this occurs, the respective FAs MUST perform encapsulation translation. An FA that receives a source trigger MUST send a Handoff Request message with the Type Of Trigger bit disabled. The sender of the Handoff Request message is the oFA and the handoff is source triggered. The message MUST also include the MN's home address, the HA address and the Link Layer Address extension (see section 7). The MN's remaining registration lifetime MUST be included in the lifetime field. The oFA MAY also include any security associations that were dynamically created. Upon receipt of a Handoff Request with the Type Of Trigger bit disabled, the nFA MUST process the packet and respond with the Handoff Reply message. If successfully processed, the nFA MUST create a visitor entry for the MN, and be prepared to deliver tunneled packets received by the initiator of the Handoff Request destined for the MN, and to tunnel packets from the MN sent under its old care of addres to the oFA. The Handoff Reply message MUST include the home address, HA address, lifetime value, and the Generalized Link-Layer Address Extension (see Section 7) with the MN's link layer address. An oFA that receives a Handoff Reply with the Code field set to success (zero value) MUST bi-cast all packets destined for the MN to both the MN on the old L2 and by tunneling to the nFA. The oFA must also be prepared to receive packets sent by the MN under its old care of address on the new L2 that are tunneled by nFA. Once a visitor entry has been created in nFA, and the MN establishes an L2 connection with the nFA, its traffic will be immediately delivered, along with an Agent Advertisement message [1]. The nFA can determine when to send the Agent Advertisement by the L2-NHC trigger. If the MN receives an L2-MHC trigger, it can send an Agent Advertisement Solicitation. Alternatively, if neither L2 trigger is available, the MN will respond to a periodic Agent Advertisement sent according to [1]. In any case, the MN can continue to use its old care of address without any delay in uplink L3 connectivity until it is established on the new L3 since the nFA tunnels its packets back to the oFA. An MN MUST issue a Registration Request when it receives an Agent Advertisement from the nFA, completing the L3 handoff. Note that the nFA MAY delay sending an Agent Advertisement, especially to reduce noticeable service disruption during a ping- pong. However, when doing so, the nFA MAY need to re-issue a new Handoff Request to oFA, to extend the visitor entry's lifetime. In the event that the visitor entry for an MN at nFA is about to expire and the MN has not yet issued a Registration Request, the nFA has the option to transmit a new Handoff Request message to the oFA to renew the registration. Whether the renewal is performed on behalf of the MN is a policy decision up to the network administrator. El Malki (Editor) et. al. [Page 25] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 An FA MAY receive packets for a MN to which it does not have a direct link layer connection. The FA MAY: - drop all packets for the MN, or - buffer packets for the MN. The choice of which action to take may depend on the type of traffic involved, but this is outside the scope of this document. The MN MAY also in parallel attempt to establish a link-layer connection with the MN. An FA MUST NOT send ICMP Destination Unreachable messages if it drops packets or is unable to deliver the received IP packets due to unavailability of direct layer connection with the MN. Given that a MN's packets will be delivered prior to a proper registration, the MN MAY discard all packets received from FAs with which it has not registered. When the nFA receives the MN's Registration Request [1] and the HA's or GFA's successful Registration Reply [1][2], it MUST transmit a Handoff Request message to the oFA with the lifetime field set to zero. An oFA that receives a Handoff Request with the lifetime field set to zero is being informed that it is no longer the anchor point for the mobile. The oFA SHOULD stop bicasting at this point, and tear down the reverse tunnel from nFA, since the MN is now fully connected at L3 on the new subnet. The oFA MAY issue a Handoff Request to the nFA in the future if it wishes to keep receiving the mobile's packets for possible delivery. 4.4 Handoff Request Message The Handoff Request message is used to inform a peer that a POST- REGISTRATION handoff is being initiated. The Handoff Request message can be used for both source and target triggers, through the Type of Trigger 'I' bit in the message flags. When sent as a result of a target trigger, the home address and HA fields MAY be set to zero (unless this information was communicated by the link layer, which is outside the scope of this document). El Malki (Editor) et. al. [Page 26] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 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 |S|x|I|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Handoff Request) S When set it indicates that both oFA and nFA will attempt to deliver datagrams directly to MN, if a link-layer connection exists. I Type of Trigger. A value of zero is a source trigger (request sent by oFA), while a value of one is a target trigger (request sent by nFA). M, G, T As defined in [1,5]. This refers to the tunnel between oFA and nFA. Lifetime The requested Lifetime for which nFA will serve the MN on behalf of oFA, without requiring a new registration. MN Home Address The home address of the MN. When using a private address, the G and T flags must be sent and a GRE Key extension must be included. HA Addr The HA address of the mobile node. Identification As in defined in [1]. Extensions The Message MUST include LLA (see Section 7) and the FA-FA Authentication Extension [2]. 4.5 Handoff Reply Message The Handoff Reply message is sent in response to the Handoff Request message. When a source trigger caused the Handoff Request message to be sent, the Handoff Reply message is sent with a successful code if the Visitor Entry was successfully created. When a target trigger El Malki (Editor) et. al. [Page 27] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 caused the Handoff Request message, receipt of the Handoff Reply message with a successfuly code SHOULD cause the Visitor Entry to be created. 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 | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|x|I|M|G|r|T|x| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Handoff Reply) Code A value indicating the result of the Handoff Request. See below for a list of currently defined Code values. Lifetime If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. S When set it indicates that both oFA and nFA will attempt to deliver datagrams directly to MN, if a link-layer connection exists. I Type of Trigger. A value of zero is a source trigger (reply sent by nFA), while a value of one is a target trigger (reply sent by oFA). M, G, T As defined in [1,5]. This refers to the tunnel between oFA and nFA. El Malki (Editor) et. al. [Page 28] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN Home Address The home address of the mobile node. When using a private address, the G and T flags must be sent and a GRE Key extension must be included. HA Addr The HA address of the mobile node. Lifetime The requested Lifetime for which nFA will serve the MN on behalf of oFA, without requiring a new registration. Identification As in defined in [1]. Extensions The Message MUST include LLA (see Section 7) and the FA-FA Authentication Extension [2]. 4.6 Applicability of POST-REGISTRATION Handoff Method The POST-REGISTRATION handoff approach allows FAs to communicate directly about a pending handoff, and does not require any IP layer messages to be sent to or from a MN prior to the L2 handoff event. Therefore, it does not place the MN's IP stack or Mobile IP client implementation on the critical path after a need for handoff is recognized but before the handoff can take place. This separation is necessary when the link layer imposes hard deadlines on the time at which a handoff must occur, such as when a MN is rapidly moving out of a radio coverage area, but when the MN's IP stack is not implemented as a hard real-time system. Because a POST-REGISTRATION handoff is triggered by an unspecified mechanism that informs the oFA or nFA that an L2 handoff is pending, the POST-REGISTRATION approach is only applicable to networks where such a mechanism is available. For example, an L2 may provide power measurements or other indications of radio signal quality that cause the oFA or nFA to send the POST-REGISTRATION handoff messages. Any such indications must also provide each FA involved in the handoff with the identity of the other, so that messages can be sent to the right place. This may involve mapping L2 information onto FA IP addresses. Also, the FAs involved in a handoff must have pre- provisioned security arrangements so that the POST-REGISTRATION messages can be authenticated. If a handoff is to be completed as a result of the POST-REGISTRATION messaging without continuing to bicast traffic to both the old and new coverage areas, any L2 handoff indications must also be securely authenticated so that traffic to the old point of attachment is not improperly halted. POST-REGISTRATION handoff is appropriate in the following cases: - L2 triggers are available on the network to indicate that L2 handoff is pending. El Malki (Editor) et. al. [Page 29] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 - Pre-provisioned security mechanisms are in place to allow fast and secure messaging between the FAs and between the MN and an FA. - Access point choice by the MN is not a concern or choice requires user intervention and therefore is not on the critical path for handoff. 5. Combined Handoff Method The combined method uses both PRE-REGISTRATION and POST-REGISTRATION handoff by running the PRE-REGISTRATION method and in parallel exchanging the POST-REGISTRATION handoff messages between oFA and nFA. The only case not considered already in the POST-REGISTRATION method is mobile-initiated handoff. In the mobile-initiated case, the Handoff Request message is initated by the oFA or nFA when it receives the Registration Request from the MN. The combined method follows the PRE-REGISTRATION Handoff when it is successful before the completion of the MN's L2 handoff. However, if PRE-REGISTRATION does not complete prior to the expiration of a timer on one or the other of the FAs, POST-REGISTRATION handoff is used. Using POST-REGISTRATION handoff insulates the MN from delays caused by errors such as loss of one of the Mobile IP messages involved in PRE-REGISTRATION. The start of POST-REGISTRATION is gated by the expiration of a timer on the FAs. The timer is started at oFA following a source-trigger, at nFA following the target-trigger, or at oFA and nFA following the receipt of the Registration Request from the MN in the mobile- initiated case. The timer is reset if the Registration Reply message is received by the appropriate FA and sent to the MN. Although the POST-REGISTRATION Handoff Request and Handoff Reply messages are exchanged in advance, no forwarding of traffic between oFA and nFA is performed unless the timer expires. The timer should be set to a value that allows forwarding between oFA and nFA to occur before the MN completes the L2 handoff to nFA. 6. Reverse Tunneling Support The handoff methods support reverse tunneling. The MN may request reverse tunneling [5] by setting the 'T' bit in its Registration Request. In the case of POST-REGISTRATION, if the MN had requested Reverse Tunneling previously at oFA, the Handoff message from oFA (see Sections 4.7 and 4.8) includes the 'T' bit enabled to inform nFA to establish a BET for the visitor entry. Typically, the 'T' bit will always be set to ensure that any delays in the MN receiving its new care of address do not result in any delay in uplink packet transmission from the MN, but local policies and particular L2 El Malki (Editor) et. al. [Page 30] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 technologies may allow the reverse tunnel to be turned off unless the MN specifically requests it. 7. Generalized Link Layer Address Extension This section defines the Generalized Link Layer Address (LLA) Extension, used by any node that needs to communicate Link Layer Addresses. The format of the extension follows MIER [7], and each sub-type of link-layer address defines its own sub-structure. This draft defines five sub-types. Future RFCs should allocate their own sub-type and define their own address formats. 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 | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length of the Link Layer Address + the one octet Sub-Type field Sub-Type This field contains the Link Layer sub-type identifier LLA Contains the Link Layer Address In this document, five subtypes are defined: 1 International Mobile Station Identity (e.g. [8]) 2 Ethernet 48 bit MAC address [9] 3 64 bit Global ID, EUI-64 [10] 4 Solicited IP Address 5 Solicited Access Point Identifier The following subsections describe the extensions. 7.1 IMSI Link Layer Address Extension The IMSI Link Layer Address Extension contains the International Mobile Station Identity. El Malki (Editor) et. al. [Page 31] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 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 | Sub-Type | IMSI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length of the IMSI field + the one octet Sub-Type field Sub-Type 1 IMSI Contains the IMSI, in the form: : Where the is an ASCII-based representation of the International Mobile Station Identifier, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same device. 7.2 Ethernet Link Layer Address Extension The Ethernet Link Layer Address Extension contains the 48 bit Ethernet MAC Address, as defined in [9]. 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 | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 7 (includes the Sub-Type field) El Malki (Editor) et. al. [Page 32] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Sub-Type 2 MAC Contains the 48 bit Ethernet MAC Address. 7.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension The 64-Bit Global Identifier (EUI-64) Address Extension contains the 64 bit address, as defined in [10]. 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 | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 9 (includes the Sub-Type field) Sub-Type 3 MAC Contains the 64-Bit Global Identifier Address. 7.4 Solicited IP Address Extension The 32-bit Solicited IP Address Extension contains the IP address of the agent (FA) being solicited. This extension MAY be present in an ICMP Agent Solicitation as explained in Section 3.3. 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 | Sub-Type | IP addr ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ El Malki (Editor) et. al. [Page 33] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Type TBD (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 4 IP Address Contains the 32-Bit IP Address of the solicited node. 7.5 Solicited Access Point Identifier Extension The 32-bit Solicited Access Point Identifier Extension contains an Identifier of the Access Point to which the MN will move. This may be a wireless L2 identifier. The MN is able to solicit an advertisement from the FA servicing a certain Access Point by using this extension with Agent Solicitations as explained in Section 3.3. 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 | Sub-Type | AP ID... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 5 AP ID Contains the 32-Bit Access Point Identifier. 8. IANA Considerations Section 7 introduces the Generalized Link Layer Address Extension numbering space that requires IANA management. This specification El Malki (Editor) et. al. [Page 34] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 makes use of the values 1-5, and all other values other than zero (0) are available for assignment via IETF consensus [14]. The numbers for the Generalized Link Layer Address Extension are taken from the numbering space defined for Mobile IP registration extensions defined in RFC 2002 [1]. These MUST NOT conflict with any numbers used in RFC 2002[1], RFC 2344 [5], RFC 2356 [12], RFC 2794 [13] and RFC 3012 [11]. In the POST-REGISTRATION Handoffs method, Sections 4.4 and 4.5 require numbers assigned from the Mobile IP control message type address space. The numbers assigned MUST NOT conflict with [1] and [2]. 9. Security Considerations A security consideration for PRE-REGISTRATION method involves changing the TTL for Router Advertisement messages sent between oFAs and nFAs, where multiple hops are present between oFA and nFA. The same applies to Registration Request messages sent by the MN to nFA routed through oFA and similarly Registration Reply messages. As discussed in Section 3.8, oFA and nFA must share a security association and oFA must be authorized to solicit nFA and relay Registration Request/Reply. In addition, the case involving tunneling of Agent Advertisements between the nFA and the MN requires restricitions to be relaxed so the TTL of the Router Advertisement is not required to be 1, as described in Section 3.4.2. Otherwise, PRE- REGISTRATION uses AAA-based security for both inter-domain and intra- domain handoff as described in [1] and [2]. Also, if the FA Challenge/Response mechanism in [11] is used then the MIN_SOLICITATION_INTERVAL must be set to a value smaller or equal to the CHALLENGE_WINDOW (in nFA) so that the nFA challenge does not expire before the MN issues the Registration Request. POST-REGISTRATION introduces a new change to Mobile IP, which is the possibility that a MN may receive packets from an FA with which it has not yet registered. In the event that the MN does not wish to receive packets from unknown FAs, it MAY drop them. In a similar way to PRE-REGISTRATION, oFA and nFA must share a security association required to protect the Handoff Request and Reply messages. Since the techniques outlined in this document depend on particular aspects of L2 handoff to optimize performance, some amount of L2 security is assumed. Both techniques depend on L2 triggers, and the security of handoff requires that the L2 triggers be secure. In addition, the POST-REGISTRATION technique depends on the ability of the wireless network to securely identify MNs. Although this document does not specify how FAs can identify or track MNs, it is assumed that the wireless L2 is sufficiently secure in order to correctly identify a MN. Wireless networks that do not provide such features will be subject to impersonation attacks, where malicious nodes could cause FAs to believe that a MN has moved to other service areas, and El Malki (Editor) et. al. [Page 35] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 to allow a bogus MN to obtain unauthorized service from an FA prior to performing a Mobile IP registration. The PRE-REGISTRATION technique instead depends on Mobile IP security between MN and FA, so the same security considerations in [1] apply. 9.1 AAA Considerations for Security For handoff between Administrative Domains (ADs), both techniques may experience additional latency if the MN must establish a security association with nFA prior to the handoff taking effect. For PRE- REGISTRATION, the need to establish a security association could delay the registration process so that no Registration Reply is received. For POST-REGISTRATION, it could result in the MN's traffic being delayed until the completion of a formal Mobile IP registration rather than as soon as the MN establishes an L2 connection at nFA. This section discusses an approach for reducing latency due to the need to establish a new security association. +-----+ +-----+ | AAA |-------------->| AAA | +-----+ +-----+ ^ | | | | AAA | | Hand-Off | | Req | | v +-----+ +-----+ | oFA | | nFA | +-----+ +-----+ +-----+ Movement +-----+ | MN | - - - - - - > | MN | +-----+ +-----+ Figure 11 - Inter-FA communication using AAA If the existing AAA infrastructure is used to establish dynamic security associations between FAs and HAs in different ADs, the same infrastructure could be used to establish the required security association for the purposes of inter-domain handoff as shown in Figure 11. Note that it is possible for geographically neighboring FAs owned by different ADs to have a pre-established security association, which would reduce the latency introduced by the AAA infrastructure traversal. Given that such geographically neighboring FAs MAY be small in number, such an approach MAY be reasonable. El Malki (Editor) et. al. [Page 36] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 10. References [1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional Tunnel Management ", draft-ietf-mobileip-reg-tunnel-03.txt (work in progress), July 2000. [3] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". BCP 14. RFC 2119. March 1997. [4] C. Perkins and D. Johnson, "Route Optimization in Mobile IP",draft-ietf-mobileip-optim-10.txt (work in progress), November 2000. [5] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. [6] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. [7] M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura, "Mobile IP Extensions Rationalization (MIER)", draft-ietf-mobileip-mier- 05 (work in progress), Dec. 1999 [8] TIA/EIA/IS-95-B [9] D. Plummer, "An Ethernet Address Resolution Protocol - or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics,Inc., November 1982. [10] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [11] C. Perkins, P. Calhoun, Mobile IP Challenge/Response Extensions. RFC 3012, November 2000. [12] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [13] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension", RFC 2794, March 2000. [14] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 El Malki (Editor) et. al. [Page 37] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 11. Authors' Addresses The authors may be contacted at the addresses below: Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 E-mail: Karim.El-Malki@era.ericsson.se Pat R. Calhoun Sun Microsystems Laboratories Sun Microsystems, Inc. 901 San Antonio Rd., UMTV 29-221 Palo Alto, California, 94303 USA Phone: +1 650 786 7733 Fax: +1 650 786 6445 E-mail: pcalhoun@eng.sun.com Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 979 7673 Fax: +1 630 979 7673 E-Mail: tom.hiller@lucent.com James Kempf Sun Microsystems Laboratories Sun Microsystems, Inc. 901 San Antonio Rd., UMTV29-221 Palo Alto, California, 94303 USA Phone: +1 650 336 1684 Fax: +1 650 691 0893 E-mail: james.kempf@sun.com El Malki (Editor) et. al. [Page 38] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 713 9359 Fax: +1 630 713 4982 E-Mail: mccap@lucent.com Ajoy Singh Motorola 1501 West Shure Drive Arlington Heights, IL o 60004 USA Phone: +1 847 632 6941 E-mail: asingh1@email.mot.com Hesham Soliman Ericsson Radio Systems Torshamnsgatan 29, Kista Stockholm SWEDEN Phone: +46 8 7578162 Fax: +46 8 4043630 E-mail: Hesham.Soliman@era.ericsson.se Sebastian Thalanany Motorola 1475 West Shure Drive Arlington Heights, IL - 60004 USA Phone: +1 847 435 9296 E-mail: sthalan1@email.mot.com The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Megisto Systems Inc. 6000 Connection Drive EMail: proberts@megisto.com Irving, TX 75039 USA Phone: +1 972-894-6709 El Malki (Editor) et. al. [Page 39] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 EMail: Raj.Patil@nokia.com Fax : +1 972-894-5349 12. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in anyway, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided onan "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." El Malki (Editor) et. al. [Page 40] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Appendix A - Gateway Foreign Agents The Mobile IP Regional Registration specification [2] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two FAs providing service to a MN have in common. Figure A.1 provides an example of a MN's initial registration through the GFA. If this is the first registration message, the message MUST be forwarded to the HA. All packets destined for the mobile will be delivered to the GFA, which in turn will forward the packets to the FA servicing the MN. Reg Req +-----+ Reg Req +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure A.1 - Initial Registrations through GFA If the MN moves to a nFA that is serviced by a GFA common with oFA, the MN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the HA, since the MN's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ Regional Reg +-----+ Regional Reg Figure A.2 - Regional Registration through GFA Note that the GFA may also be the MN's first-hop router. El Malki (Editor) et. al. [Page 41] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 A.1 GFA Considerations in the PRE-REGISTRATION Method When there is a hierarchy of foreign agents between the GFA and the announcing FA, the announcing FA MAY include the corresponding FA addresses in order between its own address (first) and the GFA address (last) in the Mobility Agent Advertisement extension of its Agent Advertisements. If there are only two hierarchical levels, a foreign agent announces itself and a GFA in the Agent Advertisement; in the first and last address in the care of address field in the Mobility Agent Advertisement extension. There must be at least one care of address in the Mobility Agent Advertisement extension. If there is only one care of address it is the address of the GFA, and the MN is connected directly to it. The MN needs to choose the appropriate HA address in the Regional Registration Request. The following two subsections discuss options. A.1.1 Mobility Agent Extension Advertises FA and GFA Address Only In this case, there is always a single path from the MN to the GFA. The MN always performs Regional Registrations using the GFA address as the HA address and the advertising FA as care of address. As the Regional Registration Request is relayed towards the GFA, each FA receiving it checks whether it has an existing binding with the MN and whether the Regional Registration has the "S" bit set to request simultaneous bindings. If this is true and the Regional Registration is validated by the GFA, the FAs activate the simultaneous binding upon receiving the successful Regional Registration Reply from the GFA. It is not necessary to advertise all FA addresses in the hierarchical branch to the MN, thus reducing bandwidth usage over the wireless link. A.1.2 Mobility Agent Advertisement Extension Advertises all FAs In specific cases where multiple regional FA levels and multiple paths from the MN to the GFA are present and are advertised, it may be necessary for the MN to identify the common route FA using the complete list of FAs in the hierarchical branch. It is assumed that the GFA advertises only one care-of address on all its interfaces towards the MN. The MN must cache the Mobility Agent Advertisement extensions for its active bindings. When it receives an advertisement from a previously unseen FA that has a different Mobility Agent Advertisement extension, it is eager to perform a new binding. The MN compares the IP addresses in the new Mobility Agent Advertisement extension with the cached Advertisements for its active bindings. If there is an IP address in common between these extensions, named the common route FA or GFA, the MN uses that IP address as the HA address and the destination address of its Regional Registration Request. In the case of a request for bicasting, the "S" bit is set. The care-of address El Malki (Editor) et. al. [Page 42] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 is the advertising FA's address. The MN adds a Hierarchical FA extension to the Regional Registration Request, in order to identify the regional FA path to be followed by the Request up the hierarchy. A Regional FA receiving a Regional Registration Request with it's own address as HA address returns a Regional Registration Reply to the MN. If there is no IP address in common between the extensions, then the MN has moved into a new hierarchy and the GFA advertised in the new extension is different from the one in the previously cached extensions. When the MN changes GFA, the MN uses the new GFA's IP address as care of address in its new Registration Request to the HA and adds the Hierarchical FA extension as described previously. If the MN has at least one existing active binding when it moves to the new GFA, it performs a low loss handoff as explained in this document. The MN is able to perform GFA registration during PRE-REGISTRATION handoffs only if its binding lifetime with the GFA or HA does not expire during the period needed by the MN to run PRE-REGISTRATION and complete its L2 handoff. Intermediate regional FAs are able to accept the MN's regional registration as simultaneous bindings only if the intermediate regional FA has an existing active binding for the MN. The resulting simultaneous binding therefore has a maximum possible lifetime equal to the lifetime remaining in its previously existing active binding. Once the registration lifetime with the GFA or HA is about to expire, the MN must perform a new Mobile IP registration with the HA. El Malki (Editor) et. al. [Page 43] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs For MNs that have two wireless network interfaces, either on the same wireless network or on wireless networks having different wireless L2 technologies, the techniques discussed in this draft may be unnecessary if the Mobile IP stack on the MN allows switching an IP address binding between interfaces. This Appendix discusses how multiple wireless interfaces can aid low latency handoff. Figure B.1 illustrates the normal and hierarchical MIPv4 models. As shown in the figure, assume that the MN is connected to Radio Network 1 (RN1) and is registered with oFA through which it is receiving traffic. Suppose MN enters the coverage area of RN2 and nFA and that it prefers connectivity to this network for reasons beyond the scope of this document (e.g. user preferences, cost, QoS available etc.). The MN activates the interface to RN2 but continues communicating through RN1. The MN may solicit advertisements from nFA through the interface connected to RN1 to speed up the handoff process, provided there is no TTL restriction, or it can solicit advertisements through the interface connected to RN2 if it has been configured for IP traffic. +------+ +---------+ | HA |--------| (GFA) | +------+ +---------+ / \ / \ ... ... / \ / \ +------+ +------+ | oFA | | nFA | +------+ +------+ | | +------+ +------+ | RN1 | | RN2 | +------+ +------+ +------+ | MN | ---------> +------+ Movement Figure B.1 - Network Model for Mobile IPv4 With Multi-Access Once the MN is registered with nFA and is successfully receiving and transmitting through the new network, it tears down the interface to El Malki (Editor) et. al. [Page 44] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 RN1. If the MN has enough time to complete this procedure without incurring degraded service or disconnection, the MN would experience a seamless multi-access handoff but it may not be possible in all cases, due to network coverage or for other reasons. Should multiple interface handoff be possible then the low latency methods described in this document are not necessary. In order to support the possible failure of the connectivity with the new network (RN2/nFA) in the short period following handoff, the MN may use the "S" bit in its Mobile IP Registration Request to maintain simultaneous bindings both its existing (HA or GFA) binding with oFA and a new binding with nFA. El Malki (Editor) et. al. [Page 45]