[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [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: April 2002                                       Pat R. Calhoun
                                                              Tom Hiller
                                                             James Kempf
                                                         Peter J. McCann
                                                              Ajoy Singh
                                                          Hesham Soliman
                                                     Sebastian Thalanany


                                                            October 2001


                    Low Latency Handoffs in Mobile IPv4
            <draft-ietf-mobileip-lowlatency-handoffs-v4-02.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/lid-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This document is a product of the Mobile IP WG.


Abstract

   Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs
   between subnets served by different Foreign Agents. In certain cases,
   the latency involved in these handoffs can be above the threshold
   required for the support of delay-sensitive or real-time services.
   The aim of this document is to present two methods to achieve low-
   latency Mobile IP handoffs. In addition, a combination of these two
   methods is described. The described techniques allow greater support



MIPv4 handoffs design team                                      [Page 1]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   for real-time services on a Mobile IPv4 network by minimising the
   period of time when a Mobile Node is unable to send or receive IP
   packets due to the delay in the Mobile IP Registration process.

TABLE OF CONTENTS

   1. Introduction.....................................................3
      1.1. Terminology ................................................3
      1.2. The Techniques .............................................5
      1.3. L2 triggers ................................................6
      1.4. Requirements language ......................................9
   2. Requirements.....................................................9
   3. The PRE-REGISTRATION Handoff Method..............................9
      3.1. Operation .................................................10
      3.2. Network-Initiated Handoff .................................12
      3.3. Mobile-Initiated Handoff ..................................14
      3.4. Obtaining and Proxying nFA Advertisements .................15
          3.4.1. Inter-FA Solicitation................................15
          3.4.2. Tunneled nFA Advertisements..........................16
          3.4.3. Piggy-backing Advertisements on L2 messaging.........16
      3.5. Caching Router Advertisements .............................17
      3.6. Movement Detection and MN Considerations ..................17
      3.7. L2 Address Considerations .................................18
      3.8. Applicability of PRE-REGISTRATION Handoff .................18
   4. The POST-REGISTRATION Handoff Method............................19
      4.1. Two Party Handoff .........................................20
      4.2. Three Party Handoff .......................................24
      4.3. Renewal or Termination of Tunneling Service ...............29
      4.4. When will the MN perform a Mobile IP Registration? ........30
      4.5. MN Considerations .........................................30
      4.6. Handoff Request (HRqst) Message format ....................31
      4.7. Handoff Reply (HRply) Message .............................33
      4.8. Handoff To Third (HTT) Message ............................34
      4.9. Applicability of POST-REGISTRATION Handoff Method .........35
   5. Combined Handoff Method.........................................36
   6. Layer 2 and Layer 3 Handoff timing Considerations...............36
   7. Reverse Tunneling Support.......................................37
   8. Generalized Link Layer Address Extension........................37
      8.1.  3GPP2 IMSI Link Layer Address and Connection ID Extension 38
      8.2.  3GPP IMSI Link Layer Address Extension ...................39
      8.3.  Ethernet Link Layer Address Extension ....................39
      8.4.  IEEE 64-Bit Global Identifier (EUI-64) Address Extension .40
      8.5.  Solicited IP Address Extension ...........................40
      8.6.  Solicited Access Point Identifier Extension ..............41
   9.  IANA Considerations............................................42
   10. Security Considerations........................................42
   11. References.....................................................43
   12. Authors' Addresses.............................................44
   13. Full Copyright Statement.......................................46
   Appendix A - Gateway Foreign Agents................................47
   Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......48



El Malki (Editor) et. al.                                       [Page 2]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


1. Introduction

   Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer
   handoff between subnets served by different Foreign Agents (FAs). In
   certain cases, the latency involved in handoff can be above the
   threshold required for the support of delay-sensitive or real-time
   services. The aim of this document is to present two methods to
   achieve low-latency Mobile IP handoff during movement between FAs.
   The presented techniques allow greater support for real-time services
   on a Mobile IPv4 network by minimising the period of time when a MN
   is unable to send or receive IP packets due to the delay in the
   Mobile IP Registration process.

   In the rest of this section, terminology used throughout the document
   is presented, the handoff techniques are briefly described, and the
   use of link layer information is outlined. In Section 2, a brief
   description of requirements is presented. Section 3 describes the
   details of the PRE-REGISTRATION handoff technique, while Section 4
   describes the details of the POST-REGISTRATION handoff technique. In
   Section 5, a combined method using the two handoff techniques
   together is presented. Section 6 discusses Layer 2 and Layer 3
   handoff timing considerations. Section 7 discusses reverse tunneling
   support, while Section 8 describes protocol extensions required by
   the handoff techniques. Sections 9 and 10 discuss IANA and security
   considerations. Finally the two appendices discuss additional
   material related to the handoff techniques. Appendix A gives a short
   introduction to Regional Registrations [2] which can be used together
   with low latency handoffs. Appendix B discusses low latency handoff
   when a MN has multiple wireless L2 interfaces, in which case the
   techniques in this document may not be necessary.


1.1. Terminology

   This section presents a few terms used throughout the document.

      oFA - old Foreign Agent, the FA involved in handling a MN's
         care of address prior to an L3 handoff.

      nFA - new Foreign Agent, the FA anticipated to be handling a
         MN's care of address after completion of an L3 handoff.

      aFA - anchor Foreign Agent, the FA that is currently handling
         the network end of the BET in POST-REGISTRATION.

      L2 handoff - Movement of a MN's point of Layer 2 (L2)
         connection from one wireless access point to another.

      L3 handoff - Movement of the FA handling a MN's care of address
         at Layer 3 (L3) from oFA to nFA.




El Malki (Editor) et. al.                                       [Page 3]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


      L2 trigger - Information from L2 that informs L3 of particular
         events before and after L2 handoff. The descriptions of L2
         triggers in this document are not specific to any particular
         L2, but rather represent generalizations of L2 information
         available from a wide variety of L2 protocols.

      source trigger - An L2 trigger that occurs at oFA, informing
         the oFA that L2 handoff is about to occur.

      target trigger - An L2 trigger that occurs at nFA, informing
         the nFA that an MN is about to be handed off to nFA.

      low latency handoff - L3 handoff in which the period of time
         during which the MN is unable to receive packets is
         minimized.

      low loss handoff - L3 handoff in which the number of packets
         dropped or delayed is minimized. Low loss handoff is often
         called smooth handoff.

      seamless handoff - L3 handoff that is both low latency and low
         loss.

      bi-directional edge tunnel (BET) - A particular kind of
         bicasting in which the oFA bicasts packets destined for a MN
         to both nFA and the L2 on which the MN previously resided.
         The packets to nFA are tunneled. The tunnel is bi-
         directional because nFA tunnels packets from MN while it is
         using its old care of address back to oFA, so the packets
         appear on a topologically correct network. If the packets
         were not tunneled back to the oFA, they might be dropped by
         ingress filtering. Bi-directional edge tunnels are only
         needed in POST-REGISTRATION handoff.

      ping-ponging - Rapid back and forth movement between two
         wireless access points often due to failure of L2 handoff.
         Ping-ponging can occur if radio conditions for both the old
         and new access points are about equivalent and less than
         optimal for establishing a good, low error L2 connection.

      network-initiated handoff - L3 handoff in which oFA or nFA
         initiates the handoff.

      mobile-initiated handoff - L3 handoff in which the MN initiates
         the handoff.

      IP address identifier - An IP address of a MN or FA, or an L2
         identifier that allows an FA to deduce the IP address of a
         MN or FA. If the IP address identifier is an L2 identifier,
         it may be specific to the L2 technology.




El Malki (Editor) et. al.                                       [Page 4]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


1.2. The Techniques

   Mobile IP was originally designed without any assumptions about the
   underlying link layers over which it would operate so that it could
   have the widest possible applicability.  This approach has the
   advantage of facilitating a clean separation between L2 and L3 of the
   protocol stack, but it has negative consequences for handoff latency.
   The strict separation between L2 and L3 results in the following
   built-in sources of delay:

     - The MN may only communicate with a directly connected FA.  This
       implies that a MN may only begin the registration process after
       an L2 handoff to nFA (new FA) has completed.

     - The registration process takes some non-zero time to complete as
       the Registration Requests propagate through the network.  During
       this period of time the MN is not able to send or receive
       IP packets.

   This document presents techniques for reducing these built-in delay
   components of Mobile IP.  The techniques can be divided into two
   general categories, depending on which of the above problems they
   are attempting to address:

     - Allow the MN to communicate with the nFA while still connected
       to the oFA.

     - Provide for data delivery to the MN at the nFA even before the
       formal registration process has completed.

   The first category of techniques allows the MN to "pre-build" its
   registration state on the nFA prior to an underlying L2 handoff.
   The second category of techniques allow for service to continue
   uninterrupted while the handoff is being processed by the network.

   Three methods are presented in this draft to achieve low-latency L3
   handoff, one for each category described above and one as a
   combination of the two:

   - PRE-REGISTRATION handoff method,

   - POST-REGISTRATION handoff method,

   - combined handoff method.

   The PRE-REGISTRATION handoff method allows the MN to be involved in
   an anticipated IP-layer handoff. The MN is assisted by the network in
   performing an L3 handoff before it completes the L2 handoff. The L3
   handoff can be either network-initiated or mobile-initated.
   Accordingly, L2 triggers are used both in the MN and in the FA to
   trigger particular L3 handoff events. The PRE-REGISTRATION method



El Malki (Editor) et. al.                                       [Page 5]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   coupled to L2 mobility helps to achieve seamless handoffs between
   FAs. The basic Mobile IPv4 concept involving advertisement followed
   by registration is supported and the PRE-REGISTRATION handoff method
   relies on Mobile IP security. No new messages are proposed, except
   for an extension to the Agent Solicitation message in the mobile-
   initiated case.

   The POST-REGISTRATION handoff method proposes extensions to the
   Mobile IP protocol to allow the oFA (old FA) and nFA (new FA) to
   utilize L2 triggers to set up a bi-directional tunnel between oFA and
   nFA that allows the MN to continue using its oFA while on nFA's
   subnet. This enables a rapid establishment of service at the new
   point of attachment which minimizes the impact on real-time
   applications. The MN must eventually perform a formal Mobile IP
   registration after L2 communication with the new FA is established,
   but this can be delayed as required by the MN or FA. Until the MN
   performs registration, the FAs will setup and move bidirectional
   tunnels as required to give the MN continued connectivity.

   The combined method involves running a PRE-REGISTRATION and a POST-
   REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can
   be performed before the L2 handoff completes, the combined method
   resolves to a PRE-REGISTRATION handoff. However, if the PRE-
   REGISTRATION handoff does not complete within an access technology
   dependent time period, the oFA starts forwarding traffic for the MN
   to the nFA as specified in the POST-REGISTRATION handoff method. This
   provides for a useful backup mechanism when completion of a PRE-
   REGISTRATION handoff cannot always be guaranteed before the L2
   handoff completion.

   It should be noted that the methods described in this document may be
   applied to MNs having a single interface (e.g. Wireless LAN
   interface) or multiple interfaces (e.g. one WLAN and one cellular
   interface). However, the case of multiply-interfaced MNs needs
   special consideration, since the handoff methods described in this
   document may not be required in all cases (see Appendix B).


1.3. L2 triggers

   An L2 trigger is a signal of an L2 event. In this document, the L2
   events relate to the L2 handoff process. One possible event is early
   notice of an upcoming change in the L2 point of attachment of the
   mobile node to the access network. Another possible event is the
   completion of relocation of the mobile node's L2 point of attachment
   to a new L2 access point. This information comes from L2
   programmatically or is derived from L2 messages. Although the
   protocols outlined in this document make use of specific L2
   information, Mobile IP should be kept independent of any specific L2.
   L2 triggers are an abstraction mechanism for a technology specific
   trigger. Therefore, an L2 trigger that is made available to the



El Malki (Editor) et. al.                                       [Page 6]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Mobile IPv4 stack is assumed to be generic and technology
   independent. The precise format of these triggers is not covered in
   this document, but the information required to be contained in the L2
   triggers for low latency handoffs is specified.

   In order to properly abstract from the L2, it is assumed that one of
   the three entities - the MN, oFA, or nFA - is made aware of the need
   for an L2 handoff, and that the nFA or MN can optionally also be made
   aware that an L2 handoff has completed. A specific L2 will often
   dictate when a trigger is received and which entity will receive it.
   Certain L2s provide advance triggers on the network-side, while
   others provide advance triggers on the MN. Also, the particular
   timing of the trigger with respect to the actual L2 handoff may
   differ from technology to technology.  For example, some wireless
   links may provide such a trigger well in advance of the actual
   handoff.  In contrast, other L2s may provide little or no information
   in anticipation of the L2 handoff.

   An L2 trigger may be categorized according to whether it is
   received by the MN, oFA, or nFA.  Table 1 gives such a categorization
   along with information expected to be contained in the trigger. The
   methods presented in this document operate based on different types
   of L2 triggers as shown in Table 1. Once the L2 trigger is received,
   the handoff processes described hereafter are initiated.






























El Malki (Editor) et. al.                                       [Page 7]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   +-------------+----------------------+------------------------------+
   | L2 trigger  |       Mobile         |               Source         |
   |             |       Trigger        |               Trigger        |
   |             |       (L2-MT)        |               (L2-ST)        |
   +-------------+----------------------+------------------------------+
   | Recipient   | MN                   |                oFA           |
   +-------------+----------------------+--------------+---------------+
   | Method      | PRE                  | PRE          | POST          |
   |             | mobile-              | network-     | source        |
   |             | initiated            | initiated    | trigger       |
   +-------------+----------------------+--------------+---------------+
   | When?       | sufficiently before  | sufficiently | sufficiently  |
   |             | the L2 handover      | before L2    | before L2     |
   |             | so that MN can       | handover for | handover for  |
   |             | solicit ProxyRtAdv   | FA to send   | oFA & nFA to  |
   |             | from oFA.            | proxyRtAdv   | exchange      |
   |             |                      | to MN.       | HRq/HRy.      |
   +-------------+----------------------+--------------+---------------+
   | Parameters  | nFA IP address       |  nFA IP address identifier   |
   |             | identifier           |  MN IP address identifier    |
   |             |                      |                              |
   +-------------+----------------------+------------------------------+


   +------------+------------------------+-------------+---------------+
   | L2 trigger | Target                 | Link-Up     |  Link-Down    |
   |            | Trigger                |             |               |
   |            | (L2-TT)                |             |               |
   |            |                        | (L2-LU)     |  (L2-LD)      |
   |------------+------------------------+-------------+---------------+
   | Recipient  | nFA                    |  MN or nFA  |     oFA       |
   |------------+------------+-----------+-------------+---------------+
   | Method     | PRE        |  POST     | PRE & POST  |    POST       |
   |            | network    |  target   |             |               |
   |            | initiated  |  trigger  |             |               |
   |------------+------------------------+-------------+---------------+
   | When?      |                        | when radio  |  when radio   |
   |            |       same as          | link between|  link between |
   |            |    source trigger      | MN & nFA  is|  MN and oFA   |
   |            |                        | established |  is lost      |
   |------------+------------------------+-------------+---------------+
   | Parameters | oFA IP address id      | @MN: nFA IP | MN IP address |
   |            | MN IP address id.      | or L2 addr. | identifier    |
   |------------+------------------------+-------------+---------------+

                         Table 1 - L2 Triggers








El Malki (Editor) et. al.                                       [Page 8]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


1.4. Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [3].

2. Requirements

   The following requirements are applicable to low-latency handoff
   techniques and are supported by the methods in this document:

   - to provide low-latency and low loss handoff for real time services,

   - to minimize the effects at L3 of ping-ponging,

   - to have no dependence on a wireless L2 technology,

   - to support inter- and intra-access technology handoffs,

   - to limit wireless bandwidth usage.


3. The PRE-REGISTRATION Handoff Method

   The PRE-REGISTRATION handoff method is based on the original concept
   of Mobile IP handoff as specified in [1], in which:

   - an advertisement for an FA is received by an MN,

   - the advertisement allows the MN to perform movement detection,

   - the MN registers with the FA.

   The PRE-REGISTRATION method allows both the MN and FA to initiate
   handoff. In both cases, abiding by the basic Mobile IP handoff
   concept allows the MN to choose with which FA to register.  The PRE-
   REGISTRATION method can make use of L2 triggers on either the FA or
   MN side, depending on whether network-initiated or mobile-initiated
   handoff occurs. PRE-REGISTRATION does not require any new messages to
   be defined in the network-initiated case and specifies one new
   extension to ICMP Solicitations for the mobile-initiated case.

   The PRE-REGISTRATION method supports handoff for a single network
   interface or between multiple network interfaces on the MN. The rest
   of this section discusses single interface handoff, Appendix C
   describes how multiple interface handoff is supported.  PRE-
   REGISTRATION also supports both the normal Mobile IP model [1] in
   which the MN is receiving packets from a Home Agent (HA) and the
   Regional Registration model [2] in which the MN receives packets from
   a Gateway Foreign Agent (GFA). Finally PRE-REGISTRATION supports




El Malki (Editor) et. al.                                       [Page 9]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   movement to a new domain, in which a new AAA transaction must occur
   to authenticate the MN with the new domain.


3.1. Operation

   The overall PRE-REGISTRATION Handoff mechanism is summarised in
   Figure 1 below:

                              +---------+
                              | HA (GFA)|<---------+
                              +---------+          | 4. (Reg)RegReq
                                                   | 5. (Reg)RegReply
                                                   v
                     +-----+    1a. RtSol       +-----+
                     |     | -----------------> | nFA |
                     | oFA |    1b. RtAdv       |     |
                     +-----+ <----------------- +-----+
                      ^   |                      ^
     (2a. ProxyRtSol) |   | 2b                  /
                      |   | ProxyRtAdv         / 3. (Reg)RegReq
                      |   |                   /
                      |   v   ---------------
                     +-----+ /
                     | MN  |
                     +-----+    - - - - - ->
                                  Movement

              Figure 1 - PRE-REGISTRATION Handoff Protocol


   The following steps provide more detail on the protocol:


       1. Messages 1a is a Router Solicitation (RtSol) from oFA to nFA.
          Message 1b is a Router (Agent) Advertisement (RtAdv) from nFA
          to oFA. These messages SHOULD occur in advance of the PRE-
          REGISTRATION Handoff in order not to delay the handoff. For
          this to occur, oFA MAY solicit and cache advertisements from
          neighbouring nFAs, thus decoupling the timing of this
          exchange from the rest of the PRE-REGISTRATION Handoff. When
          the L3 handoff is initiated by a target L2 trigger at nFA
          (L2-TT), message 1b equals message 2b and is sent unsolicited
          directly to MN rather than relayed by oFA.


       2. Message 2a is a Proxy Router Solicitation (PrRtSol). It is
          different from a normal Router Solicitation since it is
          actually soliciting an advertisement from a router different
          from the one receiving this message. The presence of message
          2a indicates that the handoff is mobile-initiated and its



El Malki (Editor) et. al.                                      [Page 10]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


          absence means that the handoff is network-initiated. In
          mobile-initiated handoff, message 2a occurs if there is an L2
          trigger in the MN to solicit for a Proxy Router Advertisement
          (PrRtAdv). When message 2a is received by the oFA, the oFA
          returns the Proxy Router Advertisement (Agent Advertisement)
          in message 2b. In network-initiated handoff, the L2 trigger
          occurs at oFA and oFA relays the Agent Advertisement in
          message 2b without the need for the MN to solicit. Note that
          it is also possible for nFA to advertise directly to the MN
          in the network-initiated target-trigger case (section 3.2).
          In all cases message 2b is simply nFA's agent advertisement.


       3. The MN performs movement detection upon receipt of either a
          solicited or unsolicited Agent Advertisement and, if
          appropriate, it sends a Registration Request (RegReq) message
          [1] in message 3 to nFA. When a local Gateway Foreign Agent
          (GFA) is present this message MAY be a Regional Registration
          Request (RegRegReq) [2]. Message 3 is routed through oFA
          since the MN is not directly connected to nFA prior to the L2
          handoff.


       4. Messages 4 and 5 complete the standard Mobile IP Registration
          [1] or Regional Registration [2] initiated with message 3.
          The Registration Reply in message 5 SHOULD be copied by nFA
          to the MN both through oFA and directly on-link. This is
          necessary, unless the L2/L3 interaction is engineered such
          that the MN does not detach from oFA until it has received
          the Reply. Since this will not always be the case, the Reply
          SHOULD be both tunneled by nFA to oFA and sent directly on-
          link. Figures 2 and 3 illustrate this tunneling, though it is
          not shown in Figure 1. Tunneling can take place either at L3
          or L2. The MN's L2 address may be obtained using the
          extensions in Section 8, as described in 3.7.


       5. If the Registration is successful then packets for the MN are
          now tunnelled from the HA (or GFA) to the nFA where the MN
          has moved to.


   PRE-REGISTRATION is not dependent on Regional Registration extensions
   [2]. However if the HA is at a distance (in terms of delay) from the
   nFA, the use of a local GFA reduces the time required for the handoff
   procedure to complete.

   The time at which the L2 trigger is received by the oFA or MN,
   thereby triggering the PRE-REGISTRATION handoff, compared to the time
   at which the actual L2 handoff occurs is important for the optimal
   performance of the low latency handoff. That is, in the optimal case



El Malki (Editor) et. al.                                      [Page 11]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   the L2 trigger will be received, the four messaging steps of PRE-REG
   described above will be completed and the first packet redirected by
   the HA (or GFA) to nFA will reach the MN at the moment in which the
   MN's L2 link to nFA is fully established. The MN would therefore not
   suffer any disruption due to the L3 handoff. This may require
   particular implementation techniques and deployment, such as L2
   techniques, buffering and bicasting, but these are outside the scope
   of this document. In addition further handoff smoothing
   considerations may be required to prevent the loss of packets in-
   flight between HA (or GFA) and oFA while the MN performs a PRE-
   REGISTRATION handoff. These are also outside the scope of this
   document.

   Figures 2, 3, and 4 contain message timing diagrams for both the
   network-initiated and mobile-initiated PRE-REGISTRATION handoff
   procedures.


3.2. Network-Initiated Handoff

   As described in Table 1, a PRE-REGISTRATION handoff can be initated
   at oFA by a source trigger or at nFA by a target trigger. A source-
   triggered network-initiated handoff occurs when an L2 trigger is
   received at the oFA informing it of a certain MN's upcoming movement
   from oFA to nFA. The L2 trigger will contain information such as the
   MN's IP address identifier (i.e. the IP address itself or an
   identifier which can be resolved to the IP address) and the nFA's IP
   address identifier. An identifier may be specific to the wireless
   technology (e.g. Access Point ID). A target-triggered network-
   initiated handoff occurs when an L2 trigger is received at the nFA
   informing it of a certain MN's upcoming movement from oFA. This type
   of trigger is also shown in Table 1. The L2 trigger contains
   information such as the MN's IP address identifier and the oFA's IP
   address identifier.

   In a source-triggered handoff, message 2b, the Proxy Router
   Advertisement, is sent by oFA to the MN. Messages 1a and 1b are
   exchanged by oFA and nFA before the L2 trigger is received. Message
   2a is not used. In a target-triggered handoff, nFA tunnels an Agent
   Advertisement directly to the MN to initiate the L3 handoff. The
   inner Advertisement is unicast by nFA to MN, thus nFA treats the
   target-trigger as a Router Solicitation. This Advertisement is
   tunneled to oFA which functions as a normal router, decapsulating the
   Advertisement and forwarding it to the MN.

   Figures 2 and 3 contain message timing diagrams describing the PRE-
   REGISTRATION network-initiated handoff for source and target
   triggers.






El Malki (Editor) et. al.                                      [Page 12]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   MN                    oFA                 nFA                 HA/GFA
    |                     |<~~~~~~ L2-Source  |                    |
    |                     |           Trigger |                    |
    |<--------------------|                   |                    |
    |  ProxyRtAdv         |                   |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   RegReq or         |                   |                    |
    |   RegRegReg         |                   |------------------->|
    |  (routed via oFA)   |                   | RegReq or RegRegReq|
    |                     |                   |                    |
    |                     |                   |<-------------------|
    |                     |                   |    (Reg)RegReply   |
    |                     |                   |                    |
    |<----------------------------------------|                    |
    |<--------------------|<------------------|                    |
    |                     | (Reg)RegReply     |                    |
    |                     | (sent to MN through oFA and nFA)       |


        Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
                    (Network-Initiated, Source Trigger)


   MN                    oFA                 nFA                 HA/GFA
    |                     | L2-Target~~~~~~~~>|                    |
    |                     |    Trigger        |                    |
    |                     |                   |                    |
    |                     |...................|                    |
    |<--------------------------------------- |                    |
    |  (ProxyRtAdv)       |...................|                    |
    |                     | Tunneled Agent    |                    |
    |                     | Advertisement     |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   RegReq. or        |                   |                    |
    |   RegRegReg         |                   |------------------->|
    |  (routed via oFA)   |                   | RegReq or RegRegReq|
    |                     |                   |                    |
    |                     |                   |<-------------------|
    |                     |                   |   (Reg)RegReply    |
    |                     |                   |                    |
    |<----------------------------------------|                    |
    |<--------------------|<------------------|                    |
    |                     | (Reg)RegReply     |                    |
    |                     | (sent to MN tunneled through oFA and
                             also directly on-link)

        Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
                    (Network-Initiated, Target Trigger)




El Malki (Editor) et. al.                                      [Page 13]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


3.3. Mobile-Initiated Handoff

   As shown in Table 1, a mobile-initiated handoff occurs when an L2
   trigger is received at the MN informing that it will shortly move to
   nFA. The L2 trigger contains information such as the nFA's IP address
   identifier (i.e. nFA's IP address or an identifier which can be
   resolved to the nFA's IP address). The message timing diagram is
   shown in Figure 4. As a consequence of the L2 trigger, the MN issues
   message 1a, the Proxy Router Solicitation (PrRtSol). This message is
   either:

   - Unicast to oFA, in which case the solicitation is for a Proxy
   Router Advertisement (PrRtAdv). This solicitation MUST have a TTL=1
   as in [1].

   - A normal Agent Solicitation [1] unicast to nFA's IP address, but
   having a TTL greater than 1.

  Both will have the same end result whereby the MN receives nFA's
  Router Advertisement with a Mobility Agent Advertisement extension
  (i.e. Agent Advertisement in [1]). Using the PrRtSol unicast to oFA
  is preferred in many cases because the amount of topological distance
  between nFA and MN could preclude a fast enough delivery of the
  Router Advertisement. In this case the PrRtSol is different from the
  Agent Solicitation in [1], where a TTL of 1 is mandated, since the
  nFA will be more than one hop away from the MN.


      MN                    oFA                 nFA               HA/GFA
       |<~~~~~ L2-Trigger    |                   |                    |
       |                     |                   |                    |
       |-------------------->|(---------------->)|                    |
       |   ProxyRtSol (to oFA or nFA)            |                    |
       |                     |                   |                    |
       |<--------------------|(<----------------)|                    |
       |   ProxyRtAdv (from oFA or nFA)          |                    |
       |                     |                   |                    |
       |---------------------------------------->|                    |
       |   RegReq or         |                   |                    |
       |   RegRegReq         |                   |------------------->|
       |  (routed via oFA)   |                   | RegReq or RegRegReq|
       |                     |                   |                    |
       |                     |                   |<-------------------|
       |                     |                   |    (Reg)RegReply   |
       |<----------------------------------------|                    |
       |<--------------------|<------------------|                    |
       |                     | (Reg)RegReply     |                    |
       |                     | (sent to MN through oFA and nFA)       |

        Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
                            (Mobile-Initiated)



El Malki (Editor) et. al.                                      [Page 14]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   The Proxy Router Advertisement solicitation unicast to oFA is an
   agent solicitation with a special extension. The solicitation MUST
   have an extension containing an IP address idenfifier because the MN
   is soliciting another specific FA's advertisement from the oFA. This
   specific FA is the one which will be its nFA. The IP address
   identifier contains the IP address of the nFA or an identifier that
   can be used by the oFA to resolve to nFA's IP address. If the
   identifier is not an IP address, it may be specific to the underlying
   wireless technology, for example, an Access Point or Base Station ID.
   The extension is a subtype of the Generalised Link-Layer Address
   extension described in Section 8. Two extension subtypes have been
   defined to contain the nFA's IP address and an access point
   identifier. They are called the Solicited Agent IP Address Extension
   and the Access Point Identifier Extension, and are described in
   Sections 7.4 and 7.5. Only one of the two should be present in the
   MN's PrRtSol message.

   As a result of the PrRtSol message, the oFA sends message 2b, the
   Proxy Router Advertisement (PrRtAdv), to the MN. The PrRtAdv is
   simply the agent advertisement for the requested nFA, either sent
   directly by nFA (tunneled through oFA) or proxied by oFA. In order to
   expedite the handoff, as explained previously, direct proxying by oFA
   is preferred. Therefore the actual nFA advertisement SHOULD be cached
   by the oFA following a previous exchange with nFA, shown in messages
   1a and 1b, as specified in Section 3.5. The PrRtAdv message MAY
   contain the nFA's L2 address (using the LLA extension in 7.2) as
   described in sections 3.7 and 3.8.


3.4. Obtaining and Proxying nFA Advertisements

   Since L2 triggers are involved in initiating PRE-REGISTRATION
   handoff, the trigger timing SHOULD be arranged such that a full L3
   PRE-REGISTRATION handoff can complete before the L2 handoff process
   completes. That is, the L2 handoff should be completed after the MN's
   Registration with the nFA is performed (message 3 in Fig.1). The
   Registration MAY be transmitted more than once to reduce the
   probability that it is lost due to errors on the wireless link.

   A PRE-REGISTRATION handoff in this case requires the MN to receive an
   agent advertisement from the nFA through the old wireless access
   point. Three ways of performing this are discussed in the following
   subsections.

3.4.1. Inter-FA Solicitation

   Inter-FA solicitation assumes that oFA has access to the IP address
   of the nFA. The IP address of nFA is obtained either by means of an
   L2 trigger at oFA in the network-initiated case (see Section 3.2) or
   by means of the extension to the Proxy Router Solicitation (PrRtSol)
   from the MN in the mobile-initiated case (see Section 3.3).



El Malki (Editor) et. al.                                      [Page 15]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Once the oFA has access to the address of the nFA for a specific MN,
   it MUST send a unicast agent solicitation to nFA. The nFA replies to
   the oFA by unicasting an Agent Advertisement with appropriate
   extensions. This method removes the TTL limitation of [1] for Mobile
   IP messages (i.e. TTL=1 is not applicable here). The TTL limitation
   cannot be applied since oFA and nFA may be more than one hop away and
   since it is unnecessary for a unicast message in any case. Security
   between oFA and nFA should be in place to ensure that solicitations
   and advertisements are protected and to enable nFA to determine that
   oFA is authorised to solicit agent advertisements.

   As a practical matter, oFA SHOULD pre-solicit and cache
   advertisements from known FAs topologically near it, in order to
   prevent having to perform the above solicitation during an actual
   handoff procedure (see Section 3.5).

3.4.2. Tunneled nFA Advertisements

   Tunneling nFA advertisments assumes that nFA is aware of the IP
   address for oFA and the MN. These IP addresses are obtained either by
   means of the IP address identifiers in an L2 trigger at nFA in the
   network-initiated case (see Section 3.2) or by means of a router
   solicitation (PrRtSol) from the MN in the mobile-initiated case (see
   Section 3.3). A router solicitation from MN directly to nFA must
   reach nFA and identify the oFA, so the solicitation MUST include an
   extension containing an IP address identifier (see section 8). This
   can be either oFA's IP address or an Access Point identifier which
   may be specific to the underlying wireless technology. As a result of
   the solicitation, the nFA sends an Agent Advertisement tunneled to
   the MN through oFA. This message is effectively message 2b, coming
   from nFA instead and only routed through oFA.

   However in [1] the MN cannot solicit an Advertisement from the nFA
   directly (Mobile-Initiated Handoff) since it is not on the same link
   as the MN. This restriction exists since the TTL must be 1 on Agent
   Solicitations. The same would apply to Router Advertisements from the
   nFA, which also affects the Network-Initiated Handoff case. Therefore
   tunneling advertisements is only applicable where the TTL limitation
   of [1] can be relaxed. This should be the case for unicast messages.

3.4.3. Piggy-backing Advertisements on L2 messaging

   Piggy-backing advertisements on L2 messaging consists in utilizing
   the L2 messaging involved in L2 handoff to transmit the Agent
   Advertisement from the nFA to the MN or oFA. When the first L2
   handoff triggers (i.e. L2-ST, L2-TT) or MN PrRtSol messages are
   received which inform of a MN's upcoming movement to a certain nFA,
   it may be possible to transmit Router Solicitation/Advertisements
   between FAs by piggybacking them onto L2 messages. Alternatively, the
   L2 at oFA may only perform this the first time and cache nFA's
   advertisements for as long as they are valid (see section 3.5).



El Malki (Editor) et. al.                                      [Page 16]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Whether this technique is applicable depends on the particulars of
   the L2 technology which are outside the scope of this document.


3.5. Caching Router Advertisements

   If done during a handoff, message exchange 1 in Figure 1 may impose
   an additional latency on the L3 handoff process. In order to remove
   this source of latency, the inter-FA Router Solicitation and
   Advertisement exchange SHOULD be performed in advance of handoff. A
   process SHOULD be in place at the oFA to solicit its neighbouring
   nFAs at a predefined time interval (MIN_SOLICITATION_INTERVAL). This
   interval SHOULD NOT be set too small to avoid unnecessary consumption
   of network bandwidth and nFA processing resources. The minimum value
   of MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response
   mechanism in [9] is used then the MIN_SOLICITATION_INTERVAL must be
   set to a value smaller or equal to the CHALLENGE_WINDOW (in nFA) so
   that the nFA challenge does not expire before the MN issues the
   Registration Request.

   The oFA SHOULD cache the most recent advertisements from its
   neighbouring nFAs. These advertisements should be sent to the MN in
   message 2b with a TTL=1. The oFA SHOULD also have a mechanism in
   place to create a list of neighbouring nFAs. The minimum support is
   to manually configure a list of nFAs for each FA in the network with
   which an L3 handoff is possible. The list will depend on deployment
   and radio coverage. It is also possible to specify another protocol
   to achieve nFA discovery, but it is outside the scope of this
   document.


3.6. Movement Detection and MN Considerations

   When the MN receives an Agent Advertisement with a Mobility Agent
   extension, it should perform actions according to the following
   movement detection mechanism: the MN MUST be "Eager" to perform new
   bindings. This means that the MN MUST perform Registrations with any
   new FA from which it receives an advertisement (i.e. MN is Eager), as
   long as there are no locally-defined policies in the MN that
   discourage the use of the discovered FA. For example, the MN may have
   a policy based on the cost of service. The method by which the MN
   determines whether the FA is a new FA is described in [1] and may
   make use of an FA-NAI extension.

   The MN also needs to change its default router from oFA to nFA. The
   MN MUST change its default router to nFA as soon as the L2 handoff
   has completed. The MN can identify this event using the L2-LU trigger
   described in Table 1. How to determine the L2 address for the default
   router is described in the next section.





El Malki (Editor) et. al.                                      [Page 17]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


3.7. L2 Address Considerations

   Some special considerations should be taken with respect to the
   wireless system on which this handoff method is being implemented.
   Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In
   PRE-REGISTRATION the MN is registering with an FA (nFA) that is not
   its current first-hop router, therefore the L2 address of the
   Ethernet frame containing the MN's Registration Request reaching the
   nFA is not the MN's address. Therefore the FA MUST NOT use the
   Ethernet address of the incoming Registration Request as the MN's L2
   address as specified in [1]. This applies to the cases where the
   wireless access points are bridges or routers and independently of
   whether the FA is implemented in the wireless access points
   themseves. In this case the MN's Registration Request (or Regional
   Registration Request) SHOULD use an L2 address extension to the
   Registration message when the MN is performing a registration. To
   communicate its L2 address, the MN includes a Generalised Link Layer
   Extension (see Section 8.3) with its Registration Request (or
   Regional Registration Request) message. If this extension is present
   the FA MUST use the L2 address contained in the extension to
   communicate with the MN. For the same reasons, in these cases the MN
   MUST NOT use the source L2 address of the Agent Advertisement message
   (PrRtAdv) as its default router's L2 address. Therefore in this case
   the oFA/nFA SHOULD include a Generalised Link Layer Extension (see
   Section 8.3) with its Agent Advertisement or PrRtAdv messages.

   In the case of the MN's Registration Request, if a particular
   wireless L2 technology has defined a special L2 interface to the
   wireless network that allows the FA to resolve the mapping between an
   MN IP address and an L2 address without the need to use the
   extension, the L2 address extension is not needed.


3.8. Applicability of PRE-REGISTRATION Handoff

   The PRE-REGISTRATON Handoff method is applicable to scenarios where a
   period of service disruption due to layer 3 is not acceptable, for
   example when performing real-time communications, and therefore where
   an anticipation of the layer 3 handoff is required. Security for the
   PRE-REGISTRATION handoff method is based on the same security model
   as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION
   is that the FA or MN are able to obtain an L2 trigger informing them
   of a pending L2 handoff procedure. The target of the L2 handoff is
   another access point or radio network which is in the coverage area
   of a new FA. The L2 trigger information may be in the form of IP
   address identifiers which may need to be resolved to IP addresses
   using methods that may be specific to the wireless network and are
   not considered here. If, for example, the FA determines that the IP
   address of the new FA is within its coverage area (i.e. it is its own
   address) the PRE-REGISTRATION handoff should not be initiated.




El Malki (Editor) et. al.                                      [Page 18]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   The L2 trigger must allow enough time for the PRE-REGISTRATION
   handoff procedure to be performed. In many wireless L2 technologies,
   the L2 handoff procedure involves a number of message exchanges
   before the effective L2 handoff is performed. For such technologies,
   PRE-REGISTRATION handoff can be initiated at the beginning of the L2
   handoff procedure and completed before the L2 handoff is completed.
   It may be efficient to engineer the network such that this succession
   of events is ensured.

   The PRE-REGISTRATION Handoff method is applicable in the following
   cases:

   - when the MN has locally defined policies that determine a
     preference for one access over another, for example due to service
     cost within the same or different technology, and therefore where
     it is necessary to allow the MN to select the appropriate FA with
     which to connect,

   - when L3 cannot rely upon L2 security between the MN and the FA to
     make modifications to IP routing and therefore authenticated
     Mobile IP messages are required,

   - when the trigger to initiate the handoff is received at the MN.

   In the first case it is necessary to involve eventual local MN
   policies in the movement detection procedure as described in 3.2.


4. The POST-REGISTRATION Handoff Method

   The POST-REGISTRATION handoff method uses bi-directional edge tunnels
   (BETs) to perform low latency change in the L2 point of attachment
   for the MN without requiring any involvement by the MN. Figure 5
   illustrates the basic POST-REGISTRATION handoff.

                            +------+
                            |  CN  |
                            +------+
                               |
                              ...
                               |
                            +------+   BET    +------+
                            | aFA  |==========| nFA  |
                            +------+          +------+
                                                  | wireless link
                                                  |
                                  movement    +------+
                                 --------->   |  MN  |
                                              +------+

                      Figure 5 - POST-REGISTRATION Concept



El Malki (Editor) et. al.                                      [Page 19]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Following a successful Mobile IP Registration between MN and oFA, the
   oFA becomes the mobility anchor point for the MN, called the anchor
   FA (aFA). When the MN moves from oFA to nFA, rather than performing
   signaling over the wireless link to register with the nFA, the MN can
   defer the L3 handoff and continue to use it's aFA (i.e. oFA in this
   case). If the MN moves to a third FA before registering with the nFA,
   the third FA signals aFA to move the wireless link end of the BET
   from nFA to it. The network end of the BET remains anchored at aFA
   until the MN performs the Mobile IP Registration.


4.1. Two Party Handoff

   Two party handoff occurs when the MN moves from oFA, where the MN
   performed a Mobile IP Registration, to nFA. In the normal case, this
   movement would result in a new Mobile IP Registration at nFA. However
   in POST-REGISTRATION, the MN and nFA MAY delay this but maintain
   connectivity using the BET between oFA and nFA. The protocol is shown
   in Figure 6.


            1a) L2-ST ~~~~> +------+ 2) HRqst +------+ <~~~ 1b) L2-TT
                            | oFA  |<-------->| nFA  |
                4a) L2-LD~> +------+ 3) HRply +------+ <~~~ 4b) L2-LU
                               ^                  ^
                     old L2    |                  |     new L2
                               +-------+    +-----+
                                       |    |
                                       |    |
                                       V    V
                                      +------+  movement
                       4c) L2-LU ---> |  MN  | --------->
                                      +------+

               Figure 6 - Two Party Handoff (POST-REGISTRATION)


   The following describes the progress of a two party handoff. The
   numbered items refer to steps in Figure 6. To identify the difference
   between a source triggered HRqst/HRply message for BET creation, a
   target triggered HRqst/HRply message for BET creation and HRqst/HRply
   to extend or terminate a BET, the message will be identified
   respectively by (s), (t) and (r).

     1) Either the oFA or nFA receives an L2 trigger informing it that a
       certain MN is about to move from oFA to nFA. The two cases are:

          a) The L2 trigger is a source trigger (L2-ST) at oFA. The
             trigger contains the MN's L2 address and an IP identifier
             (the IP address itself or an L2 address that can be
             resolved to the IP address) for nFA.



El Malki (Editor) et. al.                                      [Page 20]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


          b) The L2 trigger is a target trigger (L2-TT) at nFA. The
             trigger contains the MN's L2 address and an IP identifier
             for oFA.

     2) The FA receiving the trigger sends a Handoff Request (HRqst) to
       the other FA. There two cases:

          a) If oFA is sending the HRqst, the H bit is set and the N
             bit is unset, indicating it is an HRqst(s). The HRqst(s)
             contains the lifetime of the tunnel the oFA is willing to
             support, the home network IP address of the MN, the MN's
             HA address and an LLA option with the MN's L2 address. If
             the lifetime is zero and the T bit is not set, the oFA is
             not willing to tunnel any packets for MN. A positive
             lifetime and a set T bit indicate that the oFA is willing
             to tunnel for the indicated time. Section 4.6 describes
             the HRqst(s) and Section 8 describes the LLA option.

          b) If nFA is sending the HRqst, the N bit is set and the H
             bit is unset, indicating it is an HRqst(t). If the T bit
             is set, nFA has requested a reverse tunnel and the
             HRqst(t) contains the lifetime of the tunnel the nFA is
             requesting. The HRqst(t) also contains an LLA option with
             the MN's L2 address. The MN's home network IP address and
             HA address are not sent, unless they are discovered by
             some means outside the scope of this document (for
             example, as part of the L2-TT). Section 4.6 describes the
             HRqst(t).

    3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the
       other FA. There are two cases:

          a) If oFA is sending the HRply, the N bit is set and the H
             and R bits are unset, indicating that the reply is in
             response to a HRqst(t), i.e. it is an HRply(t). If the T
             bit is set, the HRply(t) contains the tunnel lifetime the
             oFA is willing to provide, otherwise, the tunnel lifetime
             is set to zero, indicating that the oFA is not willing to
             provide tunnel service. The HRply(t) also contains the
             MN's home subnet IP address, the MN's HA address, and an
             LLA option containing the MN's L2 address. Section 4.7
             describes the HRply(t).

          b) If nFA is sending the HRply, the H bit is set and the N
             and R bits are unset, indicating the reply is in response
             to a HRqst(s), i.e. it is an HRply(s). If the T bit is
             set, the nFA indicates that it requests a reverse tunnel,
             and the lifetime field is set with the requested tunnel
             lifetime. The T Bit can be set in HRply only if the oFA
             had set the T bit in the corresponding HRqst or if the nFA
             requires to reverse tunnel incoming packets to oFA because



El Malki (Editor) et. al.                                      [Page 21]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


             ingress filtering is enabled on its network. The tunnel
             lifetime requested by the nFA must be less than or equal
             to the tunnel lifetime offered by oFA in the HRqst(s).
             Section 4.7 describes the HRply(s).

    4) The point during the L2 handoff in which the MN is no longer
       connected on a certain link is signaled by an L2-LD trigger at
       oFA and MN. Completion of L2 handoff is signaled by an L2-LU
       trigger at nFA and MN. Each node handles the trigger in the
       following way:

          a) When the oFA receives the L2-LD trigger, it begins
             forwarding MN-bound packets through the forward tunnel
             (BET) to nFA.

          b) When the nFA receives the L2-LU trigger, it begins
             delivering packets tunneled from the oFA to the MN and
             forwards any outbound packets from MN to the next hop
             using normal routing mechanisms or through the reverse
             tunnel to oFA or HA.

          c) When the MN receives the L2-LU, it can intiate the Mobile
             IP Registration process by soliciting an Agent
             Advertisement as described in [1]. If the Registration is
             successful the nFA takes over the role of anchor FA (aFA)
             from the oFA.

    5) The oFA becomes an aFA if the MN moves to a third FA before
       having performed a Mobile IP Registration with nFA.

    6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a ping-
       pong situation arise, the oFA may be able to determine this case
       through the trigger mechanism (i.e. FA sees successive L2-ST/L2-
       TT followed by L2-LD and then L2-LU). The FA which originated
       the HRqst can in this case cancel the BET by sending an HRqst(r)
       to the other FA with lifetime zero. It will then simply continue
       delivering packets to MN exactly as if no handoff had been
       pending. Section 4.6 describes the HRqst(r).

   If in the HRqst/HRply the oFA has set the B bit and the nFA has not
   requested a reverse tunnel by setting the T bit, the nFA SHOULD
   tunnel outgoing packets from the MN to the HA because the MN has
   requested this service from the oFA. The nFA SHOULD offer this
   service only if either no security between the nFA and the MN's HA is
   required, or there is an existing nFA-HA security association in
   place.

   The actual timing of BET placement depends on the available L2
   triggers. The forward tunnel from oFA to nFA is constructed using one
   of the tunneling procedures described in [1] for the HA to FA tunnel
   with the difference that the ends of the tunnel are at the oFA and



El Malki (Editor) et. al.                                      [Page 22]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   nFA, respectively. The reverse tunnel from nFA to oFA is constructed
   as described in [4] with the difference that the network end of the
   tunnel is at the oFA instead of the HA. With optimal L2 trigger
   information, as described above, the FAs can setup the BET
   immediately when the L2 handoff is initiated, start tunneling MN-
   bound data when the link to the MN goes down and the nFA can use the
   link up trigger to start delivering packets. In the absence of
   optimal L2 trigger information, the HRply can act as the trigger to
   start tunneling MN-bound data, but in this case, the period of packet
   delivery disruption to the MN may still be present and additional
   measures may be required to provide uninterrupted service.
   Additonally, particular implementation and deployment scenarios may
   require that techniques be employed to smooth handoff by providing a
   means to convey packets arriving during the L2 handoff. The exact
   techniques involved in smoothing are currently under discussion by
   the working group and are outside the scope of this document.

   Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and
   target trigger (L2-TT) two party handoff, respectively.



                 MN                    nFA                 oFA
                  |                     |                   |
                  |                     |     HRqst(s)      |<~~~ L2-ST
                  |                     |<------------------|
                  |                     |     HRply(s)      |
                  |                     |------------------>|
                  |                     |                   |
                 --------------------------------------------<~~~ L2-LD
                                   L2 Handoff
                 --------------------------------------------<~~~ L2-LU
                  |                     |                   |
                  |<------------------->|                   |
                  |    MN's traffic     |                   |

               Figure 7 - Two Party Source Trigger Handoff Timing

















El Malki (Editor) et. al.                                      [Page 23]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


                 MN                    nFA                 oFA
                  |                     |                   |
                  |           L2-TT ~~~>|     HRqst(t)      |
                  |                     |------------------>|
                  |                     |     HRply(t)      |
                  |                     |<------------------|
                  |                     |                   |
                 --------------------------------------------<~~~ L2-LD
                                   L2 Handoff
                 --------------------------------------------<~~~ L2-LU
                  |                     |                   |
                  |<------------------->|                   |
                  |    MN's traffic     |                   |

               Figure 8 - Two Party Target Trigger Handoff Timing


   Once the BET between aFA and the current FA is in place, it is torn
   down by one of the following events:

     1) The aFA decides to stop tunneling because the lifetime it sent
       expires and was not renewed, or the aFA or current FA decide to
       terminate tunnel service prematurely for some other reason
       (refer to section 4.3).

     2) The MN completes the process by performing a Mobile IP
       Registration with the current FA. This may be initiated by the
       FA which sends an Agent Advertisement or by the MN which
       solicits for an Agent Advertisement as in [1].

     3) The MN moves to a third FA (see section 4.2)


4.2. Three Party Handoff

   In addition to the two party handoff, the FAs implementing POST-
   REGISTRATION MAY perform a three party handoff which requires an
   additional message. Three party handoff is applicable when an MN that
   has already established an aFA and is receiving tunneled packets
   through its current FA moves to a new FA without performing a Mobile
   IP Registration. The need for this function depends on the wireless
   system in which POST-REGISTRATION is being implemented. Certain
   wireless systems and implementations do not allow such fast movement
   between FAs and may force the Mobile IP Registration to occur soon
   after L2 handoff, in which case three party handoff is not
   applicable. If the this three party handoff feature is not
   implemented, the FA SHOULD send an Agent Advertisement to the MN
   after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD
   solicit a Router Advertisement after L2 handoff (L2-LU at MN).





El Malki (Editor) et. al.                                      [Page 24]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


                                     +------+
                                +--->| aFA  |<---+
                                |    +------+    |
                   4b) HRqst(r) |                | 3) HRqst(t)
                       HRply(r) |                |    HRply(t)
                                |                |
                                v    2a) HRqst   v
             1a) L2-ST ~~~> +------+     HTT  +------+ <~~~ 1b) L2-TT
                            | oFA  |<-------->| nFA  |
            4a) L2-LD ~~~>  +------+ 2b) HTT  +------+ <~~~ 5a) L2-LU
                               ^         HRply    ^
                       old L2  |                  |  new L2
                               +-------+    +-----+
                                       |    |
                                       |    |
                                       V    V
                                      +------+  movement
                       5b) L2-LU ~~~> |  MN  | --------->
                                      +------+

                         Figure 9 - Three Party Handoff

   The L3 handoff can be deferred either because of a decision by the
   MN/FA (i.e. MN does not send Router Solicitations and FA does not
   send Agent Advertisements) or it may result from rapid movement
   between oFA and nFA that does not allow enough time for the
   registration to complete. This scenario is shown in Figure 9. In this
   case, oFA must inform nFA (i.e. the third FA) to contact aFA about
   moving the radio end of the tunnel. This is performed with the
   Handoff To Third (HTT) message.

   The general idea behind the three party handoff procedure is that the
   oFA supplies nFA with the same information it would have obtained via
   an L2-TT if handoff had occurred from aFA to nFA, then the nFA
   performs an HRqst(t)/HRply(t) sequence with aFA in order to move the
   BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to
   aFA to terminate the previous BET.

   The following describes the progress of a three party handoff. The
   numbered items refer to steps in Figure 9.

     1) Either the oFA or nFA receives an L2 trigger informing it that a
       certain MN is about to be moved. The two cases are:

          a) The L2 trigger is a source trigger (L2-ST) at oFA. The
             trigger contains the MN's L2 address and an IP identifier
             (IP address or L2 address that can be mapped to an IP
             address) for nFA.

          b) The L2 trigger is a target trigger (L2-TT) at nFA. The
             trigger contains the MN's L2 address and an IP identifier



El Malki (Editor) et. al.                                      [Page 25]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


             for oFA.

    2) The oFA and nFA exchange a HTT/HRply or HRqst/HTT pair. HTT is
       indicated by setting both the H and N bits in the HRqst or
       HRply. The HTT message MUST NOT have any tunnel flags set,
       because the tunnel is negotiated between the aFA and nFA, not
       oFA and nFA. There are two cases:

          a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA
             containing the MN's home IP address, the MN's HA address,
             an LLA containing the aFA's IP address, and an LLA
             containing the L2 address of the MN. This is enough
             information for nFA to perform a target triggered handoff
             with aFA. The nFA responds with a HRply(s). Section 4.8
             describes the HTT.

          b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA,
             exactly as if a two party handoff were occurring. The oFA
             responds with HTT containing the same information as in a)
             above. This is enough information for nFA to perform a
             target triggered handoff with aFA.

    3) Upon receipt of the HTT, the nFA first checks its Visitor Cache
       to see whether it is already tunneling for MN. If so, Step 6 is
       performed. If not, nFA performs a target triggered handoff with
       aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t)
       pair. Because aFA receives no L2 trigger indicating when L2
       handoff starts, it may start tunneling to nFA upon transmission
       of the HRply(t).

     4) Once the L2 handoff is underway and the MN gets disconnected at
       L2, aFA and oFA exchange messages canceling tunnel service
       between aFA and oFA and allowing aFA to start the tunnel with
       nFA.

          a) The point in the L2 handoff process where the MN gets
             disconnected from oFA is signaled at oFA by L2-LD.

          b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime
             zero with aFA. This cancels tunnel service between oFA and
             aFA. If aFA has not already established a tunnel to nFA,
             it must do so immediately upon receipt of the HRqst(r).
             The aFA provides tunneling service exactly as described in
             Section 4.1 Step 4a.

     5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA
       and/or MN. The nFA and MN handle the trigger in the following
       ways:

          a) The nFA provides packet delivery service to the MN exactly
             as described in Section 4.1, Step 4b.



El Malki (Editor) et. al.                                      [Page 26]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001



          b) The MN either defers or initiates Mobile IP Registration
             when it receives the L2-LU, as in Section 4.1

     6) In the special case where nFA and aFA are the same (i.e. the MN
       is moving back to the original anchor FA), aFA recognizes that
       it is tunneling to oFA when it checks its Visitor Cache in Step
       3. In this case, there is no need for aFA to send the
       HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger
       on handoff completion, the aFA begins routing packets to MN and
       the tunnel to nFA is torn down. The oFA still exchanges the
       HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a
       priori that aFA and nFA are the same, but they are redundant.

   Unlike two party handoff, the timing of BET establishment between aFA
   and nFA cannot fully depend on the availability of L2 trigger
   information because aFA does not receive an L2 trigger signalling L2
   handoff. The two timing extremes at which aFA can place the BET with
   nFA are:

     1) At the earliest, aFA MAY start tunneling packets using the BET
       to nFA after sending the HRply(t) to nFA in response to the
       request for target-triggered handoff

     2) At the latest, aFA MAY start tunneling packets using the BET to
       nFA and tear down the BET with oFA when receiving the HRqst(r)
       from oFA indicating the MN has disconnected.

   In addition, aFA MAY continue tunneling to oFA if 1) is selected,
   until the HRqst(r) is received. If 1) is selected and the aFA
   continues to tunnel to oFA, the result may be duplicated packets at
   the MN, because the MN will receive packets through oFA on the old L2
   until it disconnects (L2-LD). If 2) is selected, the additional
   latency will add to the MN's L3 service disruption period. Of course,
   aFA can choose to place the BET some time between 1) and 2) if
   reliable bounds are available on the duration of time between L2-
   ST/L2-TT and the MN's disconnection (L2-LD). The exact selection of
   when to establish the BET is likely to be influenced by network
   engineering and implementation considerations, including whether a
   handoff smoothing solution is deployed, and is beyond the scope of
   this specification.

   Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and
   target trigger (L2-TT) three party handoff, respectively.










El Malki (Editor) et. al.                                      [Page 27]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


          MN               nFA            oFA              aFA
           |                |              |                |
           |                | L2-ST ~~~~~> |                |
           |                |              |                |
           |                |<-------------|                |
           |                |       HTT    |                |
           |                |              |                |
           |                |------------->|                |
           |                |    HRply(s)  |                |
           |                |              |                |
           |                |------------------------------>|
           |                |   HRqst(t)   |                |
           |                |              |                |
           |                |<------------------------------|
           |                |    HRply(t)  |                |
           |                |              |                |
          ----------------------------------<~~~ L2-LD      |
                                           |--------------->|
                        L2 Handoff         |     HRqst(r)   |
                                           |                |
                                           |<---------------|
                                           |     HRply(r)   |
                                           |                |
          ----------------------------------<~~~ L2-LU      |
           |                |              |                |
           |<-------------->|              |                |
           | MN's traffic   |              |                |
           |                |              |                |

              Figure 10 - Three Party Source Trigger Handoff Timing
























El Malki (Editor) et. al.                                      [Page 28]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


          MN               nFA            oFA              aFA
           |                |              |                |
           |                |<~~~ L2-TT    |                |
           |                |              |                |
           |                |------------->|                |
           |                |    HRqst(t)  |                |
           |                |              |                |
           |                |<-------------|                |
           |                |    HTT       |                |
           |                |              |                |
           |                |------------------------------>|
           |                |   HRqst(t)   |                |
           |                |              |                |
           |                |<------------------------------|
           |                |    HRply(t)  |                |
           |                |              |                |
          ----------------------------------<~~~ L2-LD      |
                                           |--------------->|
                        L2 Handoff         |     HRqst(r)   |
                                           |                |
                                           |<---------------|
                                           |     HRply(r)   |
                                           |                |
          ----------------------------------<~~~ L2-LU      |
           |                |              |                |
           |                |              |                |
           |<-------------->|              |                |
           | MN's traffic   |              |                |
           |                |              |                |

              Figure 11 - Three Party Target Trigger Handoff Timing


4.3. Renewal or Termination of Tunneling Service

   To prevent a BET from expiring when its lifetime runs out, the MN's
   current FA signals the aFA to either renew or terminate the BET. This
   may be the case when the MN defers Mobile IP Registration. If no such
   signal is received, the aFA will terminate the BET when the lifetime
   expires. In addition, the current FA or aFA may need to terminate the
   BET prior to the lifetime expiring. In order to avoid error
   conditions in which tunnels do not expire even though the MN to which
   they apply is no longer reachable, FAs SHOULD set the tunnel lifetime
   field to some value other that 0xffff, which indicates "good until
   cancelled".

   Figure 12 illustrates the message exchange that occurs between the FA
   needing to terminate or extend the tunnel (designated FA(1) in the
   figure) and the other FA (designated FA(2) in the figure). The
   HRqst(r)/HRply(r) is indicated by setting the R bit in the
   HRqst/HRply messages. If the HRqst(r) is renewing a BET then it



El Malki (Editor) et. al.                                      [Page 29]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   contains a non-zero lifetime, otherwise if the lifetime is set to
   zero it indicates tunnel termination. The aFA has complete control
   over whether a tunnel is extended or terminated, and it MAY reply to
   a request for extension with a shorter lifetime than was requested.

                                     HRqst(r)
                            +------+ <--------  +------+
                            | FA(2)| ---------> | FA(1)|
                            +------+ HRply(r)   +------+

                      Figure 12 - BET Renewal or Termination


4.4. When will the MN perform a Mobile IP Registration?

   The MN/FA have control over when to perform the Mobile Ip
   Registration. Although the MN/FA may decide to defer Mobile IP
   Registration for a certain period, three possible events can lead to
   the need to terminate tunneling service. If this occurs the MN MUST
   perform the Mobile IP Registration. These events are:

     1) The end of life for the BET is pending and a request by the
       current FA to aFA for renewal has been denied, or alternatively
       the current FA or aFA needs to terminate the BET prematurely.
       The FA in this case MUST initiate the Mobile IP Registration by
       sending the an Agent Advertisement to the MN as in [1].

     2) The MN itself decides to perform a Mobile IP Registration and
       initiates it by sending an Agent solicitation as in [1].

     3) During a source triggered handoff, the oFA attempts to perform
       BET handoff but nFA is not capable of performing it. The FA in
       this case MUST initiate the Mobile IP Registration by sending
       the MN an Agent Advertisement as in [1]. Note that this
       situation will never arise during target triggered handoff
       because an HRqst(t) will not be sent to oFA by an nFA that
       doesn't support POST-REGISTRATION.


4.5. MN Considerations

   According to [1], when using an FA care-of address the MN MUST choose
   its default router from those advertised in the ICMP Router
   Advertisement portion of the Agent Advertisement. If this is not
   possible it MAY consider the IP source address of the Router
   Advertisement as an alternative. The detailed selection method based
   on ICMP Router Discovery is specified in [14].

   In POST-REGISTRATION the MN may not be receiving Router
   Advertisements for extended periods of time. According to [14] hosts
   will remove default router entries if the lifetime of the Router



El Malki (Editor) et. al.                                      [Page 30]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Advertisement expires and no further advertisements are received.
   Note that the ICMP Router Advertisement lifetime is not related to
   the Registration Lifetime in the Mobility Agent Advertisement
   extension [1]. In POST-REGISTRATION, to avoid this disruption the MN
   MUST solicit the default router (i.e. FA) before the lifetime of its
   active default router entry runs out, or alternatively the FA MUST
   advertise before the Lifetime of its last Router Advertisement times
   out. This effectively means that the MN will only be able to defer
   Mobile IP Registration for as long as the remaining lifetime of the
   active default router, as configured in the ICMP Router
   Advertisements. The default Router Advertisement Lifetime in [14] is
   30 minutes. The MN MUST change its default router when it receives a
   new Router Advertisement following a POST-REGISTRATION handoff.


4.6. Handoff Request (HRqst) Message format

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |H|N|R|M|G|T|B|x|          Lifetime             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        MN Home Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          HA Address                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                         Identification                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Extensions ...
    +-+-+-+-+-+-+-+-

     Type              TBD (Handoff Request)

     H                 Source triggered handoff request. When set and
                       the N bit is unset, indicates that the request
                       was the result of an L2-ST at oFA.

     N                 Target triggered handoff request. When set and
                       the H bit is unset, indicates that the request
                       was the result of an L2-TT at nFA.

     R                 Set if the request is an HRqst(r), i.e. a request
                       to renew the tunnel. Neither the H nor the N bit
                       are set.

     M                 The FA issuing the HRqst will use Minimal
                       Encapsulation as defined in [1,5] for the tunnel.

     G                 The FA issuing the HRqst will use GRE [5]



El Malki (Editor) et. al.                                      [Page 31]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


                       Encapsulation as defined in [1,5] for the tunnel.
                       When this flag is set the HRqst may require
                       extensions containing the GRE type and key
                       fields, but they are outside the scope of this
                       document.

     T                 For an HRqst(s), indicates that the oFA is
                       willing to support both forward and reverse
                       tunnel service. For an HRqst(t), indicates that
                       the nFA is requesting reverse tunnel service.

     B                 When sent in an HRqst(s), indicates that the MN
                       has requested a reverse tunnel to the HA and that
                       the nFA SHOULD use reverse tunnel to the HA if it
                       will not be reverse tunneling to the oFA.

     Lifetime          The lifetime, in seconds, for which tunnel
                       service for the MN will be maintained. If this is
                       an HRqst(t), then the lifetime represents a
                       request by nFA for a reverse tunnel. If this is
                       an HRqst(s), then the lifetime represents the
                       maximum amount of time that oFA is willing to
                       maintain the both the forward and reverse tunnel.
                       If this is an HRqst(r), then the lifetime
                       Represents a request for the amount of time to
                       renew the tunnel's lifetime. A value of 0 on an
                       HRqst(s) indicates that the oFA is unwilling to
                       grant any tunnel service. A value of 0 on an
                       HRqst(t) indicates that the nFA does not require
                       reverse tunnel service. A value of 0 on an
                       HRqst(r) indicates that the tunnel should be
                       terminated immediately. A value of 0xffff
                       indicates infinite lifetime.

     MN Home Address   For HRqst(s), the home address of the MN.

     HA Addr           For HRqst(s), the HA address of the mobile node.

     Identification    As in defined in [1].

     Extensions        The Message MUST include an LLA (see Section 8)
                       containing the MN's L2 address and an L2 address
                       that can be mapped to an IP address for the FA.
                       For an HRqst(s), the Message MUST contain the
                       FA-FA Authentication Extension [2].









El Malki (Editor) et. al.                                      [Page 32]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


4.7. Handoff Reply (HRply) Message

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |H|N|R|M|G|T|B|x|   Code        |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Lifetime                  |         Reserved              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        MN Home Address                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                          HA Address                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                         Identification                        +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Extensions ...
    +-+-+-+-+-+-+-+-

     Type              TBD (Handoff Reply)

     Code              A value indicating the result of the Handoff
                       Request. Only two codes are currently supported,
                       0, indicating success, and a nonzero value,
                       indicating that the handoff cannot be performed.

     Lifetime          The lifetime, in seconds, for which the
                       bi-directional tunnel for the MN will be
                       maintained. If this is an HRply(s), then the
                       lifetime represents a request by nFA, and it can
                       be any value up to the maximum value sent in the
                       HRqst(s). Larger values are assumed to default to
                       OFA's maximum. If this is an HRply(t), then the
                       lifetime represents the maximum amount of time
                       that the oFA will grant to the nFA. If this is a
                       HRply(r), then the lifetime represents the
                       amount of time by which the tunnel life will be
                       extended. If the Code field indicates that
                       handoff failed, the Lifetime field will be
                       ignored and SHOULD be set to zero. A value of
                       0 on an HRply(t) indicates that the oFA is
                       unwilling to grant service. A value of 0 on an
                       HRply(s) indicates that the nFA does not require
                       service. A value of 0 on HRply(r) indicates that
                       the tunnel lifetime will be terminated. A value
                       of 0xffff indicates infinite lifetime.

     H                 Source triggered handoff reply. When set and
                       the N bit is unset, indicates that the
                       reply is in response to an HRqst(s).



El Malki (Editor) et. al.                                      [Page 33]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


     N                 Target triggered handoff reply. When set and
                       the H bit is unset, indicates that the
                       reply is in response to an HRqst(t).

     R                 Set if the reply is an HRply(r). Neither
                       the H nor the N bit are set.

     M                 The FA issuing the HRqst will use Minimal
                       Encapsulation as defined in [1,5] for
                       the tunnel.

     G                 The FA issuing the HRqst will use GRE [5]
                       Encapsulation as defined in [1,5] for the tunnel.
                       When this flag is set the HRply may require
                       extensions containing the GRE type and key
                       fields, but they are outside the scope of this
                       document.

     T                 For an HRply(s), indicates that the nFA is
                       Requesting to reverse tunnel service. For an
                       HRply(t), indicates that the oFA is willing to
                       provide both forward and reverse tunnel service.

     B                 When sent in an HRply(t), indicates that the MN
                       has requested a reverse tunnel to the HA and that
                       the nFA SHOULD use reverse tunnel to the HA if
                       it will not be reverse tunneling to the oFA. It
                       can be set in HRply(t) only if the T bit was
                       unset in the corresponding HRqst(t).

     MN Home Address   For HRply(t), the home address of the MN.

     HA Addr           For HRply(t), the HA address of the mobile node.

     Identification    As in defined in [1].

     Extensions        For an HRply(t), the Message MUST contain
                       the FA-FA Authentication Extension [2].


4.8. Handoff To Third (HTT) Message

   The Handoff to Third message has the same format as the Handoff
   Request and Handoff Reply Messages, except both the H and N bits are
   set. If the HTT message is in response to a L2-ST and is sent to
   initiate a handoff, then, with the exception of the H and N bits, the
   message has the same fields set and includes the same extensions as
   an HRqst(s). If the HTT message is sent in response to an HRqst(t),
   then, with the exception of the H and N bits, the message has the
   same fields set and includes the same extensions as an HRply(t). The
   tunnel bits MUST NOT be set in the HTT message because BET



El Malki (Editor) et. al.                                      [Page 34]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   construction is not negotiated between oFA and nFA, it is negotiated
   between nFA and aFA in the ensuing HRqst(t)/HRply(t).

   In addition, the HTT MUST contain the following extensions in the
   specified order:

        Solicited IP Address Option: containing aFA's Address

        LLA Option: containing the L2 address of the MN.


4.9. Applicability of POST-REGISTRATION Handoff Method

   The POST-REGISTRATION handoff approach allows FAs to communicate
   directly about a pending handoff, and does not require any IP layer
   messages to be sent to or from a MN prior to the L2 handoff event.
   Therefore, it eliminates a possible source of handoff latency. This
   may be required when the link layer imposes hard deadlines on the
   time at which a handoff must occur, such as when a MN is rapidly
   moving out of a radio coverage area. Consequently, POST-REGISTRATION
   is primarily of interest in handoff between FAs that support the same
   radio access technology. Handoff between heterogeneous radio
   technologies will, of necessity, require interaction between the MN
   and the network, and so is not a domain of applicability for POST-
   REGISTRATION.

   Because a POST-REGISTRATION handoff is triggered by an unspecified
   mechanism that informs the oFA or nFA that an L2 handoff is pending,
   the POST-REGISTRATION approach is only applicable to networks where
   such a mechanism is available.  For example, an L2 may provide
   indications of radio signal quality that cause the oFA or nFA to send
   the POST-REGISTRATION handoff messages. Any such indications must
   also provide each FA involved in the handoff with the identity of the
   other, so that messages can be sent to the right place.  This may
   involve mapping L2 information onto FA IP addresses.  Also, the FAs
   involved in a handoff must have pre-provisioned security arrangements
   so that the POST-REGISTRATION messages can be authenticated.  If a
   handoff is to be completed as a result of the POST-REGISTRATION
   messaging, any L2 handoff indications must also be securely
   authenticated so that traffic to the old point of attachment is not
   improperly halted.

   POST-REGISTRATION handoff is appropriate in the following cases:

   - L2 triggers are available on the network to indicate that L2
     handoff is pending.

   - Pre-provisioned security mechanisms are in place to allow fast
     and secure messaging between the FAs and between the MN and an FA.

   - Access point choice by the MN is not a concern or choice requires



El Malki (Editor) et. al.                                      [Page 35]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


     user intervention and therefore is not on the critical path for
     handoff.


5. Combined Handoff Method

   The combined method uses both PRE-REGISTRATION and POST-REGISTRATION
   handoff by running the PRE-REGISTRATION method and in parallel
   exchanging the POST-REGISTRATION handoff messages between oFA and
   nFA. The only case not considered already in the POST-REGISTRATION
   method is mobile-initiated handoff. In the mobile-initiated case, the
   Handoff Request message is initated by the oFA or nFA when it
   receives the Registration Request from the MN.

   The combined method follows the PRE-REGISTRATION Handoff when it is
   successful before the completion of the MN's L2 handoff. However, if
   PRE-REGISTRATION does not complete prior to the expiration of a timer
   on one or the other of the FAs, POST-REGISTRATION handoff is used.
   Using POST-REGISTRATION handoff insulates the MN from delays caused
   by errors such as loss of one of the Mobile IP messages involved in
   PRE-REGISTRATION.

   The start of POST-REGISTRATION is gated by the expiration of a timer
   on the FAs. The timer is started at oFA following a source-trigger,
   at nFA following the target-trigger, or at oFA and nFA following the
   receipt of the Registration Request from the MN in the mobile-
   initiated case. The timer is reset if the Registration Reply message
   is received by the appropriate FA and sent to the MN.

   Although the POST-REGISTRATION Handoff Request and Handoff Reply
   messages are exchanged in advance, no forwarding of traffic between
   oFA and nFA is performed unless the timer expires. The timer should
   be set to a value that allows forwarding between oFA and nFA to begin
   before the MN completes the L2 handoff to nFA.


6. Layer 2 and Layer 3 Handoff timing Considerations

   In the optimal cases considered in the PRE-REGISTRATION and POST-
   REGISTRATION handoffs it was assumed that a timely L2 trigger would
   be received in such a way that packets could be delivered to the MN
   via its nFA immediately upon connection. In this way the MN would not
   suffer disruption due to the L3 handoff. However such precise timing
   of the L2 trigger and handoff mechanism with respect to the actual L2
   handoff event will not be possible in all wireless systems and may
   depend on particular implementation techniques. Therefore some
   uncertainty may exist at L3 as to exactly when the L2 connection
   between the MN and the nFA becomes fully established and can be used
   for L3 traffic. The techniques which will solve this problem and
   allow the MN to receive traffic independently of the timing of the L2
   handoff event are currently under study by the WG but are outside the



El Malki (Editor) et. al.                                      [Page 36]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   scope of this document.


7. Reverse Tunneling Support

   The handoff methods all support reverse tunneling. The MN may request
   reverse tunneling [4] by setting the 'T' bit in its Registration
   Request. In the case of POST-REGISTRATION, if the MN had requested
   Reverse Tunneling previously at oFA, the Handoff message from oFA
   (see Section 4) includes the 'T' bit enabled to inform nFA to
   establish a BET for the visitor entry. Typically, the 'T' bit will
   always be set to ensure that any delays in the MN receiving its new
   care of address do not result in any delay in uplink packet
   transmission from the MN, but local policies and particular L2
   technologies may allow the reverse tunnel to be turned off unless the
   MN specifically requests it.


8. Generalized Link Layer Address Extension

   This section defines the Generalized Link Layer Address (LLA)
   Extension, used by any node that needs to communicate Link Layer
   Addresses. The format of the extension relies on sub-types, where
   each sub-type defines its own sub-structure. This draft defines six
   sub-types. Future RFCs should allocate their own sub-type and define
   their own address formats.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    LLA ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

        TBD (skippable) [1]

      Length

        The length of the Link Layer Address + the one octet Sub-Type
        field

      Sub-Type

        This field contains the Link Layer sub-type identifier

      LLA

        Contains the Link Layer Address





El Malki (Editor) et. al.                                      [Page 37]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


      In this document, six subtypes are defined:

            1        3GPP2 International Mobile Station Identity and
                     Connection ID [6]
            2        3GPP International Mobile Subscriber Identity [13]
            3        Ethernet 48 bit MAC address [7]
            4        64 bit Global ID, EUI-64 [8]
            5        Solicited IP Address
            6        Solicited Access Point Identifier

   The following subsections describe the extensions.


8.1.  3GPP2 IMSI Link Layer Address and Connection ID Extension

   The IMSI Link Layer Address Extension contains the International
   Mobile Station Identity.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    IMSI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD (skippable) [1]

         Length

            The length of the IMSI field + the one octet Sub-Type field

         Sub-Type

            1

         IMSI

            Contains the IMSI, in the form:

                       <IMSI>:<Connection Id>

            Where the <IMSI> is an ASCII-based representation of the
            International Mobile Station Identifier, most significant
            digit first, ":" is ASCII 0x3a, and the Connection ID is the
            ASCII representation of a small, decimal number used for
            distinguishing different link-layer connections from the
            same device.






El Malki (Editor) et. al.                                      [Page 38]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


8.2.  3GPP IMSI Link Layer Address Extension

   The IMSI Link Layer Address Extension contains the International
   Mobile Station Identity.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    IMSI ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD (skippable) [1]

         Length

            The length of the IMSI field + the one octet Sub-Type field

         Sub-Type

            2

         IMSI

            Contains the IMSI, a number composed of 15-digits or less,
            coded as described in [13].


8.3.  Ethernet Link Layer Address Extension

   The Ethernet Link Layer Address Extension contains the 48 bit
   Ethernet MAC Address, as defined in [7].




       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    MAC ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD (skippable) [1]

         Length

            7 (includes the Sub-Type field)




El Malki (Editor) et. al.                                      [Page 39]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


         Sub-Type

            3

         MAC

            Contains the 48 bit Ethernet MAC Address.


8.4.  IEEE 64-Bit Global Identifier (EUI-64) Address Extension

   The 64-Bit Global Identifier (EUI-64) Address Extension contains the
   64 bit address, as defined in [8].


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    MAC ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD (skippable) [1]

         Length

            9 (includes the Sub-Type field)

         Sub-Type

            4

         MAC

            Contains the 64-Bit Global Identifier Address.


8.5.  Solicited IP Address Extension

   The 32-bit Solicited IP Address Extension contains the IP address of
   the agent (FA) being solicited. This extension MAY be present in an
   ICMP Agent Solicitation as explained in Section 3.3.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    IP addr ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





El Malki (Editor) et. al.                                      [Page 40]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


         Type

            TBD (skippable) [1]

         Length

            5 (includes the Sub-Type field)

         Sub-Type

            5

         IP Address

            Contains the 32-Bit IP Address of the solicited node.


8.6.  Solicited Access Point Identifier Extension

   The 32-bit Solicited Access Point Identifier Extension contains an
   Identifier of the Access Point to which the MN will move. This may be
   a wireless L2 identifier. The MN is able to solicit an advertisement
   from the FA servicing a certain Access Point by using this extension
   with Agent Solicitations as explained in Section 3.3.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Length      |   Sub-Type    |    AP ID...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Type

            TBD (skippable) [1]

         Length

            5 (includes the Sub-Type field)

         Sub-Type

            6

         AP ID

            Contains the 32-Bit Access Point Identifier.








El Malki (Editor) et. al.                                      [Page 41]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


9.  IANA Considerations

   Section 8 introduces the Generalized Link Layer Address Extension
   numbering space that requires IANA management. This specification
   makes use of the values 1-6, and all other values other than zero (0)
   are available for assignment via IETF consensus [12]. The numbers for
   the Generalized Link Layer Address Extension are taken from the
   numbering space defined for Mobile IP registration extensions defined
   in RFC 2002 [1]. These MUST NOT conflict with any numbers used in RFC
   2002 [1], RFC 2344 [4], RFC 2356 [10], RFC 2794 [11] and RFC 3012
   [9].

   In the POST-REGISTRATION Handoffs method, Sections 4.4 and 4.5
   require numbers assigned from the Mobile IP control message type
   address space. The numbers assigned MUST NOT conflict with [1] and
   [2].

10. Security Considerations

   A security consideration for PRE-REGISTRATION method, as discussed in
   Section 3.8, is that oFA and nFA must share a security association
   and oFA must be authorized to solicit nFA and relay Registration
   Request/Reply. Also, if the FA Challenge/Response mechanism in [9] is
   used then the MIN_SOLICITATION_INTERVAL must be set to a value
   smaller or equal to the CHALLENGE_WINDOW (in nFA) so that the nFA
   challenge does not expire before the MN issues the Registration
   Request. Otherwise, PRE-REGISTRATION uses AAA-based security for both
   inter-domain and intra-domain handoff as described in [1] and [2].

   POST-REGISTRATION introduces a new change to Mobile IP, which is the
   possibility that a MN may receive packets from an FA with which it
   has not yet registered. In the event that the MN does not wish to
   receive packets from unknown FAs, it MAY drop them. In a similar way
   to PRE-REGISTRATION, oFA and nFA must share a security association
   required to protect the Handoff Request and Reply messages.

   Since the techniques outlined in this document depend on particular
   aspects of L2 handoff to optimize performance, some amount of L2
   security is assumed. Both techniques depend on L2 triggers, and the
   security of handoffs requires that the L2 triggers be secure. In
   addition, the POST-REGISTRATION technique depends on the ability of
   the wireless network to securely identify MNs. Although this document
   does not specify how FAs can identify or track MNs, it is assumed
   that the wireless L2 is sufficiently secure in order to correctly
   identify a MN. Wireless networks that do not provide such features
   will be subject to impersonation attacks, where malicious nodes could
   cause FAs to believe that a MN has moved to other service areas, and
   to allow a bogus MN to obtain unauthorized service from an FA prior
   to performing a Mobile IP registration. The PRE-REGISTRATION
   technique instead depends on Mobile IP security between MN and FA, so
   the same security considerations in [1] apply.



El Malki (Editor) et. al.                                      [Page 42]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


11. References

     [1]  C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
          1996.

     [2]  E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
          Tunnel Management ", draft-ietf-mobileip-reg-tunnel-05.txt
          (work in progress), September 2001.

     [3]  S. Bradner. "Key words for use in RFCs to Indicate Requirement
          Levels". BCP 14. RFC 2119. March 1997.

     [4]  G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 2344,
          May 1998.

     [5]  S. Hanks, T. Li, D. Farinacci, and P. Traina,  "Generic
          Routing Encapsulation (GRE)",  RFC 1701 (Informational),
          Internet Engineering Task Force, October 1994.

     [6]  TIA/EIA/IS-2000

     [7]  D. Plummer, "An Ethernet Address Resolution Protocol - or
          Converting Network Protocol Addresses to 48.bit Ethernet
          Address for Transmission on Ethernet Hardware", RFC 826,
          Symbolics,Inc., November 1982.

     [8]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
          Registration Authority",
          http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
          March 1997.

     [9]  C. Perkins,  P. Calhoun, "Mobile IP Challenge/Response
          Extensions",  RFC 3012, November 2000.

     [10] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal
          for Mobile IP", RFC 2356, June 1998.

     [11] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
          Extension", RFC 2794, March 2000.

     [12] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998

     [13] 3GPP TS 23.003 (www.3gpp.org)

     [14] S. Deering, "ICMP Router Discovery", RFC1256, September 1991







El Malki (Editor) et. al.                                      [Page 43]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


12. Authors' Addresses

   The authors may be contacted at the addresses below:

   Karim El Malki
   Ericsson Radio Systems AB
   LM Ericssons Vag. 8
   126 25 Stockholm
   SWEDEN

   Phone:  +46 8 7195803
   Fax:    +46 8 7190170
   E-mail: Karim.El-Malki@era.ericsson.se


   Pat R. Calhoun
   Sun Microsystems Laboratories
   Sun Microsystems, Inc.
   901 San Antonio Rd., UMTV 29-221
   Palo Alto, California, 94303
   USA

   Phone:  +1 650 786 7733
   Fax:  +1 650 786 6445
   E-mail:  pcalhoun@eng.sun.com


   Tom Hiller
   Lucent Technologies
   Rm 2F-218
   263 Shuman Blvd
   Naperville, IL  60566-7050
   USA

   Phone:  +1 630 979 7673
   Fax:    +1 630 979 7673
   E-Mail: tom.hiller@lucent.com


   James Kempf
   Sun Microsystems Laboratories
   Sun Microsystems, Inc.
   901 San Antonio Rd., UMTV29-221
   Palo Alto, California, 94303
   USA

   Phone:  +1 650 336 1684
   Fax:  +1 650 691 0893
   E-mail:  james.kempf@sun.com





El Malki (Editor) et. al.                                      [Page 44]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   Peter J. McCann
   Lucent Technologies
   Rm 2Z-305
   263 Shuman Blvd
   Naperville, IL  60566-7050
   USA

   Phone:  +1 630 713 9359
   Fax:    +1 630 713 4982
   E-Mail: mccap@lucent.com


   Ajoy Singh
   Motorola
   1501 West Shure Drive
   Arlington Heights, IL o 60004
   USA

   Phone: +1 847 632 6941
   E-mail: asingh1@email.mot.com


   Hesham Soliman
   Ericsson Radio Systems
   Torshamnsgatan 23, Kista
   Stockholm
   SWEDEN

   Phone:  +46 8 7570000
   Fax:    +46 8 4043630
   E-mail: Hesham.Soliman@ericsson.com.au


   Sebastian Thalanany
   Motorola
   1475 West Shure Drive
   Arlington Heights, IL - 60004
   USA
   Phone:  +1 847 435 9296
   E-mail: sthalan1@email.mot.com

   The working group can be contacted via the current chairs:

           Basavaraj Patil               Phil Roberts
           Nokia Corporation             Megisto Systems Inc.
           6000 Connection Drive         EMail:  proberts@megisto.com
           Irving, TX 75039
           USA
           Phone:  +1 972-894-6709
           EMail:  Raj.Patil@nokia.com
           Fax :  +1 972-894-5349



El Malki (Editor) et. al.                                      [Page 45]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


13. Full Copyright Statement

   Copyright (C) The Internet Society (2001). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in anyway, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English. The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided onan
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."






























El Malki (Editor) et. al.                                      [Page 46]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


Appendix A - Gateway Foreign Agents

   The Mobile IP Regional Registration specification [2] introduces the
   Gateway Foreign Agent (GFA), as a mobility agent that two FAs
   providing service to a MN have in common. Figure A.1 provides an
   example of a MN's initial registration through the GFA. If this is
   the first registration message, the message MUST be forwarded to the
   HA. All packets destined for the mobile will be delivered to the GFA,
   which in turn will forward the packets to the FA servicing the MN.


                   Reg Req   +-----+   Reg Req
                +----------->| oFA |--------------+
                |            +-----+              |
                |                                 v
             +----+                            +-----+ Reg Req +----+
             | MN |                            | GFA |<------->| HA |
             +----+                            +-----+         +----+

                              +-----+
                              | nFA |
                              +-----+

               Figure A.1 - Initial Registrations through GFA

   If the MN moves to a nFA that is serviced by a GFA common with oFA,
   the MN  MAY issue a Regional Registration Request (see Figure A.2).
   The Regional Registration message does not need to be forwarded to
   the HA, since the MN's traffic can still be delivered to the same
   GFA. This optimized approach effectively reduces the latency involved
   in the registration process.

                              +-----+
                              | oFA |
                              +-----+

             +----+                            +-----+         +----+
             | MN |                            | GFA |         | HA |
             +----+                            +-----+         +----+
                |                                 ^
                |             +-----+             |
                +------------>| nFA |-------------+
                 Regional Reg +-----+ Regional Reg


              Figure A.2 - Regional Registration through GFA


   Note that the GFA may also be the MN's first-hop router.





El Malki (Editor) et. al.                                      [Page 47]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs

   For MNs that have two wireless network interfaces, either on the same
   wireless network or on wireless networks having different wireless L2
   technologies, the techniques discussed in this draft may be
   unnecessary if the Mobile IP stack on the MN allows switching an IP
   address binding between interfaces. This Appendix discusses how
   multiple wireless interfaces can aid low latency handoff.

   Figure B.1 illustrates the normal and hierarchical MIPv4 models. As
   shown in the figure, assume that the MN is connected to Radio Network
   1 (RN1) and is registered with oFA through which it is receiving
   traffic. Suppose MN enters the coverage area of RN2 and nFA and that
   it prefers connectivity to this network for reasons beyond the scope
   of this document (e.g. user preferences, cost, QoS available etc.).
   The MN activates the interface to RN2 but continues communicating
   through RN1. The MN may solicit advertisements from nFA through the
   interface connected to RN1 to speed up the handoff process, provided
   there is no TTL restriction, or it can solicit advertisements through
   the interface connected to RN2 if it has been configured for IP
   traffic.


         +------+        +---------+
         |  HA  |--------|  (GFA)  |
         +------+        +---------+
                           /     \
                          /       \
                       ...       ...
                        /          \
                       /            \
                    +------+      +------+
                    | oFA  |      | nFA  |
                    +------+      +------+
                       |             |
                    +------+      +------+
                    | RN1  |      | RN2  |
                    +------+      +------+


                    +------+
                    |  MN  | --------->
                    +------+

                             Movement


     Figure B.1 - Network Model for Mobile IPv4 With Multi-Access

   Once the MN is registered with nFA and is successfully receiving and
   transmitting through the new network, it tears down the interface to



El Malki (Editor) et. al.                                      [Page 48]

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            Oct 2001


   RN1. If the MN has enough time to complete this procedure without
   incurring degraded service or disconnection, the MN would experience
   a seamless multi-access handoff but it may not be possible in all
   cases, due to network coverage or for other reasons. Should multiple
   interface handoff be possible then the low latency methods described
   in this document are not necessary.

   In order to support the possible failure of the connectivity with the
   new network (RN2/nFA) in the short period following handoff, the MN
   may use the "S" bit in its Mobile IP Registration Request to maintain
   simultaneous bindings both its existing (HA or GFA) binding with oFA
   and a new binding with nFA.










































El Malki (Editor) et. al.                                      [Page 49]


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