[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: November 2001                                    Pat R. Calhoun
                                                              Tom Hiller
                                                             James Kempf
                                                         Peter J. McCann
                                                              Ajoy Singh
                                                          Hesham Soliman
                                                     Sebastian Thalanany


                                                                May 2001


                    Low Latency Handoff in Mobile IPv4
            <draft-ietf-mobileip-lowlatency-handoffs-v4-01.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            May 2001


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



TABLE OF CONTENTS

   1. Introduction.....................................................3
      1.1 Terminology .................................................3
      1.2 The Techniques ..............................................5
      1.3 L2 triggers .................................................6
      1.4 Requirements language .......................................8
   2. Requirements.....................................................9
   3. The PRE-REGISTRATION Handoff Method..............................9
      3.1  Operation .................................................10
      3.2  Network-Initiated Handoff .................................11
      3.3  Mobile-Initiated Handoff ..................................13
      3.4  Obtaining and Proxying nFA Advertisements .................15
          3.4.1 Inter-FA Solicitation.................................15
          3.4.2 Tunneled nFA Advertisements...........................15
          3.4.3  Piggy-backing Advertisements on L2 messaging.........16
      3.5  Caching Router Advertisements .............................16
      3.6  Movement Detection and MN Considerations ..................17
      3.7  Simultaneous Bindings .....................................17
      3.8  L2 Address Considerations .................................18
      3.9  Applicability of PRE-REGISTRATION Handoff .................19
   4. The POST-REGISTRATION Handoff Method............................20
      4.1  Operation .................................................20
      4.2  Role of BETs ..............................................23
      4.3  Foreign Agent Considerations ..............................24
      4.4  Handoff Request Message ...................................26
      4.5  Handoff Reply Message .....................................27
      4.6  Applicability of POST-REGISTRATION Handoff Method..........29
   5. Combined Handoff Method.........................................30
   6. Reverse Tunneling Support.......................................30
   7. Generalized Link Layer Address Extension........................31
      7.1  IMSI Link Layer Address Extension .........................31
      7.2  Ethernet Link Layer Address Extension .....................32
      7.3  IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..33
      7.4  Solicited IP Address Extension ............................33
      7.5  Solicited Access Point Identifier Extension ...............34
   8. IANA Considerations.............................................34
   9. Security Considerations.........................................35
      9.1  AAA Considerations for Security ...........................36
   10. References.....................................................37
   11. Authors' Addresses.............................................38
   12. Full Copyright Statement.......................................40
   Appendix A - Gateway Foreign Agents................................41
   Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......44




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


1. Introduction

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

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

1.1 Terminology

   This section presents a few terms used throughout the document.

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

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

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

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

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

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

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

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

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

      bicasting - The splitting of a stream of packets destined for a
         MN via its current FA (the oFA) into two or more streams,
         and the simultaneous transmission of the streams to oFA and
         one or more nFA. Bicasting is a handoff smoothing technique
         used to reduce packet loss during handover.

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

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

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

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

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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


1.2 The Techniques

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

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

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

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

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

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

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

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

   - PRE-REGISTRATION handoff method,

   - POST-REGISTRATION handoff method,

   - combined handoff method.

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

   The POST-REGISTRATION handoff method proposes extensions to the
   Mobile IP protocol to allow the oFA and nFA to utilize L2 triggers to
   set up a registration on the nFA prior to receiving a formal
   Registration Request from the Mobile Node. This enables a very rapid
   establishment of service at the new point of attachment to minimize
   the impact on real-time applications. The MN must eventually perform
   a formal Mobile IP registration after L2 communication with the new
   FA is established. Security is handled by standard Mobile IP
   mechanisms, and both intra-domain and inter-domain handoff are
   supported. The technique can be used for inter-technology handoff but
   it requires the active involvement by the mobile to switch from one
   network interface to another.

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

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


1.3 L2 triggers

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

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

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






























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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   +-------------+----------------------+------------------------------+
   | L2 trigger  | mobile               |               source         |
   |             | pretrigger           |               trigger        |
   |             | (L2-MPT)             |               (L2-ST)        |
   +-------------+----------------------+------------------------------+
   | Recipient   | MN                   |                oFA           |
   +-------------+----------------------+--------------+---------------+
   | Method      | PRE                  | PRE          | POST          |
   |             | mobile-              | network-     | source        |
   |             | initiated            | initiated    | trigger       |
   +-------------+----------------------+--------------+---------------+
   | When?       | sufficiently before  | sufficiently | sufficiently  |
   |             | the L2 handover      | before L2    | before L2     |
   |             | so that MN can       | handover for | handover for  |
   |             | solicit ProxyRtAdv   | FA to send   | oFA & nFA to  |
   |             | from oFA.            | proxyRtAdv   | exchange      |
   |             |                      | to MN.       | HRq/HRy.      |
   +-------------+----------------------+--------------+---------------+
   | Parameters  | nFA IP address       |  nFA IP address identifier   |
   |             | identifier           |  MN IP address identifier    |
   |             |                      |                              |
   +-------------+----------------------+------------------------------+
   +------------+------------------------+-------------+---------------+
   | L2 trigger | target                 | mobile      |  network      |
   |            | trigger                | handoff     |  handoff      |
   |            | (L2-TT)                | complete    |  complete     |
   |            |                        | (L2-MHC)    |  (L2-NHC)     |
   |------------+------------------------+-------------+---------------+
   | Recipient  | nFA                    |   MN        |     nFA       |
   |------------+------------+-----------+-------------+---------------+
   | Method     | PRE        |  POST     |  POST       |    POST       |
   |            | network    |  target   | (optional)  |  (optional)   |
   |            | initiated  |  trigger  |             |               |
   |------------+------------------------+-------------+---------------+
   | When?      |                        | when radio  |  when radio   |
   |            |       same as          | conditions  |  conditions   |
   |            |    source trigger      | are OK for  |  are OK for   |
   |            |                        | MIP register|  MIP register |
   |------------+------------------------+-------------+---------------+
   | Parameters | oFA IP address id      |  none       |    none       |
   |            | MN IP address id.      |             |               |
   |------------+------------------------+-------------+---------------+

                         Table 1 - L2 Triggers

1.4  Requirements language

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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


2. Requirements

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

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

   - minimize the effects at L3 of ping-ponging,

   - no dependence on a wireless L2 technology,

   - support inter- and intra-access technology handoffs,

   - limit wireless bandwidth usage.


3. The PRE-REGISTRATION Handoff Method

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

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

   - the advertisement allows the MN to perform movement detection,

   - the MN registers with the FA.

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

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








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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


3.1  Operation

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

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

              Figure 1 - PRE-REGISTRATION Handoff Protocol


   The following steps provide more detail on the protocol:


   1. Messages 1a and 1b contain a solicitation of a Router
   Advertisement by oFA from nFA and a reply Router Advertisement from
   nFA. These messages SHOULD occur in advance of the PRE-REGISTRATION
   Handoff in order to not delay the handoff. For this to occur, oFA MAY
   solicit and cache advertisements from the nFA, thus decoupling the
   timing of this exchange from the rest of the PRE-REGISTRATION
   Handoff. When the L3 handoff is initiated by a target L2 trigger at
   nFA, message 1b is sent unsolicited directly to MN rather than
   relayed by oFA.


   2. The presence of message 2a indicates that the handoff is mobile-
   initated and its absence means that the handoff is network-initiated.
   In mobile-initiated handoff, message 2a occurs if there is an L2
   trigger in the MN to solicit for a Proxy Router Advertisement. When
   message 2a is received by the oFA, the oFA returns the Proxy Router
   Advertisement in message 2b. In network-initiated handoff, the L2
   trigger occurs at oFA and oFA relays the Router Advertisement in
   message 2b without the need for MN to solicit. Note that it is also
   possible for nFA to advertise directly to the MN in the network-




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   initiated target-trigger case (section 3.2). In all cases message 2b
   is simply nFA's router advertisement.


   3. The MN performs movement detection upon receipt of either a
   solicited or unsolicited Router Advertisement and, if appropriate, it
   sends a Registration Request message [1] [2] in message 3 to nFA
   requesting a simultaneous binding. Message 3 is routed through oFA
   since the MN is not directly connected to nFA prior to the L2
   handoff.


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


   5. Because of the uncertainty as to when the L2 connection between
   the MN and the nFA becomes fully established and can be used for L3
   traffic, simultaneous bindings with the GFA or the HA are used to
   allow traffic for the MN to be sent to both the oFA and the nFA.
   Between the time when the Registration Reply is sent from HA or GFA
   to nFA and when the MN's connection on L2 at the nFA is fully
   established, the HA or GFA bicasts traffic for the MN to both oFA and
   nFA. The MN is able to receive traffic independently of the exact L2
   handoff timing. Also, should the L2 handoff procedure fail,
   terminate abruptly, or ping-pong, the use of simultaneous bindings
   allows the MN to maintain L3 connectivity with the oFA, smoothing the
   handoff.


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

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


3.2 Network-Initiated Handoff

   As described in Table 1, a PRE-REGISTRATION handoff can be initated



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

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

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

   MN                    oFA                 nFA                 HA/GFA
    |                     |<~~~~~~ L2-Source  |                    |
    |                     |           Trigger |                    |
    |<--------------------|                   |                    |
    |  ProxyRtAdv         |                   |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   HA Reg. or        |                   |                    |
    |   RegReg (routed    |                   |------------------->|
    |   via oFA if pre    |                   |  HA reg or RegReg  |
    |   L2 Handoff)       |                   |                    |
    |                     |                   |<-------------------|
    |                     |                   |     Reg Reply      |
    |                     |                   |                    |
    |<----------------------------------------|                    |
    |<--------------------|<------------------|                    |
    |                     | Reg Reply         |                    |
    |                     |(sent to MN through|                    |
                            oFA and directly)


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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   MN                    oFA                 nFA                 HA/GFA
    |                     | L2-Target~~~~~~~~>|                    |
    |                     |    Trigger        |                    |
    |                     |                   |                    |
    |                     |...................|                    |
    |<--------------------------------------- |                    |
    |  (ProxyRtAdv)       |...................|                    |
    |                     | Tunneled Agent    |                    |
    |                     | Advertisement     |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   HA Reg. or        |                   |                    |
    |   RegReg (routed    |                   |------------------->|
    |   via oFA if pre    |                   |  HA reg or RegReg  |
    |   L2 Handoff)       |                   |                    |
    |                     |                   |<-------------------|
    |                     |                   |     Reg Reply      |
    |                     |                   |                    |
    |<----------------------------------------|                    |
    |<--------------------|<------------------|                    |
    |                     | Reg Reply         |                    |
    |                     |(sent to MN        |                    |
                            tunneled through oFA and directly on-link)

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

3.3 Mobile-Initiated Handoff

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

   As a consequence of the L2 trigger, the MN issues message 1a, the
   Proxy Router Solicitation. The message is either:

   - Unicast to nFA's IP address, in which case the procedure is a
   normal agent solicitation, apart from having a TTL greater than 1.

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

  Proxy Router Advertisement solicitation is required because the
  amount of topological distance between nFA and MN could preclude a
  Router Advertisement sent in reply prior to an L2 handoff. This is
  different from [1], where a TTL of 1 is mandated.





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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


      MN                    oFA                 nFA               HA/GFA
       |<~~~~~ L2-Trigger    |                   |                    |
       |                     |                   |                    |
       |-------------------->|                   |                    |
       |   ProxyRtSol        |                   |                    |
       |                     |                   |                    |
       |<--------------------|                   |                    |
       |   ProxyRtAdv        |                   |                    |
       |                     |                   |                    |
       |---------------------------------------->|                    |
       |   HA Reg. or        |                   |                    |
       |   RegReg (routed    |                   |------------------->|
       |   via oFA if pre    |                   |  HA reg or RegReg  |
       |   L2 Handoff)       |                   |                    |
       |                     |                   |<-------------------|
       |                     |                   |     Reg Reply      |
       |<----------------------------------------|                    |
       |<--------------------|<------------------|                    |
       |                     | Reg Reply         |                    |
       |                     |(sent to MN through|                    |
                               oFA and directly)

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


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

   As a result of the MN solicitation message, the oFA sends message 2b,
   the Proxy Router Advertisement, to the MN. The Proxy Router
   Advertisement contains the agent advertisement for the requested nFA.
   In order to expedite the handoff, the actual nFA advertisement SHOULD
   be cached by the oFA following a previous exchange with nFA, shown in
   messages 1a and 1b, and specified in Section 3.5.






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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


3.4 Obtaining and Proxying nFA Advertisements

   If L2 triggers are involved in initiating PRE-REGISTRATION handoff,
   the trigger timing SHOULD be arranged such that a full L3 PRE-
   REGISTRATION handoff can complete before L2 handoff initiates. That
   is, the L2 handoff should be initiated after the MN's Registration
   with the nFA completes and produces a simultaneous binding at the
   GFA/HA. The Registration MAY be transmitted more than once to reduce
   the probability that it is lost due to errors on the wireless link.

   A PRE-REGISTRATION handoff in this case requires the MN to receive
   agent advertisements from the nFA through the old wireless access
   point, and to perform a registration with the nFA through the old
   wireless access point. Three ways of performing this are discussed in
   the following subsections.

3.4.1 Inter-FA Solicitation

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

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

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

3.4.2 Tunneled nFA Advertisements

   Tunneling nFA advertisments assumes that nFA is aware of the IP
   address for oFA and the MN. These IP addresses are obtained either by
   means of the IP address identifiers in an L2 trigger at nFA in the
   network-initiated case (see Section 3.2) or by means of the Proxy
   Router Solicitation from the MN in the mobile-initiated case (see
   Section 3.3). A solicitation from MN directly to nFA must reach nFA
   and identify the oFA, so the solicitation must include an extension
   containing an IP address identifier. This can be either oFA's IP
   address or an Access Point identifier which may be specific to the



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   underlying wireless technology. As a result of the tunneled
   solicitation, the nFA sends a Router Advertisement tunneled to the MN
   through oFA. This message is effectively message 2b, coming from nFA
   instead and only routed through oFA.

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

3.4.3  Piggy-backing Advertisements on L2 messaging

   Piggy-backing advertisements on L2 messaging involves utilizing the
   L2 messaging involved in L2 handoff to transmit the Router
   Advertisement from the nFA to the MN or oFA. When the first L2
   handoff messages are exchanged, it may be possible to transmit a
   Router Advertisement piggybacked onto L2 messages. Alternatively, the
   L2 at oFA may cache nFA's advertisements and not need to receive
   Router Advertisements upon every L2 handoff initiation. Whether this
   technique is possible depends on the particulars of the L2 technology
   and is outside the scope of this document.

3.5 Caching Router Advertisements

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

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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


3.6 Movement Detection and MN Considerations

   When the MN receives an Agent Advertisement with a Mobility Agent
   extension, it should perform actions according to the following
   movement detection mechanisms. The MN MUST be:

   - "Eager" to perform new bindings,

   - "Lazy" in releasing existing bindings.

   The above means that the MN MUST perform Registrations with any new
   FA from which it receives an advertisement (i.e. MN is Eager), as
   long as there are no locally-defined policies in the MN that
   discourage the use of the discovered FA. For example, the MN may have
   a policy based on the cost of service. The method by which the MN
   determines whether the FA is a new FA is described in [1] and may
   make use of an FA-NAI extension. However the MN MUST NOT release
   existing bindings until it no longer receives advertisement from the
   old FA and the lifetime of its existing binding expires (i.e. MN is
   Lazy).

   If the MN has at least one existing binding with an FA, additional
   simultaneous Registrations are performed requesting a short lifetime.
   This is done to limit the lifetime of temporary bindings and
   therefore limit bandwidth usage. Temporary bindings occur when the MN
   is moving between FAs and uses PRE-REGISTRATION handoff to achieve
   low loss IP mobility. By limiting the lifetime, the Registrations
   time out quickly avoiding the need for the MN to cancel the
   registration. Temporary bindings are also useful to support ping-
   ponging between FAs.

3.7 Simultaneous Bindings

   Simultaneous bindings are used by a GFA or HA to decouple L3 handoff
   from L2 handoff and to reduce packet loss. Simultaneous bindings
   allow a GFA or HA to bicast packets destined to the MN to multiple
   potential future MN locations before the MN actually moves there.
   Simultaneous bindings and bicasting are also useful to support ping-
   ponging.

   Using normal Mobile IP with an HA only and no GFA, the MN MAY perform
   registrations with the HA using simultaneous bindings. This is
   described in [1] and the method to anticipate MN movement by
   interacting with the wireless L2 is described in Section 3.6.
   However, having multiple simultaneous bindings for the MN at the HA
   causes the HA to send multiple copies of data packets towards
   mutliple FAs that may be topologically distant. Bicasting from the HA
   is not efficient unless the HA is close to the FAs in question. Also,
   if the round-trip time between the HA and FAs is not negligible, the
   MN's new Registration and therefore L3 handoff can be delayed.




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   If a GFA is present, low loss handoff is achieved by bicasting
   traffic from the GFA to the oFA and the nFA while the MN is moving
   between them. The MN sets the "S" bit in the Registration Request
   [2]. When a Regional Registration Request has the "S" bit set, the
   receiving regional FA or GFA that has an existing binding with the MN
   adds the relevant new binding for the MN but also maintains any
   existing bindings it has for the MN, bicasting traffic to the MN at
   both FAs.

   If the MN has simultaneous active bindings with FAs, it could (but
   preferably should not) receive multiple copies of the same traffic
   directed to it. The use of simultaneous bindings does not mean that
   the MN is receiving packets contemporarily from multiple sources.
   This depends on the characteristics of the access (L2) technology.
   The bicasting of packets involves sending a copy of the data to the
   FA which the MN is moving to. Until the MN actually completes the L2
   handoff to the new FA and fully establishes the new L2 link, the new
   FA MAY receive packets for a MN to which it does not have a direct
   link layer connection. The FA MAY:

   - drop all packets for the MN, or

   - buffer packets for the MN.

   The choice of which action to take may depend on the type of traffic
   involved, but this is outside the scope of this document. The MN MAY
   also in parallel attempt to establish a link-layer connection with
   the MN. An FA MUST NOT send ICMP Destination Unreachable messages if
   it drops packets or is unable to deliver the received IP packets due
   to unavailability of direct layer connection with the MN.

   Appendix A contains more information about GFA considerations for the
   PRE-REGISTRATION handoff.

3.8 L2 Address Considerations

   If a wired backbone network connects wireless access points and the
   wireless network is not bridged (i.e. the wireless access points are
   not acting as routers) so that the FA is not directly on the same
   link as the MN, the MN MAY use an L2 address extension to the
   Registration message when the MN is performing a registration.
   Because the MN is registering with an FA that is not its first-hop
   router, the L2 address of the frame containing the MN's registration
   packet is not MN's address. The MN must use some means to communicate
   its L2 address other than the frame address, which is the method
   specified in [1]. To communicate its L2 address, the MN includes a
   Generalised Link Layer Extension (see Section 7) with its
   registration. The FA uses the L2 address in the extension to
   communicate with the MN. If a particular wireless L2 technology has
   defined a special L2 interface to the wireless network that allows
   the FA to resolve the mapping between an MN IP address and an L2



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   address without the need to use the extension, the extension is not
   needed.

3.9 Applicability of PRE-REGISTRATION Handoff

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

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

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

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

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

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

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










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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


4. The POST-REGISTRATION Handoff Method

   The POST-REGISTRATION handoff method is based on a network-initiated
   model of handoff. The technique does not require any MN involvement
   until the actual L2 connection with nFA is completed. The oFA and nFA
   perform a message exchange that allows the MN to establish a
   temporary registration on the nFA until the MN performs a formal
   Mobile IP FA registration. The technique derives its name because the
   registration occurs after L2 handoff is complete. POST-REGISTRATION
   makes use of bi-directional edge tunnels (BETs) to smooth packet
   delivery while the MN is in transition between oFA and nFA. If the FA
   determines that there is no change in the FA, based on the L2 trigger
   information, then the POST-REGISTRATION handoff procedures are not
   initiated. POST-REGISTRATION depends on standard AAA-based Mobile IP
   security [13], but for true low-latency handoff, pre-established
   security associations between FAs are necessary. In summary, POST-
   REGISTRATION handoff covers new cases that are not addressed by the
   framework in [1].

4.1  Operation

   In the POST-REGISTRATION method, the FA issues handoff messages on
   behalf of the Mobile Node, acting as a surrogate of sorts. The FA
   becomes aware that a handoff is about to occur at L2 through the use
   of an L2 trigger. An FA can receive two types of triggers, a source
   trigger at oFA and a target trigger at nFA. Section 1.1 and Table 1
   contain more details about source and target triggers.

   Figures 5 and 6 contain message sequences for source and target
   triggered POST-REGISTRATION handoff, respectively. Figures 7 and 8
   contain message timing diagrams for the message sequences in Figures
   5 and 6. In Figure 5, a source trigger is obtained by oFA when L2
   detects that the MN is about to depart its coverage area. In Figure
   6, a target trigger is obtained by the nFA when L2 detects that the
   MN has just arrived in the coverage area of the nFA prior to the
   completion of the L2 handoff. Note that both triggers are available
   before the actual completion of the link layer handoff.

                     +-----+ 1. Handoff Request +-----+
                     |     | -----------------> |     |
      0. Source ~~~> | oFA |                    | nFA |
         Trigger     |     | 2. Handoff Reply   |     |
                     +-----+ <----------------- +-----+
                                                  ^  |
                                  3. Reg Request  |  | 4. Reg Reply
                                                  |  v
                     +-----+    Movement        +-----+
                     | MN  | - - - - - - - - -> | MN  |
                     +-----+                    +-----+

            Figure 5 - Source Trigger POST-REGISTRATION Handoff



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


                     +-----+ 1. Handoff Request +-----+
                     |     | <----------------- |     |
                     | oFA |                    | nFA |<~~~~ 0. Target
                     |     | 2. Handoff Reply   |     |         Trigger
                     +-----+ -----------------> +-----+
                                                  ^  |
                                  3. Reg Request  |  | 4. Reg Reply
                                                  |  v
                     +-----+    Movement        +-----+
                     | MN  | - - - - - - - - -> | MN  |
                     +-----+                    +-----+

            Figure 6 - Target Trigger POST-REGISTRATION Handoff

   The message sequences between oFA and nFA depicted in Figures 5 and 6
   are very similar. The main difference is in the initiator of the
   Handoff Request message.  In both the source and target trigger
   cases, an FA obtains link-layer information that indicates the
   necessity of a handoff to the nFA. In the event of a source trigger,
   oFA transmits a Handoff Request message to nFA. The Handoff Request
   MUST include the MN's home address, HA address, remaining
   registration lifetime, and a Generalized Link-Layer Address Extension
   (see Section 7) with the MN's L2 address. Upon receipt of the
   message, nFA MUST create the MN's visitor entry, and respond with the
   Handoff Reply message.

   In the event of a target trigger, the trigger occurs on nFA, and nFA
   transmits a Handoff Request to oFA. The Handoff Request message MUST
   include the MN's  L2 address in a Generalized Link-Layer Address
   Extension (see Section 7) in order for oFA to correctly identify the
   MN. The request message MAY include additional MN information, if
   such information was provided by the L2. Upon receipt of the request,
   oFA MUST respond with the Handoff Reply message, including the MN's
   home address, HA address, remaining registration lifetime and a
   Generalized Link-Layer Address Extension with the MN's link layer
   address.


















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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


      MN                    oFA                 nFA               HA/GFA
       |                     |                   |                    |
       |                     |                   |<~~~~~~~ L2-TT      |
       |                     |<------------------|                    |
       |                     |    HReq(t)        |                    |
       |                     |                   |                    |
       |                     |------------------>|                    |
       |                     |    HRply(t)       |                    |
       |                     |                   |                    |
       |                     |...................|                    |
       |                     |<----------------->|                    |
       |                     |...................|                    |
       |<--------------------------------------->|                    |
       |                     |  Tunneled Traffic |                    |
       |                     |     to/from MN    |                    |
       |<~ ~ ~ ~ L2-MHC      |                   |                    |
       |        (optional)   |                   |                    |
       |                     |                   |                    |
       |- - - - - - - - - - - - - - - - - - - - >|                    |
       |      RtSol          |                   |                    |
       |                     |                   |<~ ~ ~ ~ L2-NHC     |
       |<- - - - - - - - - - - - - - - - - - - - |       (optional)   |
       |                     |     RtAdv         |                    |
       |                     |                   |                    |
       |------------------------------------------------------------->|
       |   HA Reg or RegReg  |                   |                    |
       |                     |                   |                    |

        Figure 7 - POST-REGISTRATION Handoff Message Timing Diagram
                             (Target-Trigger)


   Completion of POST-REGISTRATION handoff requires MN to perform a full
   FA and HA/GFA registration. A trigger that signals the completion of
   the handoff, designated as L2-NHC (Layer-2 Network Handoff Complete)
   or L2-MHC (Layer-2 Mobile Handoff Complete) in Figures 7 and 8,
   performs this function. If the MN receives an L2-MHC trigger, it
   SHOULD send a Router Solicitation message. The Router Solicitation
   causes nFA to send a Router Advertisement, allowing the MN to perform
   a complete Mobile IP or Regional Registration. Alternatively, if the
   nFA receives the L2-NHC trigger, nFA SHOULD send a Router
   Advertisement, allowing the MN to perform a complete Mobile IP or
   Regional Registration. The L2-MHC and L2-NHC triggers are optional.
   If they are not available, the MN MUST wait until nFA sends a
   periodic Agent Advertisement and MUST respond by registering with
   nFA.








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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


      MN                    oFA                 nFA               HA/GFA
       |                     |<~~~~~~ L2-ST      |                    |
       |                     |                   |                    |
       |                     |------------------>|                    |
       |                     |    HReq(s)        |                    |
       |                     |                   |                    |
       |                     |<------------------|                    |
       |                     |    HRply(s)       |                    |
       |                     |...................|                    |
       |                     |<----------------->|                    |
       |                     |...................|                    |
       |<--------------------------------------->|                    |
       |                     |                   |                    |
       |                     |  Tunneled Traffic |                    |
       |                     |     to/from MN    |                    |
       |                     |                   |                    |
       |<~ ~ ~ ~ L2-MHC      |                   |                    |
       |       (optional)    |                   |                    |
       |                     |                   |                    |
       |- - - - - - - - - - - - - - - - - - - - >|                    |
       |      RtSol          |                   |                    |
       |                     |                   |<~ ~ ~ ~ L2-NHC     |
       |<- - - - - - - - - - - - - - - - - - - - |       (optional)   |
       |                     |     RtAdv         |                    |
       |                     |                   |                    |
       |------------------------------------------------------------->|
       |   HA Reg or RegReg  |                   |                    |
       |                     |                   |                    |

      Figure 8 - POST-REGISTRATION Handoff Message Timing Diagram
                            (Source Trigger)

4.2 Role of BETs

   Bi-directional edge tunnels, or BETs, are used to achieve low loss of
   traffic to and from the MN during a handoff and to smooth handoff
   when an MN undergoes ping-ponging. The tunnel from nFA back to oFA
   allows the MN to use its old care of address prior to registering
   with nFA. If this tunnel is not established, the old care of address
   cannot be used because it is topologically incorrect and may trigger
   egress filtering in nFA's subnet, resulting in the MN's packets being
   dropped.

   Figure 9 provides an example of a BET. The BET is placed when the oFA
   issues a successful Handoff Reply to nFA, or receives a successful
   Handoff Reply from nFA. This causes oFA to forward the MN's traffic
   to the nFA. The nFA forwards the traffic further to the MN if an L2
   connection exists. In the reverse direction, as soon as MN comes up
   on the L2 connection with nFA, it can start sending packets with the
   old care of address, and nFA tunnels them to nFA, where they are
   detunneled and forwarded as if they originated through oFA.



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


                      Data    +-----+           Data            +----+
                +------------>| oFA |<--------------------------| HA |
                |             +-----+                           +----+
                v              ^   ^
             +----+    Handoff |   | Data
             | MN |    Request |   |
             +----+            |   |
                ^              v   v
                |             +-----+
                +------------>| nFA |
                      Data    +-----+

             Figure 9 - Bi-Casting by the Foreign Agent


4.3 Foreign Agent Considerations

   Upon receipt of a trigger event, an FA SHOULD issue a Handoff Request
   message to the FA to which or from which the mobile is being handed
   off.

   If the message is the result of a target trigger, the Type Of Trigger
   bit in the Handoff Request message MUST be set and the Generalized
   Link-Layer Address Extension (see Section 7) MUST be present. The
   sender of the Handoff Request is nFA and the handoff is target
   triggered. The message's home address and HA address fields MAY be
   set to NULL if this information is not known at the time the message
   is transmitted.

   Upon receipt of a Handoff Request message with the Type Of Trigger
   bit set, the oFA MUST respond with the Handoff Reply message. The
   Handoff Reply MUST include both the MN's home address and HA address.
   The MN's remaining registration lifetime MUST be included in the
   Handoff Reply's lifetime field. Furthermore, the oFA issuing the
   Handoff Reply MAY include any security associations that were
   dynamically created.  The oFA that issues a Handoff Reply with the
   Code field set to success (zero value) MUST bi-cast all packets
   destined to the MN to both the L2 to which the MN is currently
   connected and by tunneling to the nFA.The oFA must also be prepared
   to receive tunneled packets from the nFA in which the MN's packets
   appear with the old care of address.

   The nFA that receives a Handoff Reply message with a zero value in
   the Code field creates a visitor entry with the information found in
   the message. The FA MUST be prepared to deliver packets to the MN
   prior to receiving a Registration Request [1] from the MN, and it
   MUST be prepared to tunnel packets sent by the MN under the MN's old
   care of address to oFA.

   Note that it is possible for the encapsulation method used between
   oFA and nFA to be different from the one requested by the MN during



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   its Registration process. When this occurs, the respective FAs MUST
   perform encapsulation translation.

   An FA that receives a source trigger MUST send a Handoff Request
   message with the Type Of Trigger bit disabled. The sender of the
   Handoff Request message is the oFA and the handoff is source
   triggered. The message MUST also include the MN's home address, the
   HA address and the Link Layer Address extension (see section 7). The
   MN's remaining registration lifetime MUST be included in the lifetime
   field. The oFA MAY also include any security associations that were
   dynamically created.

   Upon receipt of a Handoff Request with the Type Of Trigger bit
   disabled, the nFA MUST process the packet and respond with the
   Handoff Reply message. If successfully processed, the nFA MUST create
   a visitor entry for the MN, and be prepared to deliver tunneled
   packets received by the initiator of the Handoff Request destined for
   the MN, and to tunnel packets from the MN sent under its old care of
   addres to the oFA. The Handoff Reply message MUST include the home
   address, HA address, lifetime value, and the Generalized Link-Layer
   Address Extension (see Section 7) with the MN's link layer address.

   An oFA that receives a Handoff Reply with the Code field set to
   success (zero value) MUST bi-cast all packets destined for the MN to
   both the MN on the old L2 and by tunneling to the nFA. The oFA must
   also be prepared to receive packets sent by the MN under its old care
   of address on the new L2 that are tunneled by nFA.

   Once a visitor entry has been created in nFA, and the MN establishes
   an L2 connection with the nFA, its traffic will be immediately
   delivered, along with an Agent Advertisement message [1]. The nFA can
   determine when to send the Agent Advertisement by the L2-NHC trigger.
   If the MN receives an L2-MHC trigger, it can send an Agent
   Advertisement Solicitation. Alternatively, if neither L2 trigger is
   available, the MN will respond to a periodic Agent Advertisement sent
   according to [1]. In any case, the MN can continue to use its old
   care of address without any delay in uplink L3 connectivity until it
   is established on the new L3 since the nFA tunnels its packets back
   to the oFA. An MN MUST issue a Registration Request when it receives
   an Agent Advertisement from the nFA, completing the L3 handoff.

   Note that the nFA MAY delay sending an Agent Advertisement,
   especially to reduce noticeable service disruption during a ping-
   pong. However, when doing so, the nFA MAY need to re-issue a new
   Handoff Request to oFA, to extend the visitor entry's lifetime.

   In the event that the visitor entry for an MN at nFA is about to
   expire and the MN has not yet issued a Registration Request, the nFA
   has the option to transmit a new Handoff Request message to the oFA
   to renew the registration. Whether the renewal is performed on behalf
   of the MN is a policy decision up to the network administrator.



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   An FA MAY receive packets for a MN to which it does not have a direct
   link layer connection. The FA MAY:

   - drop all packets for the MN, or

   - buffer packets for the MN.

   The choice of which action to take may depend on the type of traffic
   involved, but this is outside the scope of this document. The MN MAY
   also in parallel attempt to establish a link-layer connection with
   the MN. An FA MUST NOT send ICMP Destination Unreachable messages if
   it drops packets or is unable to deliver the received IP packets due
   to unavailability of direct layer connection with the MN. Given that
   a MN's packets will be delivered prior to a proper registration, the
   MN MAY discard all packets received from FAs with which it has not
   registered.

   When the nFA receives the MN's Registration Request [1] and the HA's
   or GFA's successful Registration Reply [1][2], it MUST transmit a
   Handoff Request message to the oFA with the lifetime field set to
   zero. An oFA that receives a Handoff Request with the lifetime field
   set to zero is being informed that it is no longer the anchor point
   for the mobile. The oFA SHOULD stop bicasting at this point, and tear
   down the reverse tunnel from nFA, since the MN is now fully connected
   at L3 on the new subnet. The oFA MAY issue a Handoff Request to the
   nFA in the future if it wishes to keep receiving the mobile's packets
   for possible delivery.


4.4  Handoff Request Message

   The Handoff Request message is used to inform a peer that a POST-
   REGISTRATION handoff is being initiated. The Handoff Request message
   can be used for both source and target triggers, through the Type of
   Trigger 'I' bit in the message flags. When sent as a result of a
   target trigger, the home address and HA fields MAY be set to zero
   (unless this information was communicated by the link layer, which is
   outside the scope of this document).
















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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |S|x|I|M|G|r|T|x|          Lifetime             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        MN Home Address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          HA Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                         Identification                        +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Extensions ...
      +-+-+-+-+-+-+-+-

   Type              TBD (Handoff Request)

      S                 When set it indicates that both oFA and nFA will
                        attempt to deliver datagrams directly to MN, if
                        a link-layer connection exists.

      I                 Type of Trigger. A value of zero is a source
                        trigger (request sent by oFA), while a value of
                        one is a target trigger (request sent by nFA).

      M, G, T           As defined in [1,5].  This refers to the
                        tunnel between oFA and nFA.

      Lifetime          The requested Lifetime for which nFA will serve
                        the MN on behalf of oFA, without requiring a new
                        registration.

      MN Home Address   The home address of the MN.  When using
                        a private address, the G and T flags must be
                        sent and a GRE Key extension must be included.

      HA Addr           The HA address of the mobile node.

      Identification    As in defined in [1].

      Extensions        The Message MUST include LLA (see Section 7) and
                        the FA-FA Authentication Extension [2].


4.5  Handoff Reply Message

   The Handoff Reply message is sent in response to the Handoff Request
   message. When a source trigger caused the Handoff Request message to
   be sent, the Handoff Reply message is sent with a successful code if
   the Visitor Entry was successfully created. When a target trigger



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   caused the Handoff Request message, receipt of the Handoff Reply
   message with a successfuly code SHOULD cause the Visitor Entry to be
   created.


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

      Type              TBD (Handoff Reply)

      Code              A value indicating the result of the Handoff
                        Request.  See below for a list of currently
                        defined Code values.

      Lifetime          If the Code field indicates that the
                        registration was accepted, the Lifetime field is
                        set to the number of seconds remaining before
                        the registration is considered expired.  A value
                        of zero indicates that the mobile node has been
                        deregistered.  A value of 0xffff indicates
                        infinity.  If the Code field indicates that the
                        registration was denied, the contents of the
                        Lifetime field are unspecified and MUST be
                        ignored on reception.

      S                 When set it indicates that both oFA and nFA will
                        attempt to deliver datagrams directly to MN, if
                        a link-layer connection exists.

      I                 Type of Trigger. A value of zero is a source
                        trigger (reply sent by nFA), while a value of
                        one is a target trigger (reply sent by oFA).

      M, G, T           As defined in [1,5].  This refers to the
                        tunnel between oFA and nFA.




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


      MN Home Address   The home address of the mobile node.  When using
                        a private address, the G and T flags must be
                        sent and a GRE Key extension must be included.

      HA Addr           The HA address of the mobile node.

      Lifetime          The requested Lifetime for which nFA will serve
                        the MN on behalf of oFA, without requiring a new
                        registration.

      Identification    As in defined in [1].

      Extensions        The Message MUST include LLA (see Section 7)
                        and the FA-FA Authentication Extension [2].


4.6 Applicability of POST-REGISTRATION Handoff Method

   The POST-REGISTRATION handoff approach allows FAs to communicate
   directly about a pending handoff, and does not require any IP layer
   messages to be sent to or from a MN prior to the L2 handoff event.
   Therefore, it does not place the MN's IP stack or Mobile IP client
   implementation on the critical path after a need for handoff is
   recognized but before the handoff can take place. This separation is
   necessary when the link layer imposes hard deadlines on the time at
   which a handoff must occur, such as when a MN is rapidly moving out
   of a radio coverage area, but when the MN's IP stack is not
   implemented as a hard real-time system.

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

   POST-REGISTRATION handoff is appropriate in the following cases:

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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

   - Access point choice by the MN is not a concern or choice requires
     user intervention and therefore is not on the critical path for
     handoff.


5. Combined Handoff Method

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

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

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

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


6. Reverse Tunneling Support

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   technologies may allow the reverse tunnel to be turned off unless the
   MN specifically requests it.


7. Generalized Link Layer Address Extension

   This section defines the Generalized Link Layer Address (LLA)
   Extension, used by any node that needs to communicate Link Layer
   Addresses. The format of the extension follows MIER [7], and each
   sub-type of link-layer address defines its own sub-structure. This
   draft defines five sub-types. Future RFCs should allocate their own
   sub-type and define their own address formats.

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

      Type

        TBD (skippable) [1]

      Length

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

      Sub-Type

        This field contains the Link Layer sub-type identifier

      LLA

        Contains the Link Layer Address

      In this document, five subtypes are defined:

            1        International Mobile Station Identity (e.g. [8])
            2        Ethernet 48 bit MAC address [9]
            3        64 bit Global ID, EUI-64 [10]
            4        Solicited IP Address
            5        Solicited Access Point Identifier

   The following subsections describe the extensions.


7.1  IMSI Link Layer Address Extension

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

         Type

            TBD (skippable) [1]

         Length

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

         Sub-Type

            1

         IMSI

            Contains the IMSI, in the form:

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


7.2  Ethernet Link Layer Address Extension

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


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

         Type

            TBD (skippable) [1]

         Length

            7 (includes the Sub-Type field)



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


         Sub-Type

            2

         MAC

            Contains the 48 bit Ethernet MAC Address.


7.3  IEEE 64-Bit Global Identifier (EUI-64) Address Extension

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


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

   Type

            TBD (skippable) [1]

         Length

            9 (includes the Sub-Type field)

         Sub-Type

            3

         MAC

            Contains the 64-Bit Global Identifier Address.


7.4  Solicited IP Address Extension

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


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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   Type

            TBD (skippable) [1]

         Length

            5 (includes the Sub-Type field)

         Sub-Type

            4

         IP Address

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


7.5  Solicited Access Point Identifier Extension

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

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

   Type

            TBD (skippable) [1]

         Length

            5 (includes the Sub-Type field)
         Sub-Type

            5

         AP ID

            Contains the 32-Bit Access Point Identifier.


8.  IANA Considerations

   Section 7 introduces the Generalized Link Layer Address Extension
   numbering space that requires IANA management. This specification



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   makes use of the values 1-5, and all other values other than zero (0)
   are available for assignment via IETF consensus [14]. The numbers for
   the Generalized Link Layer Address Extension are taken from the
   numbering space defined for Mobile IP registration extensions defined
   in RFC 2002 [1]. These MUST NOT conflict with any numbers used in RFC
   2002[1], RFC 2344 [5], RFC 2356 [12], RFC 2794 [13] and RFC 3012
   [11].

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

9.  Security Considerations

   A security consideration for PRE-REGISTRATION method involves
   changing the TTL for Router Advertisement messages sent between oFAs
   and nFAs, where multiple hops are present between oFA and nFA. The
   same applies to Registration Request messages sent by the MN to nFA
   routed through oFA and similarly Registration Reply messages. As
   discussed in Section 3.8, oFA and nFA must share a security
   association and oFA must be authorized to solicit nFA and relay
   Registration Request/Reply. In addition, the case involving tunneling
   of Agent Advertisements between the nFA and the MN requires
   restricitions to be relaxed so the TTL of the Router Advertisement is
   not required to be 1, as described in Section 3.4.2. Otherwise, PRE-
   REGISTRATION uses AAA-based security for both inter-domain and intra-
   domain handoff as described in [1] and [2]. Also, if the FA
   Challenge/Response mechanism in [11] is used then the
   MIN_SOLICITATION_INTERVAL must be set to a value smaller or equal to
   the CHALLENGE_WINDOW (in nFA) so that the nFA challenge does not
   expire before the MN issues the Registration Request.

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

   Since the techniques outlined in this document depend on particular
   aspects of L2 handoff to optimize performance, some amount of L2
   security is assumed. Both techniques depend on L2 triggers, and the
   security of handoff requires that the L2 triggers be secure. In
   addition, the POST-REGISTRATION technique depends on the ability of
   the wireless network to securely identify MNs. Although this document
   does not specify how FAs can identify or track MNs, it is assumed
   that the wireless L2 is sufficiently secure in order to correctly
   identify a MN. Wireless networks that do not provide such features
   will be subject to impersonation attacks, where malicious nodes could
   cause FAs to believe that a MN has moved to other service areas, and



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   to allow a bogus MN to obtain unauthorized service from an FA prior
   to performing a Mobile IP registration. The PRE-REGISTRATION
   technique instead depends on Mobile IP security between MN and FA, so
   the same security considerations in [1] apply.

9.1  AAA Considerations for Security

   For handoff between Administrative Domains (ADs), both techniques may
   experience additional latency if the MN must establish a security
   association with nFA prior to the handoff taking effect. For PRE-
   REGISTRATION, the need to establish a security association could
   delay the registration process so that no Registration Reply is
   received. For POST-REGISTRATION, it could result in the MN's traffic
   being delayed until the completion of a formal Mobile IP registration
   rather than as soon as the MN establishes an L2 connection at nFA.
   This section discusses an approach for reducing latency due to the
   need to establish a new security association.

                         +-----+               +-----+
                         | AAA |-------------->| AAA |
                         +-----+               +-----+
                            ^                     |
                            |                     |
                            | AAA                 |
                            | Hand-Off            |
                            | Req                 |
                            |                     v
                         +-----+               +-----+
                         | oFA |               | nFA |
                         +-----+               +-----+

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

                   Figure 11 - Inter-FA communication using AAA

   If the existing AAA infrastructure is used to establish dynamic
   security associations between FAs and HAs in different ADs, the same
   infrastructure could be used to establish the required security
   association for the purposes of inter-domain handoff as shown in
   Figure 11.

   Note that it is possible for geographically neighboring FAs owned by
   different ADs to have a pre-established security association, which
   would reduce the latency introduced by the AAA infrastructure
   traversal. Given that such geographically neighboring FAs MAY be
   small in number, such an approach MAY be reasonable.






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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


10. References

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

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

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

     [4]  C. Perkins and D. Johnson, "Route Optimization in Mobile
          IP",draft-ietf-mobileip-optim-10.txt (work in progress),
          November 2000.

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

     [6]  S. Hanks, T. Li, D. Farinacci, and P. Traina.  Generic Routing
          Encapsulation (GRE).  Request for Comments (Informational)
          1701, Internet Engineering Task Force, October 1994.

     [7]  M. Khalil, R. Narayanan, H. Akhtar and E. Qaddoura, "Mobile IP
          Extensions Rationalization (MIER)", draft-ietf-mobileip-mier-
          05 (work in progress), Dec. 1999

     [8]  TIA/EIA/IS-95-B

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

     [10] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
          Registration Authority",
          http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
          March 1997.
     [11] C. Perkins,  P. Calhoun, Mobile IP Challenge/Response
          Extensions.  RFC 3012, November 2000.

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

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

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




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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


11. Authors' Addresses

   The authors may be contacted at the addresses below:

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

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


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

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


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

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


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

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





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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

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


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

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


   Hesham Soliman
   Ericsson Radio Systems
   Torshamnsgatan 29, Kista
   Stockholm
   SWEDEN

   Phone:  +46 8 7578162
   Fax:    +46 8 4043630
   E-mail: Hesham.Soliman@era.ericsson.se


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


   The working group can be contacted via the current chairs:

           Basavaraj Patil               Phil Roberts
           Nokia Corporation             Megisto Systems Inc.
           6000 Connection Drive         EMail:  proberts@megisto.com
           Irving, TX 75039
           USA

           Phone:  +1 972-894-6709



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


           EMail:  Raj.Patil@nokia.com
           Fax :  +1 972-894-5349



12. Full Copyright Statement

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

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

























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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


Appendix A - Gateway Foreign Agents

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


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

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

               Figure A.1 - Initial Registrations through GFA

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

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

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


              Figure A.2 - Regional Registration through GFA


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





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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


A.1 GFA Considerations in the PRE-REGISTRATION Method

   When there is a hierarchy of foreign agents between the GFA and the
   announcing FA, the announcing FA MAY include the corresponding FA
   addresses in order between its own address (first) and the GFA
   address (last) in the Mobility Agent Advertisement extension of its
   Agent Advertisements. If there are only two hierarchical levels, a
   foreign agent announces itself and a GFA in the Agent Advertisement;
   in the first and last address in the care of address field in the
   Mobility Agent Advertisement extension. There must be at least one
   care of address in the Mobility Agent Advertisement extension. If
   there is only one care of address it is the address of the GFA, and
   the MN is connected directly to it.

   The MN needs to choose the appropriate HA address in the Regional
   Registration Request. The following two subsections discuss options.

A.1.1 Mobility Agent Extension Advertises FA and GFA Address Only

   In this case, there is always a single path from the MN to the GFA.
   The MN always performs Regional Registrations using the GFA address
   as the HA address and the advertising FA as care of address. As the
   Regional Registration Request is relayed towards the GFA, each FA
   receiving it checks whether it has an existing binding with the MN
   and whether the Regional Registration has the "S" bit set to request
   simultaneous bindings. If this is true and the Regional Registration
   is validated by the GFA, the  FAs activate the simultaneous binding
   upon receiving the successful Regional Registration Reply from the
   GFA. It is not necessary to advertise all FA addresses in the
   hierarchical branch to the MN, thus reducing bandwidth usage over the
   wireless link.

A.1.2 Mobility Agent Advertisement Extension Advertises all FAs

   In specific cases where multiple regional FA levels and multiple
   paths from the MN to the GFA are present and are advertised, it may
   be necessary for the MN to identify the common route FA using the
   complete list of FAs in the hierarchical branch. It is assumed that
   the GFA advertises only one care-of address on all its interfaces
   towards the MN.

   The MN must cache the Mobility Agent Advertisement extensions for its
   active bindings. When it receives an advertisement from a previously
   unseen FA that has a different Mobility Agent Advertisement
   extension, it is eager to perform a new binding. The MN compares the
   IP addresses in the new Mobility Agent Advertisement extension with
   the cached Advertisements for its active bindings. If there is an IP
   address in common between these extensions, named the common route FA
   or GFA, the MN uses that IP address as the HA address and the
   destination address of its Regional Registration Request. In the case
   of a request for bicasting, the "S" bit is set. The care-of address



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


   is the advertising FA's address. The MN adds a Hierarchical FA
   extension to the Regional Registration Request, in order to identify
   the regional FA path to be followed by the Request up the hierarchy.
   A Regional FA receiving a Regional Registration Request with it's own
   address as HA address returns a Regional Registration Reply to the
   MN.

   If there is no IP address in common between the extensions, then the
   MN has moved into a new hierarchy and the GFA advertised in the new
   extension is different from the one in the previously cached
   extensions. When the MN changes GFA, the MN uses the new GFA's IP
   address as care of address in its new Registration Request to the HA
   and adds the Hierarchical FA extension as described previously. If
   the MN has at least one existing active binding when it moves to the
   new GFA, it performs a low loss handoff as explained in this
   document.

   The MN is able to perform GFA registration during PRE-REGISTRATION
   handoffs only if its binding lifetime with the GFA or HA does not
   expire during the period needed by the MN to run PRE-REGISTRATION and
   complete its L2 handoff. Intermediate regional FAs are able to accept
   the MN's regional registration as simultaneous bindings only if the
   intermediate regional FA has an existing active binding for the MN.
   The resulting simultaneous binding therefore has a maximum possible
   lifetime equal to the lifetime remaining in its previously existing
   active binding. Once the registration lifetime with the GFA or HA is
   about to expire, the MN must perform a new Mobile IP registration
   with the HA.


























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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs

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

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


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


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

                             Movement


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

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



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

INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs            May 2001


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

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










































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


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