Mobile IP Working Group MIPv4 Handoffs Design Team INTERNET-DRAFT Karim El Malki (Editor) Expires: August 2001 Pat R. Calhoun Tom Hiller James Kempf Peter J. McCann Ajoy Singh Hesham Soliman Sebastian Thalanany February 23, 2001 Low latency Handoffs in Mobile IPv4 Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or 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 an individual submission to the IETF. Comments should be directed to the authors. Abstract Mobile IP (RFC2002) describes how a Mobile Node (MN) can perform IP- layer handoffs between Foreign Agent (FA) subnets. 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 (movement between FA subnets). These allow MIPv4 handoffs team [Page 1] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 greater support for real-time services on a Mobile IPv4 network by minimising the period of service disruption due to the delay in the Mobile IP Registration process. TABLE OF CONTENTS 1. Introduction....................................................3 1.1 Requirements language........................................4 2. Requirements....................................................4 3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff Method..........................................................4 3.1 Initiating NAMONC Handoffs through the "previous" FA.........9 I. Inter-FA Solicitation .....................................10 II. Piggy-backing Advertisements on L2 messaging.............10 3.2 Movement Detection and MN Considerations.....................10 3.3 Regional Deregistration for NAMONC Handoffs..................13 3.4 Smooth Handoffs between Hierarchies (GFAs)...................13 3.5 L2 Address Considerations for NAMONC Handoffs................14 3.6 Advantages and Applicability of NAMONC Handoff Method........15 4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method....15 4.1 Registration Latency........................................16 4.2 Movement Detection..........................................17 4.3 Ping-Pong effect............................................19 4.4 Reverse Tunneling Support...................................20 4.5 Security Relationships......................................20 4.6 Operation...................................................21 4.6.1 Foreign Agent Considerations...........................21 4.6.2 Gateway Foreign Agent Considerations...................24 4.7 Handoff Request Message.....................................24 4.8 Handoff Reply Message.......................................26 4.9 Error Values................................................27 4.10 Security Considerations.....................................27 4.11 Advantages and Applicability of NIMOT Handoff Method....... 28 5. Generalized Link Layer Address Extension.......................29 5.1 IMSI Link Layer Address Extension...........................29 5.2 Ethernet Link Layer Address Extension.......................30 5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension....31 6. IANA Considerations.............................................31 7. References......................................................32 8. Authors' Addresses..............................................33 Appendix A - Gateway Foreign Agents................................36 Appendix B - Bicasting Applicability Statement.....................37 MIPv4 Handoffs Design Team [Page 2] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 1. Introduction Mobile IPv4 (RFC2002) describes how a Mobile Node (MN) can perform IP-layer handoffs between Foreign Agent (FA) subnets. 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 (movement between FA subnets). These allow greater support for real-time services on a Mobile IPv4 network by minimising the period of service disruption due to the delay in the Mobile IP Registration process. The two methods presented in this draft to achieve low-latency IP- layer handoffs are: - Network Assisted, Mobile and Network Controlled (NAMONC) Handoffs - Network Initiated, Mobile Terminated (NIMOT) Handoffs The Network Assisted, Mobile and Network Controlled (NAMONC) Handoff method allows the MN to be involved in an anticipated IP-layer handoff procedure. The MN is therefore assisted by the network in performing an anticipated L3 handoff before it completes the L2 handoff. Information from L2 (L2 triggers) may be used both in the MN and in the FA. This method proposes the use of simultaneous bindings in order to send multiple copies of the traffic to potential Mobile Node movement locations before MN movement occurs. Therefore, the Mobile-Assisted Handoff method coupled to layer 2 mobility may help in achieving seamless (low latency + low loss) handoffs between Foreign Agents. However L2 connectivity may cause packet losses. In addition to handling the simple case of a MN, FA, and Home Agent, the NAMONC Handoff method also allows the use of Regional Registrations [2]. The Mobile IPv4 concept (Advertisement-Registration) is supported and NAMONC handoffs rely on Mobile IP security. No new messages are proposed. In cases where the MN is able to activate multiple interfaces and thus be data-connected to multiple access points simultaneously, the MN may not need to support anticipated simultaneous bindings and may achieve seamless handoffs simply by establishing connectivity through registrations with the new FA before disconnecting from the current interface. The Network Initiated, Mobile Terminated (NIMOT) handoffs method proposes extensions to the Mobile IP protocol to allow the old FA and new FA to utilize information from layer 2 (the L2 "trigger") to set up a kind of "pre-registration" prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment so that the effect of the handoff on real-time applications is minimized, although the MN must eventually perform a formal Mobile IP registration. The proposed extensions make a few minimal assumptions about support available from the link layer. Although the assumptions address the kinds of link layer support available in existing radio MIPv4 Handoffs Design Team [Page 3] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 link layers, the assumptions are not based on any specific radio link protocol. Security is handled by standard Mobile IP mechanisms, and both intra-domain and inter-domain handoff are supported. The technique can be used for inter-technology handoff but it requires the active involvement by the mobile to switch from one network interface to another. This technique covers a handoff scenario not addressed by RFC 2002, namely a pro-active, network-assisted handoff. Each method may be better suited for certain access network characteristics and the features and advantages of each method will be described later. NAMONC and NIMOT handoffs may be implemented independently. It is up to the implementor, based on the link-layer characteristics of the specific implementation and the features of each method supplied in this document to decide upon which is most appropriate for that case. 1.1 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]. 2. Requirements The following requirements are applicable to low-latency handoffs and are supported by both methods: - Support delay-sensitive (real-time) services in domain - Support back-and-forth movement of MN between FAs (ping-pong) - No dependency on a wireless L2 technology - Support Inter and Intra-access technology handoffs - Limit wireless bandwidth usage 3. Network Assisted, Mobile and Network Controlled (NAMONC) Handoff Method This method is intended to support low latency IP-layer handoffs for: - Multi-access mobility (different access technologies; MN and network controlled) - Single-access mobility (same access technology; MN and network controlled) This method considers both the normal Mobile IP model [1] and the Regional (hierarchical) Mobile IP model [2]. These are shown in Figure 1 where the Access Points (APs) or Radio Networks (RNs) are MIPv4 Handoffs Design Team [Page 4] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 used to provide a MN with wireless or wired L2 access. Both inter and intra-domain (AAA-assisted) mobility is considered. The additional features for this method are: - Support MN-control of L3 handoff (as RFC2002) MN controls its registrations and there are no proxy registrations on MN's behalf. - Support network(FA)-control of L3 handoff (as RFC2002) FA controls advertisements (which cause MN handoff) and can accept/reject registrations. - No new messages - Maintain RFC2002 concept thus allowing MN to determine which FA it will register with(advertisement->movement detection->registration) - Rely on existing Mobile IP security model MN-FA-HA (e.g. using AAA) but make no assumption on L2 security - No L3 knowledge of exact L2 handoff timing (but this method can make use of handoff indications or triggers from L2 on either the network or terminal side depending on the initiator) Figure 1 illustrates the normal and hierarchical MIPv4 models. In the simplest multi-access or single-access case where the MN is able to activate more than one interface (corresponding to different or the same access technologies) and thus be data-connected to multiple access points simultaneously it is possible to achieve low-latency handoffs in a relatively simple manner. Assume that the MN is connected to RN2 and is registered with FA2 through which it is receiving traffic. The MN may enter the coverage area of RN1 and FA1 and decide 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 would then activate the interface to RN1 as well as continue communicating through RN2. The MN may solicit advertisements from FA1 to speed up the handoff process. Once it is registered with FA1 and is successfully receiving and transmitting through the new network it may then tear down the interface to RN2. If the MN has enough time to complete this procedure without incurring degraded service or disconnection then it would provide the MN with a seamless multi-access handoff. In order to support the possible failure of the connectivity with the new network (RN1/FA1) in the short period following handoff the MN MAY use the "S" bit in its Mobile IP Registration Request to maintain both its existing (HA or GFA) binding with FA2 and a new binding with FA1 (i.e. simultaneous bindings). The use of simultaneous bindings is not necessary in most of the cases belonging to this scenario. MIPv4 Handoffs Design Team [Page 5] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 _________ _________ | | | | | HA |--------| (GFA) |________ |_________| |_________| \ / | \ \ \ ... ... ... \ \ ______/_ _\______ | | | | | | | FA2 | | FA1 | | |________| |________| | ____|___ ____|___ ____|___ | | | | | | | AP/RN 2| | AP/RN 1| | AP/RN 3| |________| |________| |________| | ____|___ | | CN | MN | |________| Figure 1 - Normal(HA only) and Hierarchical(HA and GFA) MIPv4 model In the remaining part of the description of the NAMONC Handoffs method, the scenarios for single and multi-access handoffs will be considered. In these scenarios the MN is unable to activate and communicate over more than one interface or connection to the network. This may be due to limitations imposed by the access technology or configuration of the mobile node. In these cases it is necessary to anticipate the IP-layer handoff before the MN's movement actually happens in order to achieve a seamless mobility effect as close as possible to that described previously. In Figure 1, using normal Mobile IP (no GFA) the MN MAY perform registrations with the HA using simultaneous bindings. This is described in [1] and the method to anticipate MN movement by interacting with the wireless L2 is described later in this draft. Simultaneous bindings are used to decouple the IP-layer handoff from the L2 handoff by having data reaching the multiple possible MN locations before the MN moves there since the details of the L2 handoff timing are unknown to L3. "Bicasting" or simultaneous bindings are also useful to support "ping-pong" or fast back-and- forth MN movement between FAs due to fast mobility or handoff failures. An alternative method to perform improved handoffs, namely Smooth Handoffs, is described in [4]. The method for NAMONC Handoffs addresses the need to support services having strict delay bounds (i.e. real-time) which in certain cases may be hard to support if MIPv4 Handoffs Design Team [Page 6] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 traffic has to be forwarded between FAs using Smooth Handoffs. This is especially true if the two FAs are not directly connected. If there is a common router or router network connecting the two FAs and the HA, forwarding traffic between FAs would cause twice the bandwidth usage on the common router/s and a considerable increase in delay. Also, in the non-realtime case it may be possible that the new FA receives both buffered traffic from the previous FA (smooth handoff) and traffic from the HA which could cause some delayed and possibly out-of-order packets to be delivered to the MN. This could affect the performance of higher level protocols (e.g. TCP). The same situation will not arise using NAMONC Handoffs. However, having multiple simultaneous bindings for MNs at the HA will cause the HA to send multiple copies of data packets towards mutliple FAs which may be in the same region or domain. In terms of bandwidth usage this would not be efficient unless the HA is close to the FAs in question, however this is not always the case. Also, if the round- trip time between HA and FAs is not negligible this may slow down the MN's new Registration and therefore the Mobile IP handoff. The Hierarchical MIPv4 model addresses these problems. The Regional (Hierarchical) Mobile IPv4 scheme introduced in Regional Registrations [2] allows a Mobile Node to perform registrations locally with a Gateway Foreign Agent (GFA) in order to reduce the number of signalling messages to the home network. This achieves a reduction in the signalling delay when a Mobile Node moves between Foreign Agents and therefore improves the performance of such handoffs. This draft is applicable to single-level (GFA only with no regional FAs) and multi-level Hierarchical Mobile IPv4 networks described in Regional Registrations [2]. Networks utilizing Regional Registrations with NAMONC Handoffs offer advantages which are especially important for the support of real-time services. As mentioned previously, the GFA may well be the first-hop router for the MN. In the Regional (Hierarchical) Mobile IP case the NAMONC Handoff is achieved by "bicasting" traffic from the GFA to the previous FA and new FA while the MN is moving between them. The anticipation of the MN's movement is achieved by tight coupling with Layer 2 functionality in the FA which is dependent on the type of access technology used. Bicasting is achieved through simultaneous bindings, where the MN activates the "S" bit in the Registration Request (described in [1]). In a hierarchical MIPv4 network, when a Regional Registration Request has the "S" bit set, the receiving regional FA or GFA which has an existing binding with the MN will add the relevant new binding for the MN but will also maintain any other existing bindings it had for the MN. When the MN has multiple active bindings with FAs, it MAY receive multiple copies of the same traffic directed to it. The use of simultaneous bindings does not necessarily mean that the MN is MIPv4 Handoffs Design Team [Page 7] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 receiving packets contemporarily from multiple sources. This depends on the characteristics of the access (L2) technology. The bicasting of packets is used to anticipate the MN's movement and speed up handoffs by sending a copy of the data to the FA which the MN is moving to. Until the MN actually completes the L2 handoff to the new FA, the data "copy" reaching this FA may be discarded. In this way the total handoff delay is limited to the time needed to perform the L2 handoff. Thus, NAMONC Handoffs coupled to the L2 access potentially result in loss-less IP-layer mobility. As described in 3.1, depending on the L2 characteristics, it is also possible for an MN to initiate a NAMONC Handoff through the "previous" FA without having direct access to the "new" FA. The overall NAMONC Handoff mechanism is summarised in Figure 2 below: +-----+ | GFA |<---------+ +-----+ | 4. RegRegReq. | 5. RegRegReply v +-----+ (1a RtSol) +-----+ | | -----------------> | nFA | | oFA | 1b.RtAdv | | +-----+ <----------------- +-----+ ^ | ^ (2a. RtSol) | | 2b. / | | ProxyRtAdv / 3. RegRegReq | | / | v --------------- +-----+ / | MN | +-----+ - - - - - -> Movement Figure 2 - NAMONC Handoff Message exchange Messages 1a and 1b (Router Solicitation and Router Advertisement) should occur in advance of the NAMONC Handoff and should not delay the sending of message 2b. For this purpose the old FA (oFA) MAY solicit and cache advertisements from the new FA (nFA), thus decoupling the timing of this exchange from the rest of the NAMONC Handoff. Message 2a occurs if there is an L2 trigger in the MN to solicit for a router advertisement. In network-controlled wireless systems the L2 trigger will be in the network and will reach oFA which will transmit the Proxy Router Advertisement (message 2b). This is simply nFA's advertisement relayed by oFA. The MN will perform movement detection and, if appropriate, send a Regional Registration Request message [2] (message 3) to nFA requesting a simultaneous binding. Message 3 may be routed through oFA since the MN is not directly connected to nFA at this point. Messages 3, 4 and 5 are MIPv4 Handoffs Design Team [Page 8] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 described in [2]. The Regional Registration Reply (message 5) needs to be forwarded by nFA to the MN. Unless the system is engineered such that the MN may not detach from oFA until it has received the Reply, the MN may at this time have disconnected. Therefore the Reply should be copied by nFA to the MN's old location (tunnelling the Regional Registration Reply to oFA) and to the MN's new location. The MN's new L2 address may be obtained using the extensions in section 5, as described in 3.5. At this moment it may still not be known at L3 whether the MN has detached and connected to nFA. Even if it was known at the exact instant, in most wireless systems there would not be enough time for L3 to react and forward traffic to the MN's new location by the time the MN has attached. For this reason, to maintain L3 connectivity, simultaneous binding are used. Therefore for a short time interval from the moment the Regional Registration Reply is sent by the from GFA to nFA, the GFA will start bicasting traffic for the MN to both oFA and nFA. Therefore the MN will be able to receive traffic independently of the exact L2 handoff timing. Also, should the L2 handoff procedure fail or terminate abruptly, the use of simultaneous bindings allows the MN to maintain L3 connectivity with oFA. The same stands for the case in which the MN performs "ping-pong" or fast back-and-forth movement between FAs, where simultaneous bindings allow continued L3 connectivity without the need to continuously receive advertisements and send registration messages. This reduces the signalling load over the air interface. Note that this method can be applied to the case where multiple possible nFAs are identified by oFA. 3.1 Initiating NAMONC Handoffs through the "previous" FA Some existing wireless L2 technologies and their implementations do not allow a MN to be data-connected to multiple wireless access points simultaneously. In order to perform a NAMONC Handoff it is necessary for some form of interworking between layers 2 and 3 to determine when a L3 handoff should be triggered by a L2 handoff. It should be noted that the method used by an FA to determine when a MN has initiated an L2 handoff (L2 trigger) for which the FA should initate a NAMONC Handoff is outside the scope of this draft and may involve interaction with L2 messaging. If the FA determines from the L2 trigger that movement between FAs will not occur then the NAMONC Handoff should not be initiated. When this is not the case, the interaction between L2 and L3 (on the network side and/or MN-side) should allow the Mobile Node to complete a L2 handoff (resulting in movement between FAs) after having performed the L3 NAMONC Handoff described in this draft. That is, the L2 handoff should be completed after the MN's Registration with the "new" FA which produces a simultaneous binding at the GFA/HA. This Registration may be transmitted more than once to reduce the probability that it is lost due to errors on the wireless link. MIPv4 Handoffs Design Team [Page 9] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 A NAMONC Handoff in this case requires the MN to receive "new" agent advertisements through the "old" wireless access points, and to perform a registration with the "new" FA through the "old" wireless access point. This procedure should be performed before the layer-2 handoff event. Two ways of performing this follow. I. Inter-FA Solicitation This solution assumes that the FA with which the MN is currently registered is aware of the IP address of the "new" FA which the MN is moving to. The method by which the current FA is informed of this may depend on interaction with L2 and is outside the scope of this draft. Once the current FA is aware of the address of the FA which the MN will move to, it will send the "new" FA an agent solicitation message. The "new" FA will reply to the current FA by sending it an agent advertisement with appropriate extensions. The current FA will then send the agent advertisement to the MN's address. As a consequence, the MN, being eager to perform new registrations, will send a registration request to the "new" FA through the "old" wireless access point served by the current FA. II. Piggy-backing Advertisements on L2 messaging Using Figure 1, consider a case where an MN initiates an L2 handoff from AP/RN1 to AP/RN2 (Note that it may not be the MN which takes decisions on L2 handoffs). It is assumed that when an L2 handoff is initiated, AP/RN1 and AP/RN2 perform L2 messaging procedures to negotiate the L2 handoff. Since the MN is not attached to AP/RN2 yet, FA2 is unaware of the IP address of the MN and cannot send an advertisement to it. Therefore it is necessary for the L2 procedures (which must be common to AP/RN1 and AP/RN2) to interwork with Mobile IP. Once a L2 handoff is initiated, such that AP/RN2 and AP/RN1 are in communication, it is possible for AP/RN2 to solicit an advertisement from FA2 and transfer it to AP/RN1. Once this is received by the MN, the MN can perform a registration directed to FA2 even though the MN has no data-connection to AP/RN2 yet. The precise definition of such L2 procedures is outside the scope of Mobile IP. 3.2 Movement Detection and MN Considerations When there is a hierarchy of foreign agents between the GFA and the announcing foreign agent, the announcing foreign agent MAY include the corresponding addresses in order between its own address (first) MIPv4 Handoffs Design Team [Page 10] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 and the GFA address (last) in the Mobility Agent Advertisement extension of its Agent Advertisements. If there are only two hierarchical levels, a foreign agent announces itself and a GFA in the Agent Advertisement; in the first and last address in the care-of address field in the Mobility Agent Advertisement extension. There must be at least one care-of address in the Mobility Agent Advertisement extension. If there is only one care-of address it is the address of the GFA, and the MN is connected directly to it. When the MN receives an Agent Advertisement with a Mobility Agent extension and the "I" bit set, as specified in [2], it should perform actions according to the following movement detection mechanisms. In a Hierarchical Mobile IP network such as the one described in this draft, the MN MUST be: - "Eager" to perform new bindings - "Lazy" in releasing existing bindings The above means that the MN MUST perform Regional Registrations with any "new" FA from which it receives an advertisement (Eager) as long as there are no locally-defined policies in the MN which discourage the use of this FA (e.g. cost of service). The method by which the MN determines whether the FA is a "new" FA is described in [1] and may make use of an FA-NAI extension. However the MN MUST NOT release existing bindings until it no longer receives advertisement from the relative FA and the lifetime of its existing binding expires (Lazy). It should be noted that the MN may add a Hierarchical FA extension to Registration Requests in order to identify the exact FA path to be followed by the Registration Request. This extension must not be removed by regional FAs. If the MN has at least one existing binding with a FA, additional simultaneous regional registrations will be performed requesting a short lifetime. This is done in order to limit the lifetime of bindings which the MN only needs temporarily and therefore limit bandwidth usage. This is the case when the MN is moving between FAs and uses NAMONC Handoffs to achieve loss-less IP mobility. The lifetime of additional "auxiliary" bindings needed for NAMONC Handoffs is thus limited. This may also be useful to support eventual the MN's "ping-pong" movement between FAs which would otherwise require continuous registrations and thus handoff delays. The remaining issue is the choice of the appropriate HA address in the Regional Registration Request when the MN has at least an existing active regional binding. Two options follow: 1) Mobility Agent extension advertises FA and GFA address only In this case it is assumed that there is always a single path from MIPv4 Handoffs Design Team [Page 11] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 the MN to the GFA. The MN will always perform Regional Registrations using the GFA address as HA address and the advertising FA as care-of address. As the Regional Registration Request is relayed towards the GFA, each FA receiving it will check whether it has an existing binding with the MN and whether the Regional Registration has the "S" bit set to request for simultaneous bindings. If this is true and the Regional Registration is validated by the GFA, these FAs will activate the simultaneous binding upon receiving the (successful) Regional Registration Reply from the GFA. Therefore it is not necessary to advertise to the MN all of the FA addresses in the hierarchical branch, thus reducing bandwidth usage over wireless. 2) Mobility Agent Advertisement extension advertises complete order of FAs in the branch In specific cases where multiple regional FA levels and multiple paths from the MN to the GFA are present and are advertised, it may be necessary for the MN to identify the "common route" FA using the complete list of FAs in the hierarchical branch. It is assumed that the GFA advertises only one care-of address on all its interfaces towards the MN. The MN must cache the Mobility Agent Advertisement extensions for its active bindings. When it receives an advertisement from a "new" FA which has a different Mobility Agent Adv. extension, it will be eager to perform a new binding. The MN compares the IP addresses in the new Mobility Agent Adv. extension with the ones it has cached for its active binding(s). If there is an IP address in common between these extensions, named "common route" FA or GFA, the MN will use that IP address as HA address and destination address of its Regional Registration Request in which the "S" bit will be set. The care-of address is the advertising FA's address. The MN may add a Hierarchical FA extension to the Regional Registration Request, in order to identify the regional FA path to be followed by the Request up the hierarchy. A Regional FA receiving a Regional Registration Request with it's own address as HA address may return a Regional Registration Reply to the MN. If there is no IP address in common between the extensions, then the MN must have moved into a new hierarchy and the GFA advertised in the new extension must be different from the one in the previously cached extension(s). When the MN moves between administrative domains (i.e. changes GFA) then the MN should use the new GFA's IP address as care- of address in its new Registration Request to the HA and may add the Hierarchical FA extension as described previously. If the MN has at least one existing active binding when it moves to the new GFA, it may perform a smooth handoff as explained in section 3.4. The MN is able to perform this option to implement NAMONC Handoffs only if its binding lifetime with the GFA or HA does not expire MIPv4 Handoffs Design Team [Page 12] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 during the period needed by the MN to complete its handoff. Intermediate regional FAs are able to accept the MN's regional registration (simultaneous binding) only if the intermediate regional FA has an existing active binding for the MN. The resulting simultaneous binding may therefore have a maximum possible lifetime equal to the lifetime remaining in its previously existing active binding. Once the registration lifetime with the GFA or HA is about to expire, the MN must perform a new Mobile IP registration with the HA. 3.3 Regional Deregistration for NAMONC Handoffs Regional deregistration is described in [2]. In this draft we apply the deregistration procedure to NAMONC Handoffs. When the MN performs a regional registration with a "new" regional FA, then a regional deregistration must be performed with the MN's old location, which may include all the FAs in its old regional branch. This is necessary to avoid incorrect routing of packets by the "previous" FA(s) in the old regional branch during the interval in which the MN has moved but the "previous" FA(s)'s regional binding lifetime for the MN has not yet expired. The regional deregistration is performed by a regional FA upon the first time it receives a valid Regional Registration Request, without the "S" bit set, from a MN which had previously set the "S" bit in its regional registration(s). This regional FA may respond with a Registration reply and may perform the Regional deregistration by sending a Binding Update with zero lifetime to the "next" regional FA in the MN's old regional branch, setting the Binding Update's care-of address to the the previous care-of address it had registered for the MN (i.e. the "previous" lowest level FA). The Binding Update is relayed down towards the previous care-of address, and each regional foreign agent in the hierarchy receiving this notification removes its binding for the MN. In this way, the MN updates all the Regional FAs in the "old" hierarchical branch between the "common route" FA and the "old" lowest level FA. It is assumed that GFA/FAs within the same hierarchical domain share a Security Association which can be used to perform this deregistration. The MN will be able to perform regional deregistrations through intermediate regional FAs if the GFA shares its GFA-MN security association with the regional FAs. Otherwise the regional deregistration will be performed by the GFA. 3.4 Smooth Handoffs between Hierarchies (GFAs) When the MN moves between domains it receives Mobility Agent extensions containing a new GFA IP address. The MN registers with its HA using the new GFA IP address as care-of address. In order to MIPv4 Handoffs Design Team [Page 13] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 improve inter-domain handoffs it may use the Previous Foreign Agent extension in the Regional Registration Request [4]. This results in a smooth handoff between the domains. A new flag is required in the Binding Update message to perform a smooth handoff while maintaining the existing binding in the "previous" FA. This is the "S" bit for the simultaneous binding. This simultaneous binding is necessary in the case in which the MN only momentarily moves "forward" to the new domain, then returns back to the "previous" FA (domain) before its previous binding expires. In this case the binding for the MN with the "previous" FA must be maintained. Following is the new Binding Update message with the "S" flag added which replaces one bit of the Reserved space. The "S" flag is described below. 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 |A|I|M|G|S| Rsv | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- S Simultaneous Bindings flag (see [1]). When set (1) it indicates that this binding for the MN must be added to the binding list and MUST NOT replace existing bindings for that MN. 3.5 L2 Address Considerations for NAMONC Handoffs MNs connected to networks utilising interfaces such as ethernet (e.g. between FAs and wireless access points) MAY use an L2 extension to the Registration messages. Such an extension is required in Ethernet- based networks when the MN performing a registration with a FA which is not its first-hop router needs to communicate its L2 address to that FA. Therefore the FA must use the L2 address in this extension to communicate with the MN instead of the L2 source address of the incoming Registration Request message as specified in RFC2002. Such an extension is described in section 5 of this draft. In many cases MIPv4 Handoffs Design Team [Page 14] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 wireless standards have defined special L2 interfaces to the wireless network which allows these networks to resolve the mapping between MN IP address and L2 address without the need to use these extensions. Therefore such extensions would not be needed. 3.6 Advantages and Applicability of NAMONC Handoff Method The NAMONC Handoff method is applicable to scenarios where Mobile IP Registrations are supported by the mobile nodes and the network. This method is compatible with RFC2002 and therefore is based on the same security model including the use of AAA. It is assumed that FAs are able to obtain L2 triggers from the wireless network which inform the FA that an L2 handoff procedure is being initated for a certain MN to another access point or radio network having a certain ID. The FA must be able to determine the IP address of the new FA from this ID using methods which may be specific to the wireless network and are not considered here. If the FA determines that the ID is within its coverage area then NAMONC Handoff should not be initiated. This "anticipated" L2 trigger must allow enough time for the NAMONC Handoff procedure to be performed. In many wireless systems the L2 handoff procedure involves a number of message exchanges before the effective L2 handoff is performed. Therefore the NAMONC Handoff method can be initiated at the beginning of the L2 handoff procedure and completed before the L2 handoff is completed. It may be necessary to engineer the system such that this succession of events is ensured. The NAMONC Handoff method provides advantages in the following cases: - When the MN has locally defined policies that determine a preference for one access over another (e.g. service cost) and therefore where it is necessary to allow the MN to select the appropriate FA to connect to. - When L3 cannot rely upon L2 security (between MN and FA) to make modifications to IP routing and therefore authenticated Mobile IP messages are required. In the first case it is necessary to involve eventual local MN policies in the movement detection procedure as described in 3.2. 4. Network Initiated, Mobile Terminated (NIMOT) Handoff Method As discussed in the Introduction, in the Network-Assisted Handoff method, the FA makes use of information from layer 2 to optimize handoff by doing a fast "pre-registration" prior to the formal Mobile IP registration done by the MN. The goal of the Network-Assisted Handoff design is to take maximum advantage of layer 2 information MIPv4 Handoffs Design Team [Page 15] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 without specifying particular layer 2 technologies. Thus the design depends on abstract L2 _triggers_ that have a very broad set of characteristics exhibited by many radio layer 2 protocols. In RFC 2002, no assumptions are made about the existence of any layer 2 support for handoff. In pursuit of the lowest latency possible given such layer 2 information, the Network-Assisted design proposes taking maximum advantage of any layer 2 information available, and therfore that RFC 2002 requires enhancement. The Network-Assisted design proposes new messages that work together with standard Mobile-IP handoff to reduce handoff latency. In this document, we will assume that the link-layer events are signaled to the Foreign Agent as "triggers". We assume that any such triggers will be sufficient to derive the IP addresses of the Foreign Agents that will receive or send the hand-off. If such a trigger is not available or if the MN decides on its own that a hand-off is to take place, then one of the FAs can often still derive the identity (IP address) of the other from link-layer messages or through preconfiguration. In order for the Mobile IP protocol to provide low-latency hand-off, the following problems must be addressed: 1. Reducing the latency involved in the registration process. Although optimization of the Registration process is not typically considered a Hand-Off problem, this proposal assumes that such a mechanism is in place. 2. Reducing the latency involved in the Mobile Node's movement detection process. 3. "Bi-casting" the Mobile Node's traffic to two (or more) points of attachment, ensuring that the mobile's traffic is delivered as soon as the link layer hand-off is completed. 4. Support for Reverse Tunneling, which MAY be required for private addresses. 5. The Security Relationships between the mobility entities for inter-domain hand-offs. 6. Does not increase mobile power consumption 4.1 Registration Latency The Mobile IP protocol [1] requires that a Mobile Node registers with a Foreign Agent, and subsequently its Home Agent, in order to have its packets delivered to its current point of attachment. The Mobile IP Regional Registration [2] specification proposes optimized registration approaches using Gateway Foreign Agents (GFAs), which are mobility agents that act as concentration points for Foreign Agents within an Administrative Domain. GFAs allow a Mobile Node's registration message to be processed by a Mobility Agent in the local domain, eliminating the need to contact the Home Agent, which MAY be topologically distant. MIPv4 Handoffs Design Team [Page 16] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 4.2 Movement Detection The Mobile IP protocol [1] and the Regional Registration extension [2] require Mobile Nodes to listen for, or solicit, advertisements in order to detect that a movement to a new IP subnet has occurred. This movement detection mechanism introduces significant latency into the hand-off process, which causes service degradation, especially for real-time services. Service is further impacted given the additional latency introduced through the registration process that follows the movement detection, since the mobile's traffic can only be delivered once all of the registration has completed. There have been many solutions proposed to solve this problem, including increasing the advertisement frequency. In networks where radio spectrum is expensive or bandwidth is limited, the additional signaling required for increasing advertisement frequency is a serious issue impacting deployability. In this document, we propose that the Foreign Agent take a pro-active approach and issue the Handoff messages on behalf of the Mobile Node (acting as a surrogate of sorts). When a Foreign Agent is aware that a hand-off is occurring at the link-layer, a trigger is sent to the Mobile IP protocol stack. +-----+ | GFA | +-----+ ^ | 3. Regional | | 4. Regional Reg Request | | Reg Reply | v +-----+ 1. Handoff Request +-----+ | | -----------------> | | | oFA | | nFA | | | 2. Handoff Reply | | +-----+ <----------------- +-----+ +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 3 - Source Trigger Pro-Active Handoff A source trigger (see Figure 3) is one that is obtained by the old Foreign Agent (oFA) once the link layer detects that the Mobile Node is departing its coverage area. A target trigger (see Figure 4), on the other hand, is one that is obtained by the new Foreign Agent (nFA) once the link layer detects that the Mobile Node is arriving in its coverage area. Note that both triggers may be available before the actual completion of the link layer handoff. MIPv4 Handoffs Design Team [Page 17] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 The messages depicted in both Figures 3 and 4 are very similar. The main difference is the initiator of the Handoff Request message. In both examples, an optional Gateway Foreign Agent is used, which requires the use of the Regional Registration messages [2]. In both the source and target triggers, a Foreign Agent obtains link-layer information, such as power measurements, that indicate the necessity of a handoff to the new Foreign Agent. In the event of a source trigger, oFA transmits a Handoff Request message to nFA. The Handoff Request MUST include the Mobile Node's Home Address, Home Agent Address, remaining registration lifetime, as well as the Link-Layer Address Extension (see Section 5). The GFA's identity MUST also be present, if one was used for the Mobile Node's registration. Upon receipt of the message, nFA MUST create the Mobile Node's visitor entry, and respond with the Handoff Reply message. +-----+ | GFA | +-----+ ^ | 3. Regional | | 4. Regional Reg Request | | Reg Reply | v +-----+ 1. Handoff Request +-----+ | | <----------------- | | | oFA | | nFA | | | 2. Handoff Reply | | +-----+ -----------------> +-----+ +-----+ Movement +-----+ | MN | - - - - - - - - -> | MN | +-----+ +-----+ Figure 4 - Target Trigger Pro-Active Handoff In target triggers, the trigger occurs on nFA, which results in the transmission of a Handoff Request to oFA. The Handoff Request message MUST include the Mobile Node's Link-Layer Address (see Section 5) in order for oFA to correctly identify the Mobile Node. The request message MAY include additional Mobile Node information, if such information was provided by the link layer. Upon receipt of the request, oFA MUST respond with the Handoff Reply message, which includes the Mobile Node's Home Address, Home Agent Address, remaining registration lifetime and Link-Layer Address Extension. If a GFA was used in the Mobile Node's registration, it's address MUST be supplied. Regardless of the direction of the Handoff Request, if nFA receives GFA information within the message from oFA, it SHOULD issue a Regional Registration Request with the GFA, which will respond with the Regional Registration Reply. MIPv4 Handoffs Design Team [Page 18] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 4.3 Ping-Pong effect Some link-layers are subject to rapid motion of MNs between two FAs. For example, even though link-layer power measurements may indicate that a hand-off is necessary, the mobile may fail to attach to the new point of attachment, and return almost immediately to its old point of attachment. This event is known as a "ping-pong" effect. Data +-----+ Data +----+ +-------------| oFA |<--------------------------| HA | | +-----+ +----+ v ^ | +----+ Handoff | | Data | MN | Request | | +----+ | | ^ v v | +-----+ +-------------| nFA | Data +-----+ Figure 5 - Bi-Casting by the Anchor Foreign Agent Figure 5 provides an example of bi-casting a Mobile Node's through both the old and new Foreign Agents. Bi-casting is established when the oFA issues a successful Handoff Reply to nFA, or receives a successful Handoff Reply from nFA. This causes oFA to forward all of the Mobile Node's traffic to the nFA, as well as to the Mobile Node, if a link-layer channel exists. Figure 6 provides an example where bi-casting is performed on the Gateway Foreign Agent, which is initiated by nFA setting the 'S' bit (Simultaneous Binding) in the Regional Registration Request. Data +-----+ Data +-------------| oFA |<-------------+ | +-----+ | v | +----+ +-----+ Data +----+ | MN | | GFA |<--------| HA | +----+ +-----+ +----+ ^ | | +-----+ | +-------------| nFA |<-------------+ Data +-----+ Data Figure 6 - Bi-Casting by the Gateway Foreign Agent When simultaneous bindings are in effect, and a ping-pong event occurs, the mobile's service is guaranteed not to experience any additional latency beyond that imposed by the link-layer handoff. MIPv4 Handoffs Design Team [Page 19] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 4.4 Reverse Tunneling Support In the event the Mobile Node requested Reverse Tunneling [5] support, by setting the 'T' bit in its Registration Request, the Handoff message from oFA (see Sections 4.7 and 4.8) includes the 'T' bit enabled to inform nFA to establish a bi-directional tunnel for the visitor entry. 4.5 Security Relationships The Mobile IP Regional Registration specification [2] requires that the communicating Mobility Agents exchange authenticated messages. This imposes a requirement for Mobility Agents to share a pre- established security association. This assumption is valid for intra- domain mobility (mobility within an Administrative Domain). However, such a requirement introduces a scaling problem when the Mobility Agents are owned by separate Administrative Domains (ADs). Given that the existing AAA infrastructure is used to establish dynamic security associations between Foreign and Home Agents in different ADs, the same infrastructure could be used to establish the required security association for the purposes of inter-domain hand- offs (see Figure 7). +-----+ +-----+ | AAA |-------------->| AAA | +-----+ +-----+ ^ | | | | AAA | | Hand-Off | | Req | | v +-----+ +-----+ | oFA | | nFA | +-----+ +-----+ +-----+ Movement +-----+ | MN | - - - - - - > | MN | +-----+ +-----+ Figure 7 - Inter-FA communication using AAA Note that it is possible for geographically neighboring Foreign Agents owned by different Administrative Domains to have a pre- established security association, which would reduce the latency introduced by the AAA infrastructure traversal. Given that such geographically neighboring FAs MAY be small in number, such an approach MAY be reasonable. MIPv4 Handoffs Design Team [Page 20] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 4.6 Operation A Foreign Agent can receive two different types of triggers informing it of a handoff (The event that causes the trigger may be derived via link layer messaging assistance from the network or from the mobile): - a "source trigger" is when the old FA is informed of an upcoming link-layer handoff, - a "target trigger" occurs at the new FA when it is informed that a link layer handoff is in progress. The method by which such triggers occur are link-layer specific, and are outside the scope of this document. It is also possible that a particular kind of link layer technology can support both source and target triggers. 4.6.1 Foreign Agent Considerations Upon receipt of a trigger event, a Foreign Agent MAY issue a Handoff request message to the Foreign Agent the mobile is being handed off to/from. If the message is the result of a target trigger, the Type Of Trigger bit MUST be set and the Link-Layer Address Extension (see Section 5) MUST be present. The message's Home Address and Home Agent Address fields MAY be set to NULL if this information is not known at the time the message is transmitted. Upon receipt of a Handoff Request message with the Type Of Trigger bit set, a Foreign Agent MUST respond with the Handoff Reply message. The Handoff Reply MUST include both the Mobile Node's Home Address and Home Agent Address in the message header. The remaining mobile's registration lifetime MUST be included in the Reply's lifetime field. Furthermore, the Foreign Agent MAY include any security associations that were dynamically created. If a Gateway Foreign Agent was used in the Mobile's registration, the GFA's identity MUST be included in the Gateway Foreign Agent Address Extension [2] MUST be present. A Foreign Agent that issues such a Handoff Reply with the Code field set to success (zero value) MUST "bi-cast" all packets destined to the Mobile Node to both the Mobile Node and to the new Foreign Agent. The Foreign Agent that receives a successful Handoff Reply message (one that includes a zero value in the Code field), a visitor entry is created with the information found in the message. The Foreign Agent MUST be prepared to deliver packets to the Mobile Node prior to receiving a Registration Request [1] from the Mobile Node. Note that it is possible for the encapsulation method used between oFA and nFA to be different from the one requested by the Mobile Node MIPv4 Handoffs Design Team [Page 21] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 during its Registration process. When this occurs, the respective Foreign Agents MUST perform encapsulation translation. A Foreign Agent that receives a source trigger, it MUST send a Handoff Request message with the Type Of Trigger bit disabled. The message MUST also include the Mobile Node's Home Address and Home Agent Address in the message header. The remaining mobile registration lifetime MUST be included in the lifetime field. The Foreign Agent MAY also include any security associations that were dynamically created. If a Gateway Foreign Agent was used for the mobile, it's identity MUST be included in the Gateway Foreign Agent Address Extension [2]. Upon receipt of a Handoff Request with the Type Of Trigger bit disabled, a Foreign Agent MUST process the packet and respond with the Handoff Reply message. If successfully processed, the Foreign Agent MUST create a Visitor Entry for the Mobile Node, and be prepared to deliver packets received by the initiator of the Handoff Request destined for the Mobile Node. The Handoff Reply message MUST include the Home Address, Home Agent Address, lifetime value, and the Link-Layer Address Extension (see Section 5). A Foreign Agent that receives a Handoff Reply with the Code field set to success (zero value) MUST "bi-cast" all packets destined to the Mobile Node to both the Mobile Node and to the new Foreign Agent. If the message received by the new Foreign Agent contained a GFA IP Address Extension [2], and it shares a security association with the GFA, it MUST issue a Regional Registration Request to the GFA. The Regional Registration Request's Care-Of address field MUST be set to the local Foreign Agent's address, while the GFA IP Address MUST be set to the address of the recipient of the request. The request's lifetime field is set to an administratively configured value. A successful Regional Registration Reply MUST cause the Foreign Agent to create a visitor entry for the Mobile Node. If a Regional Registration Reply message is received with the code field set to DO_NOT_SERVICE_MN (Section 4.9), the Foreign Agent SHOULD NOT provide service to the Mobile Node. The Foreign Agent MAY enforce this by closing the Link-Layer connection (if possible), not issuing any Mobility Advertisements to the Mobile Node (assuming a point-to- point Link Layer), or simply denying all Registration Requests with the error code set to 65 (Administratively Prohibited) [1]. Once a visitor entry has been created, and the Mobile Node establishes a link layer channel with the Foreign Agent, its traffic will be immediately delivered, along with a Mobility Advertisement message [1]. A Mobile Node MUST issue a Registration Request when it receives a Mobility Advertisement from a new Foreign Agent. MIPv4 Handoffs Design Team [Page 22] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Note that Foreign Agents MAY delay in sending Mobility Advertisements, especially to reduce noticeable service disruption during a ping-pong effect. However, when doing so, the Foreign Agent MAY need to re-issue a new Handoff Request to oFA (and optionally the Regional Registration message to GFA), to extend the visitor entry's lifetime. Delaying Mobility Advertisements MAY also be done in wireless technologies that support dormant mobiles. When this is done, a Foreign Agent would typically wait to send the advertisement until the mobile is no longer in the dormant mode. When data is received by the Foreign Agent for a dormant Mobile Node, it SHOULD initiate the link-layer mechanism that causes the mobile to "wake-up" (this is typically known as paging). The above procedures require that Foreign Agents issue Handoff Requests as a result of Link-Layer triggers. However, the discovery of the identity of the Foreign Agents to which the Handoff messages must be sent is outside the scope of this document. In the event that a Foreign Agent handling a particular Mobile Node's visitor entry is soon to expire, and the Mobile Node has not yet issued a Registration Request, the FA has the option to transmit a new Handoff Request message to the old Foreign Agent (and the optional Regional Registration Request to the GFA). Whether the renewal is performed on behalf of the Mobile Node is a policy decision up to the network administrator. A Foreign Agent MAY receive packets for a Mobile Node to which it does not have a direct link layer connection. At this point, the Foreign Agent MAY: 1. Drop all packets for the Mobile Node 2. Buffer packets for the Mobile Node 3. Attempt to establish a link-layer connection with the mobile 4. Issue a Regional Registration Request with a zero lifetime Given that a Mobile Node's packets will be delivered prior to registration, a Mobile Node is free to discard all packets received from Foreign Agents with which it hasn't registered. When the new Foreign Agent receives the Mobile Node's Registration Request [1], its Anchor Foreign Agent (GFA as first-hop router) changes to the new Foreign Agent. The Foreign Agent MUST transmit a Handoff Request message to the old Foreign Agent with the lifetime field set to zero. A Foreign Agent that receives a Handoff Request with the lifetime field set to zero is being informed that it is no longer the anchor point for the mobile. It MAY issue a Handoff Request to the new Foreign Agent in the future if it wishes to keep receiving the mobile's packets for possible delivery. MIPv4 Handoffs Design Team [Page 23] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 When a Foreign Agent determines that it is no longer servicing a Mobile Node, it SHOULD issue a Regional Registration Request message with the lifetime field set to zero (0). This will cause the visitor entry associated with the Foreign Agent's Care-Of address on the GFA to be deleted. Foreign Agents MAY decide to not issue this message immediately when a link-layer trigger is received, in order to support smooth service during a ping-pong event. 4.6.2 Gateway Foreign Agent Considerations Upon receipt of a Regional Registration Request, a GFA MUST create a visitor entry indicating the Mobile Node's current point of attachment. In the event that a visitor entry already exists, the GFA SHOULD be able to create multiple visitor entries for the same Mobile Nodes with different Care-Of addresses. If the 'S' bit was enabled in the Regional Registration Request, the GFA MUST be able to forward the mobile's packets to all Foreign Agents in the visitor entries. When constructing the Regional Registration Reply, the GFA SHOULD include the FA-FA authentication extension [2], and set the lifetime field to the lesser of: 1. number of seconds before the Mobile Node's Registration with its Home Agent will expire. 2. The lifetime of the locally created Visitor Entry. In the event that the Regional Registration Request's lifetime field was set to zero (0), the GFA MUST remove the visitor entry associated with the Care-Of address in the message. Should the GFA decide that the Foreign Agent is not to provide service to the Mobile Node, it MUST issue a Regional Registration Reply message, with the code field set to DO_NOT_SERVICE_MN (see Section 4.9). 4.7 Handoff Request Message The Handoff Request message is used to inform a peer that a pro- active handoff is being initiated. The Handoff Request message can be used for both source and target triggers, through the Type of Trigger 'I' bit in the message flags. When sent as a result of a target trigger, the Home Address and Home Agent fields MAY be set to zero (unless this information was communicated by the link layer, which is outside the scope of this document). MIPv4 Handoffs Design Team [Page 24] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|x|I|M|G|r|T|x| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Handoff Request) S When set, and when no GFA address extension is present, it indicates that both oFA and nFA will attempt to deliver datagrams directly to MN, if a link-layer connection exists. If a GFA address extension is present, it implies that nFA should set the 'S' bit in its regional registration. I Type of Trigger. A value of zero is a source trigger (sent by oFA), while a value of one is a target trigger (sent by nFA). M, G, T As defined in [1,5]. This refers to the tunnel between oFA and nFA, or, if GFA IP address extension is present, to the parameters that should be requested in the Regional Reg Req. Lifetime The requested Lifetime for which nFA will serve the MN on behalf of oFA, without requiring a new registration. MN Home Address The home address of the mobile node. When using a private address, the G and T flags must be sent and a GRE Key extension must be included. Home Agent Addr The home agent address of the mobile node. Identification As in defined in [1]. Extensions The Message MUST include LLA (see Section 5), the FA-FA Authentication Extension [2], and MAY include GFA IP address. MIPv4 Handoffs Design Team [Page 25] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 4.8 Handoff Reply Message The Handoff Reply message is sent in response to the Handoff Request message. When a source trigger caused the Handoff Request message to be sent, this message is sent with a successful code if the Visitor Entry was successfully created. When a target trigger caused the Handoff Request message, receipt of this message with a successfuly code SHOULD cause the Visitor Entry to be created. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|x|I|M|G|r|T|x| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type TBD (Handoff Reply) Code A value indicating the result of the Handoff Request. See below for a list of currently defined Code values. Lifetime If the Code field indicates that the registration was accepted, the Lifetime field is set to the number of seconds remaining before the registration is considered expired. A value of zero indicates that the mobile node has been deregistered. A value of 0xffff indicates infinity. If the Code field indicates that the registration was denied, the contents of the Lifetime field are unspecified and MUST be ignored on reception. S When set, and when no GFA address extension is present, it indicates that both oFA and nFA will attempt to deliver datagrams directly to MN, if a link-layer connection exists. If a GFA address extension is present, it implies that nFA should set the 'S' bit in its regional registration. MIPv4 Handoffs Design Team [Page 26] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 I Type of Trigger. A value of zero is a source trigger (sent by oFA), while a value of one is a target trigger (sent by nFA). M, G, T As defined in [1,5]. This refers to the tunnel between oFA and nFA, or, if GFA IP address extension is present, to the parameters that should be requested in the Regional Reg Req. MN Home Address The home address of the mobile node. When using a private address, the G and T flags must be sent and a GRE Key extension must be included. Home Agent Addr The home agent address of the mobile node. Lifetime The requested Lifetime for which nFA will serve the MN on behalf of oFA, without requiring a new registration. Identification As in defined in [1]. Extensions The Message MUST include LLA (see Section 5) and the FA-FA Authentication Extension [2]. 4.9 Error Values The following table contains the name of Code [6] to be returned in a Registration Reply, the value for the Code, and the section in which the error is first mentioned in this specification. Error Name Value Section of Document ---------------------- ----- ------------------- DO_NOT_SERVICE_MN TBD 4.6.1 4.10 Security Considerations Similar to [2], this specification assumes that the local Foreign Agent, and the GFA inherently trust each other. This MAY be achieved through the use of a long lived security association. This specification introduces a new change to Mobile IP, which is the ability for a Mobile Node to receive packets from a Foreign Agent to which it has not yet registered. In the event that the Mobile Node does not wish to receive packets from unknown Foreign Agents, it MAY drop them. Although this document does not specify how Foreign Agents can identify, or track, Mobile Nodes, it is assumed that the wireless MIPv4 Handoffs Design Team [Page 27] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 link layer be sufficiently secure in order to correctly identify a Mobile Node. Wireless networks that do not provide such features will be subjected to impersonation attacks, where malicious nodes could cause the Foreign Agents to believe that a Mobile Node has moved to other service areas. 4.11 Advantages and Applicability of NIMOT Handoff Method The NIMOT handoff approach allows foreign agents to communicate directly about a pending handoff, and does not require any IP layer messages to be sent to or from a mobile node prior to the link layer handoff event. Therefore, it does not place the mobile node's IP stack or Mobile IP client implementation on the critical path after a need for handoff is recognized but before the handoff can take place. This separation is necessary when the link layer (or the laws of physics) imposes hard deadlines on the time at which a handoff must occur, such as when a mobile node is rapidly moving out of a radio coverage area, but when the mobile node's IP stack is not implemented as a hard real-time system. Because a NIMOT handoff is triggered by some unspecified mechanism that informs the old or new foreign agent that a handoff is needed, the NIMOT approach is only applicable to networks where such a mechanism is available. For example, a link layer may provide power measurements or other indications of radio signal quality that cause the old or new foreign agent to send the NIMOT handoff messages. Any such indications must also provide each foreign agent involved in the handoff with the identity of the other, so that messages can be sent to the right place. This may involve mapping link layer information onto foreign agent identities. Also, the foreign agents involved in a handoff must have pre-provisioned security arrangements so that the NIMOT messages can be authenticated. If a handoff is to be completed as a result of the NIMOT messaging without continuing to bicast traffic to both the old and new coverage areas, then any link layer handoff indications must also be securely authenticated so that traffic to the old point of attachment is not improperly halted. MIPv4 Handoffs Design Team [Page 28] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 5. Generalized Link Layer Address Extension This section defines the Generalized Link Layer Address (LLA) Extension, used by any that needs to communicate Link Layer Addresses. The format of the extension follows MIER [7], and each sub-type of link-layer address defines its own sub-structure. This draft defines two sub-types, the IMSI and the Ethernet Address. Future RFCs should allocate their own sub-type and define their own address formats. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | LLA ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length The length of the Link Layer Address + the one octet Sub-Type field Sub-Type This field contains the Link Layer sub-type identifier LLA Contains the Link Layer Address In this document, two subtypes are defined: 1 International Mobile Station Identity (e.g. [8]) 2 Ethernet 48 bit MAC address [9] 3 64 bit Global ID, EUI-64 [10] 5.1 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MIPv4 Handoffs Design Team [Page 29] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Type TBD (skippable) [1] Length The length of the IMSI field + the one octet Sub-Type field Sub-Type 1 IMSI Contains the IMSI, in the form: : Where the is an ASCII-based representation of the International Mobile Station Identifier, most significant digit first, ":" is ASCII 0x3a, and the Connection ID is the ASCII representation of a small, decimal number used for distinguishing different link-layer connections from the same device. 5.2 Ethernet Link Layer Address Extension The Ethernet Link Layer Address Extension contains the 48 bit Ethernet MAC Address, as defined in [9]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 7 (includes the Sub-Type field) Sub-Type 2 MAC MIPv4 Handoffs Design Team [Page 30] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Contains the 48 bit Ethernet MAC Address. 5.3 IEEE 64-Bit Global Identifier (EUI-64) Address Extension The 64-Bit Global Identifier (EUI-64) Address Extension contains the 64 bit address, as defined in [10]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | MAC ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD (skippable) [1] Length 7 (includes the Sub-Type field) Sub-Type 3 MAC Contains the 64-Bit Global Identifier Address. 6. IANA Considerations The number for the Generalized Link Layer Address Extension in section 5 is 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 NIMOT Handoffs method, the Code values specified for errors, listed in section 4.9, MUST NOT conflict with any other code values listed in RFC 2002 [1], RFC 2344 [5], RFC 2356 [12], RFC 2794 [13] and RFC 3012 [11]. Also Sections 4.7 and 4.8 require numbers assigned from the Mobile IP control message type address space. The numbers assigned MUST NOT conflict with [1] and [2]. MIPv4 Handoffs Design Team [Page 31] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 7. References [1] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October 1996. [2] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional Tunnel Management ", draft-ietf-mobileip-reg-tunnel-03.txt (work in progress), July 2000. [3] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". BCP 14. RFC 2119. March 1997. [4] C. Perkins and D. Johnson, "Route Optimization in Mobile IP",draft-ietf-mobileip-optim-10.txt (work in progress), November 2000. [5] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344, May 1998. [6] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. [7] M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura, "Mobile IP Extensions Rationalization (MIER)", draft-ietf-mobileip-mier- 05 (work in progress), Dec. 1999 [8] TIA/EIA/IS-95-B [9] D. Plummer, "An Ethernet Address Resolution Protocol - or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, Symbolics,Inc., November 1982. [10] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/regauth/oui/tutorials/EUI64.html, March 1997. [11] C. Perkins, P. Calhoun, Mobile IP Challenge/Response Extensions. RFC 3012, November 2000. [12] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for Mobile IP", RFC 2356, June 1998. [13] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier Extension", RFC 2794, March 2000. MIPv4 Handoffs Design Team [Page 32] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 8. Authors' Addresses The authors may be contacted at the addresses below: Karim El Malki Ericsson Radio Systems AB LM Ericssons Vag. 8 126 25 Stockholm SWEDEN Phone: +46 8 7195803 Fax: +46 8 7190170 E-mail: Karim.El-Malki@era.ericsson.se Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 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 Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-mail: james.kempf@eng.sun.com MIPv4 Handoffs Design Team [Page 33] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566-7050 USA Phone: +1 630 713 9359 Fax: +1 630 713 4982 E-Mail: mccap@lucent.com Ajoy Singh Motorola 1501 West Shure Drive Arlington Heights, IL o 60004 USA Phone: +1 847 632 6941 E-mail: asingh1@email.mot.com Hesham Soliman Ericsson Radio Systems Torshamnsgatan 29, Kista Stockholm SWEDEN Phone: +46 8 7578162 Fax: +46 8 4043630 E-mail: Hesham.Soliman@era.ericsson.se Sebastian Thalanany Motorola 1475 West Shure Drive Arlington Heights, IL - 60004 USA Phone: +1 847 435 9296 E-mail: sthalan1@email.mot.com The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Corporation Motorola M/S M8-540 6000 Connection Drive 1501 West Shure Drive Irving, TX 75039 Arlington Heights, IL 60004 USA USA MIPv4 Handoffs Design Team [Page 34] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Phone: +1 972-894-6709 Phone: +1 847-632-3148 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com Fax : +1 972-894-5349 9. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in anyway, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided onan "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MIPv4 Handoffs Design Team [Page 35] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Appendix A - Gateway Foreign Agents The Mobile IP Regional Registration specification [2] introduces the Gateway Foreign Agent (GFA), as a mobility agent that two Foreign Agents providing service to a Mobile Node have in common. Figure 1 provides an example of a Mobile's initial registration, through the GFA. Given this is the first registration message, the message MUST be forwarded to the Home Agent. All packets destined for the mobile will be delivered to the GFA, which in turn will forward the packets to the Foreign Agent servicing the Mobile Node. Reg Req +-----+ Reg Req +----------->| oFA |--------------+ | +-----+ | | v +----+ +-----+ Reg Req +----+ | MN | | GFA |<------->| HA | +----+ +-----+ +----+ +-----+ | nFA | +-----+ Figure A.1 - Initial Registrations through GFA In the event that the mobile moves to a new Foreign Agent that is serviced by a GFA that is common with oFA, the Mobile Node MAY issue a Regional Registration Request (see Figure A.2). The Regional Registration message does not need to be forwarded to the Home Agent, since the mobile's traffic can still be delivered to the same GFA. This optimized approach effectively reduces the latency involved in the registration process. +-----+ | oFA | +-----+ +----+ +-----+ +----+ | MN | | GFA | | HA | +----+ +-----+ +----+ | ^ | +-----+ | +------------>| nFA |-------------+ Regional Reg +-----+ Regional Reg Figure A.2 - Regional Registration through GFA Note that the GFA may also be the MN's first-hop router. MIPv4 Handoffs Design Team [Page 36] INTERNET-DRAFT Low Latency Mobile IPv4 Handoffs February 2001 Appendix B - Bicasting Applicability Statement Both NAMONC and NIMOT Handoffs propose using bicasting as a technique for delivering packets to the MN through both the old and new FA. Bicasting is used in order to avoid dropping packets while the handoff is in progress and to decouple the handoff process from layer 2 handoff timing. Other techniques, for example buffering, have been proposed for smooth handoff [4]. Since the interaction between TCP and bicasting has not been fully studied, bicasting should be considered only in cases where layer 2 support is available to co- ordinate handoff such that duplicate packet delivery to the MN can be reduced or avoided, until the interactions between TCP and bicasting are more clearly understood. Neither low latency handoff technique is dependent on the use of bicasting for low-loss handoffs, though a low-loss handoff technique is required for a fully seamless solution. MIPv4 Handoffs Design Team [Page 37]