tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4881

 
 
 

Low-Latency Handoffs in Mobile IPv4

Part 2 of 3, p. 23 to 45
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 23 
4.  The POST-REGISTRATION Handoff Method

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

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

                Figure 5 - POST-REGISTRATION Concept

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

   Messages between oFA/aFA and nFA MUST be authenticated.  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].  POST-REGISTRATION FAs MUST implement the inter-FA
   authentication extension (FA-FA authentication extension) specified
   in [11] and MAY additionally use other security mechanisms.

Top      Up      ToC       Page 24 
4.1.  Two-Party Handoff

   Two-party handoff occurs when the MN moves from oFA to nFA.
   Normally, this movement would result in a new Mobile IPv4
   Registration at nFA.  However, in POST-REGISTRATION, the MN and nFA
   MAY delay this but maintain connectivity using the BET (or
   alternatively unidirectional tunnel) between oFA and nFA.  The
   protocol is shown in Figure 6.

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

            Figure 6 - Two-Party Handoff (POST-REGISTRATION)

   The following describes the progress of a two-party handoff.  The
   numbered items refer to steps in Figure 6.  The source-triggered
   HRqst/HRply message for tunnel creation, the target-triggered
   HRqst/HRply message for tunnel creation, and the HRqst/HRply to
   extend or terminate a BET (or unidirectional tunnel) are identified
   using the suffixes (s), (t), and (r), respectively.

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

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

         b) The L2 trigger is a target trigger (L2-TT) at nFA.  The
            trigger contains the MN's L2 address and an identifier for
            the oFA (the IPv4 address itself or an L2 address that can
            be resolved to the IPv4 address of the oFA).

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

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

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

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

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

         b) If nFA sends the HRply, the H bit is set and the N and R
            bits are unset, indicating that this is a response to
            HRqst(s), i.e., it is an HRply(s).  If the T bit is set, the
            nFA indicates that it requests a reverse tunnel, and the
            lifetime field is set with the requested tunnel lifetime.
            The T bit can be set in HRply only if the oFA had set the T
            bit in the corresponding HRqst or if the nFA is required to
            reverse tunnel incoming packets to oFA because ingress
            filtering is enabled on its network.  This establishes a
            BET.  The tunnel lifetime requested by the nFA must be less
            than or equal to the tunnel lifetime offered by oFA in the
            HRqst(s).  Section 4.6 describes the HRply(s).

Top      Up      ToC       Page 26 
      4) The point during the L2 handoff in which the MN is no longer
         connected on a given link is signaled by an L2-LD trigger at
         oFA and MN.  Completion of L2 handoff is signaled by an L2-LU
         trigger at nFA and MN.  The trigger is handled as follows:

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

         b) When the nFA receives the L2-LU trigger, it begins
            delivering packets tunneled from oFA to MN and forwards
            outbound packets from MN using normal routing mechanisms or
            through a reverse tunnel to oFA or HA.  The nFA at this
            point may not yet be the default router of the MN (see
            Section 4.4); therefore, to receive all outbound packets
            from the MN the nFA must send a unicast proxy ARP message
            (used in [1]) to the MN upon receiving an L2-LU trigger.
            This proxy ARP message is an ARP Reply [5] sent by the nFA
            on behalf of oFA, therefore supplying the nFA link-layer
            address in the Sender Hardware Address field and the oFA
            IPv4 address in the Target Protocol Address field.

         c) When the MN receives the L2-LU, it MAY initiate the Mobile
            IPv4 Registration process by soliciting an Agent
            Advertisement as described in [1].  If the registration is
            successful, the nFA takes over the role of anchor FA (aFA)
            from the oFA.  Alternatively, the MN MAY defer the Mobile
            IPv4 Registration (see Section 4.4).

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

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

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

Top      Up      ToC       Page 27 
   The actual timing of BET or unidirectional tunnel placement depends
   on the available L2 triggers.  The forward tunnel from oFA to nFA is
   constructed using one of the tunneling procedures described in [1]
   for the HA to FA tunnel with the difference that the ends of the
   tunnel are at the oFA and nFA, respectively.  The reverse tunnel from
   nFA to oFA is constructed as described in [3] with the difference
   that the network end of the tunnel is at the oFA instead of the HA.
   If both forward and reverse tunnels are established, then a BET has
   been established.  With optimal L2 trigger information, as described
   above, the FAs can set up the BET immediately when the L2 handoff is
   initiated, start tunneling MN-bound data when the link to the MN goes
   down, and the nFA can use the link-up trigger to start delivering
   packets.  In the absence of optimal L2 trigger information, the HRply
   can act as the trigger to start tunneling MN-bound data, but in this
   case, the period of packet delivery disruption to the MN could still
   be present and additional measures may be required to provide
   uninterrupted service.  Particular implementation and deployment
   scenarios could require techniques to smooth the handoff by providing
   a means to convey packets arriving during the L2 handoff.  The exact
   techniques are outside the scope of this document.

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

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

            Figure 7 - Two-Party Source Trigger Handoff Timing

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

            Figure 8 - Two-Party Target Trigger Handoff Timing

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

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

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

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

4.2.  Three-Party Handoff

   Three-party handoff is applicable when an MN, which has already
   established an aFA and is receiving tunneled packets through its
   current FA, moves to a new FA without performing a Mobile IPv4
   Registration.

   The need for the three-party handoff function depends on the wireless
   system in which POST-REGISTRATION is being implemented.  For radio L2
   protocols in which it is possible for the MN to move so rapidly from
   one FA to another such that a probability exists that the Mobile IPv4
   Registration with nFA will not complete before the MN moves on, HTT
   (Handoff to Third) SHOULD be implemented.  Certain wireless systems
   and implementations do not allow such fast movement between FAs and
   may force the Mobile IPv4 Registration to occur soon after L2
   handoff, in which case three-party handoff is not applicable.  If
   this three-party handoff feature is not implemented, the FA SHOULD

Top      Up      ToC       Page 29 
   send an Agent Advertisement to the MN after L2 handoff has completed
   (L2-LU at nFA) and/or the MN SHOULD solicit an Agent Advertisement
   after L2 handoff (L2-LU at MN).

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

                       Figure 9 - Three-Party Handoff

   The L3 handoff can be deferred either because of a decision by the
   MN/FA (i.e., MN does not send Agent Solicitations and FA does not
   send Agent Advertisements), or it may result from rapid movement
   between oFA and nFA that does not allow enough time for the
   registration to complete.  This scenario is shown in Figure 9.  In
   this case, oFA must inform nFA (i.e., the third FA) to contact aFA
   about moving the radio end of the tunnel.  This is performed with the
   HTT message.  The general idea behind the three-party handoff
   procedure is that the oFA supplies nFA with the same information it
   would have obtained via an L2-TT if handoff had occurred from aFA to
   nFA; then, the nFA performs an HRqst(t)/HRply(t) sequence with aFA in
   order to move the BET to nFA.  When the L2 handoff is complete, oFA
   sends an HRqst(r) to aFA to terminate the previous BET.

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

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

Top      Up      ToC       Page 30 
         a) The L2 trigger is a source trigger (L2-ST) at oFA.  The
            trigger contains the MN's L2 address and an identifier for
            the nFA (the IPv4 address itself or an L2 address that can
            be mapped to the IPv4 address of the nFA).

         b) The L2 trigger is a target trigger (L2-TT) at nFA.  The
            trigger contains the MN's L2 address and an identifier for
            the oFA (the IPv4 address itself or an L2 address that can
            be resolved to the IPv4 address of the oFA).

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

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

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

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

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

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

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

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

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

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

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

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

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

            Figure 10 - Three-Party Source Trigger Handoff Timing

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

            Figure 11 - Three-Party Target Trigger Handoff Timing

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

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

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

   In addition, aFA MAY continue tunneling to oFA if 1) is selected,
   until the HRqst(r) is received.  In this case, the result may be
   duplicated packets at the MN because the MN will receive packets
   through oFA on the old L2 until it disconnects (L2-LD).  If 2) is
   selected, the additional latency will add to the MN's L3 service
   disruption period.  Of course, aFA can choose to place the BET
   sometime between 1) and 2) if reliable bounds are available on the
   duration of time between L2-ST/L2-TT and the MN's disconnection (L2-
   LD).  The exact selection of when to establish the BET is likely to

Top      Up      ToC       Page 34 
   be influenced by network engineering and implementation
   considerations, including whether a handoff smoothing solution is
   used, and is beyond the scope of this specification.

4.3.  Renewal or Termination of Tunneling Service

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

   Figure 12 illustrates the message exchange that occurs between the FA
   needing to terminate or extend the tunnel (designated FA(1) in the
   figure) and the other FA (designated FA(2) in the figure).  The
   HRqst(r)/HRply(r) is indicated by setting the R bit in the
   HRqst/HRply messages.  If the HRqst(r) is renewing a BET, then it
   contains a non-zero lifetime; otherwise, if the lifetime is set to
   zero, it indicates tunnel termination.  The aFA has complete control
   over whether a tunnel is extended or terminated, and it MAY reply to
   a request for extension with a shorter lifetime than was requested.

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

                Figure 12 - BET Renewal or Termination

4.4.  When Will the MN Perform a Mobile IPv4 Registration?

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

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

Top      Up      ToC       Page 35 
      2) The MN itself decides to perform a Mobile IPv4 Registration and
         initiates it by sending an Agent Solicitation as in [1].

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

   Some detailed scenarios relating to case 2) will be described
   hereafter.  According to [1], when using an FA care-of address, the
   MN MAY use the FA as its default router.  Otherwise, it MUST choose
   its default router from those advertised in the ICMP Router
   Advertisement portion of the Agent Advertisement.  Here we assume
   that the FA router is also the MN's default router.  In POST-
   REGISTRATION, when a tunnel is established between oFA and nFA and
   the MN has moved to nFA, the oFA MUST NOT send Agent Advertisements
   to the MN.  In this case, it is possible that the MN will not receive
   Agent Advertisements for extended periods of time.  According to [8],
   hosts will remove default router entries if the lifetime of the
   Router Advertisement expires and no further advertisements are
   received.  Note that the ICMP Router Advertisement lifetime is not
   related to the Registration Lifetime in the Mobility Agent
   Advertisement extension [1].  To avoid this disruption, the MN MUST
   solicit the default router (i.e., FA) before the lifetime of its
   active default router entry runs out, or alternatively, the FA MUST
   advertise as soon as the MN-nFA link is up (L2-LU).  This effectively
   means that the MN will at most be able to defer Mobile IPv4
   Registration for as long as the remaining lifetime of the active
   default router, as configured in the ICMP Router Advertisements.  The
   MN MUST perform a Mobile IPv4 Registration [1] when it receives an
   Agent Advertisement following a POST-REGISTRATION handoff.

Top      Up      ToC       Page 36 
4.5.  Handoff Request (HRqst) Message Format

   This is a new Mobile IPv4 message carried on UDP (destination port
   434) [1].  The UDP header is followed by the fields below.

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

      Type              16 (Handoff Request)

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

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

      R                 Set if the request is an HRqst(r) (i.e., a
                        request to renew the tunnel, H and N bits must
                        be unset).

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

      G                 The FA issuing the HRqst will use Generic
                        Routing Encapsulation (GRE) [4] as defined in
                        [1,5] for the tunnel.  Extensions of HRqst
                        containing GRE type and key Fields are outside
                        the scope of this document.

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

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

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

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

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

      Identification    As defined in [1].

      Extensions        The message MUST include an LLA (see Section 9)
                        containing the MN's L2 address and an L2 address
                        that can be mapped to an IPv4 address for the
                        FA.  This message MUST contain the FA-FA
                        Authentication Extension [11] that is used to
                        secure the HRqst message.

Top      Up      ToC       Page 38 
4.6.  Handoff Reply (HRply) Message Format

   This is a new Mobile IPv4 message carried on UDP (destination port
   434) [1].  The UDP header is followed by the fields below.

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

      Type              17 (Handoff Reply)

      Code              A value indicating the result of the Handoff
                        Request.  Only two codes are currently
                        supported, 0, indicating success, and 1,
                        indicating that the handoff cannot be performed.
                        The remaining values are for future use.

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

Top      Up      ToC       Page 39 
                        require service.  A value of 0 on an HRply(r)
                        indicates that the tunnel lifetime will be
                        terminated.  A value of 0xffff indicates an
                        infinite lifetime.

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

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

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

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

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

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

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

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

      HA Addr           For HRply(t), the HA IPv4 address of the MN.

      Identification    As defined in [1].

      Extensions        This Message MUST contain the FA-FA
                        Authentication Extension [11] that is used to
                        secure the HRply message.

Top      Up      ToC       Page 40 
4.7.  Handoff to Third (HTT) Message Format

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

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

      Solicited IPv4 Address Option: containing aFA's Address

      LLA Option: containing the L2 address of the MN.

4.8.  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 IPv4-layer
   messages to be sent to or from an MN prior to the L2 handoff event.
   Therefore, it eliminates a possible source of handoff latency.  This
   may be required when the link layer imposes hard deadlines on the
   time at which a handoff must occur, such as when an MN is rapidly
   moving out of a radio coverage area.  Consequently, POST-REGISTRATION
   is primarily of interest in handoff between FAs that support the same
   radio access technology.  Handoff between heterogeneous radio
   technologies will, of necessity, require interaction between the MN
   and the network, and so is not a domain of applicability for POST-
   REGISTRATION.

   Because a POST-REGISTRATION handoff is triggered by an unspecified
   mechanism that informs the oFA or nFA that an L2 handoff is pending,
   the POST-REGISTRATION approach is only applicable to networks where
   such a mechanism is available.  For example, an L2 may provide
   indications of radio signal quality that cause the oFA or nFA to send
   the POST-REGISTRATION handoff messages.  Any such indications must
   also provide each FA involved in the handoff with the identity of the
   other, so that messages can be sent to the right place.  This may
   involve mapping L2 information onto FA IPv4 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

Top      Up      ToC       Page 41 
   messaging, any L2 handoff indications must also be securely
   authenticated so that traffic to the old point of attachment is not
   improperly halted.

   POST-REGISTRATION handoff is appropriate in the following cases:

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

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

      - Access point choice by the MN is not a concern or the 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.  If PRE-REGISTRATION does not complete prior to the
   expiration of a timer on the nFA, the POST-REGISTRATION mechanism is
   used to create the tunnel between oFA and nFA.  This protects the MN
   from delays caused by errors such as loss of the Mobile IPv4
   Registration Reply message involved in PRE-REGISTRATION for the
   mobile-initiated and network-initiated source-triggered cases.  It
   also protects the MN from delays caused by errors or the loss of any
   of the Mobile IPv4 messages involved in PRE-REGISTRATION for the
   network-initiated target-triggered case.

   When the nFA receives a target trigger, it will follow the PRE-
   REGISTRATION procedure.  When the combined method is used, the nFA
   MUST also start a timer when it receives a target trigger.  The timer
   should be set to a small value (default for target trigger case: 1
   second).

   According to PRE-REGISTRATION, the nFA will receive the Registration
   Request from the MN.  When the combined method is used, this
   Registration Request sent by the MN MUST contain the IPv4 address of
   the oFA in an FA IPv4 address LLA extension (see Section 9.7).  This
   same Registration Request message will contain multiple LLA
   extensions, since it will also contain the MN's layer 2 address in an
   LLA extension as described for PRE-REGISTRATION (see Sections 3.7 and
   9).  When the nFA has not started the handoff procedure using a
   target trigger (i.e., mobile-initiated or network-initiated target-
   triggered cases), the nFA MUST start a timer as soon as it receives
   the low-latency Registration Request from the MN.  This timer should
   be set to a small value (default: 1 second).

Top      Up      ToC       Page 42 
   In all cases, the timer MUST be reset when the Registration Reply
   message is received by nFA.  If the timer expires before the
   Registration Reply is received, the nFA MUST initiate the POST-
   REGISTRATION procedure.  The nFA utilizes the oFA IPv4 address
   (previously received in the extension to the Registration Request
   message) as the destination of the POST-REGISTRATION HRqst message to
   create the tunnel between nFA and oFA.  The nFA MAY tear down this
   tunnel when it receives and forwards a successful Registration Reply
   for that MN.

6.  Layer 2 and Layer 3 Handoff Timing Considerations

   In the optimal cases considered in the PRE-REGISTRATION and POST-
   REGISTRATION handoffs, it was assumed that a timely L2 trigger would
   be received in such a way that packets could be delivered to the MN
   via its nFA immediately upon connection.  In this way, the MN does
   not suffer disruption due to the L3 handoff.  However, such precise
   timing of the L2 trigger and handoff mechanism with respect to the
   actual L2 handoff event will not be possible in all wireless systems
   and may depend on particular implementation techniques.  Therefore,
   some uncertainty may exist at L3 as to exactly when the L2 connection
   between the MN and the nFA becomes fully established and can be used
   for L3 traffic.  It is possible that in certain implementations
   traffic will be re-routed too early or too late with respect to the
   moment when the connection between the MN and the nFA becomes fully
   established.  The techniques that may solve this problem and allow
   the MN to receive traffic independently of the timing of the L2
   handoff event include buffering and simultaneous bindings (i.e.,
   bicasting: setting the S bit [1] in Registration Requests).  However,
   these are optional and are not mandated.

7.  Reverse Tunneling Support

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

Top      Up      ToC       Page 43 
8.  Handoff Signaling Failure Recovery

   In general and to a greater extent in wireless networks, packets
   carrying handoff signaling may be dropped or lost due to errors on
   the link.  In this section, we consider mechanisms for recovery from
   handoff signaling failures.

8.1.  PRE-REGISTRATION Signaling Failure Recovery

   Failure of PRE-REGISTRATION signaling breaks down into three cases:

      1) Loss of messages PrRtSol and PrRtAdv on the air link.

      2) Loss of the solicitation by an FA to obtain another neighboring
         FA's Advertisement or loss of the neighboring FA's
         advertisement.

      3) Failure of the standard Mobile IPv4 Registration.

   Of these, case 3) is handled by standard Mobile IPv4 mechanisms
   described in [1].  Case 2) is expected to be a rare event because
   spontaneous packet drop rates on the fixed network are caused by
   congestion or router failure.  Since bit error rates on wireless
   links are higher than on fixed links, case 1) is more likely to
   occur.  In the following subsections, cases 1) and 2) are considered.

8.1.1.  Failure of PrRtSol and PrRtAdv

   PRE-REGISTRATION handoff can fail in network-initiated handoff when
   the PrRtAdv sent by oFA in response to the source trigger (L2-ST) or
   the advertisement sent by nFA in response to the target trigger (L2-
   TT) fails to reach the MN.  PRE-REGISTRATION handoff can also fail in
   mobile-initiated handoff when either the PrRtSol sent from the MN or
   return PrRtAdv sent from the oFA is dropped.  To reduce the
   probability that PrRtAdv and PrRtSol are lost, the MN and FA MAY
   transmit multiple copies of these messages.  Should these messages
   fail anyway, in both cases the MN connects to the nFA without having
   received any prior signaling.  In this case, the MN solicits an FA
   Advertisement when it connects to nFA at L2 (L2-LU), as described in
   Section 3.6, and performs a standard Mobile IPv4 Registration with
   the nFA as specified in [1].

Top      Up      ToC       Page 44 
8.1.2.  Failure of Inter-FA Solicitation and Advertisement

   The solicitation from an FA to another neighboring FA may fail or the
   corresponding advertisement from the neighboring FA may be lost.  To
   reduce the probability that these messages are lost, the FAs MAY
   transmit multiple copies of these messages.  If a failure occurs
   anyway, the FA soliciting the Agent Advertisement is unable to send a
   PrRtAdv in response to a source trigger or to a mobile-initiated
   PrRtSol.  In these cases, when the MN does not receive a notification
   or confirmation of a PRE-REGISTRATION handoff, the MN MUST perform a
   standard Mobile IPv4 Registration as soon as it connects to the nFA
   (L2-LU) as described in Section 8.1.1.

8.2.  POST-REGISTRATION Signaling Failure Recovery

   Failure occurs in POST-REGISTRATION when either the HRqst or HRply
   message is dropped.  The effects of the failure and the recovery
   procedure depend on which message is dropped, and whether the handoff
   is source or target triggered.  Since all of the POST-REGISTRATION
   signaling is going over the fixed network, it can be expected that
   spontaneous dropping of packets in the absence of congestion and
   router failure should be a relatively rare event.  Nevertheless,
   failure recovery mechanisms SHOULD be implemented.

8.2.1.  HRqst Message Dropped

   If the HRqst message is dropped, the effect is the same for both
   source- and target-triggered handoffs.  In either case, the FA to
   which the HRqst was destined will never respond with an HRply
   message.  If the handoff is source triggered, then the nFA never
   learns of the handoff, and the oFA never receives confirmation.  If
   the handoff is target-triggered, then the oFA never learns of the
   handoff, and the nFA never receives confirmation.

   The recovery procedure in this case is as follows: the oFA MUST NOT
   construct a forward tunnel when the MN moves off-link (L2-LD) if the
   handoff is source-triggered, and the nFA MUST NOT construct a reverse
   tunnel if the handoff is target triggered.  If the nFA was not
   informed of the handoff by an HRqst message (corresponding to failure
   of source-triggered handoff) or if the handoff was not confirmed by
   an HRply message (corresponding to failure of target-triggered
   handoff), the nFA MUST unicast an Agent Advertisement to the MN as
   soon as its L2 connection is established (L2-LU at nFA).

Top      Up      ToC       Page 45 
8.2.2.  HRply Message Dropped

   If the HRply message is dropped, the FA sending the HRply will assume
   that the handoff has been confirmed, but the FA that is expecting to
   receive the HRply does not receive confirmation.  In this case, the
   failure recovery procedure is different for source-triggered and
   target-triggered handoffs.

   In a target-triggered handoff, the oFA assumes that the handoff is
   confirmed because it has sent the HRply, but the nFA has not received
   it so it does not have confirmation.  The oFA starts tunneling
   packets to the nFA when the MN moves from its link (L2-LD).  The nFA
   MUST send an FA Advertisement to the MN as soon as its L2 link is up
   (L2-LU at nFA) and MAY drop the tunneled packets.  The nFA SHOULD
   send an ICMP Destination Unreachable [9] message to the oFA.  When
   the oFA receives this message, it will terminate the tunnel and stop
   forwarding packets.  If reverse tunneling was requested, the nFA MUST
   NOT reverse tunnel because it has not received handoff confirmation.

   In source-triggered handoff, the nFA assumes that the handoff is
   confirmed because it has sent the HRply, but the oFA has not received
   it so it does not have confirmation.  Without failure recovery, the
   MN could move to the nFA without the oFA being able to start the
   forward tunnel for the MN's packets, and the MN would not be able to
   initiate a Mobile IPv4 Registration because it does not know that the
   handoff has failed.  In this situation, the oFA MUST send out an
   HRqst message to the nFA with lifetime zero as soon as the MN leaves
   its link (L2-LD).  The oFA SHOULD continue to retransmit the HRqst
   message, with exponential backoff for CONFIG-HFAIL seconds or until
   it receives an HRply acknowledging the request to cancel the tunnel.
   The default value for CONFIG-HFAIL is 10 seconds.  When the nFA
   receives the HRqst, it MUST immediately send an Agent Advertisement
   to the MN, as is the case whenever a tunnel is canceled.  In
   addition, the oFA MUST also drop any packets received through the
   reverse tunnel from the nFA.  The oFA SHOULD NOT send the ICMP
   Destination Unreachable message to the nFA because the nFA has been
   informed by the HRqst message to cancel the tunnel.  However, if the
   nFA receives an ICMP Destination Unreachable message for the tunnel
   prior to receiving the HRqst canceling the tunnel, it MUST send an FA
   Advertisement to the MN and cancel the tunnel.


Next RFC Part