view Side-By-Side changes
Mobile IP Working Group MIPv4 Handoffs Design Team INTERNET-DRAFT Karim El Malki (Editor) Expires:November 2001April 2002 Pat R. Calhoun Tom Hiller James Kempf Peter J. McCann Ajoy Singh Hesham Soliman Sebastian ThalananyMayOctober 2001 Low LatencyHandoffHandoffs in Mobile IPv4<draft-ietf-mobileip-lowlatency-handoffs-v4-01.txt><draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt> 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 HandoffsMayOct 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.....................................................31.11.1. Terminology.................................................3 1.2................................................3 1.2. The Techniques..............................................5 1.3.............................................5 1.3. L2 triggers.................................................6 1.4................................................6 1.4. Requirements language.......................................8......................................9 2. Requirements.....................................................9 3. The PRE-REGISTRATION Handoff Method..............................93.13.1. Operation .................................................103.23.2. Network-Initiated Handoff.................................11 3.3.................................12 3.3. Mobile-Initiated Handoff..................................13 3.4..................................14 3.4. Obtaining and Proxying nFA Advertisements .................153.4.13.4.1. Inter-FASolicitation.................................15 3.4.2Solicitation................................15 3.4.2. Tunneled nFAAdvertisements...........................15 3.4.3Advertisements..........................16 3.4.3. Piggy-backing Advertisements on L2 messaging.........163.53.5. Caching Router Advertisements.............................16 3.6.............................17 3.6. Movement Detection and MN Considerations ..................173.7 Simultaneous Bindings .....................................17 3.83.7. L2 Address Considerations .................................183.93.8. Applicability of PRE-REGISTRATION Handoff.................19.................18 4. The POST-REGISTRATION HandoffMethod............................20 4.1 Operation .................................................20 4.2 Role of BETs ..............................................23 4.3 Foreign AgentMethod............................19 4.1. Two Party Handoff .........................................20 4.2. Three Party Handoff .......................................24 4.3. Renewal or Termination of Tunneling Service ...............29 4.4. When will the MN perform a Mobile IP Registration? ........30 4.5. MN Considerations..............................24 4.4.........................................30 4.6. Handoff Request (HRqst) Message...................................26 4.5format ....................31 4.7. Handoff Reply (HRply) Message.....................................27 4.6.............................33 4.8. Handoff To Third (HTT) Message ............................34 4.9. Applicability of POST-REGISTRATION HandoffMethod..........29Method .........35 5. Combined HandoffMethod.........................................30Method.........................................36 6. Layer 2 and Layer 3 Handoff timing Considerations...............36 7. Reverse TunnelingSupport.......................................30 7.Support.......................................37 8. Generalized Link Layer AddressExtension........................31 7.1Extension........................37 8.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension 38 8.2. 3GPP IMSI Link Layer Address Extension.........................31 7.2...................39 8.3. Ethernet Link Layer Address Extension.....................32 7.3....................39 8.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension..33 7.4.40 8.5. Solicited IP Address Extension............................33 7.5...........................40 8.6. Solicited Access Point Identifier Extension...............34 8. IANA Considerations.............................................34..............41 9.Security Considerations.........................................35 9.1 AAA Considerations for Security ...........................36IANA Considerations............................................42 10.References.....................................................37Security Considerations........................................42 11.Authors' Addresses.............................................38References.....................................................43 12. Authors' Addresses.............................................44 13. Full CopyrightStatement.......................................40Statement.......................................46 Appendix A - Gateway ForeignAgents................................41Agents................................47 Appendix B - Low Latency Handoffs for Multiply-InterfacedMNs......44MNs......48 El Malki (Editor) et. al. [Page 2] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 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 botha combined method using the two handoff techniques togetherareis presented. Section 6 discusses Layer 2 and Layer 3 handoff timing considerations. Section 7 discusses reverse tunneling support, while Section78 describestheprotocol extensions required by the handoff techniques. Sections8 and9 and 10 discuss IANA and security considerations.Two appendiciesFinally the two appendices discuss additional material related to the handoff techniques. Appendix Adescribes howgives a short introduction to RegionalRegistrationRegistrations [2]and simultaneous bindingswhich can be used together with low latencyhandoff.handoffs. 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.11.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. aFA - anchor Foreign Agent, the FA that is currently handling the network end of the BET in POST-REGISTRATION. 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. El Malki (Editor) et. al. [Page 3] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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 2001source 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 byegressingress filtering. Bi-directional edge tunnels are only needed in POST-REGISTRATION handoff. ping-ponging - Rapid back and forth movement between two wireless access points often due to failure of L2 handoff.Ping- pongingPing-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 HandoffsMayOct 20011.21.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 (new FA) 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 HandoffsMayOct 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 (old FA) and nFA (new FA) to utilize L2 triggers to set up aregistration on thebi-directional tunnel between oFA and nFAprior to receiving a formal Registration Request fromthat allows theMobile Node.MN to continue using its oFA while on nFA's subnet. This enables averyrapid establishment of service at the new point of attachmentto minimizewhich minimizes the impact on real-time applications. The MN must eventually perform a formal Mobile IP registration after L2 communication with the new FA isestablished. Security is handled by standard Mobile IP mechanisms, and both intra-domain and inter-domain handoff are supported. The techniqueestablished, but this can beused for inter-technology handoff but it requires the active involvementdelayed as required by themobile to switch from one network interfaceMN or FA. Until the MN performs registration, the FAs will setup and move bidirectional tunnels as required toanother.give the MN continued connectivity. The combined method involves running a PRE-REGISTRATION and a POST- REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can becompletedperformed 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 trafficdestined tofor the MN to the nFA as specified in the POST-REGISTRATION handoff method. This provides for a useful backup mechanism when completion of aPRE-REGISTRATIONPRE- 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.31.3. L2 triggers An L2 trigger isused toa signalsome event during the processof an L2handoff.event. In this document, the L2 events relate to the L2 handoff process. 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 alinktechnology specific trigger. Therefore, an L2 trigger that is made available to the El Malki (Editor) et. al. [Page 6] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001available to theMobile 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 provideno orlittle or no 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 describedin Sections 3 or 4 is performed.hereafter are initiated. El Malki (Editor) et. al. [Page 7] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001 +-------------+----------------------+------------------------------+ | L2 trigger |mobileMobile |sourceSource | | |pretriggerTrigger |triggerTrigger | | |(L2-MPT)(L2-MT) | (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 |targetTarget |mobileLink-Up |networkLink-Down | | |triggerTrigger |handoff|handoff| | | (L2-TT) |complete|complete| | | |(L2-MHC)(L2-LU) |(L2-NHC)(L2-LD) | |------------+------------------------+-------------+---------------+ | Recipient | nFA | MN|or nFA | oFA | |------------+------------+-----------+-------------+---------------+ | Method | PRE | POST | PRE & POST | POST | | | network | target |(optional)|(optional)| | | initiated | trigger | | | |------------+------------------------+-------------+---------------+ | When? | | when radio | when radio | | | same as |conditions | conditionslink between| link between | | | source trigger |are OK forMN & nFA is| MN and oFA |are OK for| | | established |MIP register| MIP registeris lost | |------------+------------------------+-------------+---------------+ | Parameters | oFA IP address id |none@MN: nFA IP |noneMN IP address | | | MN IP address id. | or L2 addr. | identifier | |------------+------------------------+-------------+---------------+ Table 1 - L2 Triggers1.4El Malki (Editor) et. al. [Page 8] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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 20012. Requirements The following requirements are applicable to low-latency handoff techniques and are supported by the methods in this document: - to provide low-latency and low loss handoff for real time services, - to minimize the effects at L3 of ping-ponging, - to have no dependence on a wireless L2 technology, - to support inter- and intra-access technology handoffs, - to 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,AppendexAppendix 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 El Malki (Editor) et. al. [Page 9] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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.13.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 1aand 1b contain a solicitation ofis a RouterAdvertisement by oFASolicitation (RtSol) fromnFA andoFA to nFA. Message 1b is areplyRouter (Agent) Advertisement (RtAdv) fromnFA.nFA to oFA. These messages SHOULD occur in advance of thePRE-REGISTRATIONPRE- REGISTRATION Handoff in ordertonot to delay the handoff. For this to occur, oFA MAY solicit and cache advertisements fromthe nFA,neighbouring nFAs, 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 atnFA,nFA (L2-TT), message 1b equals message 2b and is sent unsolicited directly to MN rather than relayed by oFA. 2. Message 2a is a Proxy Router Solicitation (PrRtSol). It is different from a normal Router Solicitation since it is actually soliciting an advertisement from a router different from the one receiving this message. The presence of message 2a indicates that the handoff ismobile- initatedmobile-initiated and its El Malki (Editor) et. al. [Page 10] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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 RouterAdvertisement.Advertisement (PrRtAdv). When message 2a is received by the oFA, the oFA returns the Proxy Router Advertisement (Agent Advertisement) in message 2b. In network-initiated handoff, the L2 trigger occurs at oFA and oFA relays theRouterAgent Advertisement in message 2b without the need for the MN to solicit. Note that it is also possible for nFA to advertise directly to the MN in thenetwork- El Malki (Editor) et. al. [Page 10] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 initiatednetwork-initiated target-trigger case (section 3.2). In all cases message 2b is simply nFA'srouteragent advertisement. 3. The MN performs movement detection upon receipt of either a solicited or unsolicitedRouterAgent Advertisement and, if appropriate, it sends a Registration Request (RegReq) message [1][2]in message 3 tonFA requestingnFA. When asimultaneous binding.local Gateway Foreign Agent (GFA) is present this message MAY be a Regional Registration Request (RegRegReq) [2]. Message 3 is routed through oFA since the MN is not directly connected to nFA prior to the L2 handoff. 4. Messages3,4 and 5constitute acomplete the standard Mobile IP Registration [1] or Regional Registration[2].[2] initiated with message 3. The Registration Reply in message 5MUSTSHOULD be copied by nFA to the MN both through oFA and directlyon- link.on-link. This is necessary, unless the L2/L3 interaction is engineered such that the MNmaydoes not detach from oFA until it has received the Reply. Since this will not always be the case, the Reply SHOULD be both tunneled by nFA to oFA and sent directlyon-link.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 Section7,8, as described in3.5.3.7. 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 orIf theHA are used to allow trafficRegistration is successful then packets for the MNto be sent to both the oFA and the nFA. Between the time when the Registration Reply is sentare now tunnelled fromHA or GFA to nFA and when the MN's connection on L2 at the nFA is fully established,the HAor GFA bicasts traffic for the MN to both oFA and nFA. The MN is able(or GFA) toreceive traffic independently of the exact L2 handoff timing. Also, should the L2 handoff procedure fail, terminate abruptly, or ping-pong,theuse of simultaneous bindings allowsnFA where the MNto maintain L3 connectivity with the oFA, smoothing the handoff.has moved to. 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.FiguresThe time at which the L2 trigger is received by the oFA or MN, thereby triggering the PRE-REGISTRATION handoff, compared to the time at which the actual L2 handoff occurs is important for the optimal performance of the low latency handoff. That is, in the optimal case El Malki (Editor) et. al. [Page 11] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 the L2 trigger will be received, the four messaging steps of PRE-REG described above will be completed and the first packet redirected by the HA (or GFA) to nFA will reach the MN at the moment in which the MN's L2 link to nFA is fully established. The MN would therefore not suffer any disruption due to the L3 handoff. This may require particular implementation techniques and deployment, such as L2 techniques, buffering and bicasting, but these are outside the scope of this document. In addition further handoff smoothing considerations may be required to prevent the loss of packets in- flight between HA (or GFA) and oFA while the MN performs a PRE- REGISTRATION handoff. These are also outside the scope of this document. Figures 2, 3, and 4 contain message timing diagrams for both the network-initiated and mobile-initiated PRE-REGISTRATION handoff procedures.3.23.2. Network-Initiated Handoff As described in Table 1, a PRE-REGISTRATION handoff can be initatedEl Malki (Editor) et. al. [Page 11] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001at 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'sthe IP address itself or an identifier which can be resolvedby the oFAto theMN'sIP 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. El Malki (Editor) et. al. [Page 12] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 MN oFA nFA HA/GFA | |<~~~~~~ L2-Source | | | | Trigger | | |<--------------------| | | | ProxyRtAdv | | | | | | | |---------------------------------------->| | |HA Reg.RegReq or | | | |RegReg (routedRegRegReg | |------------------->| | (routed viaoFA if preoFA) | |HA regRegReq orRegReg |RegRegReq| |L2 Handoff)| | | | | |<-------------------| | | |Reg Reply(Reg)RegReply | | | | | |<----------------------------------------| | |<--------------------|<------------------| | | |Reg Reply(Reg)RegReply | | ||(sent| (sent to MNthrough| |through oFA anddirectly)nFA) | 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 2001MN oFA nFA HA/GFA | | L2-Target~~~~~~~~>| | | | Trigger | | | | | | | |...................| | |<--------------------------------------- | | | (ProxyRtAdv) |...................| | | | Tunneled Agent | | | | Advertisement | | | | | | |---------------------------------------->| | |HA Reg.RegReq. or | | | |RegReg (routedRegRegReg | |------------------->| | (routed viaoFA if preoFA) | |HA regRegReq orRegReg |RegRegReq| |L2 Handoff)| | | | | |<-------------------| | | |Reg Reply(Reg)RegReply | | | | | |<----------------------------------------| | |<--------------------|<------------------| | | |Reg Reply(Reg)RegReply | | ||(sent| (sent to MN| |tunneled through oFA and also directly on-link) Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram (Network-Initiated, Target Trigger)3.3El Malki (Editor) et. al. [Page 13] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 3.3. Mobile-Initiated Handoff As shown in Table 1, a mobile-initiated handoff occurs when an L2 trigger is received at the MN informingitthat 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 resolvedby MNto 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 RouterSolicitation. TheSolicitation (PrRtSol). This message is either: - Unicast tonFA's IP address, in which case the procedure is a normal agent solicitation, apart from having a TTL greater than 1. - Unicast tooFA, in which case the solicitation is for a Proxy RouterAdvertisement.Advertisement (PrRtAdv). This solicitation MUST have a TTL=1 as in [1].Proxy- A normal Agent Solicitation [1] unicast to nFA's IP address, but having a TTL greater than 1. Both will have the same end result whereby the MN receives nFA's Router Advertisementsolicitationwith a Mobility Agent Advertisement extension (i.e. Agent Advertisement in [1]). Using the PrRtSol unicast to oFA isrequiredpreferred in many cases because the amount of topological distance between nFA and MN could preclude a fast enough delivery of the RouterAdvertisement sent in reply prior to an L2 handoff. ThisAdvertisement. In this case the PrRtSol is different from the Agent Solicitation in [1], where a TTL of 1 ismandated. El Malki (Editor) et. al. [Page 13] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001mandated, since the nFA will be more than one hop away from the MN. MN oFA nFA HA/GFA |<~~~~~ L2-Trigger | | | | | | ||-------------------->| ||-------------------->|(---------------->)| | | ProxyRtSol (to oFA or nFA) | | | | | || |<--------------------| ||<--------------------|(<----------------)| | | ProxyRtAdv|(from oFA or nFA) | | | | | | |---------------------------------------->| | |HA Reg.RegReq or | | | |RegReg (routedRegRegReq | |------------------->| | (routed viaoFA if preoFA) | |HA regRegReq orRegRegRegRegReq| | |L2 Handoff) || | | | |<-------------------| | | |Reg Reply(Reg)RegReply | |<----------------------------------------| | |<--------------------|<------------------| | | |Reg Reply(Reg)RegReply | | | ||(sent(sent to MNthrough| |through oFA anddirectly)nFA) | Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram (Mobile-Initiated) El Malki (Editor) et. al. [Page 14] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 The Proxy Router Advertisement solicitation unicast to oFA is an agent solicitation with a special extension. The solicitation MUST have an extension containing an IP address idenfifier because the MN is solicitingaanother 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 Section7.8. Two extension subtypes have been defined to contain the nFA's IP address and an access pointidentifieridentifier. 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'ssolicitation.PrRtSol message. As a result of theMN solicitationPrRtSol message, the oFA sends message 2b, the Proxy RouterAdvertisement,Advertisement (PrRtAdv), to the MN. TheProxy Router Advertisement containsPrRtAdv is simply the agent advertisement for the requestednFA.nFA, either sent directly by nFA (tunneled through oFA) or proxied by oFA. In order to expedite the handoff, as explained previously, direct proxying by oFA is preferred. Therefore the actual nFA advertisement SHOULD be cached by the oFA following a previous exchange with nFA, shown in messages 1a and 1b,andas specified in Section 3.5.El Malki (Editor) et. al. [Page 14] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 3.4The PrRtAdv message MAY contain the nFA's L2 address (using the LLA extension in 7.2) as described in sections 3.7 and 3.8. 3.4. Obtaining and Proxying nFA AdvertisementsIfSince L2 triggers are involved in initiating PRE-REGISTRATION handoff, the trigger timing SHOULD be arranged such that a full L3PRE- REGISTRATIONPRE-REGISTRATION handoff can complete before the L2 handoffinitiates.process completes. That is, the L2 handoff should beinitiatedcompleted after the MN's Registration with the nFAcompletes and produces a simultaneous binding at the GFA/HA.is performed (message 3 in Fig.1). 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 an agentadvertisementsadvertisement from the nFA through the old wireless accesspoint, and to perform a registration with the nFA through the old wireless accesspoint. Three ways of performing this are discussed in the following subsections.3.4.13.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 (PrRtSol) from the MN in the mobile-initiated case (see Section 3.3).Conceptually, onceEl Malki (Editor) et. al. [Page 15] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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).TTL=1 is not applicable here). The TTL limitation cannot be applied since oFA and nFA may be more than one hop away and since it is unnecessary for a unicast message in any case. Security between oFA and nFA should be in place to ensure thatagentsolicitations 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.23.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 ofthe Proxy Router Solicitationa router solicitation (PrRtSol) from the MN in the mobile-initiated case (see Section 3.3). A router solicitation from MN directly to nFA must reach nFA and identify the oFA, so the solicitationmustMUST include an extension containing an IP addressidentifier.identifier (see section 8). This can be either oFA's IP address or an Access Point identifier which may be specific to theEl Malki (Editor) et. al. [Page 15] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001underlying wireless technology. As a result of thetunneledsolicitation, the nFA sendsa Routeran Agent 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 restrictionapplies ifexists since the TTL must be 1 onRouterAgent 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.33.4.3. Piggy-backing Advertisements on L2 messaging Piggy-backing advertisements on L2 messaginginvolvesconsists in utilizing the L2 messaging involved in L2 handoff to transmit theRouterAgent Advertisement from the nFA to the MN or oFA. When the first L2 handoff triggers (i.e. L2-ST, L2-TT) or MN PrRtSol messages areexchanged,received which inform of a MN's upcoming movement to a certain nFA, it may be possible to transmitaRouterAdvertisement piggybackedSolicitation/Advertisements between FAs by piggybacking them onto L2 messages. Alternatively, the L2 at oFA may only perform this the first time and cache nFA's advertisementsand not need to receive Router Advertisements upon every L2 handoff initiation.for as long as they are valid (see section 3.5). El Malki (Editor) et. al. [Page 16] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 Whether this technique ispossibleapplicable depends on the particulars of the L2 technologyand iswhich are outside the scope of this document.3.53.5. Caching Router Advertisements If done during a handoff, message exchange 1 in Figure 1imposesmay impose an additional latencypenaltyon 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][9] 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.63.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 detectionmechanisms. Themechanism: the MN MUSTbe: -be "Eager" to perform newbindings, - "Lazy" in releasing existingbindings.The aboveThis 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 theThe MNMUST NOT release existing bindings until it no longer receives advertisement from the old FA and the lifetime ofalso needs to change itsexisting 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 thedefault router from oFA to nFA. The MN MUST change its default router tocancelnFA as soon as theregistration. 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 fromL2 handoffand 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, thehas completed. The MNMAY perform registrations with the HAcan identify this event usingsimultaneous bindings. This isthe L2-LU trigger described in[1] and the methodTable 1. How toanticipate MN movement by interacting withdetermine thewirelessL2is described in Section 3.6. However, having multiple simultaneous bindingsaddress for theMN 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 HAdefault router isclose to the FAsdescribed inquestion. Also, if the round-trip time between the HA and FAs is not negligible,theMN's new Registration and therefore L3 handoff can be delayed.next section. El Malki (Editor) et. al. [Page 17] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001If a GFA is present, low loss handoff is achieved by bicasting traffic from the GFA to the oFA and the nFA while3.7. L2 Address Considerations Some special considerations should be taken with respect to theMNwireless system on which this handoff method ismoving between them. Thebeing implemented. Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In PRE-REGISTRATION the MNsetsis registering with an FA (nFA) that is not its current first-hop router, therefore the"S" bit inL2 address of the Ethernet frame containing the MN's Registration Request[2]. When a Regional Registration Request hasreaching the"S" bit set,nFA is not thereceiving regional FA or GFA that has an existing binding withMN's address. Therefore theMN addsFA MUST NOT use therelevant new binding forEthernet address of theMN but also maintains any existing bindings it has forincoming Registration Request as theMN, bicasting trafficMN's L2 address as specified in [1]. This applies to theMN at both FAs. If the MN has simultaneous active bindings with FAs, it could (but preferably should not) receive multiple copies ofcases where thesame traffic directed to it. The usewireless access points are bridges or routers and independently ofsimultaneous bindings does not mean thatwhether theMNFA isreceiving packets contemporarily from multiple sources. This depends on the characteristics ofimplemented in the wireless access(L2) technology. The bicasting of packets involves sending a copy ofpoints themseves. In this case thedataMN's Registration Request (or Regional Registration Request) SHOULD use an L2 address extension to theFA whichRegistration message when the MN ismoving to. Untilperforming a registration. To communicate its L2 address, the MNactually completes the L2 handoff toincludes a Generalised Link Layer Extension (see Section 8.3) with its Registration Request (or Regional Registration Request) message. If this extension is present thenewFAand fully establishesMUST use thenewL2link,address contained in thenew 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 dueextension tounavailability of direct layer connectioncommunicate 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 onFor the samelink as the MN,reasons, in these cases the MNMAYMUST NOT usean 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 source L2 address of theframe containing the MN's registration packet is not MN's address. The MN must use some means to communicateAgent Advertisement message (PrRtAdv) as its default router's L2address other than the frame address, which is the method specifiedaddress. Therefore in[1]. To communicate its L2 address,this case theMN includesoFA/nFA SHOULD include a Generalised Link Layer Extension (see Section7)8.3) with itsregistration. The FA uses the L2 address inAgent Advertisement or PrRtAdv messages. In theextension to communicate withcase of theMN. IfMN's Registration Request, 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 L2El Malki (Editor) et. al. [Page 18] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001address without the need to use the extension, the L2 address extension is not needed.3.93.8. Applicability of PRE-REGISTRATION Handoff The PRE-REGISTRATON Handoff method is applicable to scenarios where a period of service disruption due to layer 3 is not acceptable, for example when performing real-time communications, and therefore where an anticipation of the layer 3 handoff is required. 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. it is its own address) the PRE-REGISTRATION handoff should not be initiated. El Malki (Editor) et. al. [Page 18] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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 benecessaryefficient 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 due to servicecost,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. 4. The POST-REGISTRATION Handoff Method The POST-REGISTRATION handoff method uses bi-directional edge tunnels (BETs) to perform low latency change in the L2 point of attachment for the MN without requiring any involvement by the MN. Figure 5 illustrates the basic POST-REGISTRATION handoff. +------+ | CN | +------+ | ... | +------+ BET +------+ | aFA |==========| nFA | +------+ +------+ | wireless link | movement +------+ ---------> | MN | +------+ Figure 5 - POST-REGISTRATION Concept El Malki (Editor) et. al. [Page 19] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 20014. The POST-REGISTRATION Handoff Method The POST-REGISTRATION handoff method is based onFollowing anetwork-initiated model of handoff. The technique does not require anysuccessful Mobile IP Registration between MNinvolvement untiland oFA, theactual L2 connection with nFA is completed. TheoFAand nFA perform a message exchange that allowsbecomes the mobility anchor point for the MN, called the anchor FA (aFA). When the MN moves from oFA toestablish a temporary registration onnFA, rather than performing signaling over thenFA untilwireless link to register with the nFA, the MNperforms a formal Mobile IP FA registration. The technique derives its name becausecan defer theregistration occurs after L2L3 handoffis complete. POST-REGISTRATION makes use of bi-directional edge tunnels (BETs)and continue tosmooth packet delivery whileuse it's aFA (i.e. oFA in this case). If the MNis in transition between oFA and nFA. Ifmoves to a third FA before registering with the nFA, the third FAdetermines that there is no change insignals aFA to move theFA, based onwireless link end of theL2 trigger information, thenBET from nFA to it. The network end of the BET remains anchored at aFA until the MN performs thePOST-REGISTRATION handoff procedures are not initiated. POST-REGISTRATION depends on standard AAA-basedMobile IPsecurity [13], but for true low-latency handoff, pre-established security associations between FAs are necessary. In summary, POST- REGISTRATIONRegistration. 4.1. Two Party Handoff Two party handoffcovers new cases that are not addressed byoccurs when theframework in [1]. 4.1 OperationMN moves from oFA, where the MN performed a Mobile IP Registration, to nFA. In thePOST-REGISTRATION method,normal case, this movement would result in a new Mobile IP Registration at nFA. However in POST-REGISTRATION, theFA issues handoff messages on behalf ofMN and nFA MAY delay this but maintain connectivity using theMobile Node, acting as a surrogate of sorts.BET between oFA and nFA. TheFA becomes aware that a handoffprotocol isabout to occur atshown in Figure 6. 1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT | oFA |<-------->| nFA | 4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU ^ ^ old L2through| | new L2 +-------+ +-----+ | | | | V V +------+ movement 4c) L2-LU ---> | MN | ---------> +------+ Figure 6 - Two Party Handoff (POST-REGISTRATION) The following describes theuseprogress ofan L2 trigger. An FA can receivea twotypes of triggers,party handoff. The numbered items refer to steps in Figure 6. To identify the difference between a sourcetrigger at oFA andtriggered HRqst/HRply message for BET creation, a targettrigger at nFA. Section 1.1 and Table 1 contain more details about source and target triggers. Figures 5 and 6 containtriggered HRqst/HRply messagesequencesforsourceBET creation andtarget triggered POST-REGISTRATION handoff, respectively. Figures 7 and 8 contain message timing diagrams forHRqst/HRply to extend or terminate a BET, the messagesequences in Figures 5 and 6. In Figure 5, a source trigger is obtainedwill be identified respectively by (s), (t) and (r). 1) Either the oFAwhenor nFA receives an L2detectstrigger informing it thatthea certain MN is about todepart its coverage area. In Figure 6, a targetmove from oFA to nFA. The two cases are: a) The L2 trigger isobtained bya source trigger (L2-ST) at oFA. The trigger contains thenFA whenMN's L2detects that the MN has just arrived in the coverage area of the nFA prior to the completion of theaddress and an IP identifier (the IP address itself or an L2handoff. Noteaddress thatboth triggers are available before the actual completion ofcan be resolved to thelink 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 HandoffIP address) for nFA. El Malki (Editor) et. al. [Page 20] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001+-----+ 1.b) The L2 trigger is a target trigger (L2-TT) at nFA. The trigger contains the MN's L2 address and an IP identifier for oFA. 2) The FA receiving the trigger sends a Handoff Request+-----+ | | <----------------- | | |(HRqst) to the other FA. There two cases: a) If 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 differenceisin the initiator ofsending theHandoff Request message. In bothHRqst, thesourceH bit is set andtarget trigger cases,the N bit is unset, indicating it is anFA obtains link-layer information that indicatesHRqst(s). The HRqst(s) contains thenecessitylifetime ofa handoff tothenFA. Intunnel theevent of a source trigger,oFAtransmits a Handoff Request messageis willing tonFA. The Handoff Request MUST includesupport, theMN'shomeaddress,network IP address of the MN, the MN's HAaddress, remaining registration lifetime,address anda Generalized Link-Layer Address Extension (see Section 7)an LLA option with the MN's L2 address.Upon receipt of the message, nFA MUST createIf theMN's visitor entry,lifetime is zero andrespond with the Handoff Reply message. Intheevent of a target trigger,T bit is not set, thetrigger occurs on nFA,oFA is not willing to tunnel any packets for MN. A positive lifetime andnFA transmitsaHandoff Request to oFA. The Handoff Request message MUST includeset T bit indicate that theMN's L2 address in a Generalized Link-Layer Address Extension (see Section 7) in order foroFA is willing tocorrectly identifytunnel for theMN. The request message MAY include additional MN information, if such information was provided byindicated time. Section 4.6 describes theL2. Upon receipt ofHRqst(s) and Section 8 describes therequest, oFA MUST respond withLLA option. b) If nFA is sending theHandoff Reply message, includingHRqst, theMN's home address, HA address, remaining registration lifetimeN bit is set anda Generalized Link-Layer Address Extension withtheMN's link layer address. El Malki (Editor) et. al. [Page 21] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 MN oFAH bit is unset, indicating it is an HRqst(t). If the T bit is set, nFAHA/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 performhas requested afull FAreverse tunnel andHA/GFA registration. A trigger that signalsthecompletionHRqst(t) contains the lifetime of thehandoff, 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. Iftunnel theMN receives an L2-MHC trigger, it SHOULD send a Router Solicitation message. The Router Solicitation causesnFAto send a Router Advertisement, allowingis requesting. The HRqst(t) also contains an LLA option with theMN to perform a complete MobileMN's L2 address. The MN's home network IPor Regional Registration. Alternatively, ifaddress and HA address are not sent, unless they are discovered by some means outside thenFA receivesscope of this document (for example, as part of theL2-NHC trigger, nFA SHOULD sendL2-TT). Section 4.6 describes the HRqst(t). 3) The FA receiving the HRqst sends aRouter Advertisement, allowingHandoff Reply (HRply) to theMNother FA. There are two cases: a) If oFA is sending the HRply, the N bit is set and the H and R bits are unset, indicating that the reply is in response toperformacomplete Mobile IP or Regional Registration.HRqst(t), i.e. it is an HRply(t). If the T bit is set, the HRply(t) contains the tunnel lifetime the oFA is willing to provide, otherwise, the tunnel lifetime is set to zero, indicating that the oFA is not willing to provide tunnel service. TheL2-MHCHRply(t) also contains the MN's home subnet IP address, the MN's HA address, andL2-NHC triggers are optional.an LLA option containing the MN's L2 address. Section 4.7 describes the HRply(t). b) IftheynFA is sending the HRply, the H bit is set and the N and R bits arenot available,unset, indicating the reply is in response to a HRqst(s), i.e. it is an HRply(s). If the T bit is set, theMN MUST wait untilnFAsendsindicates that it requests aperiodic Agent Advertisementreverse tunnel, andMUST respond by registeringthe lifetime field is set withnFA.the requested tunnel lifetime. The T Bit can be set in HRply only if the oFA had set the T bit in the corresponding HRqst or if the nFA requires to reverse tunnel incoming packets to oFA because El Malki (Editor) et. al. [Page22]21] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001MN oFAingress filtering is enabled on its network. The tunnel lifetime requested by the nFAHA/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,must be less than orBETs, are used to achieve low loss of trafficequal toand fromtheMN during a handoff and to smooth handoff when an MN undergoes ping-ponging. Thetunnelfrom nFA back tolifetime offered by oFAallowsin the HRqst(s). Section 4.7 describes the HRply(s). 4) The point during the L2 handoff in which the MNto use its old care of address prior to registering with nFA. If this tunnelisnot established, the old careno longer connected on a certain link is signaled by an L2-LD trigger at oFA and MN. Completion ofaddress cannot be used because itL2 handoff istopologically incorrectsignaled by an L2-LU trigger at nFA andmayMN. Each node handles the triggeregress filtering in nFA's subnet, resultingin theMN's packets being dropped. Figure 9 provides an example of a BET. The BET is placed whenfollowing way: a) When the oFAissues a successful Handoff Reply to nFA, orreceivesa successful Handoff Reply from nFA. This causes oFA to forwardtheMN's traffic toL2-LD trigger, it begins forwarding MN-bound packets through the forward tunnel (BET) to nFA.Theb) When the nFAforwardsreceives thetraffic furtherL2-LU trigger, it begins delivering packets tunneled from the oFA to the MNif an L2 connection exists. Inand forwards any outbound packets from MN to the next hop using normal routing mechanisms or through the reversedirection, as soon astunnel to oFA or HA. c) When the MNcomes up onreceives theL2 connection with nFA,L2-LU, it canstart sending packets withintiate theold 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 LatencyMobileIPv4 Handoffs May 2001 Data +-----+ Data +----+ +------------>| oFA |<--------------------------| HA | | +-----+ +----+ v ^ ^ +----+ Handoff | | Data | MN | Request | | +----+ | | ^ v v | +-----+ +------------>| nFA | Data +-----+ Figure 9 - Bi-CastingIP Registration process bythe Foreign Agent 4.3 Foreign Agent Considerations Upon receipt of a trigger event,soliciting anFA SHOULD issue a Handoff Request message to the FA to which or from which the mobile is being handed off.Agent Advertisement as described in [1]. If themessageRegistration is successful theresult of a target trigger, the Type Of Trigger bit innFA takes over theHandoff Request message MUST be set androle of anchor FA (aFA) from theGeneralized Link-Layer Address Extension (see Section 7) MUST be present.oFA. 5) Thesender of the Handoff Request is nFA andoFA becomes an aFA if the MN moves to a third FA before having performed a Mobile IP Registration with nFA. 6) Should L2 handoffis target triggered. The message's home addressfail in Step 4 (due to L2 reasons) andHA address fields MAYa ping- pong situation arise, the oFA may besetable toNULL ifdetermine thisinformation is not known atcase through thetimetrigger mechanism (i.e. FA sees successive L2-ST/L2- TT followed by L2-LD and then L2-LU). The FA which originated themessage is transmitted. Upon receipt of a Handoff Request message withHRqst can in this case cancel theType Of Trigger bit set,BET by sending an HRqst(r) to theoFA MUST respondother FA withthe Handoff Reply message. The Handoff Reply MUST include both the MN's home address and HA address. The MN's remaining registrationlifetimeMUST be includedzero. It will then simply continue delivering packets to MN exactly as if no handoff had been pending. Section 4.6 describes the HRqst(r). If in theHandoff Reply's lifetime field. Furthermore,HRqst/HRply the oFAissuinghas set theHandoff Reply MAY include any security associations that were dynamically created. The oFA that issuesB bit and the nFA has not requested aHandoff Reply withreverse tunnel by setting theCode field set to success (zero value) MUST bi-cast allT bit, the nFA SHOULD tunnel outgoing packetsdestined tofrom the MN toboththeL2 to whichHA because the MNis currently connected and by tunneling to the nFA.The oFA must also be prepared to receive tunneled packetshas requested this service from the oFA. The nFAin whichSHOULD offer this service only if either no security between theMN's packets appear withnFA and theold careMN's HA is required, or there is an existing nFA-HA security association in place. The actual timing ofaddress.BET placement depends on the available L2 triggers. ThenFA 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 packetsforward tunnel from oFA to nFA is constructed using one of theMN prior to receiving a Registration Requesttunneling procedures described in [1]fromfor theMN, and it MUST be preparedHA to FA tunnelpackets sent bywith theMN underdifference that theMN's old careends ofaddress to oFA. Note that it is possible fortheencapsulation method used betweentunnel are at the oFA andnFA to be different from the one requested by the MN duringEl Malki (Editor) et. al. [Page24]22] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001its Registration process. When this occurs,nFA, respectively. The reverse tunnel from nFA to oFA is constructed as described in [4] with therespective FAs MUST perform encapsulation translation. An FAdifference thatreceives a source trigger MUST send a Handoff Request message withtheType Of Trigger bit disabled. The sendernetwork end of theHandoff Request messagetunnel is at the oFAandinstead of the HA. With optimal L2 trigger information, as described above, the FAs can setup the BET immediately when the L2 handoff issource triggered. The message MUST also includeinitiated, start tunneling MN- bound data when theMN's home address,link to theHA addressMN goes down and theLink Layer Address extension (see section 7). The MN's remaining registration lifetime MUST be included innFA can use thelifetime field. The oFA MAY also include any security associations that were dynamically created. Upon receiptlink up trigger to start delivering packets. In the absence ofa Handoff Request withoptimal L2 trigger information, theType Of Trigger bit disabled,HRply can act as thenFA MUST processtrigger to start tunneling MN-bound data, but in this case, the period of packetand respond withdelivery disruption to theHandoff Reply message. If successfully processed, the nFA MUST create a visitor entry for the MN,MN may still be present and additional measures may bepreparedrequired todeliver tunneledprovide uninterrupted service. Additonally, particular implementation and deployment scenarios may require that techniques be employed to smooth handoff by providing a means to convey packetsreceivedarriving during the L2 handoff. The exact techniques involved in smoothing are currently under discussion by theinitiator ofworking group and are outside theHandoff Request destinedscope of this document. Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) two party handoff, respectively. MN nFA oFA | | | | | HRqst(s) |<~~~ L2-ST | |<------------------| | | HRply(s) | | |------------------>| | | | --------------------------------------------<~~~ L2-LD L2 Handoff --------------------------------------------<~~~ L2-LU | | | |<------------------->| | | MN's traffic | | Figure 7 - Two Party Source Trigger Handoff Timing El Malki (Editor) et. al. [Page 23] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 MN nFA oFA | | | | L2-TT ~~~>| HRqst(t) | | |------------------>| | | HRply(t) | | |<------------------| | | | --------------------------------------------<~~~ L2-LD L2 Handoff --------------------------------------------<~~~ L2-LU | | | |<------------------->| | | MN's traffic | | Figure 8 - Two Party Target Trigger Handoff Timing Once theMN,BET between aFA andto tunnel packets fromtheMN sent under its old carecurrent FA is in place, it is torn down by one ofaddres totheoFA.following events: 1) TheHandoff Reply message MUST includeaFA decides to stop tunneling because thehome address, HA address,lifetimevalue,it sent expires and was not renewed, or theGeneralized Link-Layer Address Extension (see Section 7)aFA or current FA decide to terminate tunnel service prematurely for some other reason (refer to section 4.3). 2) The MN completes the process by performing a Mobile IP Registration with theMN'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 alsocurrent FA. This may beprepared to receive packets sent by the MN under its old care of address on the new L2 that are tunneledinitiated bynFA. Once a visitor entry has been created in nFA, and the MN establishes an L2 connection withthenFA, its traffic will be immediately delivered, along withFA which sends an Agent Advertisementmessage [1]. The nFA can determine when to send the Agent Advertisementor by theL2-NHC trigger. If theMNreceives an L2-MHC trigger, it can sendwhich solicits for an Agent AdvertisementSolicitation. Alternatively, if neither L2 trigger is available, theas in [1]. 3) The MNwill respondmoves to aperiodic Agent Advertisement sent according to [1].third FA (see section 4.2) 4.2. Three Party Handoff Inany case, the MN can continueaddition touse its old care of address without any delay in uplink L3 connectivity until it is established on the new L3 sincethenFA tunnels its packets back totwo party handoff, theoFA. An MN MUST issueFAs implementing POST- REGISTRATION MAY perform aRegistration Requestthree party handoff which requires an additional message. Three party handoff is applicable whenit receivesanAgent Advertisement from the nFA, completing the L3 handoff. NoteMN thatthe nFA MAY delay sendinghas already established anAgent Advertisement, especially to reduce noticeable service disruption during a ping- pong. However, when doing so, the nFA MAY needaFA and is receiving tunneled packets through its current FA moves tore-issuea newHandoff Request to oFA, to extend the visitor entry's lifetime. In the event that the visitor entryFA without performing a Mobile IP Registration. The need foran MN at nFAthis function depends on the wireless system in which POST-REGISTRATION isabout to expirebeing implemented. Certain wireless systems andthe MN hasimplementations do notyet issued a Registration Request, the nFA hasallow such fast movement between FAs and may force theoption to transmit a new Handoff Request messageMobile IP Registration to occur soon after L2 handoff, in which case three party handoff is not applicable. If theoFA to renewthis three party handoff feature is not implemented, theregistration. WhetherFA SHOULD send an Agent Advertisement to therenewal is performed on behalf ofMN after L2 handoff has completed (L2-LU at nFA) and/or the MNisSHOULD solicit apolicy decision up to the network administrator.Router Advertisement after L2 handoff (L2-LU at MN). El Malki (Editor) et. al. [Page25]24] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001An FA MAY receive packets for+------+ +--->| aFA |<---+ | +------+ | 4b) HRqst(r) | | 3) HRqst(t) HRply(r) | | HRply(t) | | v 2a) HRqst v 1a) L2-ST ~~~> +------+ HTT +------+ <~~~ 1b) L2-TT | oFA |<-------->| nFA | 4a) L2-LD ~~~> +------+ 2b) HTT +------+ <~~~ 5a) L2-LU ^ HRply ^ old L2 | | new L2 +-------+ +-----+ | | | | V V +------+ movement 5b) L2-LU ~~~> | MN | ---------> +------+ Figure 9 - Three Party Handoff The L3 handoff can be deferred either because of a decision by the MN/FA (i.e. MNto which itdoes nothave a direct link layer connection. Thesend Router Solicitations and FAMAY: - drop all packets for the MN,does not send Agent Advertisements) or- buffer packetsit may result from rapid movement between oFA and nFA that does not allow enough time for theMN. The choice of which actionregistration totake may depend on the type of traffic involved, but thiscomplete. This scenario isoutside the scope of this document. The MN MAY alsoshown inparallel attempt to establish a link-layer connection withFigure 9. In this case, oFA must inform nFA (i.e. theMN. An FA MUST NOT send ICMP Destination Unreachable messages if it drops packets or is unablethird FA) todelivercontact aFA about moving thereceived IP packets due to unavailabilityradio end ofdirect layer connectionthe tunnel. This is performed with theMN. Given that a MN's packets will be delivered prior to a proper registration,Handoff To Third (HTT) message. The general idea behind theMN MAY discard all packets received from FAs with which it has not registered. Whenthree party handoff procedure is that the oFA supplies nFAreceives the MN's Registration Request [1] andwith theHA's or GFA's successful Registration Reply [1][2],same information itMUST transmit a Handoff Request messagewould have obtained via an L2-TT if handoff had occurred from aFA to nFA, then theoFAnFA performs an HRqst(t)/HRply(t) sequence withthe lifetime field setaFA in order tozero. An oFA that receives a Handoff Request withmove thelifetime field setBET tozero 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, sincenFA. When theMNL2 handoff isnow fully connected at L3 oncomplete, oFA sends an HRqst(r) to aFA to terminate thenew subnet.previous BET. TheoFA MAY issuefollowing describes the progress of aHandoff Requestthree party handoff. The numbered items refer tothe nFAsteps in Figure 9. 1) Either thefuture ifoFA or nFA receives an L2 trigger informing itwishes to keep receiving the mobile's packets for possible delivery. 4.4 Handoff Request Message The Handoff Request message is used to inform a peerthat aPOST- REGISTRATION handoffcertain MN isbeing initiated. The Handoff Request message canabout to beused for both source and target triggers, through the Type of Trigger 'I' bit in the message flags. When sent as a result ofmoved. The two cases are: a) The L2 trigger is atarget trigger,source trigger (L2-ST) at oFA. The trigger contains thehomeMN's L2 address andHA fields MAYan IP identifier (IP address or L2 address that can besetmapped tozero (unless this information was communicated by the link layer, whichan IP address) for nFA. b) The L2 trigger isoutsidea target trigger (L2-TT) at nFA. The trigger contains thescope of this document).MN's L2 address and an IP identifier El Malki (Editor) et. al. [Page26]25] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 20010 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 bothfor oFA. 2) The oFA and nFAwill 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), whileexchange avalue of oneHTT/HRply or HRqst/HTT pair. HTT isa target trigger (request sentindicated bynFA). M, G, T As definedsetting both the H and N bits in[1,5]. This refers tothe HRqst or HRply. The HTT message MUST NOT have any tunnel flags set, because the tunnel is negotiated between the aFA and nFA, not oFA and nFA.LifetimeThere are two cases: a) Therequested Lifetime for whichL2 trigger is an L2-ST. The oFA sends HTT to nFAwill servecontaining theMN on behalf of oFA, without requiring a new registration. MN Home Address TheMN's homeaddress ofIP address, theMN. When using a privateMN's HA address, an LLA containing theG and T flags must be sentaFA's IP address, anda GRE Key extension must be included. HA Addr The HAan LLA containing the L2 address of themobile node. Identification As in defined in [1]. ExtensionsMN. This is enough information for nFA to perform a target triggered handoff with aFA. TheMessage MUST include LLA (seenFA responds with a HRply(s). Section7) and4.8 describes theFA-FA Authentication Extension [2]. 4.5 Handoff Reply MessageHTT. b) TheHandoff Reply messageL2 trigger issent in responsean L2-TT. The nFA sends HRqst(t) tothe Handoff Request message. WhenoFA, exactly as if asource trigger caused the Handoff Request message to be sent,two party handoff were occurring. The oFA responds with HTT containing theHandoff Reply messagesame information as in a) above. This issent withenough information for nFA to perform asuccessful code iftarget triggered handoff with aFA. 3) Upon receipt of the HTT, the nFA first checks its VisitorEntry was successfully created. WhenCache to see whether it is already tunneling for MN. If so, Step 6 is performed. If not, nFA performs a target triggered handoff with aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t) pair. Because aFA receives no L2 triggerEl Malki (Editor) et. al. [Page 27] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs May 2001 caused the Handoff Request message, receiptindicating when L2 handoff starts, it may start tunneling to nFA upon transmission of theHandoff Reply message with a successfuly code SHOULD causeHRply(t). 4) Once theVisitor EntryL2 handoff is underway and the MN gets disconnected at L2, aFA and oFA exchange messages canceling tunnel service between aFA and oFA and allowing aFA tobe 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,start theLifetime field is set totunnel with nFA. a) The point in thenumber of seconds remaining beforeL2 handoff process where theregistrationMN gets disconnected from oFA isconsidered expired. A value ofsignaled at oFA by L2-LD. b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime zeroindicates 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 bothwith aFA. This cancels tunnel service between oFA andnFA will attempt to deliver datagrams directly to MN, ifaFA. If aFA has not already established alink-layer connection exists. I Typetunnel to nFA, it must do so immediately upon receipt ofTrigger. A valuethe HRqst(r). The aFA provides tunneling service exactly as described in Section 4.1 Step 4a. 5) Completion ofzeroL2 handoff isa source trigger (reply sentsignaled bynFA), while a value of one is a targetan L2-LU trigger at nFA and/or MN. The nFA and MN handle the trigger(reply sent by oFA). M, G, T As definedin[1,5]. This refersthe following ways: a) The nFA provides packet delivery service to thetunnel between oFA and nFA. El Malki (Editor)MN exactly as described in Section 4.1, Step 4b. El Malki (Editor) et. al. [Page28]26] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001MN Home Addressb) Thehome address ofMN either defers or initiates Mobile IP Registration when it receives themobile node. When using a private address,L2-LU, as in Section 4.1 6) In theG and T flags must be sentspecial case where nFA anda GRE Key extension must be included. HA Addr The HA address ofaFA are themobile node. Lifetime The requested Lifetime for which nFA will servesame (i.e. the MNon behalf of oFA, without requiring a new registration. Identification As in definedis moving back to the original anchor FA), aFA recognizes that it is tunneling to oFA when it checks its Visitor Cache in[1]. Extensions The Message MUST include LLA (see Section 7) andStep 3. In this case, there is no need for aFA to send theFA-FA Authentication Extension [2]. 4.6 ApplicabilityHRqst(t)/HRply(t) in Step 3. Upon receipt ofPOST-REGISTRATION Handoff Method The POST-REGISTRATIONthe L2-LU trigger on handoffapproach allows FAscompletion, the aFA begins routing packets tocommunicate directly about a pending handoff,MN anddoes not require any IP layer messages to be sentthe tunnel toor fromnFA is torn down. The oFA still exchanges the HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know aMN prior topriori that aFA and nFA are the same, but they are redundant. Unlike two party handoff, the timing of BET establishment between aFA and nFA cannot fully depend on the availability of L2handoff event. Therefore, ittrigger information because aFA does not receive an L2 trigger signalling L2 handoff. The two timing extremes at which aFA can place theMN's IP stack or Mobile IP client implementation onBET with nFA are: 1) At thecritical pathearliest, aFA MAY start tunneling packets using the BET to nFA aftera need for handoff is recognized but beforesending the HRply(t) to nFA in response to the request for target-triggered handoffcan take place. This separation is necessary when2) At thelink layer imposes hard deadlines onlatest, aFA MAY start tunneling packets using thetime at which a handoff must occur, such asBET to nFA and tear down the BET with oFA whenareceiving the HRqst(r) from oFA indicating the MN has disconnected. In addition, aFA MAY continue tunneling to oFA if 1) israpidly moving out of a radio coverage area, but whenselected, until theMN's IP stackHRqst(r) isnot implemented as a hard real-time system. Because a POST-REGISTRATION handoffreceived. If 1) istriggered by an unspecified mechanism that informsselected and the aFA continues to tunnel to oFA, the result may be duplicated packets at the MN, because the MN will receive packets through oFAor nFA that anon the old L2handoffuntil it disconnects (L2-LD). If 2) ispending,selected, thePOST-REGISTRATION approach is only applicableadditional latency will add tonetworks where such a mechanism is available. For example, an L2 may provide power measurements or other indications of radio signal quality that causetheoFA or nFAMN's L3 service disruption period. Of course, aFA can choose tosend the POST-REGISTRATION handoff messages. Any such indications must also provide each FA involved inplace thehandoff withBET some time between 1) and 2) if reliable bounds are available on theidentityduration of time between L2- ST/L2-TT and theother, so that messages can be sentMN's disconnection (L2-LD). The exact selection of when to establish theright 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 handoffBET is likely to becompleted asinfluenced by network engineering and implementation considerations, including whether aresult of the POST-REGISTRATION messaging without continuing to bicast traffic to both the old and new coverage areas, any L2handoffindications must also be securely authenticated so that traffic to the old point of attachmentsmoothing solution isnot improperly halted. POST-REGISTRATION handoffdeployed, and isappropriate in the following cases: - L2 triggers are available onbeyond thenetwork to indicate that L2 handoff is pending.scope of this specification. Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and target trigger (L2-TT) three party handoff, respectively. El Malki (Editor) et. al. [Page29]27] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 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 theMNis 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 betweennFA oFAand nFA. The only case not considered already in the POST-REGISTRATION method is mobile-initiated handoff. In the mobile-initiated case, theaFA | | | | | | L2-ST ~~~~~> | | | | | | | |<-------------| | | | HTT | | | | | | | |------------->| | | | HRply(s) | | | | | | | |------------------------------>| | | HRqst(t) | | | | | | | |<------------------------------| | | HRply(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 HandoffRequest message is initated by the oFA or nFA when it receives the Registration Request from the MN. The combined method follows the PRE-REGISTRATION| HRqst(r) | | | |<---------------| | HRply(r) | | | ----------------------------------<~~~ L2-LU | | | | | |<-------------->| | | | MN's traffic | | | | | | | Figure 10 - Three Party Source Trigger Handoffwhen it is successful before the completionTiming El Malki (Editor) et. al. [Page 28] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 MN nFA oFA aFA | | | | | |<~~~ L2-TT | | | | | | | |------------->| | | | HRqst(t) | | | | | | | |<-------------| | | | HTT | | | | | | | |------------------------------>| | | HRqst(t) | | | | | | | |<------------------------------| | | HRply(t) | | | | | | ----------------------------------<~~~ L2-LD | |--------------->| L2 Handoff | HRqst(r) | | | |<---------------| | HRply(r) | | | ----------------------------------<~~~ L2-LU | | | | | | | | | |<-------------->| | | | MN's traffic | | | | | | | Figure 11 - Three Party Target Trigger Handoff Timing 4.3. Renewal or Termination of Tunneling Service To prevent a BET from expiring when its lifetime runs out, the MN'sL2 handoff. However, if PRE-REGISTRATION does not complete prior tocurrent FA signals theexpiration of a timer on oneaFA to either renew or terminate theother ofBET. This may be theFAs, POST-REGISTRATION handoff is used. Using POST-REGISTRATION handoff insulatescase when the MNfrom delays caused by errors such as loss of one of thedefers Mobile IPmessages involved in PRE-REGISTRATION. The start of POST-REGISTRATIONRegistration. If no such signal isgated byreceived, theexpiration of a timer onaFA will terminate theFAs. The timer is started at oFA following a source-trigger, at nFA followingBET when thetarget-trigger, or at oFA and nFA followinglifetime expires. In addition, thereceipt ofcurrent FA or aFA may need to terminate theRegistration Request fromBET prior to theMNlifetime expiring. In order to avoid error conditions in which tunnels do not expire even though themobile- initiated case. The timerMN to which they apply isreset ifno longer reachable, FAs SHOULD set the tunnel lifetime field to some value other that 0xffff, which indicates "good until cancelled". Figure 12 illustrates theRegistration Replymessageis received byexchange that occurs between theappropriateFAand sentneeding to terminate or extend theMN. Although the POST-REGISTRATION Handoff Request and Handoff Reply messages are exchangedtunnel (designated FA(1) inadvance, no forwarding of traffic between oFA and nFA is performed unlessthetimer expires. The timer should be set to a value that allows forwarding between oFAfigure) andnFA to occur beforetheMN completesother FA (designated FA(2) in theL2 handoff to nFA. 6. Reverse Tunneling Support The handoff methods support reverse tunneling.figure). TheMN may request reverse tunneling [5]HRqst(r)/HRply(r) is indicated by setting the'T'R bit inits Registration Request. In the case of POST-REGISTRATION, iftheMN had requested Reverse Tunneling previously at oFA, the Handoff message from oFA (see Sections 4.7 and 4.8) includesHRqst/HRply messages. If the'T' bit enabled to inform nFA to establishHRqst(r) is renewing a BETfor 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 L2then it El Malki (Editor) et. al. [Page30]29] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001technologies may allowcontains a non-zero lifetime, otherwise if thereverse tunnellifetime is set tobe 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.zero it indicates tunnel termination. Theformat 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-typeaFA has complete control over whether a tunnel is extended or terminated, anddefine 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 | Lengthit MAY reply to a request for extension with a shorter lifetime than was requested. HRqst(r) +------+ <-------- +------+ |Sub-TypeFA(2)| ---------> |LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length ofFA(1)| +------+ HRply(r) +------+ Figure 12 - BET Renewal or Termination 4.4. When will theLink Layer Address +MN perform a Mobile IP Registration? The MN/FA have control over when to perform theone octet Sub-Type field Sub-Type This field containsMobile Ip Registration. Although theLink Layer sub-type identifier LLA ContainsMN/FA may decide to defer Mobile IP Registration for a certain period, three possible events can lead to theLink Layer Address Inneed to terminate tunneling service. If thisdocument, five subtypes are defined: 1 Internationaloccurs the MN MUST perform the MobileStation Identity (e.g. [8]) 2 Ethernet 48 bit MAC address [9] 3 64 bit Global ID, EUI-64 [10] 4 SolicitedIPAddress 5 Solicited Access Point IdentifierRegistration. These events are: 1) Thefollowing subsections describeend of life for theextensions. 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 ofBET is pending and a request by theIMSI field +current FA to aFA for renewal has been denied, or alternatively theone octet Sub-Type field Sub-Type 1 IMSI Containscurrent FA or aFA needs to terminate theIMSI,BET prematurely. The FA in this case MUST initiate theform: <IMSI>:<Connection Id> WhereMobile IP Registration by sending the<IMSI> isanASCII-based representation ofAgent Advertisement to theInternationalMN as in [1]. 2) The MN itself decides to perform a MobileStation Identifier, most significant digit first, ":" is ASCII 0x3a,IP Registration and initiates it by sending an Agent solicitation as in [1]. 3) During a source triggered handoff, theConnection IDoFA attempts to perform BET handoff but nFA isthe ASCII representationnot capable ofa small, decimal number used for distinguishing different link-layer connections from the same device. 7.2 Ethernet Link Layer Address Extensionperforming it. TheEthernet Link Layer Address Extension containsFA in this case MUST initiate the48 bit Ethernet MAC Address,Mobile IP Registration by sending the MN an Agent Advertisement asdefinedin[9]. 0 1 2 3 0 1 2 3 4[1]. Note that this situation will never arise during target triggered handoff because an HRqst(t) will not be sent to oFA by an nFA that doesn't support POST-REGISTRATION. 4.5. MN Considerations According to [1], when using an FA care-of address the MN MUST choose its default router from those advertised in the ICMP Router Advertisement portion of the Agent Advertisement. If this is not possible it MAY consider the IP source address of the Router Advertisement as an alternative. The detailed selection method based on ICMP Router Discovery is specified in [14]. In POST-REGISTRATION the MN may not be receiving Router Advertisements for extended periods of time. According to [14] hosts will remove default router entries if the lifetime of the Router El Malki (Editor) et. al. [Page 30] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 Advertisement expires and no further advertisements are received. Note that the ICMP Router Advertisement lifetime is not related to the Registration Lifetime in the Mobility Agent Advertisement extension [1]. In POST-REGISTRATION, to avoid this disruption the MN MUST solicit the default router (i.e. FA) before the lifetime of its active default router entry runs out, or alternatively the FA MUST advertise before the Lifetime of its last Router Advertisement times out. This effectively means that the MN will only be able to defer Mobile IP Registration for as long as the remaining lifetime of the active default router, as configured in the ICMP Router Advertisements. The default Router Advertisement Lifetime in [14] is 30 minutes. The MN MUST change its default router when it receives a new Router Advertisement following a POST-REGISTRATION handoff. 4.6. Handoff Request (HRqst) Message format 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 |H|N|R|M|G|T|B|x| Lifetime |Length+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-TypeMN Home Address |MAC ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type| HA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD(skippable) [1] Length 7 (includes(Handoff Request) H Source triggered handoff request. When set and theSub-Type field)N bit is unset, indicates that the request was the result of an L2-ST at oFA. N Target triggered handoff request. When set and the H bit is unset, indicates that the request was the result of an L2-TT at nFA. R Set if the request is an HRqst(r), i.e. a request to renew the tunnel. Neither the H nor the N bit are set. M The FA issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel. G The FA issuing the HRqst will use GRE [5] El Malki (Editor) et. al. [Page32]31] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001Sub-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,Encapsulation 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[1,5] for theSub-Type field) Sub-Type 3 MAC Containstunnel. When this flag is set the64-Bit Global Identifier Address. 7.4 Solicited IP Address Extension The 32-bit Solicited IP Address Extension containsHRqst may require extensions containing theIP address ofGRE type and key fields, but they are outside theagent (FA) being solicited. This extension MAY be present inscope of this document. T For anICMP 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 ContainsHRqst(s), indicates that the32-Bit IP Address ofoFA is willing to support both forward and reverse tunnel service. For an HRqst(t), indicates that thesolicited node. 7.5 Solicited Access Point Identifier Extension The 32-bit Solicited Access Point Identifier Extension containsnFA is requesting reverse tunnel service. B When sent in anIdentifier ofHRqst(s), indicates that theAccess PointMN has requested a reverse tunnel towhichtheMNHA and that the nFA SHOULD use reverse tunnel to the HA if it willmove. This maynot bea wireless L2 identifier.reverse tunneling to the oFA. Lifetime The lifetime, in seconds, for which tunnel service for the MN will be maintained. If this isable to solicitanadvertisement fromHRqst(t), then theFA servicinglifetime represents acertain Access Pointrequest byusingnFA for a reverse tunnel. If thisextension with Agent Solicitations as explained in Section 3.3. 0 1 2 3is an HRqst(s), then the lifetime represents the maximum amount of time that oFA is willing to maintain the both the forward and reverse tunnel. If this is an HRqst(r), then the lifetime Represents a request for the amount of time to renew the tunnel's lifetime. A value of 01 2 3 4on an HRqst(s) indicates that the oFA is unwilling to grant any tunnel service. A value of 0 on an HRqst(t) indicates that the nFA does not require reverse tunnel service. A value of 0 on an HRqst(r) indicates that the tunnel should be terminated immediately. A value of 0xffff indicates infinite lifetime. MN Home Address For HRqst(s), the home address of the MN. HA Addr For HRqst(s), the HA address of the mobile node. Identification As in defined in [1]. Extensions The Message MUST include an LLA (see Section 8) containing the MN's L2 address and an L2 address that can be mapped to an IP address for the FA. For an HRqst(s), the Message MUST contain the FA-FA Authentication Extension [2]. El Malki (Editor) et. al. [Page 32] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 4.7. Handoff Reply (HRply) Message 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 |H|N|R|M|G|T|B|x| Code |LengthReserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HA Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + |Sub-Type|AP ID...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- 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(Handoff Reply) Code A value indicating theGeneralized 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 useresult of thevalues 1-5, and all other values other than zero (0)Handoff Request. Only two codes areavailable 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.4currently supported, 0, indicating success, and4.5 require numbers assigned froma nonzero value, indicating that theMobile IP control message type address space.handoff cannot be performed. Lifetime Thenumbers assigned MUST NOT conflict with [1] and [2]. 9. Security Considerations A security considerationlifetime, in seconds, forPRE-REGISTRATION method involves changingwhich theTTLbi-directional tunnel forRouter Advertisement messages sent between oFAs and nFAs, where multiple hops are present between oFA and nFA. The same applies to Registration Request messages sent bythe MNto nFA routed through oFA and similarly Registration Reply messages. As discussed in Section 3.8, oFA and nFA must sharewill be maintained. If this is an HRply(s), then the lifetime represents asecurity associationrequest by nFA, andoFA mustit can beauthorizedany value up tosolicit nFA and relay Registration Request/Reply. In addition, the case involving tunneling of Agent Advertisements betweenthenFA andmaximum value sent in theMN requires restricitionsHRqst(s). Larger values are assumed tobe relaxed sodefault to OFA's maximum. If this is an HRply(t), then theTTLlifetime represents the maximum amount of time that theRouter Advertisement is not requiredoFA will grant tobe 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, iftheFA Challenge/Response mechanism in [11]nFA. If this isuseda HRply(r), then theMIN_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 issueslifetime represents theRegistration Request. POST-REGISTRATION introduces a new change to Mobile IP,amount of time by whichisthepossibility that a MN may receive packets from an FA with which it has not yet registered. Intunnel life will be extended. If theeventCode field indicates that handoff failed, theMN does not wish to receive packets from unknown FAs, it MAY drop them. In a similar way to PRE-REGISTRATION, oFALifetime field will be ignored andnFA must share a security association requiredSHOULD be set toprotect the Handoff Request and Reply messages. Since the techniques outlined in this document depend on particular aspectszero. A value ofL2 handoff0 on an HRply(t) indicates that the oFA is unwilling tooptimize performance, some amountgrant service. A value ofL2 security is assumed. Both techniques depend0 onL2 triggers, andan HRply(s) indicates that thesecuritynFA does not require service. A value ofhandoff requires0 on HRply(r) indicates that theL2 triggerstunnel lifetime will besecure. In addition, the POST-REGISTRATION technique depends on the abilityterminated. A value of 0xffff indicates infinite lifetime. H Source triggered handoff reply. When set and thewireless network to securely identify MNs. Although this document does not specify how FAs can identify or track MNs, itN bit isassumedunset, indicates that thewireless L2reply issufficiently secureinorder 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 movedresponse toother service areas, andan HRqst(s). El Malki (Editor) et. al. [Page35]33] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001 N Target triggered handoff reply. When set and the H bit is unset, indicates that the reply is in response toallow a bogus MN to obtain unauthorized service froman HRqst(t). R Set if the reply is an HRply(r). Neither the H nor the N bit are set. M The FAprior to performing a Mobile IP registration.issuing the HRqst will use Minimal Encapsulation as defined in [1,5] for the tunnel. G ThePRE-REGISTRATION technique instead depends on Mobile IP security between MN and FA, soFA issuing thesame security considerationsHRqst will use GRE [5] Encapsulation as defined in[1] apply. 9.1 AAA Considerations[1,5] forSecurity For handoff between Administrative Domains (ADs), both techniquesthe tunnel. When this flag is set the HRply mayexperience additional latency ifrequire extensions containing the GRE type and key fields, but they are outside the scope of this document. T For an HRply(s), indicates that theMN must establish a security association withnFAprioris Requesting tothe handoff taking effect.reverse tunnel service. ForPRE- REGISTRATION,an HRply(t), indicates that theneedoFA is willing toestablishprovide both forward and reverse tunnel service. B When sent in an HRply(t), indicates that the MN has requested asecurity association could delayreverse tunnel to theregistration process soHA and thatno Registration Reply is received. For POST-REGISTRATION,the nFA SHOULD use reverse tunnel to the HA if itcould result inwill not be reverse tunneling to theMN's traffic being delayed untiloFA. It can be set in HRply(t) only if thecompletion of a formal Mobile IP registration rather than as soon asT bit was unset in the corresponding HRqst(t). MNestablishes an L2 connection at nFA. This section discusses an approach for reducing latency due toHome Address For HRply(t), theneed 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 Ifhome address of theexisting AAA infrastructure is used to establish dynamic security associations between FAs and HAsMN. HA Addr For HRply(t), the HA address of the mobile node. Identification As indifferent ADs,defined in [1]. Extensions For an HRply(t), thesame infrastructure could be used to establishMessage MUST contain therequired security association forFA-FA Authentication Extension [2]. 4.8. Handoff To Third (HTT) Message The Handoff to Third message has thepurposes of inter-domain handoffsame format asshownthe Handoff Request and Handoff Reply Messages, except both the H and N bits are set. If the HTT message is inFigure 11. Note that itresponse to a L2-ST and ispossible for geographically neighboring FAs owned by different ADssent tohaveinitiate apre-established security association, which would reducehandoff, then, with thelatency introduced byexception of theAAA infrastructure traversal. Given that such geographically neighboring FAs MAY be smallH and N bits, the message has the same fields set and includes the same extensions as an HRqst(s). If the HTT message is sent innumber, suchresponse to anapproach MAYHRqst(t), then, with the exception of the H and N bits, the message has the same fields set and includes the same extensions as an HRply(t). The tunnel bits MUST NOT bereasonable.set in the HTT message because BET El Malki (Editor) et. al. [Page36]34] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 200110. References [1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [2] E. Gustafsson, A. Jonssonconstruction is not negotiated between oFA andC. 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. PerkinsnFA, it is negotiated between nFA andD. Johnson, "Route OptimizationaFA inMobile IP",draft-ietf-mobileip-optim-10.txt (workthe ensuing HRqst(t)/HRply(t). In addition, the HTT MUST contain the following extensions inprogress), 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, "Mobilethe specified order: Solicited IPExtensions Rationalization (MIER)", draft-ietf-mobileip-mier- 05 (work in progress), Dec. 1999 [8] TIA/EIA/IS-95-B [9] D. Plummer, "An EthernetAddressResolution Protocol - or Converting Network Protocol Addresses to 48.bit EthernetOption: containing aFA's Addressfor 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.LLA Option: containing the L2 address of the MN. 4.9. Applicability of POST-REGISTRATION Handoff Method The POST-REGISTRATION handoff approach allows FAs to communicate directly about a pending handoff, andV. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [13] P. Calhoun, C. Perkins, "Mobiledoes not require any IPNetwork 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 maylayer messages to becontacted at the addresses below: Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag.sent to or from a MN prior to the L2 handoff event. Therefore, it eliminates a possible source of handoff latency. This may be required 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. Consequently, POST-REGISTRATION is primarily of interest in handoff between FAs that support the same radio access technology. Handoff between heterogeneous radio technologies will, of necessity, require interaction between the MN and the network, and so is not a domain of applicability for POST- REGISTRATION. 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 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, 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. - 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 El Malki (Editor) et. al. [Page 35] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 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 begin before the MN completes the L2 handoff to nFA. 6. Layer 2 and Layer 3 Handoff timing Considerations In the optimal cases considered in the PRE-REGISTRATION and POST- REGISTRATION handoffs it was assumed that a timely L2 trigger would be received in such a way that packets could be delivered to the MN via its nFA immediately upon connection. In this way the MN would not suffer disruption due to the L3 handoff. However such precise timing of the L2 trigger and handoff mechanism with respect to the actual L2 handoff event will not be possible in all wireless systems and may depend on particular implementation techniques. Therefore some uncertainty may exist at L3 as to exactly when the L2 connection between the MN and the nFA becomes fully established and can be used for L3 traffic. The techniques which will solve this problem and allow the MN to receive traffic independently of the timing of the L2 handoff event are currently under study by the WG but are outside the El Malki (Editor) et. al. [Page 36] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 scope of this document. 7. Reverse Tunneling Support The handoff methods all support reverse tunneling. The MN may request reverse tunneling [4] 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 Section 4) 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 technologies may allow the reverse tunnel to be turned off unless the MN specifically requests it. 8. 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 relies on sub-types, where each sub-type defines its own sub-structure. This draft defines six 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 El Malki (Editor) et. al. [Page 37] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 In this document, six subtypes are defined: 1 3GPP2 International Mobile Station Identity and Connection ID [6] 2 3GPP International Mobile Subscriber Identity [13] 3 Ethernet 48 bit MAC address [7] 4 64 bit Global ID, EUI-64 [8] 5 Solicited IP Address 6 Solicited Access Point Identifier The following subsections describe the extensions. 8.1. 3GPP2 IMSI Link Layer Address and Connection ID Extension The IMSI Link Layer Address Extension contains the International Mobile Station Identity. 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: <IMSI>:<Connection Id> Where the <IMSI> 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. El Malki (Editor) et. al. [Page 38] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 8.2. 3GPP IMSI Link Layer Address Extension The IMSI Link Layer Address Extension contains the International Mobile Station Identity. 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 2 IMSI Contains the IMSI, a number composed of 15-digits or less, coded as described in [13]. 8.3. Ethernet Link Layer Address Extension The Ethernet Link Layer Address Extension contains the 48 bit Ethernet MAC Address, as defined in [7]. 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 39] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 Sub-Type 3 MAC Contains the 48 bit Ethernet MAC Address. 8.4. 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 [8]. 0 1 2 3 0 1 2 3 4 5 6 7 8126 25 Stockholm SWEDEN Phone: +469 0 1 2 3 4 5 6 7 87195803 Fax: +469 0 1 2 3 4 5 6 7 87190170 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.com9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 9 (includes the Sub-Type field) Sub-Type 4 MAC Contains the 64-Bit Global Identifier Address. 8.5. 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. [Page38]40] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001Peter 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.comType TBD (skippable) [1] Length 5 (includes the Sub-Type field) Sub-Type 5 IP Address Contains the 32-Bit IP Address of the solicited node. 8.6. Solicited Access Point Identifier Extension Theworking group can32-bit Solicited Access Point Identifier Extension contains an Identifier of the Access Point to which the MN will move. This may becontacted viaa wireless L2 identifier. The MN is able to solicit an advertisement from thecurrent 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-6709FA 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 6 AP ID Contains the 32-Bit Access Point Identifier. El Malki (Editor) et. al. [Page39]41] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001EMail: 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 works9. IANA Considerations Section 8 introduces the Generalized Link Layer Address Extension numbering space thatcomment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restrictionrequires IANA management. This specification makes use ofany kind, provided thattheabove copyright noticevalues 1-6, andthis paragraph are included onallsuch copies and derivative works. However, this document itself may not be modified in anyway, such as by removingother values other than zero (0) are available for assignment via IETF consensus [12]. The numbers for thecopyright notice or references toGeneralized Link Layer Address Extension are taken from theInternet Society or other Internet organizations, except as needednumbering 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 [4], RFC 2356 [10], RFC 2794 [11] and RFC 3012 [9]. In thepurpose of developing Internet standardsPOST-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]. 10. Security Considerations A security consideration for PRE-REGISTRATION method, as discussed inwhich caseSection 3.8, is that oFA and nFA must share a security association and oFA must be authorized to solicit nFA and relay Registration Request/Reply. Also, if theprocedures for copyrights definedFA Challenge/Response mechanism in [9] is used then theInternet Standards processMIN_SOLICITATION_INTERVAL must befollowed,set to a value smaller oras requiredequal totranslate it into languages other than English. The limited permissions granted above are perpetual and willthe CHALLENGE_WINDOW (in nFA) so that the nFA challenge does notbe revoked byexpire before theInternet Society or its successors or assigns. This document andMN issues theinformation 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 RegionalRegistrationspecification [2] introduces the Gateway Foreign Agent (GFA),Request. Otherwise, PRE-REGISTRATION uses AAA-based security for both inter-domain and intra-domain handoff as described in [1] and [2]. POST-REGISTRATION introduces amobility agent that two FAs providing servicenew change to Mobile IP, which is the possibility that a MNhave in common. Figure A.1 providesmay receive packets from anexample ofFA 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 aMN's initial registration throughsimilar way to PRE-REGISTRATION, oFA and nFA must share a security association required to protect theGFA. IfHandoff 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 thefirst registration message,security of handoffs requires that themessage MUSTL2 triggers beforwarded tosecure. In addition, theHA. All packets destined forPOST-REGISTRATION technique depends on themobile will be deliveredability 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 theGFA, whichwireless L2 is sufficiently secure inturn will forward the packetsorder tothe FA servicing thecorrectly identify a MN.Reg Req +-----+ Reg Req +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure A.1 - Initial Registrations through GFA If the MN movesWireless networks that do not provide such features will be subject toa nFAimpersonation attacks, where malicious nodes could cause FAs to believe thatis serviced byaGFA common with oFA, theMNMAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not needhas moved tobe forwardedother service areas, and tothe HA, since the MN's traffic can still be deliveredallow 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 sameGFA. This optimized approach effectively reduces the latency involvedsecurity considerations inthe registration process. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ Regional Reg +-----+[1] apply. El Malki (Editor) et. al. [Page 42] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 11. References [1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP RegionalReg Figure A.2Tunnel Management ", draft-ietf-mobileip-reg-tunnel-05.txt (work in progress), September 2001. [3] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". BCP 14. RFC 2119. March 1997. [4] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. [5] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701 (Informational), Internet Engineering Task Force, October 1994. [6] TIA/EIA/IS-2000 [7] D. Plummer, "An Ethernet Address Resolution Protocol -Regionalor Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics,Inc., November 1982. [8] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registrationthrough GFA Note that the GFA may also be the MN's first-hop router.Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [9] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions", RFC 3012, November 2000. [10] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [11] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension", RFC 2794, March 2000. [12] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [13] 3GPP TS 23.003 (www.3gpp.org) [14] S. Deering, "ICMP Router Discovery", RFC1256, September 1991 El Malki (Editor) et. al. [Page41]43] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001A.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 must12. Authors' Addresses The authors may be contacted atleast 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 fromtheGFA. It is not necessary to advertise all FAaddressesin 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 tobelow: 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 44] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 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 23, Kista Stockholm SWEDEN Phone: +46 8 7570000 Fax: +46 8 4043630 E-mail: Hesham.Soliman@ericsson.com.au 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 theGFA are presentcurrent 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 EMail: Raj.Patil@nokia.com Fax : +1 972-894-5349 El Malki (Editor) et. al. [Page 45] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs Oct 2001 13. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document andare advertised,translations of it may benecessary for the MNcopied and furnished toidentify the common route FA using the complete list of FAsothers, and derivative works that comment on or otherwise explain it or assist inthe hierarchical branch. It is assumedits implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that theGFA advertises only one care-of addressabove copyright notice and this paragraph are included on allits interfaces towardssuch copies and derivative works. However, this document itself may not be modified in anyway, such as by removing theMN. The MN must cachecopyright notice or references to theMobility Agent Advertisement extensionsInternet Society or other Internet organizations, except as needed forits 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 comparestheIP addressespurpose of developing Internet standards in which case thenew Mobility Agent Advertisement extension with the cached Advertisementsprocedures forits active bindings. If there is an IP addresscopyrights defined incommon between these extensions, namedthecommon route FAInternet Standards process must be followed, orGFA, the MN uses that IP addressasthe HA addressrequired to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by thedestination address ofInternet Society or itsRegional Registration Request. In the case of a request for bicasting,successors or assigns. This document and the"S" bitinformation contained herein isset. The care-of addressprovided 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. [Page42]46] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 2001is the advertising FA's address.Appendix A - Gateway Foreign Agents TheMN adds a Hierarchical FA extension to theMobile IP Regional RegistrationRequest, in order to identify the regional FA path to be followed by the Request upspecification [2] introduces thehierarchy. A Regional FA receiving a Regional Registration Request with it's own addressGateway Foreign Agent (GFA), asHA address returnsaRegional Registration Replymobility agent that two FAs providing service tothe MN. If there is no IP address in common between the extensions, then the MN has moved intoanew hierarchy and the GFA advertisedMN have in common. Figure A.1 provides an example of a MN's initial registration through thenew extensionGFA. If this isdifferent from the one inthepreviously cached extensions. Whenfirst registration message, theMN changes GFA,message MUST be forwarded to theMN usesHA. All packets destined for thenew GFA's IP address as care of address in its new Registration Requestmobile will be delivered to theHA and addsGFA, which in turn will forward the packets to theHierarchicalFAextension as described previously.servicing the MN. Reg Req +-----+ Reg Req +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure A.1 - Initial Registrations through GFA If the MNhas at least one existing active binding when itmoves tothe new GFA, it performsalow loss handoff as explained in this document. The MNnFA that isable to performserviced by a GFAregistration during PRE-REGISTRATION handoffs only if its binding lifetimecommon with oFA, theGFA or HAMN MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does notexpire during the period needed by the MNneed torun PRE-REGISTRATION and complete its L2 handoff. Intermediate regional FAs are ablebe forwarded toaccept the MN's regional registration as simultaneous bindings only iftheintermediate regional FA has an existing active binding forHA, since theMN. The resulting simultaneous binding therefore has a maximum possible lifetime equalMN's traffic can still be delivered to thelifetime remainingsame GFA. This optimized approach effectively reduces the latency involved inits previously existing active binding. Oncethe registrationlifetime with theprocess. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFAor| | HAis about to expire,| +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ Regional Reg +-----+ Regional Reg Figure A.2 - Regional Registration through GFA Note that theMN must perform a new Mobile IP registration withGFA may also be theHA.MN's first-hop router. El Malki (Editor) et. al. [Page43]47] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 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. [Page44]48] INTERNET-DRAFT Low Latency Mobile IPv4 HandoffsMayOct 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. [Page45]49] ----