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

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

               Mobile IP Working Group                          Karim El Malki (Editor)
               INTERNET-DRAFT                                            Pat R. Calhoun
               Expires: Dec 2003                                             Tom Hiller
                                                                            James Kempf
                                                                        Peter J. McCann
                                                                             Ajoy Singh
                                                                         Hesham Soliman
                                                                    Sebastian Thalanany
               
               
               
                                                                              June 2003
               
               
                                    Low Latency Handoffs in Mobile IPv4
                            <draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt>
               
               
               Status of this memo
               
                  This document is an Internet-Draft and is in full conformance with
                  all provisions of Section 10 of RFC 2026.
               
                  Internet-Drafts are working documents of the Internet Engineering
                  Task Force (IETF), its areas, and its working groups. Note that other
                  groups may also distribute working documents as Internet-Drafts.
               
                  Internet-Drafts are draft documents valid for a maximum of six months
                  and may be updated, replaced, or obsoleted by other documents at any
                  time. It is inappropriate to use Internet-Drafts as reference
                  material or cite them other than as "work in progress".
               
                  The list of current Internet-Drafts can be accessed at
                  http://www.ietf.org/ietf/lid-abstracts.txt
               
                  The list of Internet-Draft Shadow Directories can be accessed at
                  http://www.ietf.org/shadow.html
               
                  This document is a product of the Mobile IP WG.
               
               
               Abstract
               
                  Mobile IPv4 describes how a Mobile Node can perform IP-layer handoffs
                  between subnets served by different Foreign Agents. In certain cases,
                  the latency involved in these handoffs can be above the threshold
                  required for the support of delay-sensitive or real-time services.
                  The aim of this document is to present two methods to achieve low-
                  latency Mobile IP handoffs. In addition, a combination of these two
                  methods is described. The described techniques allow greater support
               
               
               
               El Malki (Editor) et. al.                                       [Page 1]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  for real-time services on a Mobile IPv4 network by minimising the
                  period of time when a Mobile Node is unable to send or receive IP
                  packets due to the delay in the Mobile IP Registration process.
               
               
               
               TABLE OF CONTENTS
               
                  1. Introduction....................................................3
                     1.1. Terminology................................................3
                     1.2. The Techniques.............................................5
                     1.3. L2 triggers................................................7
                     1.4. Requirements language......................................9
                  2. Requirements....................................................9
                  3. The PRE-REGISTRATION Handoff Method.............................9
                     3.1. Operation..................................................9
                     3.2. Network-Initiated Handoff.................................12
                     3.3. Mobile-Initiated Handoff..................................14
                     3.4. Obtaining and Proxying nFA Advertisements.................15
                        3.4.1. Inter-FA Solicitation................................15
                        3.4.2. Tunneled nFA Advertisements..........................16
                     3.5. Caching Router Advertisements.............................16
                     3.6. Movement Detection and MN Considerations..................17
                     3.7. L2 Address Considerations.................................18
                     3.8. Applicability of PRE-REGISTRATION Handoff.................19
                  4. The POST-REGISTRATION Handoff Method...........................20
                     4.1. Two Party Handoff.........................................20
                     4.2. Three Party Handoff.......................................25
                     4.3. Renewal or Termination of Tunneling Service...............29
                     4.4. When will the MN perform a Mobile IP Registration?........30
                     4.5. Handoff Request (HRqst) Message format....................31
                     4.6. Handoff Reply (HRply) Message.............................33
                     4.7. Handoff To Third (HTT) Message............................35
                     4.8. Applicability of POST-REGISTRATION Handoff Method.........35
                  5. Combined Handoff Method........................................36
                  6. Layer 2 and Layer 3 Handoff timing Considerations..............37
                  7. Reverse Tunneling Support......................................37
                  8. Handoff Signaling Failure Recovery.............................37
                     8.1. PRE-REGISTRATION Signaling Failure Recovery...............37
                        8.1.1. Failure of ProxyRtSol and ProxyRtAdv.................38
                        8.1.2. Failure of Inter-FA solicitation and advertisement...38
                     8.2. POST-REGISTRATION Signaling Failure Recovery..............38
                        8.2.1. HRqst Message Dropped................................39
                        8.2.2. HRply Message Dropped................................39
                  9. Generalized Link Layer Address Extension.......................40
                     9.1.  3GPP2 IMSI Link Layer Address and Connection ID Ext......41
                     9.2.  3GPP IMSI Link Layer Address Extension...................41
                     9.3.  Ethernet Link Layer Address Extension....................42
                     9.4.  IEEE 64-Bit Global Identifier (EUI-64) Address Ext.......43
                     9.5.  Solicited IP Address Extension...........................43
                     9.6.  Access Point Identifier Extension........................44
               
               
               
               El Malki (Editor) et. al.                                       [Page 2]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  10. IANA Considerations............................................44
                  11. Security Considerations........................................45
                  12. Acknowledgements...............................................46
                  13. Normative References...........................................46
                  14. Informative References.........................................47
                  15. AuthorsÆ Addresses.............................................47
                  16. Full Copyright Statement.......................................49
                  Appendix A - Gateway Foreign Agents................................50
                  Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs......51
               
               
               1. Introduction
               
                  Mobile IPv4 [1] describes how a Mobile Node (MN) can perform IP-layer
                  handoff between subnets served by different Foreign Agents (FAs). In
                  certain cases, the latency involved in handoff can be above the
                  threshold required for the support of delay-sensitive or real-time
                  services. The aim of this document is to present two methods to
                  achieve low-latency Mobile IP handoff during movement between FAs.
                  The presented techniques allow greater support for real-time services
                  on a Mobile IPv4 network by minimising the period of time when a MN
                  is unable to send or receive IP packets due to the delay in the
                  Mobile IP Registration process.
               
                  In the rest of this section, terminology used throughout the document
                  is presented, the handoff techniques are briefly described, and the
                  use of link layer information is outlined. In Section 2, a brief
                  description of requirements is presented. Section 3 describes the
                  details of the PRE-REGISTRATION handoff technique, while Section 4
                  describes the details of the POST-REGISTRATION handoff technique. In
                  Section 5, a combined method using the two handoff techniques
                  together is presented. Section 6 discusses Layer 2 and Layer 3
                  handoff timing considerations. Section 7 discusses reverse tunneling
                  support, Section 8 describes mechanisms to recover from message
                  failures while Section 9 describes protocol extensions required by
                  the handoff techniques. Sections 10 and 11 discuss IANA and security
                  considerations. Finally the two appendices discuss additional
                  material related to the handoff techniques. Appendix A gives a short
                  introduction to Regional Registrations [11] which can be used
                  together with low latency handoffs. Appendix B discusses low latency
                  handoff when a MN has multiple wireless L2 interfaces, in which case
                  the techniques in this document may not be necessary.
               
               
               1.1. Terminology
               
                  This section presents a few terms used throughout the document.
               
                     oFA - old Foreign Agent, the FA involved in handling a MN's
                        care of address prior to an L3 handoff.
               
               
               
               
               El Malki (Editor) et. al.                                       [Page 3]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                     nFA - new Foreign Agent, the FA anticipated to be handling a
                        MN's care of address after completion of an L3 handoff.
               
                     aFA - anchor Foreign Agent, the FA that is currently handling
                        the network end of the BET in POST-REGISTRATION.
               
                     L2 handoff - Movement of a MN's point of Layer 2 (L2)
                        connection from one wireless access point to another.
               
                     L3 handoff - Movement of a MN between FAs which involves
                        changing the care-of address (CoA) 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 a 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.
               
                     seamless handoff - L3 handoff that is both low latency and low
                        loss.
               
                     bi-directional edge tunnel (BET) -  A bidirectional tunnel
                        established between two FAs for purposes of temporarily
                        routing a MN's traffic to/from it on a new subnet without
                        requiring the MN to change CoA.
               
               
               
               
               
               El Malki (Editor) et. al.                                       [Page 4]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                     ping-ponging - Rapid back and forth movement between two
                        wireless access points often due to failure of L2 handoff.
                        Ping-ponging can occur if radio conditions for both the old
                        and new access points are about equivalent and less than
                        optimal for establishing a good, low-error L2 connection.
               
                     network-initiated handoff - L3 handoff in which oFA or nFA
                        initiates the handoff.
               
                     mobile-initiated handoff - L3 handoff in which the MN initiates
                        the handoff.
               
                     IP address identifier - An IP address of a MN or FA, or an L2
                        identifier that allows an FA to deduce the IP address of a
                        MN or FA. If the IP address identifier is an L2 identifier,
                        it may be specific to the L2 technology.
               
               
               1.2. The Techniques
               
                  Mobile IP was originally designed without any assumptions about the
                  underlying link layers over which it would operate so that it could
                  have the widest possible applicability.  This approach has the
                  advantage of facilitating a clean separation between L2 and L3 of the
                  protocol stack, but it has negative consequences for handoff latency.
                  The strict separation between L2 and L3 results in the following
                  built-in sources of delay:
               
                    - The MN may only communicate with a directly connected FA.  This
                      implies that a MN may only begin the registration process after
                      an L2 handoff to nFA (new FA) has completed.
               
                    - The registration process takes some non-zero time to complete as
                      the Registration Requests propagate through the network.  During
                      this period of time the MN is not able to send or receive
                      IP packets.
               
                  This document presents techniques for reducing these built-in delay
                  components of Mobile IP.  The techniques can be divided into two
                  general categories, depending on which of the above problems they
                  are attempting to address:
               
                    - Allow the MN to communicate with the nFA while still connected
                      to the oFA.
               
                    - Provide for data delivery to the MN at the nFA even before the
                      formal registration process has completed.
               
                  The first category of techniques allows the MN to "pre-build" its
                  registration state on the nFA prior to an underlying L2 handoff.
                  The second category of techniques allow for service to continue
               
               
               
               El Malki (Editor) et. al.                                       [Page 5]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  uninterrupted while the handoff is being processed by the network.
               
                  Three methods are presented in this draft to achieve low-latency L3
                  handoff, one for each category described above and one as a
                  combination of the two:
               
                  - PRE-REGISTRATION handoff method,
               
                  - POST-REGISTRATION handoff method,
               
                  - combined handoff method.
               
                  The PRE-REGISTRATION handoff method allows the MN to be involved in
                  an anticipated IP-layer handoff. The MN is assisted by the network in
                  performing an L3 handoff before it completes the L2 handoff. The L3
                  handoff can be either network-initiated or mobile-initated.
                  Accordingly, L2 triggers are used both in the MN and in the FA to
                  trigger particular L3 handoff events. The PRE-REGISTRATION method
                  coupled to L2 mobility helps to achieve seamless handoffs between
                  FAs. The basic Mobile IPv4 concept involving advertisement followed
                  by registration is supported and the PRE-REGISTRATION handoff method
                  relies on Mobile IP security. No new messages are proposed, except
                  for an extension to the Agent Solicitation message in the mobile-
                  initiated case.
               
                  The POST-REGISTRATION handoff method proposes extensions to the
                  Mobile IP protocol to allow the oFA (old FA) and nFA (new FA) to
                  utilize L2 triggers to set up a bi-directional tunnel between oFA and
                  nFA that allows the MN to continue using its oFA while on nFA's
                  subnet. This enables a rapid establishment of service at the new
                  point of attachment which minimizes the impact on real-time
                  applications. The MN must eventually perform a formal Mobile IP
                  registration after L2 communication with the new FA is established,
                  but this can be delayed as required by the MN or FA. Until the MN
                  performs registration, the FAs will setup and move bidirectional
                  tunnels as required to give the MN continued connectivity.
               
                  The combined method involves running a PRE-REGISTRATION and a POST-
                  REGISTRATION handoff in parallel. If the PRE-REGISTRATION handoff can
                  be performed before the L2 handoff completes, the combined method
                  resolves to a PRE-REGISTRATION handoff. However, if the PRE-
                  REGISTRATION handoff does not complete within an access technology
                  dependent time period, the oFA starts forwarding traffic for the MN
                  to the nFA as specified in the POST-REGISTRATION handoff method. This
                  provides for a useful backup mechanism when completion of a PRE-
                  REGISTRATION handoff cannot always be guaranteed before the L2
                  handoff completion.
               
                  It should be noted that the methods described in this document may be
                  applied to MNs having a single interface (e.g. Wireless LAN
                  interface) or multiple interfaces (e.g. one WLAN and one cellular
               
               
               
               El Malki (Editor) et. al.                                       [Page 6]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  interface). However, the case of multiply-interfaced MNs needs
                  special consideration, since the handoff methods described in this
                  document may not be required in all cases (see Appendix B).
               
               
               1.3. L2 triggers
               
                  An L2 trigger is a signal of an L2 event. In this document, the L2
                  events relate to the L2 handoff process. One possible event is early
                  notice of an upcoming change in the L2 point of attachment of the
                  mobile node to the access network. Another possible event is the
                  completion of relocation of the mobile node's L2 point of attachment
                  to a new L2 access point. This information comes from L2
                  programmatically or is derived from L2 messages. Although the
                  protocols outlined in this document make use of specific L2
                  information, Mobile IP should be kept independent of any specific L2.
                  L2 triggers are an abstraction mechanism for a technology specific
                  trigger. Therefore, an L2 trigger that is made available to the
                  Mobile IPv4 stack is assumed to be generic and technology
                  independent. The precise format of these triggers is not covered in
                  this document, but the information required to be contained in the L2
                  triggers for low latency handoffs is specified.
               
                  In order to properly abstract from the L2, it is assumed that one of
                  the three entities - the MN, oFA, or nFA - is made aware of the need
                  for an L2 handoff, and that the nFA or MN can optionally also be made
                  aware that an L2 handoff has completed. A specific L2 will often
                  dictate when a trigger is received and which entity will receive it.
                  Certain L2s provide advance triggers on the network-side, while
                  others provide advance triggers on the MN. Also, the particular
                  timing of the trigger with respect to the actual L2 handoff may
                  differ from technology to technology.  For example, some wireless
                  links may provide such a trigger well in advance of the actual
                  handoff.  In contrast, other L2s may provide little or no information
                  in anticipation of the L2 handoff.
               
                  An L2 trigger may be categorized according to whether it is
                  received by the MN, oFA, or nFA.  Table 1 gives such a categorization
                  along with information expected to be contained in the trigger. The
                  methods presented in this document operate based on different types
                  of L2 triggers as shown in Table 1. Once the L2 trigger is received,
                  the handoff processes described hereafter are initiated. The three
                  triggers: L2-ST, L2-TT and L2-MT are independent of each other and
                  MUST NOT occur together since each will trigger a different type of
                  handoff behaviour.
               
               
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                       [Page 7]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  +-------------+----------------------+------------------------------+
                  | L2 trigger  |       Mobile         |               Source         |
                  |             |       Trigger        |               Trigger        |
                  |             |       (L2-MT)        |               (L2-ST)        |
                  +-------------+----------------------+------------------------------+
                  | Recipient   | MN                   |                oFA           |
                  +-------------+----------------------+--------------+---------------+
                  | Method      | PRE                  | PRE          | POST          |
                  |             | mobile-              | network-     | source        |
                  |             | initiated            | initiated    | trigger       |
                  +-------------+----------------------+--------------+---------------+
                  | When?       | sufficiently before  | sufficiently | sufficiently  |
                  |             | the L2 handover      | before L2    | before L2     |
                  |             | so that MN can       | handover for | handover for  |
                  |             | solicit ProxyRtAdv   | FA to send   | oFA & nFA to  |
                  |             | from oFA.            | proxyRtAdv   | exchange      |
                  |             |                      | to MN.       | HRq/HRy.      |
                  +-------------+----------------------+--------------+---------------+
                  | Parameters  | nFA IP address       |  nFA IP address identifier   |
                  |             | identifier           |  MN IP address identifier    |
                  |             |                      |                              |
                  +-------------+----------------------+------------------------------+
               
               
                  +------------+------------------------+-------------+---------------+
                  | L2 trigger | Target                 | Link-Up     |  Link-Down    |
                  |            | Trigger                |             |               |
                  |            | (L2-TT)                |             |               |
                  |            |                        | (L2-LU)     |  (L2-LD)      |
                  |------------+------------------------+-------------+---------------+
                  | Recipient  | nFA                    |  MN or nFA  |     oFA       |
                  |------------+------------+-----------+-------------+---------------+
                  | Method     | PRE        |  POST     | PRE & POST  |    POST       |
                  |            | network    |  target   |             |               |
                  |            | initiated  |  trigger  |             |               |
                  |------------+------------------------+-------------+---------------+
                  | When?      |                        | when radio  |  when radio   |
                  |            |       same as          | link between|  link between |
                  |            |    source trigger      | MN & nFA  is|  MN and oFA   |
                  |            |                        | established |  is lost      |
                  |------------+------------------------+-------------+---------------+
                  | Parameters | oFA IP address id      | @MN: nFA IP | MN IP address |
                  |            | MN IP address id.      | or L2 addr. | identifier    |
                  |------------+------------------------+-------------+---------------+
               
                                         Table 1 - L2 Triggers
               
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                       [Page 8]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               1.4. Requirements language
               
                  In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
                  "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
                  described in [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 services,
               
                  - to have no dependence on a wireless L2 technology,
               
                  - to support inter- and intra-access technology handoffs,
               
                  - to limit wireless bandwidth usage.
               
               
               3. The PRE-REGISTRATION Handoff Method
               
                  The PRE-REGISTRATION handoff method is based on the original concept
                  of Mobile IP handoff as specified in [1], in which:
               
                  - an advertisement for an FA is received by an MN,
               
                  - the advertisement allows the MN to perform movement detection,
               
                  - the MN registers with the FA.
               
                  It reuses the basic messages specified in [1]. The PRE-REGISTRATION
                  method allows both the MN and FA to initiate handoff. In both cases,
                  abiding by the basic Mobile IP handoff concept allows the MN to
                  choose with which FA to register.  The PRE-REGISTRATION method can
                  make use of L2 triggers on either the FA or MN side, depending on
                  whether network-initiated or mobile-initiated handoff occurs. PRE-
                  REGISTRATION also supports both the normal Mobile IP model [1] in
                  which the MN is receiving packets from a Home Agent (HA) and the
                  Regional Registration model [11] in which the MN receives packets
                  from a Gateway Foreign Agent (GFA). It also supports movement where a
                  new AAA transaction must occur to authenticate the MN with the new
                  domain.
               
               
               3.1. Operation
               
                  The overall PRE-REGISTRATION Handoff mechanism is summarised in
                  Figure 1 below:
               
               
               
               
               El Malki (Editor) et. al.                                       [Page 9]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                                             +---------+
                                             | HA (GFA)|<---------+
                                             +---------+          | 4. (Reg)RegReq
                                                                  | 5. (Reg)RegReply
                                                                  v
                                    +-----+    1a. RtSol       +-----+
                                    |     | -----------------> | nFA |
                                    | oFA |    1b. RtAdv       |     |
                                    +-----+ <----------------- +-----+
                                     ^   |                      ^
                    (2a. ProxyRtSol) |   | 2b                  /
                                     |   | ProxyRtAdv         / 3. (Reg)RegReq
                                     |   |                   /
                                     |   v   ---------------
                                    +-----+ /
                                    | MN  |
                                    +-----+    - - - - - ->
                                                 Movement
               
                             Figure 1 - PRE-REGISTRATION Handoff Protocol
               
               
                  The following steps provide more detail on the protocol:
               
               
                       1. Messages 1a is a Router Solicitation (RtSol) from oFA to nFA.
                          Message 1b is a Router (Agent) Advertisement (RtAdv) from nFA
                          to oFA. These messages SHOULD occur in advance of the PRE-
                          REGISTRATION Handoff in order not to delay the handoff. For
                          this to occur, oFA SHOULD solicit and cache advertisements
                          from neighbouring nFAs, thus decoupling the timing of this
                          exchange from the rest of the PRE-REGISTRATION Handoff. When
                          the L3 handoff is initiated by a target L2 trigger at nFA
                          (L2-TT), message 1b equals message 2b and is sent unsolicited
                          directly to MN (tunneled by nFA to MN through oFA) instead of
                          being relayed by oFA.
               
               
                       2. Message 2a is a Proxy Router Solicitation (PrRtSol). It is
                          different from a normal Router Solicitation since it is
                          actually soliciting an advertisement from a router different
                          from the one receiving this message. The presence of message
                          2a indicates that the handoff is mobile-initiated and its
                          absence means that the handoff is network-initiated. In
                          mobile-initiated handoff, message 2a occurs if there is an L2
                          trigger in the MN to solicit for a Proxy Router Advertisement
                          (PrRtAdv). When message 2a is received by the oFA, the oFA
                          MUST return the Proxy Router Advertisement (Agent
                          Advertisement) in message 2b. In network-initiated handoff,
                          the L2 trigger occurs at oFA and oFA MUST relay the Agent
                          Advertisement in message 2b without the need for the MN to
               
               
               
               El Malki (Editor) et. al.                                      [Page 10]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                          solicit. Note that it is also possible for nFA to advertise
                          directly to the MN in the network-initiated target-trigger
                          case (section 3.2). In all cases message 2b is simply nFAÆs
                          agent advertisement.
               
               
                       3. The MN performs movement detection upon receipt of either a
                          solicited or unsolicited Agent Advertisement and, if
                          appropriate, it sends a Registration Request (RegReq) message
                          [1] in message 3 to nFA. When a local Gateway Foreign Agent
                          (GFA) is present this message MAY be a Regional Registration
                          Request (RegRegReq) [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 IP Registration
                          [1] or Regional Registration [11] initiated with message 3.
                          In the network-initiated target-triggered case, the
                          Registration Reply in message 5 SHOULD be sent by nFA to the
                          MN both through oFA and directly on-link. This is necessary
                          since the MN may have to detach from oFA, due to the wireless
                          L2 connection, before it received the Reply. Figures 2 and 3
                          illustrate this tunneling, though it is not shown in Figure
                          1. Tunneling can take place either at L3 or L2. In the
                          mobile-initiated and network-initiated source-triggered cases
                          the nFA will not have the oFA's address. Therefore the Reply
                          MUST be unicast by nFA to the MN on-link as soon as the MN
                          connects to nFA (L2-UP). The MNÆs L2 address is obtained
                          using the extensions in Section 9, as described in 3.7.
               
               
                       5. If the Registration is successful then packets for the MN are
                          now tunnelled from the HA (or GFA) to the nFA where the MN
                          has moved to.
               
               
                  PRE-REGISTRATION is not dependent on Regional Registration extensions
                  [11]. However if the HA is at a distance (in terms of delay) from the
                  nFA, the use of a local GFA reduces the time required for the handoff
                  procedure to complete.
               
                  The time at which the L2 trigger is received by the oFA or MN,
                  thereby triggering the PRE-REGISTRATION handoff, compared to the time
                  at which the actual L2 handoff occurs is important for the optimal
                  performance of the low latency handoff. That is, in the optimal case
                  the L2 trigger will be received, the four messaging steps of PRE-REG
                  described above will be completed (i.e. Registration Request
                  processed by HA or GFA) 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
               
               
               
               El Malki (Editor) et. al.                                      [Page 11]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  disruption due to the L3 handoff. This may require particular
                  implementation techniques and deployment, such as L2 techniques,
                  buffering and bicasting, but these are outside the scope of this
                  document. In addition further handoff smoothing considerations may be
                  required to prevent the loss of packets in-flight between HA (or GFA)
                  and oFA while the MN performs a PRE-REGISTRATION handoff. These are
                  also outside the scope of this document.
               
                  Figures 2, 3, and 4 contain message timing diagrams for both the
                  network-initiated and mobile-initiated PRE-REGISTRATION handoff
                  procedures.
               
               
               3.2. Network-Initiated Handoff
               
                  As described in Table 1, a PRE-REGISTRATION handoff can be initated
                  at oFA by a source trigger or at nFA by a target trigger. A source-
                  triggered network-initiated handoff occurs when an L2 trigger is
                  received at the oFA informing it of a certain MNÆs upcoming movement
                  from oFA to nFA. The L2 trigger contains information such as the MNÆs
                  IP address identifier (i.e. the IP address itself or an identifier
                  which can be resolved to the IP address) and the nFAÆs IP address
                  identifier. An identifier may be specific to the wireless technology
                  (e.g. Access Point ID). A target-triggered network-initiated handoff
                  occurs when an L2 trigger is received at the nFA informing it of a
                  certain MNÆs upcoming movement from oFA. This type of trigger is also
                  shown in Table 1. The L2 trigger contains information such as the
                  MNÆs IP address identifier and the oFAÆs IP address identifier.
               
                  In a source-triggered handoff, 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 sections 9.3 or 9.6. 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. 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 Solicitation. This
                  Advertisement is tunneled to oFA which functions as a normal router,
                  decapsulating the Advertisement and forwarding it to the MN. This
                  messages MUST be authenticated to prevent attacks (see section
                  3.4.2).
               
                  Figures 2 and 3 contain message timing diagrams describing the PRE-
                  REGISTRATION network-initiated handoff for source and target
                  triggers.
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 12]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  MN                    oFA                 nFA                 HA/GFA
                   |                     |<~~~~~~ L2-Source  |                    |
                   |                     |           Trigger |                    |
                   |<--------------------|                   |                    |
                   |  ProxyRtAdv         |                   |                    |
                   |                     |                   |                    |
                   |---------------------------------------->|                    |
                   |   RegReq or         |                   |                    |
                   |   RegRegReq         |                   |------------------->|
                   |  (routed via oFA)   |                   | RegReq or RegRegReq|
                   |                     |                   |                    |
                   |                     |                   |<-------------------|
                   |                     |                   |    (Reg)RegReply   |
                   |                     |                   |                    |
                   |<----------------------------------------|                    |
                   |                     | (Reg)RegReply     |                    |
                   |                     | (sent to MN when it attaches to nFA)   |
               
               
                        Figure 2 - PRE-REGISTRATION Handoff Message Timing Diagram
                                    (Network-Initiated, Source Trigger)
               
               
                  MN                    oFA                 nFA                 HA/GFA
                   |                     | L2-Target~~~~~~~~>|                    |
                   |                     |    Trigger        |                    |
                   |                     |                   |                    |
                   |                     |...................|                    |
                   |<--------------------------------------- |                    |
                   |  (ProxyRtAdv)       |...................|                    |
                   |                     | Tunneled Agent    |                    |
                   |                     | Advertisement     |                    |
                   |                     |                   |                    |
                   |---------------------------------------->|                    |
                   |   RegReq. or        |                   |                    |
                   |   RegRegReq         |                   |------------------->|
                   |  (routed via oFA)   |                   | RegReq or RegRegReq|
                   |                     |                   |                    |
                   |                     |                   |<-------------------|
                   |                     |                   |   (Reg)RegReply    |
                   |                     |                   |                    |
                   |<----------------------------------------|                    |
                   |                     | (Reg)RegReply     |                    |
                   |                     | (sent to MN when it attaches to nFA)   |
               
                        Figure 3 - PRE-REGISTRATION Handoff Message Timing Diagram
                                    (Network-Initiated, Target Trigger)
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 13]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               3.3. Mobile-Initiated Handoff
               
                  As shown in Table 1, a mobile-initiated handoff occurs when an L2
                  trigger is received at the MN informing that it will shortly move to
                  nFA. The L2 trigger contains information such as the nFAÆs IP address
                  identifier (i.e. nFAÆs IP address or an identifier which can be
                  resolved to the nFAÆs IP address). The message timing diagram is
                  shown in Figure 4.
               
               
                     MN                    oFA                 nFA               HA/GFA
                      |<~~~~~ L2-Trigger    |                   |                    |
                      |                     |                   |                    |
                      |-------------------->|                   |                    |
                      |   ProxyRtSol        |                   |                    |
                      |                     |                   |                    |
                      |<--------------------|                   |                    |
                      |   ProxyRtAdv        |                   |                    |
                      |                     |                   |                    |
                      |---------------------------------------->|                    |
                      |   RegReq or         |                   |                    |
                      |   RegRegReq         |                   |------------------->|
                      |  (routed via oFA)   |                   | RegReq or RegRegReq|
                      |                     |                   |                    |
                      |                     |                   |<-------------------|
                      |                     |                   |    (Reg)RegReply   |
                      |<----------------------------------------|                    |
                      |                     | (Reg)RegReply     |                    |
                      |                     | (sent to MN when it attaches to nFA)   |
               
                        Figure 4 - PRE-REGISTRATION Handoff Message Timing Diagram
                                            (Mobile-Initiated)
               
               
                  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 IP address identifier because the MN is
                  soliciting another specific FAÆs advertisement from the oFA. This
                  specific FA will be the MN's nFA. The IP address identifier contains
                  the IP address of the nFA or an identifier that can be used by the
                  oFA to resolve to nFA's IP address. If the identifier is not an IP
                  address, it MAY be specific to the underlying wireless technology,
                  for example, an Access Point or Base Station ID. The extension is a
                  subtype of the Generalised Link-Layer Address extension described in
                  Section 9. Two extension subtypes have been defined to contain the
                  nFAÆs IP address and an access point identifier. They are called the
                  Solicited Agent IP Address Extension and the Access Point Identifier
               
               
               
               El Malki (Editor) et. al.                                      [Page 14]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  Extension, and are described in Sections 9.5 and 9.6. These two
                  extensions SHOULD NOT be present in the same PrRtSol message.
               
                  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 9.2).
                  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 Fig.1). The
                  Registration MAY be transmitted more than once to reduce the
                  probability that it is lost due to errors on the wireless link.
               
                  A PRE-REGISTRATION handoff in this case requires the MN to receive an
                  agent advertisement from the nFA through the old wireless access
                  point. How to achieve this is discussed in the following subsections.
                  Messages exchanged between FAs MUST be authenticated to prevent
                  attacks. The minimal requirement is that all FAs involved in low
                  latency handoffs MUST support manual pre-configuration of security
                  associations with other neighbouring FAs, involving shared keys and
                  the default algorithms of [1].
               
               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 IP address of the nFA. The IP 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).
               
                  Once the oFA has access to the address of the nFA for a specific MN,
                  it MUST send a unicast agent solicitation to nFA. The nFA replies to
                  the oFA by unicasting an Agent Advertisement with appropriate
                  extensions. This method removes the TTL limitation of [1] for Mobile
                  IP messages (i.e. TTL=1 is not applicable here). The TTL limitation
                  cannot be applied since oFA and nFA may be more than one hop away and
                  since it is unnecessary for a secured unicast message. The ICMP
                  solicitations and advertisements MUST be authenticated. These
                  messages MUST be protected using ESP [10] to prevent attacks. An FA
               
               
               
               El Malki (Editor) et. al.                                      [Page 15]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  MUST NOT accept ICMP solicitations or advertisements from sources
                  which are not authenticated.
               
                  As a practical matter, oFA SHOULD pre-solicit and cache
                  advertisements from known neighboring FAs (see section 3.5), in order
                  to prevent having to perform the above 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
                  advertisments assumes that the nFA is aware of the IP address for oFA
                  and the MN. These IP addresses are obtained by means of the IP
                  address identifiers in an L2 trigger 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 packets from sources which
                  are not authenticated.
               
               
               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 Solicitation and Advertisement exchange
                  SHOULD be performed in advance of handoff. A process SHOULD be in
                  place at the oFA to solicit its neighbouring nFAs at a predefined
                  time interval (MIN_SOLICITATION_INTERVAL). This interval SHOULD NOT
                  be set too small to avoid unnecessary consumption of network
                  bandwidth and nFA processing resources. The minimum value of
                  MIN_SOLICITATION_INTERVAL is 1 sec. If the FA Challenge/Response
                  mechanism in [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
                  MIN_SOLICITATION_INTERVAL in oFA MUST be set to a value equal to (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
               
               
               
               El Malki (Editor) et. al.                                      [Page 16]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  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
                  neighbouring 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 neighbouring nFAs. The minimum requirement
                  for each FA is that it SHOULD allow manual configuration of a list of
                  nFA addresses which 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 it is outside the scope of this document.
               
               
               3.6. Movement Detection and MN Considerations
               
                  When the MN receives an Agent Advertisement with a Mobility Agent
                  extension, it performs actions according to the following movement
                  detection mechanism: the MN MUST be "Eager" to perform new bindings.
                  This means that the MN MUST perform Registrations with any new FA
                  from which it receives an advertisement (i.e. MN is Eager), as long
                  as there are no locally-defined policies in the MN that discourage
                  the use of the discovered FA. For example, the MN 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].
               
                  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 both the PRE-
                  REGISTRATION procedure has completed (Registration Reply is received)
                  as described in [1].
               
                  Overall the MN behaves as described in [1] with the following
                  additions: the specified movement detection mechanism mentioned above
                  the ability to use the L2-MT to initiate an agent solicitation with a
                  special extension (PrRtSol).
               
                  When moving from a PRE-REGISTRATION network to a normal Mobile IP [1]
                  network the MN will no longer receive PrRtAdv messages (agent
                  advertisements with the LLA extension). If the MN still receives L2-
                  MTs then it will attempt to send PrRtSol messages. The FA will either
                  ignore the solicitation or will reply with a normal agent
                  advertisement [1]. In the absence of a PrRtSol, when receiving a
                  normal agent advertisement the MN MUST resort to normal Mobile IP
                  behaviour [1]. If the MN does not receive a PrRtAdv in reply to its
                  PrRtSol, it SHOULD 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
               
               
               
               El Malki (Editor) et. al.                                      [Page 17]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  is not received within PRE_SOL_INTERVAL seconds after the last
                  PrRtSol attempt, the MN MUST resort to normal Mobile IP behaviour
                  [1]. The default values for PRE_SOL_ATTEMPTS is 2 and the default
                  value for PRE_SOL_INTERVAL is 1 second. It should be noted that the
                  performance of the movement detection mechanism mandated in PRE-
                  REGISTRATION MAY have sub-optimal behaviour on the other Mobile IP
                  [1] network. Instead when the MN moves from a normal Mobile IP [1]
                  network to a PRE-REGISTRATION network, the MN will start receiving
                  L2-MTs or PrRtAdv messages. When the MN receives L2-MTs or PrRtAdv
                  messages it MUST follow the PRE-REGISTRATION procedure. If there is
                  uncertainty as to which mode to choose (e.g. MN receives messages
                  from both PRE-REGISTRATION and normal FAs) the MN SHOULD choose PRE-
                  REGISTRATION.
               
               
               3.7. L2 Address Considerations
               
                  Some special considerations should be taken with respect to the
                  wireless system on which this handoff method is being implemented.
                  Consider an Ethernet-like system (e.g. IEEE 802.11) for example. In
                  PRE-REGISTRATION the MN is registering with an FA (nFA) that is not
                  its current first-hop router, therefore the L2 address of the
                  Ethernet frame containing the MN's Registration Request reaching the
                  nFA is not the MN's address. Therefore the FA MUST NOT use the
                  Ethernet address of the incoming Registration Request as the MNÆs L2
                  address as specified in [1]. This applies to the cases where the
                  wireless access points are bridges or routers and independently of
                  whether the FA is implemented in the wireless access points
                  themselves. In this case the MNÆs Registration Request (or Regional
                  Registration Request) MUST use an L2 address extension to the
                  Registration message when the MN is performing a registration. 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 Generalised Link Layer Extension (see
                  Section 9.3) with its Registration Request (or Regional Registration
                  Request) message. If this extension is present the FA MUST use the L2
                  address contained in the extension to communicate with the MN. For
                  the same reasons, the MN MUST NOT use the source L2 address of the
                  Agent Advertisement message (PrRtAdv) as its default routerÆs L2
                  address. Therefore the oFA/nFA MUST include a Generalised Link Layer
                  Extension (see Section 9.3) with its Agent Advertisement (PrRtAdv)
                  messages.
               
                  If a particular wireless L2 technology has defined a special L2
                  interface to the wireless network that allows the FA to resolve the
                  mapping between an MN's IP address and an L2 address without the need
                  to use the extension, the L2 address extension would not be needed.
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 18]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               3.8. Applicability of PRE-REGISTRATION Handoff
               
                  The PRE-REGISTRATON Handoff method is applicable to scenarios where a
                  period of service disruption due to layer 3 is not acceptable, for
                  example when performing real-time communications, and therefore where
                  an anticipation of the layer 3 handoff is required. Security for the
                  PRE-REGISTRATION handoff method is based on the same security model
                  as [1] including the use of AAA. A prerequisite for PRE-REGISTRATION
                  is that the FA or MN are able to obtain an L2 trigger informing them
                  of a pending L2 handoff procedure. The target of the L2 handoff is
                  another access point or radio network that is in the coverage area of
                  a new FA. The L2 trigger information may be in the form of IP address
                  identifiers which may need to be resolved to IP addresses using
                  methods that may be specific to the wireless network and are not
                  considered here. If, for example, the oFA or MN determines that the
                  IP address of the new FA is 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
                  cases:
               
                  - when the MN has locally defined policies that determine a
                     preference for one access over another, for example due to service
                     cost within the same or different technology, and therefore where
                     it is necessary to allow the MN to select the appropriate FA with
                     which to connect,
               
                  - when L3 cannot rely upon L2 security between the MN and the FA to
                     make modifications to IP routing and therefore authenticated
                     Mobile IP messages are required,
               
                  - when the trigger to initiate the handoff is received at the MN.
               
                  In the first case it is necessary to involve eventual local MN
                  policies in the movement detection procedure as described in 3.6.
               
               
               
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 19]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               4. The POST-REGISTRATION Handoff Method
               
                  The POST-REGISTRATION handoff method uses bi-directional 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.
               
                  Following a successful Mobile IP Registration between MN and oFA, the
                  oFA becomes the mobility anchor point for the MN, called the anchor
                  FA (aFA). When the MN moves from oFA to nFA, rather than performing
                  signaling over the wireless link to register with the nFA, the MN can
                  defer the L3 handoff and continue to use itÆs aFA (i.e. oFA in this
                  case). If the MN moves to a third FA before registering with the nFA,
                  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 IP
                  Registration.
               
                                           +------+
                                           |  CN  |
                                           +------+
                                              |
                                             ...
                                              |
                                           +------+   BET    +------+
                                           | aFA  |==========| nFA  |
                                           +------+          +------+
                                                                 | wireless link
                                                                 |
                                                 movement    +------+
                                                --------->   |  MN  |
                                                             +------+
               
                                     Figure 5 - POST-REGISTRATION Concept
               
                  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
                  neighbouring 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.
               
               
               4.1. Two Party Handoff
               
                  Two party handoff occurs when the MN moves from oFA, where the MN
                  performed a Mobile IP Registration, to nFA. In the normal case, this
                  movement would result in a new Mobile IP Registration at nFA. However
                  in POST-REGISTRATION, the MN and nFA MAY delay this but maintain
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 20]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  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. To identify the difference
                  between a source triggered HRqst/HRply message for tunnel creation, a
                  target triggered HRqst/HRply message for tunnel creation and
                  HRqst/HRply to extend or terminate a BET (or unidirectional tunnel),
                  the message will be identified respectively by (s), (t) and (r).
               
                    1) Either the oFA or nFA receives an L2 trigger informing it that a
                       certain MN is about to move from oFA to nFA. The two cases are:
               
                          a) The L2 trigger is a source trigger (L2-ST) at oFA. The
                             trigger contains the MN's L2 address and an IP identifier
                             (the IP address itself or an L2 address that can be
                             resolved to the IP address) for nFA.
               
                          b) The L2 trigger is a target trigger (L2-TT) at nFA. The
                             trigger contains the MN's L2 address and an IP identifier
                             for oFA.
               
                    2) The FA receiving the trigger sends a Handoff Request (HRqst) to
                       the other FA. There two cases:
               
                          a) If oFA is sending the HRqst, the H bit is set and the N
                             bit is unset, indicating it is an HRqst(s). The HRqst(s)
                             contains the lifetime of the tunnel the oFA is willing to
                             support, the home network IP address of the MN, the MN's
                             HA address and an LLA option with the MN's L2 address. If
                             the lifetime is zero and the T bit is not set, the oFA is
                             not willing to tunnel any packets for MN. A positive
                             lifetime and a set T bit indicate that the oFA is willing
                             to tunnel for the indicated time. Section 4.6 describes
               
               
               
               El Malki (Editor) et. al.                                      [Page 21]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                             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 it is an HRqst(t). If the T bit
                             is set, nFA has requested a reverse tunnel and the
                             HRqst(t) contains the lifetime of the tunnel the nFA is
                             requesting. The HRqst(t) also contains an LLA option with
                             the MN's L2 address. The MN's home network IP address and
                             HA address are not sent, unless they are discovered by
                             some means outside the scope of this document (for
                             example, as part of the L2-TT). Section 4.6 describes the
                             HRqst(t).
               
                    3) The FA receiving the HRqst sends a Handoff Reply (HRply) to the
                       other FA. There are two cases:
               
                          a) If oFA is sending the HRply, the N bit is set and the H
                             and R bits are unset, indicating that the reply is in
                             response to a HRqst(t), i.e. it is an HRply(t). If the T
                             bit is set, the HRply(t) contains the tunnel lifetime the
                             oFA is willing to provide, otherwise, the tunnel lifetime
                             is set to zero, indicating that the oFA is not willing to
                             provide tunnel service. 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 IP
                             address, the MN's HA address, and an LLA option containing
                             the MN's L2 address. Section 4.7 describes the HRply(t).
               
                          b) If nFA is sending the HRply, the H bit is set and the N
                             and R bits are unset, indicating the reply is in response
                             to a HRqst(s), i.e. it is an HRply(s). If the T bit is
                             set, the nFA indicates that it requests a reverse tunnel,
                             and the lifetime field is set with the requested tunnel
                             lifetime. The T Bit can be set in HRply only if the oFA
                             had set the T bit in the corresponding HRqst or if the nFA
                             requires to reverse tunnel incoming packets to oFA because
                             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.7 describes the
                             HRply(s).
               
                    4) The point during the L2 handoff in which the MN is no longer
                       connected on a certain link is signaled by an L2-LD trigger at
                       oFA and MN. Completion of L2 handoff is signaled by an L2-LU
                       trigger at nFA and MN. Each node handles the trigger in the
                       following way:
               
                          a) When the oFA receives the L2-LD trigger, it begins
                             forwarding MN-bound packets through the forward tunnel to
                             nFA.
               
               
               
               El Malki (Editor) et. al.                                      [Page 22]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                          b) When the nFA receives the L2-LU trigger, it begins
                             delivering packets tunneled from the oFA to the MN and
                             forwards any outbound packets from MN to the next hop
                             using normal routing mechanisms or through the reverse
                             tunnel to oFA or HA.
               
                          c) When the MN receives the L2-LU, it MAY intiate the Mobile
                             IP Registration process by soliciting an Agent
                             Advertisement as described in [1]. If the Registration is
                             successful the nFA takes over the role of anchor FA (aFA)
                             from the oFA. Alternatively the MN MAY defer the Mobile IP
                             Registration (see section 4.4).
               
                    5) The oFA becomes an aFA if the MN moves to a third FA before
                       having performed a Mobile IP Registration with nFA.
               
                    6) Should L2 handoff fail in Step 4 (due to L2 reasons) and a ping-
                       pong situation arise, the oFA may be able to determine this case
                       through the trigger mechanism (i.e. FA sees successive L2-ST/L2-
                       TT followed by L2-LD and then L2-LU). The FA which originated
                       the HRqst can in this case cancel the 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.6 describes the HRqst(r).
               
                  If in the HRqst/HRply the oFA has set the B bit and the nFA has not
                  requested a reverse tunnel by setting the T bit, the nFA SHOULD
                  tunnel outgoing packets from the MN to the HA because the MN has
                  requested this service from the oFA. The nFA SHOULD offer this
                  service only if either no security between the nFA and the MN's HA is
                  required, or there is an existing nFA-HA security association in
                  place.
               
                  The actual timing of BET 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 setup the BET immediately when the L2 handoff is
                  initiated, start tunneling MN-bound data when the link to the MN goes
                  down and the nFA can use the link up trigger to start delivering
                  packets. In the absence of optimal L2 trigger information, the HRply
                  can act as the trigger to start tunneling MN-bound data, but in this
                  case, the period of packet delivery disruption to the MN could still
                  be present and additional measures may be required to provide
                  uninterrupted service. Additonally, particular implementation and
                  deployment scenarios could require that techniques be employed to
               
               
               
               El Malki (Editor) et. al.                                      [Page 23]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  smooth handoff by providing a means to convey packets arriving during
                  the L2 handoff. The exact techniques involved in smoothing are
                  currently under discussion by the working group and are outside the
                  scope of this document.
               
                  Figures 7 and 8 show timing diagrams for source trigger (L2-ST) and
                  target trigger (L2-TT) two party handoff, respectively.
               
               
                                MN                    nFA                 oFA
                                 |                     |                   |
                                 |                     |     HRqst(s)      |<~~~ L2-ST
                                 |                     |<------------------|
                                 |                     |     HRply(s)      |
                                 |                     |------------------>|
                                 |                     |                   |
                                --------------------------------------------<~~~ L2-LD
                                                  L2 Handoff
                                --------------------------------------------<~~~ L2-LU
                                 |                     |                   |
                                 |<------------------->|                   |
                                 |    MN's traffic     |                   |
               
                              Figure 7 - Two Party Source Trigger Handoff Timing
               
               
               
                                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).
               
               
               
               El Malki (Editor) et. al.                                      [Page 24]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                    2) The MN completes the process by performing a Mobile IP
                       Registration with the current FA. This may be initiated by the
                       FA which sends an Agent Advertisement or by the MN which
                       solicits for an Agent Advertisement as in [1].
               
                    3) The MN moves to a third FA (see section 4.2)
               
               
               4.2. Three Party Handoff
               
                  Three party handoff is applicable when an MN that has already
                  established an aFA and is receiving tunneled packets through its
                  current FA moves to a new FA without performing a Mobile IP
                  Registration. The need for this function depends on the wireless
                  system in which POST-REGISTRATION is being implemented. 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 IP
                  Registration with nFA will not complete before the MN moves on, HTT
                  SHOULD be implemented. Certain wireless systems and implementations
                  do not allow such fast movement between FAs and may force the Mobile
                  IP Registration to occur soon after L2 handoff, in which case three
                  party handoff is not applicable. If this three party handoff feature
                  is not implemented, the FA SHOULD send an Agent Advertisement to the
                  MN after L2 handoff has completed (L2-LU at nFA) and/or the MN SHOULD
                  solicit a Router Advertisement after L2 handoff (L2-LU at MN).
               
                                                   +------+
                                              +--->| aFA  |<---+
                                              |    +------+    |
                                 4b) HRqst(r) |                | 3) HRqst(t)
                                     HRply(r) |                |    HRply(t)
                                              |                |
                                              v    2a) HRqst   v
                           1a) L2-ST ~~~> +------+     HTT  +------+ <~~~ 1b) L2-TT
                                          | oFA  |<-------->| nFA  |
                          4a) L2-LD ~~~>  +------+ 2b) HTT  +------+ <~~~ 5a) L2-LU
                                             ^         HRply    ^
                                     old L2  |                  |  new L2
                                             +-------+    +-----+
                                                     |    |
                                                     |    |
                                                     V    V
                                                    +------+  movement
                                     5b) L2-LU ~~~> |  MN  | --------->
                                                    +------+
               
                                        Figure 9 - Three Party Handoff
               
                  The L3 handoff can be deferred either because of a decision by the
                  MN/FA (i.e. MN does not send Router Solicitations and FA does not
                  send Agent Advertisements) or it may result from rapid movement
               
               
               
               El Malki (Editor) et. al.                                      [Page 25]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  between oFA and nFA that does not allow enough time for the
                  registration to complete. This scenario is shown in Figure 9. In this
                  case, oFA must inform nFA (i.e. the third FA) to contact aFA about
                  moving the radio end of the tunnel. This is performed with the
                  Handoff To Third (HTT) message.
               
                  The general idea behind the three party handoff procedure is that the
                  oFA supplies nFA with the same information it would have obtained via
                  an L2-TT if handoff had occurred from aFA to nFA, then the nFA
                  performs an HRqst(t)/HRply(t) sequence with aFA in order to move the
                  BET to nFA. When the L2 handoff is complete, oFA sends an HRqst(r) to
                  aFA to terminate the previous BET.
               
                  The following describes the progress of a three party handoff. The
                  numbered items refer to steps in Figure 9.
               
                    1) Either the oFA or nFA receives an L2 trigger informing it that a
                       certain MN is about to be moved. The two cases are:
               
                          a) The L2 trigger is a source trigger (L2-ST) at oFA. The
                             trigger contains the MN's L2 address and an IP identifier
                             (IP address or L2 address that can be mapped to an IP
                             address) for nFA.
               
                          b) The L2 trigger is a target trigger (L2-TT) at nFA. The
                             trigger contains the MN's L2 address and an IP identifier
                             for oFA.
               
                    2) The oFA and nFA exchange a HTT/HRply or HRqst/HTT pair. HTT is
                       indicated by setting both the H and N bits in the HRqst or
                       HRply. The HTT message MUST NOT have any tunnel flags set,
                       because the tunnel is negotiated between the aFA and nFA, not
                       oFA and nFA. There are two cases:
               
                          a) The L2 trigger is an L2-ST. The oFA sends HTT to nFA
                             containing the MN's home IP address, the MN's HA address,
                             an LLA containing the aFA's IP address, and an LLA
                             containing the L2 address of the MN. This is enough
                             information for nFA to perform a target triggered handoff
                             with aFA. The nFA responds with a HRply(s). Section 4.8
                             describes the HTT.
               
                          b) The L2 trigger is an L2-TT. The nFA sends HRqst(t) to oFA,
                             exactly as if a two party handoff were occurring. The oFA
                             responds with HTT containing the same information as in a)
                             above. This is enough information for nFA to perform a
                             target triggered handoff with aFA.
               
                    3) Upon receipt of the HTT, the nFA first checks its Visitor Cache
                       to see whether it is already tunneling for MN. If so, Step 6 is
                       performed. If not, nFA performs a target triggered handoff with
               
               
               
               El Malki (Editor) et. al.                                      [Page 26]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                       aFA, exactly as in Section 4.1, exchanging a HRqst(t)/HRply(t)
                       pair. Because aFA receives no L2 trigger indicating when L2
                       handoff starts, it may start tunneling to nFA upon transmission
                       of the HRply(t).
               
                    4) Once the L2 handoff is underway and the MN gets disconnected at
                       L2, aFA and oFA exchange messages canceling tunnel service
                       between aFA and oFA and allowing aFA to start the tunnel with
                       nFA.
               
                          a) The point in the L2 handoff process where the MN gets
                             disconnected from oFA is signaled at oFA by L2-LD.
               
                          b) The oFA exchanges a HRqst(r)/HRply(r) pair having lifetime
                             zero with aFA. This cancels tunnel service between oFA and
                             aFA. If aFA has not already established a tunnel to nFA,
                             it must do so immediately upon receipt of the HRqst(r).
                             The aFA provides tunneling service exactly as described in
                             Section 4.1 Step 4a.
               
                    5) Completion of L2 handoff is signaled by an L2-LU trigger at nFA
                       and/or MN. The nFA and MN handle the trigger in the following
                       ways:
               
                          a) The nFA provides packet delivery service to the MN exactly
                             as described in Section 4.1, Step 4b.
               
                          b) The MN either defers or initiates Mobile IP Registration
                             when it receives the L2-LU, as in Section 4.1
               
                    6) In the special case where nFA and aFA are the same (i.e. the MN
                       is moving back to the original anchor FA), aFA recognizes that
                       it is tunneling to oFA when it checks its Visitor Cache in Step
                       3. In this case, there is no need for aFA to send the
                       HRqst(t)/HRply(t) in Step 3. Upon receipt of the L2-LU trigger
                       on handoff completion, the aFA begins routing packets to MN and
                       the tunnel to nFA is torn down. The oFA still exchanges the
                       HRqst(r)/HRply(r) with aFA in Step 4b because oFA cannot know a
                       priori that aFA and nFA are the same, but they are redundant.
               
                  Unlike two party handoff, the timing of BET establishment between aFA
                  and nFA cannot fully depend on the availability of L2 trigger
                  information because aFA does not receive an L2 trigger signalling L2
                  handoff. The two timing extremes at which aFA can place the BET with
                  nFA are:
               
                    1) At the earliest, aFA MAY start tunneling packets using the BET
                       to nFA after sending the HRply(t) to nFA in response to the
                       request for target-triggered handoff
               
                    2) At the latest, aFA MAY start tunneling packets using the BET to
               
               
               
               El Malki (Editor) et. al.                                      [Page 27]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                       nFA and tear down the BET with oFA when receiving the HRqst(r)
                       from oFA indicating the MN has disconnected.
               
                  In addition, aFA MAY continue tunneling to oFA if 1) is selected,
                  until the HRqst(r) is received. If 1) is selected and the aFA
                  continues to tunnel to oFA, the result may be duplicated packets at
                  the MN, because the MN will receive packets through oFA on the old L2
                  until it disconnects (L2-LD). If 2) is selected, the additional
                  latency will add to the MN's L3 service disruption period. Of course,
                  aFA can choose to place the BET some time between 1) and 2) if
                  reliable bounds are available on the duration of time between L2-
                  ST/L2-TT and the MN's disconnection (L2-LD). The exact selection of
                  when to establish the BET is likely to be influenced by network
                  engineering and implementation considerations, including whether a
                  handoff smoothing solution is deployed, and is beyond the scope of
                  this specification.
               
                  Figures 10 and 11 show timing diagrams for source trigger (L2-ST) and
                  target trigger (L2-TT) three party handoff, respectively.
               
               
                         MN               nFA            oFA              aFA
                          |                |              |                |
                          |                | L2-ST ~~~~~> |                |
                          |                |              |                |
                          |                |<-------------|                |
                          |                |       HTT    |                |
                          |                |              |                |
                          |                |------------->|                |
                          |                |    HRply(s)  |                |
                          |                |              |                |
                          |                |------------------------------>|
                          |                |   HRqst(t)   |                |
                          |                |              |                |
                          |                |<------------------------------|
                          |                |    HRply(t)  |                |
                          |                |              |                |
                         ----------------------------------<~~~ L2-LD      |
                                                          |--------------->|
                                       L2 Handoff         |     HRqst(r)   |
                                                          |                |
                                                          |<---------------|
                                                          |     HRply(r)   |
                                                          |                |
                         ----------------------------------<~~~ L2-LU      |
                          |                |              |                |
                          |<-------------->|              |                |
                          | MN's traffic   |              |                |
                          |                |              |                |
               
                             Figure 10 - Three Party Source Trigger Handoff Timing
               
               
               
               El Malki (Editor) et. al.                                      [Page 28]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                         MN               nFA            oFA              aFA
                          |                |              |                |
                          |                |<~~~ L2-TT    |                |
                          |                |              |                |
                          |                |------------->|                |
                          |                |    HRqst(t)  |                |
                          |                |              |                |
                          |                |<-------------|                |
                          |                |    HTT       |                |
                          |                |              |                |
                          |                |------------------------------>|
                          |                |   HRqst(t)   |                |
                          |                |              |                |
                          |                |<------------------------------|
                          |                |    HRply(t)  |                |
                          |                |              |                |
                         ----------------------------------<~~~ L2-LD      |
                                                          |--------------->|
                                       L2 Handoff         |     HRqst(r)   |
                                                          |                |
                                                          |<---------------|
                                                          |     HRply(r)   |
                                                          |                |
                         ----------------------------------<~~~ L2-LU      |
                          |                |              |                |
                          |                |              |                |
                          |<-------------->|              |                |
                          | MN's traffic   |              |                |
                          |                |              |                |
               
                             Figure 11 - Three Party Target Trigger Handoff Timing
               
               
               4.3. Renewal or Termination of Tunneling Service
               
                  To prevent a BET from expiring when its lifetime runs out, the MN's
                  current FA signals the aFA to either renew or terminate the BET. This
                  may be the case when the MN defers Mobile IP Registration. If no such
                  signal is received, the aFA will terminate the BET when the lifetime
                  expires. In addition, the current FA or aFA may need to terminate the
                  BET prior to the lifetime expiring. In order to avoid error
                  conditions in which tunnels do not expire even though the MN to which
                  they apply is no longer reachable, FAs SHOULD set the tunnel lifetime
                  field to some value other that 0xffff, which indicates "good until
                  cancelled".
               
                  Figure 12 illustrates the message exchange that occurs between the FA
                  needing to terminate or extend the tunnel (designated FA(1) in the
                  figure) and the other FA (designated FA(2) in the figure). The
                  HRqst(r)/HRply(r) is indicated by setting the R bit in the
                  HRqst/HRply messages. If the HRqst(r) is renewing a BET then it
               
               
               
               El Malki (Editor) et. al.                                      [Page 29]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  contains a non-zero lifetime, otherwise if the lifetime is set to
                  zero it indicates tunnel termination. The aFA has complete control
                  over whether a tunnel is extended or terminated, and it MAY reply to
                  a request for extension with a shorter lifetime than was requested.
               
                                                    HRqst(r)
                                           +------+ <--------  +------+
                                           | FA(2)| ---------> | FA(1)|
                                           +------+ HRply(r)   +------+
               
                                     Figure 12 - BET Renewal or Termination
               
               
               4.4. When will the MN perform a Mobile IP Registration?
               
                  The MN/FA have control over when to perform the Mobile IP
                  Registration. Although the MN/FA may decide to defer Mobile IP
                  Registration for a certain period, three possible events can lead to
                  the need to terminate tunneling service. If this occurs the MN MUST
                  perform the Mobile IP Registration. These events are:
               
                    1) The end of life for the BET is pending and a request by the
                       current FA to aFA for renewal has been denied, or alternatively
                       the current FA or aFA needs to terminate the BET prematurely.
                       The FA in this case MUST initiate the Mobile IP Registration by
                       sending an Agent Advertisement to the MN as in [1].
               
                    2) The MN itself decides to perform a Mobile IP Registration and
                       initiates it by sending an Agent solicitation as in [1].
               
                    3) During a source triggered handoff, the oFA attempts to perform
                       BET handoff but nFA is not capable of performing it. The FA in
                       this case MUST initiate the Mobile IP Registration by sending
                       the MN an Agent Advertisement as in [1]. Note that this
                       situation will never arise during target triggered handoff
                       because an HRqst(t) will not be sent to oFA by an nFA that
                       doesn't support POST-REGISTRATION.
               
                  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 both a
                  forward and reverse tunnel are established between oFA and nFA (i.e.
                  a BET) and the MN has moved to nFA, the oFA MUST continue sending
                  Router Advertisements to the MN. This is to refresh the MN's default
                  router entry. The Router Advertisements are tunnelled from oFA to nFA
                  through the forward tunnel and MUST be unicast to the MN. Similarly
                  to PRE-REGISTRATION, tunneling of Advertisements is possible only if
                  the TTL limitation of [1] is relaxed. If this is not possible then
               
               
               
               El Malki (Editor) et. al.                                      [Page 30]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  the nFA MUST advertise to the MN as soon as it's link to the nFA is
                  up (L2-UP). The MN MUST perform a Mobile IP registration [1] when it
                  receives an Agent Advertisement following a POST-REGISTRATION
                  handoff.
               
                  Instead, when the forward tunnel is established but not the reverse
                  tunnel, oFA MUST NOT advertise to the MN. In this case, as described
                  previously, it is possible that the MN will not receive Router
                  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-UP). This effectively means that the MN
                  will at most be able to defer Mobile IP Registration for as long as
                  the remaining lifetime of the active default router, as configured in
                  the ICMP Router Advertisements. The MN MUST perform a Mobile IP
                  registration [1] when it receives an Agent Advertisement following a
                  POST-REGISTRATION handoff.
               
               
               4.5. Handoff Request (HRqst) Message format
               
                  This is a new Mobile IP 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              TBD (Handoff Request)
               
                    H                 Source triggered handoff request. When set and
                                      the N bit is unset, indicates that the request
               
               
               
               El Malki (Editor) et. al.                                      [Page 31]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                                      was the result of an L2-ST at oFA.
               
                    N                 Target triggered handoff request. When set and
                                      the H bit is unset, indicates that the request
                                      was the result of an L2-TT at nFA.
               
                    R                 Set if the request is an HRqst(r), i.e. a request
                                      to renew the tunnel. Neither the H nor the N bit
                                      are set.
               
                    M                 The FA issuing the HRqst will use Minimal
                                      Encapsulation as defined in [1,5] for the tunnel.
               
                    G                 The FA issuing the HRqst will use GRE [4]
                                      Encapsulation as defined in [1,5] for the tunnel.
                                      When this flag is set the HRqst may require
                                      extensions containing the GRE type and key
                                      fields, but they are outside the scope of this
                                      document.
               
                    T                 For an HRqst(s), indicates that the oFA is
                                      willing to support both forward and reverse
                                      tunnel service. For an HRqst(t), indicates that
                                      the nFA is requesting reverse tunnel service.
               
                    B                 When sent in an HRqst(s), indicates that the MN
                                      has requested a reverse tunnel to the HA and that
                                      the nFA SHOULD use reverse tunnel to the HA if it
                                      will not be reverse tunneling to the oFA.
               
                    Lifetime          The lifetime, in seconds, for which tunnel
                                      service for the MN will be maintained. If this is
                                      an HRqst(t), then the lifetime represents a
                                      request by nFA for a reverse tunnel. If this is
                                      an HRqst(s), then the lifetime represents the
                                      maximum amount of time that oFA is willing to
                                      maintain the both the forward and reverse tunnel.
                                      If this is an HRqst(r), then the lifetime
                                      Represents a request for the amount of time to
                                      renew the tunnel's lifetime. A value of 0 on an
                                      HRqst(s) indicates that the oFA is unwilling to
                                      grant any tunnel service. A value of 0 on an
                                      HRqst(t) indicates that the nFA does not require
                                      reverse tunnel service. A value of 0 on an
                                      HRqst(r) indicates that the tunnel should be
                                      terminated immediately. A value of 0xffff
                                      indicates 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.
               
               
               
               El Malki (Editor) et. al.                                      [Page 32]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                    Identification    As in 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 IP address for the FA.
                                      This Message MUST contain the FA-FA
                                      Authentication Extension [11] that is used to
                                      secure the HRqst message.
               
               
               4.6. Handoff Reply (HRply) Message
               
                  This is a new Mobile IP 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              TBD (Handoff Reply)
               
                    Code              A value indicating the result of the Handoff
                                      Request. Only two codes are currently supported,
                                      0, indicating success, and a nonzero value,
                                      indicating that the handoff cannot be performed.
               
                    Lifetime          The lifetime, in seconds, for which the
                                      bi-directional tunnel for the MN will be
                                      maintained. If this is an HRply(s), then the
                                      lifetime represents a request by nFA, and it can
                                      be any value up to the maximum value sent in the
                                      HRqst(s). Larger values are assumed to default to
                                      OFA's maximum. If this is an HRply(t), then the
                                      lifetime represents the maximum amount of time
                                      that the oFA will grant to the nFA. If this is a
                                      HRply(r), then the lifetime represents the
                                      amount of time by which the tunnel life will be
               
               
               
               El Malki (Editor) et. al.                                      [Page 33]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                                      extended. If the Code field indicates that
                                      handoff failed, the Lifetime field will be
                                      ignored and SHOULD be set to zero. A value of
                                      0 on an HRply(t) indicates that the oFA is
                                      unwilling to grant service. A value of 0 on an
                                      HRply(s) indicates that the nFA does not require
                                      service. A value of 0 on HRply(r) indicates that
                                      the tunnel lifetime will be terminated. A value
                                      of 0xffff indicates infinite lifetime.
               
                    H                 Source triggered handoff reply. When set and
                                      the N bit is unset, indicates that the
                                      reply is in response to an HRqst(s).
                    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 is set the HRply may require
                                      extensions containing the GRE type and key
                                      fields, but they are outside the scope of this
                                      document.
               
                    T                 For an HRply(s), indicates that the nFA is
                                      Requesting to reverse tunnel service. For an
                                      HRply(t), indicates that the oFA is willing to
                                      provide both forward and reverse tunnel service.
               
                    B                 When sent in an HRply(t), indicates that the MN
                                      has requested a reverse tunnel to the HA and that
                                      the nFA SHOULD use reverse tunnel to the HA if
                                      it will not be reverse tunneling to the oFA. It
                                      can be set in HRply(t) only if the T bit was
                                      unset in the corresponding HRqst(t).
               
                    MN Home Address   For HRply(t), the home address of the MN.
               
                    HA Addr           For HRply(t), the HA address of the mobile node.
               
                    Identification    As in defined in [1].
               
                    Extensions        This Message MUST contain the FA-FA
                                      Authentication Extension [11] that is used to
               
               
               
               El Malki (Editor) et. al.                                      [Page 34]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                                      secure the HRply message.
               
               
               4.7. Handoff To Third (HTT) Message
               
                  The Handoff to Third message has the same format as the Handoff
                  Request and Handoff Reply Messages, except both the H and N bits are
                  set. If the HTT message is in response to a L2-ST and is sent to
                  initiate a handoff, then, with the exception of the H and N bits, the
                  message has the same fields set and includes the same extensions as
                  an HRqst(s). If the HTT message is sent in response to an HRqst(t),
                  then, with the exception of the H and N bits, the message has the
                  same fields set and includes the same extensions as an HRply(t). The
                  tunnel bits MUST NOT be set in the HTT message because BET
                  construction is not negotiated between oFA and nFA, it is negotiated
                  between nFA and aFA in the ensuing HRqst(t)/HRply(t).
               
                  In addition, the HTT MUST contain the following extensions in the
                  specified order:
               
                       Solicited IP Address Option: containing aFA's Address
               
                       LLA Option: containing the L2 address of the MN.
               
               
               4.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 IP layer
                  messages to be sent to or from a MN prior to the L2 handoff event.
                  Therefore, it eliminates a possible source of handoff latency. This
                  may be required when the link layer imposes hard deadlines on the
                  time at which a handoff must occur, such as when a MN is rapidly
                  moving out of a radio coverage area. Consequently, POST-REGISTRATION
                  is primarily of interest in handoff between FAs that support the same
                  radio access technology. Handoff between heterogeneous radio
                  technologies will, of necessity, require interaction between the MN
                  and the network, and so is not a domain of applicability for POST-
                  REGISTRATION.
               
                  Because a POST-REGISTRATION handoff is triggered by an unspecified
                  mechanism that informs the oFA or nFA that an L2 handoff is pending,
                  the POST-REGISTRATION approach is only applicable to networks where
                  such a mechanism is available.  For example, an L2 may provide
                  indications of radio signal quality that cause the oFA or nFA to send
                  the POST-REGISTRATION handoff messages. Any such indications must
                  also provide each FA involved in the handoff with the identity of the
                  other, so that messages can be sent to the right place.  This may
                  involve mapping L2 information onto FA IP addresses.  Also, the FAs
                  involved in a handoff must have pre-provisioned security arrangements
                  so that the POST-REGISTRATION messages can be authenticated.  If a
               
               
               
               El Malki (Editor) et. al.                                      [Page 35]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  handoff is to be completed as a result of the POST-REGISTRATION
                  messaging, any L2 handoff indications must also be securely
                  authenticated so that traffic to the old point of attachment is not
                  improperly halted.
               
                  POST-REGISTRATION handoff is appropriate in the following cases:
                  - L2 triggers are available on the network to indicate that L2
                    handoff is pending.
               
                  - Pre-provisioned security mechanisms are in place to allow fast
                    and secure messaging between the FAs and between the MN and an FA.
               
                  - Access point choice by the MN is not a concern or choice requires
                    user intervention and therefore is not on the critical path for
                    handoff.
               
               
               5. Combined Handoff Method
               
                  The combined method uses both PRE-REGISTRATION and POST-REGISTRATION
                  handoff by running the PRE-REGISTRATION method and in parallel
                  exchanging the POST-REGISTRATION handoff messages between oFA and
                  nFA. The only case not considered already in the POST-REGISTRATION
                  method is mobile-initiated handoff. In the mobile-initiated case, the
                  Handoff Request message is initated by the oFA or nFA when it
                  receives the Registration Request from the MN.
               
                  The combined method follows the PRE-REGISTRATION Handoff when it is
                  successful before the completion of the MNÆs L2 handoff. However, if
                  PRE-REGISTRATION does not complete prior to the expiration of a timer
                  on one or the other of the FAs, POST-REGISTRATION handoff is used.
                  Using POST-REGISTRATION handoff insulates the MN from delays caused
                  by errors such as loss of one of the Mobile IP messages involved in
                  PRE-REGISTRATION.
               
                  The start of POST-REGISTRATION is gated by the expiration of a timer
                  on the FAs. The timer is started at oFA following a source-trigger,
                  at nFA following the target-trigger, or at oFA and nFA following the
                  receipt of the Registration Request from the MN in the mobile-
                  initiated case. The timer is reset if the Registration Reply message
                  is received by the appropriate FA and sent to the MN.
               
                  Although the POST-REGISTRATION Handoff Request and Handoff Reply
                  messages are exchanged in advance, no forwarding of traffic between
                  oFA and nFA is performed unless the timer expires. The timer should
                  be set to a value that allows forwarding between oFA and nFA to begin
                  before the MN completes the L2 handoff to nFA.
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 36]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               6. Layer 2 and Layer 3 Handoff timing Considerations
               
                  In the optimal cases considered in the PRE-REGISTRATION and POST-
                  REGISTRATION handoffs it was assumed that a timely L2 trigger would
                  be received in such a way that packets could be delivered to the MN
                  via its nFA immediately upon connection. In this way the MN would not
                  suffer disruption due to the L3 handoff. However such precise timing
                  of the L2 trigger and handoff mechanism with respect to the actual L2
                  handoff event will not be possible in all wireless systems and may
                  depend on particular implementation techniques. Therefore some
                  uncertainty may exist at L3 as to exactly when the L2 connection
                  between the MN and the nFA becomes fully established and can be used
                  for L3 traffic. It is possible that in certain implementations
                  traffic will be re-reouted too early or too late with respect to the
                  moment when the connection between the MN and the nFA becomes fully
                  established. The techniques which will solve this problem and allow
                  the MN to receive traffic independently of the timing of the L2
                  handoff event are currently under study by the Mobile IP WG but are
                  outside the scope of this document.
               
               
               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 unless the
                  MN specifically requests it.
               
               
               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 ProxyRtSol and ProxyRtAdv on the air link.
               
                    2) Loss of the solicitation by an FA to obtain another neighbouring
                       FA's Advertisment or loss of the neighbouring FA's
               
               
               
               El Malki (Editor) et. al.                                      [Page 37]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                       advertisement.
               
                    3) Failure of the standard Mobile IP Registration.
               
                  Of these, case 3) is handled by standard Mobile IP mechanisms
                  described in [1]. Case 2) is relatively unlikely because spontaneous
                  packet drop rates on the fixed network are caused by congestion or
                  router failure and likely to be low. Since bit error rates on
                  wireless links are higher than on fixed links, case 1) is more likely
                  to occur. In the following subsections, the cases 1) and 2) are
                  considered.
               
               8.1.1. Failure of ProxyRtSol and ProxyRtAdv
               
                  PRE-REGISTRATION handoff can fail in network-initiated handoff when
                  the ProxyRtAdv 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 ProxyRtSol sent from the
                  MN or return ProxyRtAdv sent from the oFA are dropped. To reduce the
                  probability that ProxyRtAdv and ProxyRtSol are lost the MN and FA MAY
                  transmit multiple copies of these messages. Sholuld these messages
                  fail anyway, in both cases the MN connects to the nFA without having
                  received any prior signaling. When this happens the MN MUST solicit
                  an FA Advertisement when it connects to nFA at L2 (L2-UP) and perform
                  standard Mobile IP registration on the nFA as specified in [1].
               
               8.1.2. Failure of Inter-FA solicitation and advertisement
               
                  The solicitation from an FA to another neighbouring FA may fail or
                  the corresponding advertisement from the neighbouring 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 Advertisment is unable to send a
                  ProxyRtAdv in response to a source trigger or to a mobile-initiated
                  ProxyRtSol. 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 IP registration as soon as it connects
                  to the nFA (L2-UP) as specified in 8.1.1 and [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
                  handover 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.
               
               
               
               El Malki (Editor) et. al.                                      [Page 38]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               8.2.1. HRqst Message Dropped
               
                  If the HRqst message is dropped, the effect is the same for both
                  source and target-triggered handoff. 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).
               
               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 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
                  a FA Advertisement to the MN as soon as its L2 link is up (L2-UP 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 confirmation of the handoff.
               
                  In source-triggered handoff, the nFA assumes 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 IP registration because it does not know that the handoff
                  has failed. In this situation, the oFA MUST send out a 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
               
               
               
               El Malki (Editor) et. al.                                      [Page 39]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  HRqst, it MUST immediately send an Agent Advertisement to the MN, as
                  is the case whenever a tunnel is cancelled. 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.
               
               
               9. Generalized Link Layer Address Extension
               
                  This section defines the Generalized Link Layer Address (LLA)
                  Extension, used by any node that needs to communicate Link Layer
                  Addresses. The format of the extension relies on sub-types, where
                  each sub-type defines its own sub-structure. This draft defines six
                  sub-types. Future RFCs should allocate their own sub-type and define
                  their own address formats.
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    LLA ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                     Type
               
                       TBD (skippable) [1]  - when used for Mobile IP Registrations
                       TBD (skippable) [1]  - when used for Router Advertisements
               
                     Length
               
                       The length of the Link Layer Address + the one octet Sub-Type
                       field
               
                     Sub-Type
               
                       This field contains the Link Layer sub-type identifier
               
                     LLA
               
                       Contains the Link Layer Address
               
               
                     In this document, six subtypes are defined:
               
                           1        3GPP2 International Mobile Station Identity and
                                    Connection ID [12]
                           2        3GPP International Mobile Subscriber Identity [16]
                           3        Ethernet 48 bit MAC address [5]
               
               
               
               El Malki (Editor) et. al.                                      [Page 40]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                           4        64 bit Global ID, EUI-64 [6]
                           5        Solicited IP Address
                           6        Access Point Identifier
               
                  The following subsections describe the extensions.
               
               
               9.1.  3GPP2 IMSI Link Layer Address and Connection ID Extension
               
                  The IMSI Link Layer Address Extension contains the International
                  Mobile Station Identity.
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    IMSI ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           The length of the IMSI field + the one octet Sub-Type field
               
                        Sub-Type
               
                           1
               
                        IMSI
               
                           Contains the IMSI, in the form:
               
                                      <IMSI>:<Connection Id>
               
                           Where the <IMSI> is an ASCII-based representation of the
                           International Mobile Station Identifier, most significant
                           digit first, ":" is ASCII 0x3a, and the Connection ID is the
                           ASCII representation of a small, decimal number used for
                           distinguishing different link-layer connections from the
                           same device.
               
               
               9.2.  3GPP IMSI Link Layer Address Extension
               
                  The IMSI Link Layer Address Extension contains the International
                  Mobile Station Identity.
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 41]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    IMSI ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           The length of the IMSI field + the one octet Sub-Type field
               
                        Sub-Type
               
                           2
               
                        IMSI
               
                           Contains the IMSI, a number composed of 15-digits or less,
                           coded as described in [16].
               
               
               9.3.  Ethernet Link Layer Address Extension
               
                  The Ethernet Link Layer Address Extension contains the 48 bit
                  Ethernet MAC Address, as defined in [5].
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    MAC ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           7 (includes the Sub-Type field)
               
                        Sub-Type
               
                           3
               
                        MAC
               
                           Contains the 48 bit Ethernet MAC Address.
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 42]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               9.4.  IEEE 64-Bit Global Identifier (EUI-64) Address Extension
               
                  The 64-Bit Global Identifier (EUI-64) Address Extension contains the
                  64 bit address, as defined in [6].
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    MAC ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           9 (includes the Sub-Type field)
               
                        Sub-Type
               
                           4
               
                        MAC
               
                           Contains the 64-Bit Global Identifier Address.
               
               
               9.5.  Solicited IP Address Extension
               
                  The 32-bit Solicited IP Address Extension contains the IP address of
                  the agent (FA) being solicited. This extension MAY be present in an
                  ICMP Agent Solicitation as explained in Section 3.3.
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    IP addr ...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           5 (includes the Sub-Type field)
               
                        Sub-Type
               
                           5
               
               
               
               El Malki (Editor) et. al.                                      [Page 43]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                        IP Address
               
                           Contains the 32-Bit IP Address of the solicited node.
               
               
               9.6.  Access Point Identifier Extension
               
                  The 32-bit Access Point Identifier Extension contains an Identifier
                  of the Access Point to which the MN will move. This may be a wireless
                  L2 identifier. The MN is able to solicit an advertisement from the FA
                  servicing a certain Access Point by using this extension with Agent
                  Solicitations as explained in Section 3.3.
               
                      0                   1                   2                   3
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |     Type      |   Length      |   Sub-Type    |    AP ID...
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               
                        Type
               
                           TBD (skippable) [1]
               
                        Length
               
                           5 (includes the Sub-Type field)
               
                        Sub-Type
               
                           6
               
                        AP ID
               
                           Contains the 32-Bit Access Point Identifier.
               
               
               10. IANA Considerations
               
                  Section 9 introduces the Generalized Link Layer Address Extension
                  numbering space that requires IANA management. This specification
                  makes use of the subtype values 1-6, and all other values other than
                  zero (0) are available for assignment via IETF consensus [15]. The
                  numbers for the Generalized Link Layer Address Extension are taken
                  from the numbering space defined for Mobile IP registration and
                  Router Advertisement extensions in [1]. The same Generalized Link
                  Layer Address Extensions are used in both Mobile IP Registration and
                  Router Advertisement messages, which have different extension
                  numbering spaces defined in [1]. Therefore two separate Generalized
                  Link Layer Address Extension numbering spaces are required having the
                  same sub-type values. The Generalized Link Layer Address Extension
                  numbering MUST NOT conflict with any numbers used in [1], [3], [7],
               
               
               
               El Malki (Editor) et. al.                                      [Page 44]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  [13] and [14].
               
                  In the POST-REGISTRATION Handoffs method, Sections 4.4 and 4.5
                  require numbers assigned from the Mobile IP control message type
                  address space. The numbers assigned MUST NOT conflict with [1] and
                  [11].
               
               
               11. Security Considerations
               
                  A security consideration for PRE-REGISTRATION method, as discussed in
                  Section 3.8, is that oFA and nFA MUST share a security association to
                  authenticate messages transported between them and oFA must be
                  authorized to solicit nFA. The inter-FA messages (solicitations and
                  advertisements) MUST be authenticated using ESP [10]. The absence of
                  this security would allow denial of service attacks from malicious
                  nodes at any distance from the FA. Otherwise, PRE-REGISTRATION uses
                  the security mechanisms described in [1] and [11].
               
                  POST-REGISTRATION introduces a new change to Mobile IP, which is the
                  possibility that a MN may receive packets from an FA with which it
                  has not yet registered. In the event that the MN does not wish to
                  receive packets from unknown FAs, it MAY drop them. In a similar way
                  to PRE-REGISTRATION, oFA and nFA MUST share a security association
                  required to protect the Handoff Request and Reply messages. The
                  Handoff Request and Reply messages MUST be authenticated using the
                  FA-FA authentication extension [11]. The absence of this security
                  would allow impersonation attacks and denial of service attacks.
               
                  The minimal requirement is that all FAs involved in low latency
                  handoffs MUST support manual pre-configuration of security
                  associations with neighbouring FAs, involving shared keys and the
                  default algorithms of [1].
               
                  Since the techniques outlined in this document depend on particular
                  L2 information (triggers) to optimize performance, some level of L2
                  security is assumed. Both PRE and POST-REGISTRATION techniques depend
                  on L2 triggers, but the L2 security implications are different for
                  the two techniques. In particular, in POST-REGISTRATION the L2
                  triggers initiate the establishment of tunnels which route IP packets
                  for the MN to its new location. Therefore the L2 triggers MUST be
                  secured against any tampering by malicious nodes, either mobile or
                  within the wired network. The L2 addresses or IP addresses for the MN
                  and the FAs that appear in the L2 triggers MUST correspond to the
                  actual nodes that are participating in the handover. If there is any
                  possibility that tampering may occur, the recipient of an L2 trigger
                  MUST have some way of authenticating the L2 information. Provided the
                  L2 triggers are so secured, the nodes involved in a handover can
                  reject any traffic from a node whose L2 address or IP address was not
                  received in a trigger, yet tries to send traffic. Wireless networks
                  that do not provide such features will be subject to impersonation
               
               
               
               El Malki (Editor) et. al.                                      [Page 45]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  attacks, where malicious nodes could cause FAs to believe that a MN
                  has moved to other service areas or to allow a bogus MN to obtain
                  unauthorized service from an FA prior to performing a Mobile IP
                  registration. In PRE-REGISTRATION the security of L2 triggers has
                  different implications. The PRE-REGISTRATION technique depends on
                  Mobile IP security between MN and FA, so the same security
                  considerations in [1] apply. Should malicious nodes be able to
                  generate or modify L2 trigger information (i.e. L2-ST or L2-TT), this
                  would cause advertisements to be sent to the MN. They would consume
                  wireless resources and processing in the MN, but would not allow an
                  impersonation attack. In order to prevent such denial of service
                  attacks, there should be a limit on the number of advertisements that
                  an FA (oFA) will relay to the MN as a result of the reception of L2
                  triggers. This number will depend on the L2 technology. In order to
                  prevent any such denial of service attacks the L2 triggers SHOULD be
                  secured.
               
               
               12. Acknowledgements
               
                  Thanks to the Mobile IP WG chairs, Phil Roberts and Basavaraj Patil,
                  for their input and to Jonathan Wood for valuable comments on PRE-
                  REGISTRATION.
               
               
               13. Normative References
               
                    [1]  C. Perkins, Editor, "IP Mobility Support for IPv4", RFC 3220,
                         January 2002.
               
                    [2]  S. Bradner. "Key words for use in RFCs to Indicate Requirement
                         Levels". BCP 14, RFC 2119, March 1997.
               
                    [3]  G. Montenegro, "Reverse Tunneling for Mobile IP, revised", RFC
                         3024, January 2001.
               
                    [4]  D. Farinacci, T. Li, S. Hanks, and P. Traina,  "Generic
                         Routing Encapsulation (GRE)",  RFC 2784, Internet Engineering
                         Task Force, March 2000.
               
                    [5]  D. Plummer, "An Ethernet Address Resolution Protocol - or
                         Converting Network Protocol Addresses to 48.bit Ethernet
                         Address for Transmission on Ethernet Hardware", RFC 826,
                         Symbolics,Inc., November 1982.
               
                    [6]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
                         Registration Authority",
                         http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
                         March 1997.
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 46]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                    [7]  C. Perkins,  P. Calhoun, "Mobile IP Challenge/Response
                         Extensions",  RFC 3012, November 2000.
               
                    [8] S. Deering, "ICMP Router Discovery", RFC 1256, September 1991
               
                    [9] J. Postel, "Internet Control Message Protocol," RFC 792,
                         September 1981.
               
                    [10] S.Kent, R. Atkinson, "IP Encapsulating Security Payload
                         (ESP)", RFC 2406, November 1998.
               
                    [11] E. Gustafsson, A. Jonsson and C. Perkins, "Mobile IP Regional
                         Tunnel Management ", draft-ietf-mobileip-reg-tunnel-06 (work
                         in progress), March 2002.
               
               
               14. Informative References
               
                    [12] TIA/EIA/IS-2000.
               
                    [13] G. Montenegro and V. Gupta, "Sun's SKIP Firewall Traversal for
                         Mobile IP", RFC 2356, June 1998.
               
                    [14] P. Calhoun, C. Perkins, "Mobile IP Network Access Identifier
                         Extension", RFC 2794, March 2000.
               
                    [15] T. Narten, H, Alvestrand, "Guidelines for Writing an IANA
                         Considerations Section in RFCs", BCP 26, RFC 2434, October
                         1998.
               
                    [16] 3GPP TS 23.003 (www.3gpp.org).
               
               
               15. AuthorsÆ Addresses
               
                  The document editor and authors may be contacted at the addresses
                  below:
               
                  Karim El Malki
                  Ericsson Radio Systems AB
                  LM Ericssons Vag. 8
                  126 25 Stockholm
                  SWEDEN
                  Phone:  +46 8 7195803
                  E-mail: Karim.El-Malki@ericsson.com
               
                  Pat Calhoun
                  Black Storm Networks
                  250 Cambridge Ave. Suite 200
                  Palo Alto, CA 94306
                  USA
               
               
               
               El Malki (Editor) et. al.                                      [Page 47]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  Phone:  +1 650 617 2932
                  E-mail: pcalhoun@bstormnetworks.com
               
                  Tom Hiller
                  Lucent Technologies
                  Rm 2F-218
                  263 Shuman Blvd
                  Naperville, IL  60566-7050
                  USA
                  Phone:  +1 630 979 7673
                  Fax:    +1 630 979 7673
                  E-Mail: tom.hiller@lucent.com
               
                  James Kempf
                  NTT DoCoMo USA Labs
                  181 Metro Drive,  Suite 300
                  San Jose, CA 95110
                  USA
                  Phone: +1 408 451 4711
                  EMail: kempf@docomolabs-usa.com
               
                  Peter J. McCann
                  Lucent Technologies
                  Rm 2Z-305
                  263 Shuman Blvd
                  Naperville, IL  60566-7050
                  USA
                  Phone:  +1 630 713 9359
                  Fax:    +1 630 713 4982
                  E-Mail: mccap@lucent.com
               
                  Ajoy Singh
                  Motorola
                  1501 West Shure Drive
                  Arlington Heights, IL Ÿ 60004
                  USA
                  Phone: +1 847 632 6941
                  E-mail: asingh1@email.mot.com
               
                  Hesham Soliman
                  Ericsson Radio Systems
                  Torshamnsgatan 23, Kista
                  Stockholm
                  SWEDEN
                  Phone:  +46 8 4046619
                  Fax:    +46 8 4043630
                  E-mail: Hesham.Soliman@era.ericsson.se
               
                  Sebastian Thalanany
                  Motorola
                  1475 West Shure Drive
               
               
               
               El Malki (Editor) et. al.                                      [Page 48]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  Arlington Heights, IL - 60004
                  USA
                  Phone:  +1 847 435 9296
                  E-mail: sthalan1@email.mot.com
               
               
                  The working group can be contacted via the current chairs:
               
                          Basavaraj Patil               Phil Roberts
                          Nokia Corporation             Megisto Systems Inc.
                          6000 Connection Drive         Suite 120, 20251 Century Blvd
                          Irving, TX 75039              Germantown MD 20874
                          USA                           USA
                          Phone:  +1 972-894-6709       Phone:  +1 847-202-9314
                          EMail:  Raj.Patil@nokia.com   EMail:  proberts@megisto.com
                          Fax :   +1 972-894-5349
               
               
               16. Full Copyright Statement
               
                  Copyright (C) The Internet Society (2003).  All Rights Reserved.
               
                  This document and translations of it may be copied and furnished to
                  others, and derivative works that comment on or otherwise explain it
                  or assist in its implementation may be prepared, copied, published
                  and distributed, in whole or in part, without restriction of any
                  kind, provided that the above copyright notice and this paragraph are
                  included on all such copies and derivative works.  However, this
                  document itself may not be modified in any way, such as by removing
                  the copyright notice or references to the Internet Society or other
                  Internet organizations, except as needed for the purpose of
                  developing Internet standards in which case the procedures for
                  copyrights defined in the Internet Standards process must be
                  followed, or as required to translate it into languages other than
                  English.
               
                  The limited permissions granted above are perpetual and will not be
                  revoked by the Internet Society or its successors or assigns.
               
                  This document and the information contained herein is provided on an
                  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
                  TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
                  BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
                  HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
                  MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
               
               
                  Acknowledgement
               
                     Funding for the RFC Editor function is currently provided by the
                     Internet Society.
               
               
               
               El Malki (Editor) et. al.                                      [Page 49]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               Appendix A - Gateway Foreign Agents
               
                  The Mobile IP Regional Registration specification [11] introduces the
                  Gateway Foreign Agent (GFA), as a mobility agent that two FAs
                  providing service to a MN have in common. Figure A.1 provides an
                  example of a MN's initial registration through the GFA. If this is
                  the first registration message, the message MUST be forwarded to the
                  HA. All packets destined for the mobile will be delivered to the GFA,
                  which in turn will forward the packets to the FA servicing the MN.
               
               
                                  Reg Req   +-----+   Reg Req
                               +----------->| oFA |--------------+
                               |            +-----+              |
                               |                                 v
                            +----+                            +-----+ Reg Req +----+
                            | MN |                            | GFA |<------->| HA |
                            +----+                            +-----+         +----+
               
                                             +-----+
                                             | nFA |
                                             +-----+
               
                              Figure A.1 - Initial Registrations through GFA
               
                  If the MN moves to a nFA that is serviced by a GFA common with oFA,
                  the MN  MAY issue a Regional Registration Request (see Figure A.2).
                  The Regional Registration message does not need to be forwarded to
                  the HA, since the MN's traffic can still be delivered to the same
                  GFA. This optimized approach effectively reduces the latency involved
                  in the registration process.
               
                                             +-----+
                                             | oFA |
                                             +-----+
               
                            +----+                            +-----+         +----+
                            | MN |                            | GFA |         | HA |
                            +----+                            +-----+         +----+
                               |                                 ^
                               |             +-----+             |
                               +------------>| nFA |-------------+
                                Regional Reg +-----+ Regional Reg
               
               
                             Figure A.2 - Regional Registration through GFA
               
               
                  Note that the GFA may also be the MNÆs first-hop router.
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 50]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
               Appendix B - Low Latency Handoffs for Multiply-Interfaced MNs
               
                  For MNs that have two wireless network interfaces, either on the same
                  wireless network or on wireless networks having different wireless L2
                  technologies, the techniques discussed in this document may be
                  unnecessary if the Mobile IP stack on the MN allows switching an IP
                  address binding between interfaces. This Appendix discusses how
                  multiple wireless interfaces can aid low latency handoff.
               
                  Figure B.1 illustrates the normal and hierarchical MIPv4 models. As
                  shown in the figure, assume that the MN is connected to Radio Network
                  1 (RN1) and is registered with oFA through which it is receiving
                  traffic. Suppose MN enters the coverage area of RN2 and nFA and that
                  it prefers connectivity to this network for reasons beyond the scope
                  of this document (e.g. user preferences, cost, QoS available etc.).
                  The MN activates the interface to RN2 but continues communicating
                  through RN1. The MN may solicit advertisements from nFA through the
                  interface connected to RN1 to speed up the handoff process, provided
                  there is no TTL restriction, or it can solicit advertisements through
                  the interface connected to RN2 if it has been configured for IP
                  traffic.
               
               
                        +------+        +---------+
                        |  HA  |--------|  (GFA)  |
                        +------+        +---------+
                                          /     \
                                         /       \
                                      ...       ...
                                       /          \
                                      /            \
                                   +------+      +------+
                                   | oFA  |      | nFA  |
                                   +------+      +------+
                                      |             |
                                   +------+      +------+
                                   | RN1  |      | RN2  |
                                   +------+      +------+
               
               
                                   +------+
                                   |  MN  | --------->
                                   +------+
               
                                            Movement
               
               
                    Figure B.1 - Network Model for Mobile IPv4 With Multi-Access
               
                  Once the MN is registered with nFA and is successfully receiving and
                  transmitting through the new network, it tears down the interface to
               
               
               
               El Malki (Editor) et. al.                                      [Page 51]
               

               INTERNET-DRAFT      Low Latency Mobile IPv4 Handoffs           June 2003
               
               
                  RN1. If the MN has enough time to complete this procedure without
                  incurring degraded service or disconnection, the MN would experience
                  a seamless multi-access handoff but it may not be possible in all
                  cases, due to network coverage or for other reasons. Should multiple
                  interface handoff be possible then the low latency methods described
                  in this document are not necessary.
               
                  In order to support the possible failure of the connectivity with the
                  new network (RN2/nFA) in the short period following handoff, the MN
                  may use the "S" bit in its Mobile IP Registration Request to maintain
                  simultaneous bindings both its existing (HA or GFA) binding with oFA
                  and a new binding with nFA.
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               El Malki (Editor) et. al.                                      [Page 52]
               

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