Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 4881

Pages: 64
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MIP4

Low-Latency Handoffs in Mobile IPv4

Part 1 of 3, p. 1 to 22
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                   K. El Malki, Ed.
Request for Comments: 4881                                       Athonet
Category: Experimental                                         June 2007

                  Low-Latency Handoffs in Mobile IPv4

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   Mobile IPv4 describes how a Mobile Node can perform IPv4-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 IPv4 handoffs.  In addition, a combination
   of these two methods is described.  The described techniques allow
   greater support for real-time services on a Mobile IPv4 network by
   minimizing the period of time when a Mobile Node is unable to send or
   receive IPv4 packets due to the delay in the Mobile IPv4 Registration

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. The Techniques .............................................5
      1.3. L2 Triggers ................................................7
      1.4. Requirements Language ......................................9
   2. Requirements ....................................................9
   3. The PRE-REGISTRATION Handoff Method ............................10
      3.1. Operation .................................................11
      3.2. Network-Initiated Handoff .................................13
      3.3. Mobile-Initiated Handoff ..................................15
      3.4. Obtaining and Proxying nFA Advertisements .................17
           3.4.1. Inter-FA Solicitation ..............................17
           3.4.2. Tunneled nFA Advertisements ........................18
      3.5. Caching Router Advertisements .............................19

Top      ToC       Page 2 
      3.6. Movement Detection, MN, and FA Considerations .............19
      3.7. L2 Address Considerations .................................21
      3.8. Applicability of PRE-REGISTRATION Handoff .................21
   4. The POST-REGISTRATION Handoff Method ...........................23
      4.1. Two-Party Handoff .........................................24
      4.2. Three-Party Handoff .......................................28
      4.3. Renewal or Termination of Tunneling Service ...............34
      4.4. When Will the MN Perform a Mobile IPv4 Registration? ......34
      4.5. Handoff Request (HRqst) Message Format ....................36
      4.6. Handoff Reply (HRply) Message Format ......................38
      4.7. Handoff to Third (HTT) Message Format .....................40
      4.8. Applicability of POST-REGISTRATION Handoff Method .........40
   5. Combined Handoff Method ........................................41
   6. Layer 2 and Layer 3 Handoff Timing Considerations ..............42
   7. Reverse Tunneling Support ......................................42
   8. Handoff Signaling Failure Recovery .............................43
      8.1. PRE-REGISTRATION Signaling Failure Recovery ...............43
           8.1.1. Failure of PrRtSol and PrRtAdv .....................43
           8.1.2. Failure of Inter-FA Solicitation and
                  Advertisement ......................................44
      8.2. POST-REGISTRATION Signaling Failure Recovery ..............44
           8.2.1. HRqst Message Dropped ..............................44
           8.2.2. HRply Message Dropped ..............................45
   9. Generalized Link Layer and IPv4 Address (LLA) Extension ........46
      9.1. 3GPP2 IMSI Link Layer Address and Connection ID
           Extension .................................................47
      9.2. 3GPP IMSI Link Layer Address Extension ....................48
      9.3. Ethernet Link Layer Address Extension .....................49
      9.4. IEEE 64-Bit Global Identifier (EUI-64) Address Extension ..50
      9.5. Solicited IPv4 Address Extension ..........................51
      9.6. Access Point Identifier Extension .........................52
      9.7. FA IPv4 Address Extension .................................53
   10. IANA Considerations ...........................................53
      10.1. New Extension Values .....................................53
      10.2. Generalized Link Layer and IP Address Identifier (LLA) ...54
      10.3. New Message Type and Code ................................54
   11. Security Considerations .......................................55
   12. Acknowledgements ..............................................57
   13. References ....................................................57
      13.1. Normative References .....................................57
      13.2. Informative References ...................................58
   Appendix A - Gateway Foreign Agents................................59
   Appendix B - Low Latency Handoffs for Multiple-Interface MNs.......60
   Appendix C - PRE_REGISTRATION Message Summary......................61

Top      ToC       Page 3 
1.  Introduction

   Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IPv4-
   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
   techniques to achieve low-latency Mobile IPv4 handoff during movement
   between FAs.  A further combination of these two techniques is also
   described.  The presented techniques allow greater support for real-
   time services on a Mobile IPv4 network by minimizing the period of
   time during which an MN is unable to send or receive IPv4 packets due
   to the delay in the Mobile IPv4 Registration process.  One or more of
   these techniques may be required to achieve fast Mobile IPv4 handoffs
   over different wireless technologies (e.g., WLAN, Cellular, WiMAX,
   Flash-OFDM, etc.).  Each wireless technology has different layer 2
   handoff procedures, and the best low-latency technique for each
   scenario should be used to optimize the handoff performance.  Further
   deployment and experimentation are required to determine which
   technique is best suited to the wireless technologies in terms of
   implementation and performance.  Therefore, the authors encourage
   further performance measurements and work on low-latency-over-foo
   specifications in collaboration with the appropriate wireless
   technology fora to describe the applicability to different wireless
   layer 2s.

   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, and Section 4
   describes the details of the POST-REGISTRATION handoff technique.  In
   Section 5, a combined method using the two handoff techniques
   together is presented.  Section 6 discusses layer 2 and layer 3
   handoff timing considerations.  Section 7 discusses reverse tunneling
   support, Section 8 describes mechanisms to recover from message
   failures, and Section 9 describes protocol extensions required by the
   handoff techniques.  Sections 10 and 11 discuss IANA and security
   considerations.  Finally, the three appendices discuss additional
   material related to the handoff techniques.  Appendix A gives a short
   introduction to Regional Registrations [11], which can be used
   together with low-latency handoffs.  Appendix B discusses low-latency
   handoff when an MN has multiple wireless L2 interfaces, in which case
   the techniques in this document may not be necessary.  Appendix C
   provides a summary of the messages used in PRE-REGISTRATION.

Top      ToC       Page 4 
1.1.  Terminology

   This section presents a few terms used throughout the document.

      oFA - old Foreign Agent (FA), the FA involved in handling the
         care-of address (CoA) of a Mobile Node (MN) prior to a layer 3
         (L3) handoff.

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

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

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

      L3 handoff - Movement of an MN between FAs that involves changing
         the care-of address at Layer 3 (L3).

      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.

      L2-MT - An L2 trigger that occurs at the MN, informing of movement
         to a certain nFA (Mobile Trigger).

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

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

      L2-LU - An L2 trigger that occurs at the MN or nFA, informing that
         the L2 link between MN and nFA is established.

      L2-LD - An L2 trigger that occurs at the oFA, informing the oFA
         that the L2 link between MN and oFA is lost.

      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.

Top      ToC       Page 5 
      seamless handoff - L3 handoff that is both low latency and low

      bidirectional edge tunnel (BET) -  A bidirectional tunnel
         established between two FAs for purposes of temporarily routing
         an MN's traffic to/from it on a new subnet without requiring
         the MN to change CoA.

      ping-pong - Rapid back-and-forth movement between two wireless
         access points often due to failure of L2 handoff.  Ping-pong
         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.

      MN or FA identifier - An IPv4 address of an MN or FA, or an L2
         identifier that can be resolved to the IPv4 address of an MN or
         FA.  If the identifier is an L2 identifier, it may be specific
         to the L2 technology.

1.2.  The Techniques

   Mobile IPv4 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 an MN may only begin the registration process after
        an L2 handoff to nFA (new FA) has completed.

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

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

Top      ToC       Page 6 
      - 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 allows for service to continue
   uninterrupted while the handoff is being processed by the network
   without requiring the MN's involvement.

   Three methods are presented in this document 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, and

      - combined handoff method.

   The PRE-REGISTRATION handoff method allows the MN to be involved in
   an anticipated IPv4-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-initiated.
   Accordingly, L2 triggers are used both in the MN and in the FA to
   trigger particular L3 handoff events.  The PRE-REGISTRATION method
   coupled with 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 IPv4 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 IPv4 protocol to allow the oFA (old FA) and nFA (new FA) to
   utilize L2 triggers to set up a bidirectional tunnel between oFA and
   nFA that allows the MN to continue using its oFA while on nFA's
   subnet.  This enables a rapid establishment of service at the new
   point of attachment, which minimizes the impact on real-time
   applications.  The MN must eventually perform a formal Mobile IPv4
   Registration after L2 communication with the new FA is established,
   but this can be delayed as required by the MN or FA.  Until the MN
   performs registration, the FAs will set up and move bidirectional
   tunnels as required to give the MN continued connectivity.

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

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

1.3.  L2 Triggers

   An L2 trigger is a signal of an L2 event.  In this document, the L2
   events relate to the L2 handoff process.  One possible event is early
   notice of an upcoming change in the L2 point of attachment of the
   mobile node to the access network.  Another possible event is the
   completion of relocation of the mobile node's L2 point of attachment
   to a new L2 access point.  This information may come explicitly from
   L2 in a solicited or unsolicited manner, or it may be derived from L2
   messages.  Although the protocols outlined in this document make use
   of specific L2 information, Mobile IPv4 should be kept independent of
   any specific L2.  L2 triggers are an abstraction mechanism for a
   technology-specific trigger.  Therefore, an L2 trigger that is made
   available to the Mobile IPv4 stack is assumed to be generic and
   technology independent.  The precise format of these triggers is not
   covered in this document, but the information required to be
   contained in the L2 triggers for low-latency handoffs is specified.

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

Top      ToC       Page 8 
   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 contained in the trigger.  The methods presented in
   this document operate based on different types of L2 triggers as
   shown in Table 1.  Once the L2 trigger is received, the handoff
   processes described hereafter are initiated.  The three triggers,
   L2-ST, L2-TT, and L2-MT, are independent of each other and are not
   expected to occur together since each will trigger a different type
   of handoff behaviour.

   | L2 Trigger  |       Mobile         |           Source             |
   |             |       Trigger        |           Trigger            |
   |             |       (L2-MT)        |           (L2-ST)            |
   | Recipient   |          MN          |             oFA              |
   | Method      | PRE                  | PRE          | POST          |
   |             | mobile-initiated     | network-     | source        |
   |             |                      | initiated    | trigger       |
   | When?       | sufficiently before  | sufficiently | sufficiently  |
   |             | the L2 handoff       | before L2    | before L2     |
   |             | so that MN can       | handoff for  | handoff for   |
   |             | solicit PrRtAdv      | FA to send   | oFA & nFA to  |
   |             | from oFA             | PrRtAdv      | exchange      |
   |             |                      | to MN        | HRqst/HRply   |
   | Parameters  | nFA identifier       | nFA identifier, MN identifier|

                            Table 1 - L2 Trigger
                          (continued on next page)

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

                           Table 1 - L2 Trigger

1.4.  Requirements Language

   In this document, the key words "MAY", "MUST", "MUST NOT",
   interpreted as described in [2].

2.  Requirements

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

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

      - to have no dependence on a wireless L2 technology,

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

      - to limit wireless bandwidth usage.

Top      ToC       Page 10 
3.  The PRE-REGISTRATION Handoff Method

   The PRE-REGISTRATION handoff method is based on the normal Mobile
   IPv4 handoff procedure specified in [1], according to 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 basic messages specified in [1] are extended to carry information
   required to achieve fast handoffs.  The PRE-REGISTRATION method
   allows both the MN and FA to initiate the layer 3 handoff and it 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 supports the normal Mobile IPv4 model [1] and
   optionally also the Regional Registration model [11].  There can be
   advantages in implementing [11] together with low-latency handoff
   mechanisms, in particular in cases where the Home Agent (HA) is at a
   distance (in terms of delay) from the nFA.  The time required for the
   handoff procedure to complete can be reduced by using a closer local
   HA, called Gateway Foreign Agent (GFA) in [11].  However,
   implementation of [11] is not required by PRE-REGISTRATION.  PRE-
   REGISTRATION also supports movement where a new Authentication,
   Authorization, and Accounting (AAA) transaction must occur to
   authenticate the MN with a new domain.

Top      ToC       Page 11 
3.1.  Operation

   The PRE-REGISTRATION handoff mechanism is summarized in Figure 1.

                            | HA (GFA)|<---------+
                            +---------+          | 4.  (Reg)RegReq
                                                 | 5.  (Reg)RegReply
                   +-----+    1a.  PrRtSol    +-----+
                   |     | -----------------> | nFA |
                   | oFA |    1b.  PrRtAdv    |     |
                   +-----+ <----------------- +-----+
                    ^   |                       ^
      (2a.  PrRtSol)|   | 2b                    |
                    |   | PrRtAdv               | 3.  (Reg)RegReq
                    |   |                       |
                    |   v   --------------------+
                   +-----+ /
                   | MN  |
                   +-----+    - - - - - ->

            Figure 1 - PRE-REGISTRATION Handoff Protocol

   The following steps provide more detail on the protocol:

      1. Message 1a is a Proxy Router (Agent) Solicitation (PrRtSol)
         from oFA to nFA.  It is a Mobile IP agent solicitation
         containing an identifier for the nFA (i.e., IP address or L2
         address) in a Generalized Link Layer and IP Address Extension
         (see Section 9).  When message 1a is received by the nFA
         containing nFA's correct identifier in the LLA extension, the
         nFA MUST return the Proxy Router Advertisement (Agent
         Advertisement) in message 1b.  Message 1b is simply nFA's Agent
         Advertisement containing the nFA layer 2 address in a
         Generalized Link Layer and IP Address (LLA) Extension (see
         Section 9.3).  Messages 1a and 1b SHOULD occur in advance of
         the PRE-REGISTRATION handoff in order not to delay the handoff.
         For this to occur, oFA SHOULD solicit and cache advertisements
         from neighboring nFAs using messages 1a and 1b, thus decoupling
         the timing of this exchange from the rest of the PRE-
         REGISTRATION handoff.  When the L3 handoff is initiated by a
         target L2 trigger at nFA (L2-TT), message 1b equals message 2b
         and is sent unsolicited directly to MN (tunneled by nFA to MN
         through oFA) instead of being relayed by oFA.

Top      ToC       Page 12 
      2. Message 2a is a Proxy Router Solicitation (PrRtSol) from MN to
         oFA.  It is different from a normal Router (Agent) Solicitation
         since it is soliciting an advertisement from a router different
         from the one receiving this message.  It is a Mobile IP Agent
         Solicitation containing an identifier for the nFA (i.e., IP
         address or L2 address) in a Generalized Link Layer and IP
         Address Extension (see Section 9).  The presence of message 2a
         indicates that the handoff is mobile-initiated 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
         (PrRtAdv).  When message 2a is received by the oFA, it MUST
         return the Proxy Router Advertisement (Agent Advertisement) in
         message 2b.  This is simply nFA's Agent Advertisement
         containing the nFA layer 2 address in a Generalized Link Layer
         and IP Address (LLA) Extension (see Section 9.3).  In network-
         initiated source-triggered handoff, the L2 trigger occurs at
         oFA, and oFA MUST relay the Agent Advertisement in message 2b
         without the need for the MN to solicit.  Note that it is also
         possible for nFA to advertise directly to the MN in the
         network-initiated target-triggered case (see Section 3.2).

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

      4. Messages 4 and 5 complete the standard Mobile IPv4 Registration
         [1] or optionally Regional Registration [11] initiated with
         message 3.  The Registration Request MUST contain the MN's
         layer 2 address in a Generalized Link Layer and IP Address
         Extension (see Sections 3.7 and 9).  This identifier may be a
         plain Ethernet address or an identifier specific to the
         wireless technology.  If the MN is not already connected to
         nFA, the Registration Reply in message 5 MUST be buffered by
         the nFA and unicast to the MN on-link as soon as the MN
         connects to nFA (i.e., L2-LU trigger at nFA, which can be
         implemented by the MN sending an Agent Solicitation or
         optionally using special layer 2 techniques, which are outside
         the scope of this document).  This is necessary since the MN
         may have to detach from oFA, due to the wireless L2 connection,
         before it receives the reply.  The MN's L2 address is obtained
         using the extensions in Section 9, as described in Section 3.7.
         Figures 2 and 3 illustrate this procedure.

Top      ToC       Page 13 
      5. If the registration is successful, packets for the MN are
         tunneled from the HA (or GFA) to the nFA and then to the MN.

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

   The time at which the L2 trigger is received by the oFA or MN,
   thereby triggering the PRE-REGISTRATION handoff, compared to the time
   at which the actual L2 handoff occurs is important for the optimal
   performance of the low-latency handoff.  That is, in the optimal
   case, the L2 trigger will be received and the four messaging steps of
   PRE-REGISTRATION described above will be completed (i.e., up to when
   the Registration Request is processed by HA or GFA) before the MN
   moves.  Optimally, the Registration Reply and the first packet
   redirected by the HA (or GFA) to nFA will reach the MN at the moment
   in which the MN's L2 link to nFA is fully established.  The MN would
   therefore not suffer any disruption due to the L3 handoff.  This
   cannot always be guaranteed unless particular implementation
   techniques are used.  To alleviate a part of this timing problem, the
   MN MAY set the S bit [1] in low-latency Registration Requests sent by
   the MN.  This allows the MN to receive packets at both oFA and nFA
   during the short layer 2 handoff time.  Other techniques may be
   required, such as L2 techniques or buffering, but these are outside
   the scope of this document.  In addition, further handoff smoothing
   considerations may be required to prevent the loss of packets in-
   flight between HA (or GFA) and oFA while the MN performs a PRE-
   REGISTRATION handoff.  These are also outside the scope of this

   Figures 2, 3, and 4 contain message timing diagrams for 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 initiated
   at oFA by a source trigger or at nFA by a target trigger.  Figures 2
   and 3 contain message timing diagrams for PRE-REGISTRATION network-
   initiated handoff for source and target triggers.

   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 contains
   information including the MN's identifier (i.e., the IPv4 address
   itself or an identifier that can be resolved to the IPv4 address) and
   the nFA's identifier.  An identifier may be an IPv4 address or
   something specific to the wireless technology (e.g., Base Station or
   Access Point Identifier).  A target-triggered, network-initiated

Top      ToC       Page 14 
   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 and contains information including the MN's
   and the oFA's identifier.

   MN                    oFA                 nFA                 HA/GFA
    |                     |<~~~~~~ L2-Source  |                    |
    |                     |           Trigger |                    |
    |<--------------------|                   |                    |
    |     PrRtAdv         |                   |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   RegReq or         |                   |                    |
    |   RegRegReq (routed via oFA)            |------------------->|
    |                                         | RegReq or RegRegReq|
    |                                         |                    |
    |                          Buffered ~~~~~>|<-------------------|
    |---------------------------------------->|    (Reg)RegReply   |
    | Agent Solicitation                      |                    |
    | (sent when MN connects to nFA)          |                    |
    |                                         |                    |
    |<----------------------------------------|                    |
    |              (Reg)RegReply              |                    |
    |              (sent when nFA receives Solicitation or L2-LU)  |

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

   In a source-triggered handoff, when oFA receives the trigger (L2-ST),
   it MUST send message 2b, the Proxy Router Advertisement (PrRtAdv), to
   the MN.  The PrRtAdv is nFA's Agent Advertisement [1] with one of the
   link-layer extensions described in Section 9.  The use of the
   contents of this extension is described in Section 3.7.  Messages 1a
   and 1b SHOULD be exchanged by oFA and nFA before the L2 trigger is
   received (see Section 3.4.1).  Message 2a is not used.

Top      ToC       Page 15 
   MN                    oFA                 nFA                 HA/GFA
    |                     | L2-Target~~~~~~~~>|                    |
    |                     |    Trigger        |                    |
    |                     |...................|                    |
    |<--------------------------------------- |                    |
    |     (PrRtAdv)       |...................|                    |
    |                     | Tunneled Agent Advertisement           |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   RegReq. or        |                   |                    |
    |   RegRegReq (routed via oFA)            |------------------->|
    |                                         | RegReq or RegRegReq|
    |                                         |                    |
    |                          Buffered ~~~~~>|<-------------------|
    |---------------------------------------->|    (Reg)RegReply   |
    | Agent Solicitation                      |                    |
    | (sent when MN connects to nFA)          |                    |
    |                                         |                    |
    |<----------------------------------------|                    |
    |              (Reg)RegReply              |                    |
    |              (sent when nFA receives Solicitation or L2-LU)  |

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

   In a target-triggered handoff, when nFA receives the trigger (L2-TT),
   it MUST tunnel an Agent Advertisement to the MN through oFA to
   initiate the L3 handoff.  The inner advertisement is unicast by nFA
   to MN, thus nFA treats the target trigger as a Router (Agent)
   Solicitation.  This advertisement is tunneled to oFA, which functions
   as a normal router, decapsulating the advertisement and forwarding it
   to the MN.  This message MUST be authenticated to prevent attacks
   (see Section 3.4.2).

3.3.  Mobile-Initiated Handoff

   As shown in Table 1, a mobile-initiated handoff occurs when an L2
   trigger is received at the MN informing that it will shortly move to
   nFA.  The L2 trigger contains information such as the nFA's
   identifier (i.e., nFA's IPv4 address or an identifier that can be
   resolved to the nFA's IPv4 address).  As an example, a Wireless LAN
   MN may perform a scan to obtain the Base Station Identifier (BSSID)
   of the access point that is a potential handoff target (i.e., its
   signal is becoming stronger).  The message timing diagram is shown in
   Figure 4.

Top      ToC       Page 16 
   MN                    oFA                 nFA               HA/GFA
    |<~~~~~ L2-Trigger    |                   |                    |
    |                     |                   |                    |
    |-------------------->|                   |                    |
    |      PrRtSol        |                   |                    |
    |                     |                   |                    |
    |<--------------------|                   |                    |
    |      PrRtAdv        |                   |                    |
    |                     |                   |                    |
    |---------------------------------------->|                    |
    |   RegReq or         |                   |                    |
    |   RegRegReq (routed via oFA)            |------------------->|
    |                                         | RegReq or RegRegReq|
    |                                         |                    |
    |                          Buffered ~~~~~>|<-------------------|
    |---------------------------------------->|    (Reg)RegReply   |
    | Agent Solicitation                      |                    |
    | (sent when MN connects to nFA)          |                    |
    |                                         |                    |
    |<----------------------------------------|                    |
    |              (Reg)RegReply              |                    |
    |              (sent when nFA receives Solicitation or L2-LU)  |

         Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram

   As a consequence of the L2 trigger (L2-MT), the MN MUST send message
   1a, the Proxy Router Solicitation (PrRtSol).  This message is a
   unicast Agent Solicitation to oFA for a Proxy Router Advertisement
   (PrRtAdv).  This solicitation MUST have a TTL=1 as in [1].  The Proxy
   Router Advertisement Solicitation unicast to oFA is an Agent
   Solicitation with a special extension.  The solicitation MUST have an
   extension containing an FA identifier (i.e., IPv4 address or L2
   address contained in an LLA extension, see Section 9) because the MN
   is soliciting another specific FA's advertisement from the oFA.  This
   specific FA will be the MN's nFA.  The identifier is the IPv4 address
   of the nFA or another identifier that can be used by the oFA to
   resolve to nFA's IPv4 address.  If the identifier is not an IPv4
   address, it MAY be specific to the underlying wireless technology,
   for example, an access point or Base Station Identifier (e.g., WLAN
   BSSID) that can be mapped by oFA to the nFA IPv4 address as described
   in Section 3.4.1.  The extension containing the identifier is a sub-
   type of the Generalized Link Layer Address Extension described in
   Section 9.

   Two extension sub-types have been defined to contain the nFA's IPv4
   address and an access point identifier.  They are called the
   Solicited Agent IPv4 Address Extension and the Access Point

Top      ToC       Page 17 
   Identifier Extension, and are described in Sections 9.5 and 9.6.
   These two extensions SHOULD NOT be present in the same PrRtSol

   When oFA receives the PrRtSol message, it MUST reply to the MN with
   the Proxy Router Advertisement (PrRtAdv, message 2b).  The PrRtAdv is
   simply the Agent Advertisement for the requested nFA, proxied by oFA.
   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, as specified in Section 3.5.  The PrRtAdv message
   MUST contain the nFA's L2 address (using the LLA extension in Section
   9.3).  This is further described in Section 3.7.

3.4.  Obtaining and Proxying nFA Advertisements

   Since L2 triggers are involved in initiating PRE-REGISTRATION
   handoff, the trigger timing SHOULD be arranged such that a full L3
   PRE-REGISTRATION handoff can complete before the L2 handoff process
   completes.  That is, the L2 handoff should be completed after the
   MN's registration with the nFA is performed (message 3 in Figure 1).
   The registration MAY be transmitted in more than one copy (default
   recommendation: 2) to reduce the probability that it is lost due to
   errors on the wireless link.  This would not apply to reliable
   wireless links where retransmissions are performed at layer 2 in case
   of error to guarantee packet delivery.

   A PRE-REGISTRATION handoff in this case requires the MN to receive an
   Agent Advertisement from the nFA through the old wireless access
   point.  How to achieve this is discussed in the following
   subsections.  Messages exchanged between FAs MUST be authenticated to
   prevent impersonation attacks.  The minimal requirement is that all
   FAs involved in low-latency handoffs MUST support manual pre-
   configuration of security associations with other neighboring FAs,
   involving shared keys and the default algorithms of [1] (see the
   Security Considerations of this document).

3.4.1.  Inter-FA Solicitation

   This applies to the network-initiated source-triggered (L2-ST) and
   mobile-initiated (L2-MT) cases only.  Inter-FA solicitation assumes
   that oFA has access to the IPv4 address of the nFA.  The IPv4 address
   of nFA is obtained by means of an L2 trigger at oFA in the network-
   initiated case (see Section 3.2) or by means of the extension to the
   Proxy Router Solicitation (PrRtSol) from the MN in the mobile-
   initiated case (see Section 3.3).  This extension to the PrRtSol may
   contain an IPv4 address or another identifier, for example, an
   identifier of a Wireless Base Station such as the WLAN BSSID.  In the
   latter case, the oFA must implement a mechanism to resolve the Base

Top      ToC       Page 18 
   Station Identifier to an IPv4 address.  The default mechanism is to
   use a configured table of neighboring Base Station Identifiers (e.g.,
   BSSID) to FA IPv4 address mappings in each FA.  Other automated
   discovery mechanisms may also be used.

   If oFA does not cache advertisements (see Section 3.5) once it
   receives an L2 trigger and obtains the address of the nFA for a
   specific MN, it MUST send a unicast Agent Solicitation (PrRtSol) to
   nFA.  The nFA replies to the oFA by unicasting an Agent Advertisement
   with appropriate extensions (PrRtAdv).  This method removes the TTL
   limitation of [1] for Mobile IPv4 messages (i.e., TTL=1 is not
   applicable here).  The TTL limitation cannot be applied since oFA and
   nFA may be more than one hop away and since it is unnecessary for a
   secured unicast message.  The ICMP solicitations and advertisements
   MUST be authenticated and integrity protected.  These messages MUST
   be protected using Encapsulating Security Payload (ESP) [10] to
   prevent attacks (see the Security Considerations section of this
   document).  An FA MUST NOT accept ICMP solicitations or
   advertisements from sources that are not authenticated.

   As a practical matter, oFA SHOULD pre-solicit and cache
   advertisements from known neighboring FAs (see section 3.5) to avoid
   performing the solicitation during an actual handoff procedure.

3.4.2.  Tunneled nFA Advertisements

   This applies to the network-initiated target-triggered (L2-TT) case
   only.  Following a target trigger (L2-TT) the nFA MUST send a
   tunneled Agent Advertisement to the MN through oFA.  Tunneling nFA
   advertisements assumes that the nFA is aware of the IPv4 address for
   oFA and the MN.  These IPv4 addresses are obtained by means of the FA
   and MN identifiers contained in an L2 trigger received at nFA in the
   network-initiated case (see Section 3.2).  However, in [1] the TTL
   must be 1 on Agent Advertisements from the nFA.  Therefore, tunneling
   advertisements is applicable if the TTL limitation of [1] is relaxed.
   For this purpose, a pre-established security association between oFA
   and nFA MUST be in place to authenticate this message and relax the
   TTL limitation.  If the implementation requires this, a tunnel SHOULD
   be configured when the inter-FA security association is established.
   The tunneled ICMP advertisement MUST be secured using tunnel mode ESP
   [10] between nFA and oFA.  An FA MUST NOT accept tunneled ICMP
   packets destined to it from sources that are not authenticated.

Top      ToC       Page 19 
3.5.  Caching Router Advertisements

   In the mobile-initiated (L2-MT) case and the network-initiated
   source-triggered (L2-ST) case, the message exchange 1 in Figure 1
   could impose an additional latency on the L3 handoff process if done
   as part of the handoff procedure.  In order to remove this source of
   latency, the inter-FA Router (Agent) Solicitation and Advertisement
   exchange SHOULD be performed in advance of handoff.  A process SHOULD
   be in place at the oFA to solicit its neighboring 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 second.  If the FA Challenge/Response
   mechanism in [7] is used, then the MIN_SOLICITATION_INTERVAL MUST be
   set to a value smaller then the window of time in which a challenge
   remains valid so that the nFA challenge does not expire before the MN
   issues the Registration Request.  Therefore, the recommended default
   value for the MIN_SOLICITATION_INTERVAL in oFA is (0.5 * nFA's
   CHALLENGE_WINDOW * nFA's Agent Advertisement interval).  The
   CHALLENGE_WINDOW and Agent Advertisement interval are defined in [7]
   and [1] respectively.  The minimum requirement is that the
   MIN_SOLICITATION_INTERVAL MUST be manually configurable, while
   possible autoconfiguration mechanisms are outside the scope of this
   document.  To allow advertisement caching in certain implementations
   and in cases where the nFA advertisement interval is very small, it
   MAY be necessary for the implementation in nFA to allow different
   CHALLENGE_WINDOW and Agent Advertisement interval settings for its
   nFA-oFA interface.

   The oFA SHOULD cache the most recent advertisement from its
   neighboring nFAs.  This advertisement MUST 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 neighboring nFAs.  The minimum requirement
   for each FA is that it SHOULD allow manual configuration of a list of
   nFA addresses that an MN could possibly perform an L3 handoff to.
   The FA addresses in this list will depend on deployment and radio
   coverage.  It is also possible to specify another protocol to achieve
   nFA discovery, but this is outside the scope of this document.

3.6.  Movement Detection, MN, and FA Considerations

   When the MN receives an Agent Advertisement with a Mobility Agent
   extension, it performs actions according to the following movement
   detection mechanism: the MN SHOULD be "Eager" to perform new
   bindings.  This means that the MN SHOULD 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

Top      ToC       Page 20 
   could 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 use an FA-NAI extension [11].  By being "Eager" to
   perform registrations, the MN reduces latency times.

   The MN also needs to change its default router from oFA to nFA.  The
   MN MUST change its default router to nFA as soon as the PRE-
   REGISTRATION procedure has completed (i.e., Registration Reply is
   received by MN) as described in [1].

   Overall, the MN behaves as described in [1] with the following
   changes: the specified movement detection mechanism mentioned above
   and the ability to use the L2-MT to initiate an Agent Solicitation
   with a special extension (PrRtSol).  Also, when the MN receives an
   L2-LU trigger (i.e., new interface or link is up), it MUST
   immediately send an Agent Solicitation [1] on that interface.  An nFA
   that receives an Agent Solicitation [1] will use it as an L2-LU
   trigger event, and according to [1] it will record the MN's
   IPv4/layer 2 addresses (i.e., the Address Resolution Protocol (ARP)
   entry).  At that point, the nFA starts delivering data to the MN
   including the previously buffered Registration Reply.  The nFA MAY
   also use other L2 mechanisms to detect earlier that the MN has
   attached to the new link and to start forwarding data to it.  The MN
   SHOULD NOT attempt to retransmit a low-latency Registration Request
   (i.e., Registration Request containing an LLA extension described in
   Section 9.) when it does not receive the Registration Reply.

   When moving from a PRE-REGISTRATION network to a normal Mobile IPv4
   [1] network, the MN will no longer receive PrRtAdv messages (i.e.,
   Agent Advertisements with the LLA extension).  If the MN still
   receives L2-MTs, it will attempt to send PrRtSol messages.  The
   normal FA will reply with a normal Agent Advertisement [1].  If the
   MN does not receive a PrRtAdv in reply to its PrRtSol, it MAY
   retransmit the PrRtSol message once after PRE_SOL_INTERVAL seconds
   and then for another PRE_SOL_ATTEMPTS times with exponential backoff
   of the transmission interval.  If a PrRtAdv is not received within
   PRE_SOL_INTERVAL seconds after the last PrRtSol attempt, the MN MUST
   stop sending PrRtSol messages until after a registration with a new
   FA is performed.  The default value for PRE_SOL_ATTEMPTS is 2, and
   for PRE_SOL_INTERVAL, it is 1 second.  It should be noted that the
   performance of the movement detection mechanism mandated in PRE-
   REGISTRATION (i.e., eager to register) may have sub-optimal behaviour
   in a standard Mobile IPv4 [1] network.  Therefore, standard movement
   detection mechanisms [1] should be used in plain Mobile IPv4
   networks.  Instead, when the MN moves from a normal Mobile IPv4 [1]
   network to a PRE-REGISTRATION network, the MN starts receiving L2-MT
   triggers or PrRtAdv messages.  When the MN receives L2-MT triggers or
   PrRtAdv messages, it SHOULD follow the PRE-REGISTRATION procedure.

Top      ToC       Page 21 
   If there is uncertainty as to which mode to choose (e.g., MN receives
   messages from both PRE-REGISTRATION and normal FAs), the MN decides
   based on its registration status with the current FA.  If the MN
   already has a valid normal Mobile IPv4 Registration [1] with the
   advertising FA, it SHOULD give priority to the PRE-REGISTRATION
   procedure.  Otherwise it SHOULD give priority to normal Mobile IPv4
   [1] Registration procedure.  The MN SHOULD NOT attempt to perform
   PRE-REGISTRATION and standard Mobile IPv4 [1] Registrations in

3.7.  L2 Address Considerations

   Some special considerations should be taken with respect to the
   wireless system on which this handoff method is being implemented.
   Consider an Ethernet-like system such as IEEE 802.11, for example.
   In PRE-REGISTRATION, the MN is registering with an FA (nFA) that is
   not its current first-hop router; therefore, the L2 address of the
   Ethernet frame containing the MN's Registration Request reaching the
   nFA is not the MN's address.  Therefore, the FA MUST NOT use the
   Ethernet address of the incoming Registration Request as the MN's L2
   address as specified in [1].  This applies to the cases where the
   wireless access points are bridges or routers and independently of
   whether the FA is implemented in the wireless access points
   themselves.  In this case, the MN's Registration Request (or Regional
   Registration Request) MUST use an L2 address extension to the
   registration message.  Such an L2 address is either the same L2
   address that remains constant as the MN moves, or it is the MN's L2
   address at nFA.  To communicate its L2 address, the MN includes a
   Generalized Link Layer and IP Address Extension (see Section 9) with
   its Registration Request (or Regional Registration Request) message.
   If this extension is present, the FA MUST use the L2 address
   contained in the extension to communicate with the MN.  If a
   particular wireless L2 technology has defined a special interface to
   the wireless network that allows the FA to resolve the mapping
   between an MN's IPv4 address and its L2 address without the need to
   use the extension, the L2 address extension contents may be
   discarded.  For the same reasons above, the MN MUST NOT use the
   source L2 address of the Agent Advertisement message (PrRtAdv) as its
   default router's L2 address.  Therefore, the nFA MUST include a
   Generalized Link Layer and IP Address Extension (see Section 9.3)
   with its Agent Advertisement (PrRtAdv) messages.

3.8.  Applicability of PRE-REGISTRATION Handoff

   The PRE-REGISTRATION handoff method is applicable to scenarios where
   a period of service disruption due to layer 3 is not acceptable, for
   example, when performing real-time communications, and therefore
   where an anticipation of the layer 3 handoff is required.  Security

Top      ToC       Page 22 
   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 is able to obtain an L2 trigger
   informing it of a pending L2 handoff procedure.  The target of the L2
   handoff is another access point or radio network that is in the
   coverage area of a new FA.  The L2 trigger information may be in the
   form of identifiers that need to be resolved to IPv4 addresses using
   methods that may be specific to the wireless network and are not
   considered here.  If, for example, the oFA or MN determines that the
   IPv4 address of the new FA matches oFA's address, then 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 is efficient to engineer the network such that this succession of
   events is ensured.

   The PRE-REGISTRATION handoff method is applicable in the following

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

      - when L2 security between the MN and the FA is either not present
        or cannot be relied upon to provide adequate security.

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

Next RFC Part