[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 07 08 09 10 11 RFC 4881

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
           <draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt>


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:

                       <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.


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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/