Mobile IP Working Group                                     Eunsoo Shim
                                                      Richard D. Gitlin
Internet Draft                                      Columbia University
Document: draft-shim-mobileip-neighbor-00.txt             November 2000
Category: Informational


                Fast Handoff Using Neighbor Information


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.





Abstract

   We propose a new fast handoff mechanism in wireless IP using
   neighboring Foreign Agent information. Our proposal is based on the
   policy of utilizing, or perhaps even wasting, wired bandwidth between
   Foreign Agents, while minimizing rf (radio frequency) bandwidth
   exchanges, in order that handoff latency is minimized. We minimize
   the handoff latency by initiating data forwarding to the possible new
   foreign agent candidates (i.e., the neighbor foreign agents)
   immediately when the mobile node is about to start the link layer
   handoff procedure. This proposal builds upon the Mobile IP handoff
   procedure by adding a couple of additional message types. The handoff
   mechanism is a unified procedure for inter- and intra-domain handoffs
   and provides flexible choices to the network while maintaining
   transparency to the mobile node. The neighbor learning process is a
   distributed and dynamic mechanism.





1. Introduction


Shim/Gitlin               Expires April 2001                         1

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   Mobile IP [3]Æs handoff latency can be separated into two elements:
   motion detection time and forwarding setup time. Forwarding setup
   time is the time consumed to register the new care-of address with
   the Home Agent (HA) in the Mobile IP protocol. The registration
   procedure starts after the mobile node (MN) detects that it is in an
   area with a new attachment point, that is, a new Foreign Agent (FA).
   When a MN hands over from FA æAÆ to FA æBÆ, FA æAÆ is called an old
   FA and FA æBÆ is called a new FA in this draft. There are several
   proposals that reduce forwarding setup time by localizing forwarding
   setup for intra-domain handoffs such as Regional Registration [4].
   Many of these proposals retain the latency aspect of motion
   detection.

   One could wonder whether the MN or the network can predict the new FA
   before data transport from the old FA to MN is interrupted. If this
   is possible, the network can start forwarding setup to the new FA
   while the MN is still communicating with the old FA and thus reduce
   the handoff latency significantly. But this is not easy or feasible
   in general in the current wireless networks. It is not preferable to
   impose such a capability considering the complexity of the prediction
   either. While it is difficult to predict the new FA exactly, it is
   not too difficult to find a reasonable set of candidate FAs that are
   likely to be the new FA after a handoff. If we allow data forwarding
   to these prospective FAs just before, or during, the handoff process,
   then we can achieve very low handoff latency, without introducing
   significant complexity to the network or MN. Obviously forwarding to
   all the prospective FAs consumes more bandwidth in the wired network
   that connects the prospective FAs. The bandwidth of wired network is
   getting more abundant, as well as cheaper, and the available
   bandwidth of wired networks can be larger than that of the rf
   bandwidth by one or more orders of magnitude. With this in mind,
   achieving minimal handoff latency and thus providing the best
   possible quality of service to mobile IP applications at the expense
   of inefficient bandwidth usage in the wired networks is a sound
   engineering tradeoff.

   When a MN can hand over from FA æAÆ to FA æBÆ, FA æAÆ and FA æBÆ are
   called neighbor FAs to each other. A reasonable set of prospective
   new FAs is the set of neighbor FAs, while the set of prospective new
   FAs can be reduced down to one depending on the capabilities of the
   network or MN. We define a protocol through which each FA learns
   about its neighbor FAs. Then detailed handoff procedures are
   presented in various scenarios.
   Our proposal is built upon Mobile IP. Several new messages are
   introduced while keeping the Mobile IP protocol. Our proposal
   provides a framework for fast handoff that allows utilizing of
   different capabilities of the networks or MNs.



1.1. Conventions used in this document



Shim/Gitlin               Expires April 2001                         2

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].


1.2. Terminology

   old FA: When a MN hands over from FA æAÆ to FA æBÆ, FA æAÆ is the old
   FA in the handoff.

   new FA: When a MN hands over from FA æAÆ to FA æBÆ, FA æBÆ is the new
   FA in the handoff.

   neighbor FA: When a MN can hand over from FA æAÆ to FA æBÆ, FA æAÆ
   and FA æBÆ are called a neighbor FA to each other.


2. Neighbor FA Information

   Each FA can learn about its neighbor FAs from the MN. That is, the MN
   keeps the address of the old FA and notifies the new FA about it.
   Then the new FA learns about one of its neighbor FAs and notifies the
   neighbor (the old FA) about itself. A FA can learn about all of its
   neighbor FAs as time goes by and many handoffs occur.



                                   +-----+
                                   | oFA |  (4)Update Neighbor FA table
                                   +-----+
                                      ^
             +----+                   |
             | MN |                   |     (3)Neighbor FA Notification
             +----+                   |
                |                     |
                |                  +-----+
                +----------------->| nFA |  (2)Update Neighbor FA table
                                   +-----+
              (1)Registration message
                 with Previous FA Notification Extension

                  Figure 1 û Neighbor FA Learning Procedure




   Figure 1 shows the procedure through which each FA learns about its
   Neighbor FAs. In Mobile IP, the MN sends a Registration Request
   message to the new FA after it gets the Agent Advertisement message.
   In [4], Previous Foreign Agent Notification Extension is proposed.
   This extension is used to notify the new FA of the old FA address.
   But the semantics of the extension is different from that of [4]. It
   depends on whether Route Optimization proposed in [4] is adopted

Shim/Gitlin               Expires April 2001                         3

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   whether the new FA should send a Binding Update message to the old
   FA. And the old FA should not remove the visitor entry for the MN
   immediately even if it receives the Binding Update message.

   Each FA maintains a Neighbor FA table. Each entry of the Neighbor FA
   table contains the following fields:

   - Neighbor FA Address
   - Notified Time
   - Notification Time
   - Neighbor FAÆs Neighbor FA Cache Timeout Period

   After being notified of the old FA, the new FA updates its Neighbor
   FA table. Notified Time is the latest time the FA got notified of the
   Neighbor FA, which is updated every time the FA gets notification of
   the Neighbor FA. If the Notified Time is not updated for a certain
   period of time, called Neighbor FA Cache Timeout Period, the Neighbor
   FA entry is removed from the table.

   Then, the new FA checks whether it needs to notify the old FA of its
   address. Notification Time is the latest time the FA notified the
   Neighbor FA of itself. To avoid too frequent notification, the FA
   sends Neighbor Notification to the Neighbor FA only when it has
   passed since the Notification Time by more than a half of the
   Neighbor FAÆs Neighbor FA Cache Timeout Period. By default, the
   Neighbor FAÆs Neighbor FA Cache Timeout Period has the same value as
   the local FAÆs Neighbor FA Cache Timeout Period.


      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      |                Reserved                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Neighbor FA Address                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Neighbor FA Cache Timeout Period                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      |                 Authentication                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   The old FA gets the Neighbor FA Notification message and updates its
   Neighbor FA table. If the Neighbor FA Cache Timeout Period included
   in the Neighbor FA Notification message is different from the value
   in the table, the timeout value in the table is modified to the value
   in the message. Also if there is large difference between the old
   FAÆs Neighbor FA Cache Timeout Period and that of the new FA, the old
   FA can send a Neighbor FA Notification message to the new FA so that
   the new FA can have the correct value for the old FAÆs Neighbor FA
   Cache Timeout Period in its table.

Shim/Gitlin               Expires April 2001                         4

Internet Draft        Fast Handoff Using Neighbor Info    November 2000



   This Neighbor FA information is of soft state, that is, each entry
   expires after Neighbor FA Cache Timeout Period has passed without any
   new notification for the Neighbor FA entry.



3. Handoff Schemes


3.1. Scenario 1

   In this scenario, we assume each base station belongs to a different
   subnet and thus each layer 2 (L2) handoff is accompanied by layer 3
   (L3) handoff, that is, Mobile IP handoff. We assume also no Route
   Optimization or Regional Registration is incorporated to simplify the
   description. Interoperation with each proposal will be covered later.

   The L2 handoff procedure can be initiated due to various causes. The
   cause may be detection of low signal strength or too high bit error
   rate. In most cases, the MN can know that it is going to do handoff
   before actual handoff occurs. Even in the case of network-controlled
   handoff mechanisms, the MN is informed of the L2 handoff in the early
   stage of L2 handoff. We assume the Mobile IP protocol stack is
   notified of the impending or beginning L2 handoff.



                                ^  ^
          (1) Handoff           |  H
              Notification    +-----+
          +------------------>|     |
          |H==================| oFA |===================H
          |H   Data           +-----+                   H
          |V                    |^ H                    H
        +----+               (2)|| H (3-a)             +----+
        |    |        Forwarding|| H Data              |    |
        | MN |      Notification|| H                   | HA |
        +----+                  || H (3-b)             +----+
                                V| V  Forwarding
                              +-----+ Acknowledgement
                              |     |
                              | nFA |
                              +-----+

        ----> Signaling Message
        ====> Data

               Figure 2û Handoff Procedure, Scenario 1, Phase 1





Shim/Gitlin               Expires April 2001                         5

Internet Draft        Fast Handoff Using Neighbor Info    November 2000




   Our handoff protocol in this scenario is shown in Figure 2,3, and 4.
   While the MN is bound to the old FA, the L2 handoff starts and the
   Mobile IP protocol stack gets notification of the handoff. Then the
   Mobile IP protocol stack generates a Handoff Notification message and
   sends it to the old FA.

   The following is the Handoff Notification message format.


      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  LAC  |N|      Reserved       |   Seq         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 MN Home IP Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      |                 Authentication                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 New FA Address (optional)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Link Layer Address Extension (optional)       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     . . .                                     /
      /                                                               /
      |                 Link Layer Address Extension (optional)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       LAC
            Link Layer Address Count, that is, the number of Link
            Layer Address Extension contained in the message

       N
            New FA Address. N bit is set if the new FAÆs address
            is contained

       MN Home IP Address
            Home IP Address of the mobile node sending the message

       Seq
            Sequence number assigned by the MN

       New FA Address
            IP address of the new FA at the current handoff

       Authentication
            Values needed for authentication of the mobile node

       Link Layer Address Extension [5]

Shim/Gitlin               Expires April 2001                         6

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


            Extension for the link layer address of an interface
            of the mobile node


   The MN Home IP Address is used to identify the MN sending the Handoff
   Notification message. MN assigns the same value to the Seq field when
   it sends multiple Handoff Notification messages to the old FA for one
   instance of handoff. Thus the old FA can filter out Handoff
   Notification messages which were sent in the past handoffs by
   checking the Seq field. When the MN sends Handoff Notification before
   it registers with the new FA as assumed in this scenario, the MN does
   not know the new FAÆs address in general. But it may be possible for
   the MN to it depending on the technology. Then the MN set N bit and
   fills this New FA Address field. It enables the old FA to forward
   data to the new FA only.

   Each Link Layer Address Extension provides the link layer address of
   a network interface of the MN. The MN may have multiple radio
   interfaces and it may use the different interface after the handoff.
   It is possible in particular in the cases of heterogeneous wireless
   overlay networks where the MN may hand over from a network to another
   network using a different technology.

   As soon as the old FA gets Handoff Notification from a MN, it reads
   its Neighbor FA table and sends Forwarding Notification messages to
   the Neighbor FAs. If the Handoff Notification message from the MN
   contains the new FAÆs address, the old FA sends Forwarding
   Notification only to the new FA. The Neighbor FAs of the old FA
   should then add the information into their temporary forwarding table
   and should reply to the old FA with the Forwarding Acknowledgement
   message. If the old FA does not receive Forwarding Acknowledgement
   from a Neighbor FA within a certain period, Forwarding
   Acknowledgement Wait Timeout Period, it sends again Forwarding
   Notification to the Neighbor FA. Even if the old FA does not receive
   Forwarding Acknowledgement from a Neighbor FA, it forwards data to
   the Neighbor FA up to Forwarding No ACK Timeout Period. The
   Forwarding Notification message format is the following.

















Shim/Gitlin               Expires April 2001                         7

Internet Draft        Fast Handoff Using Neighbor Info    November 2000



      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      |  LAC  |Reserve|         Sequence              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 MN Home IP Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      |                 Authentication                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Link Layer Address Extension (optional)       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                     . . .                                     /
      /                                                               /
      |                 Link Layer Address Extension (optional)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



       LAC
            Link Layer Address Count, that is, the number of Link
            Layer Address Extension contained in the message

       Sequence
            Sequence number of the Forwarding Notification Message
            assigned by the FA sending the message

       MN Home IP Address
            Home IP Address of the MN for which data is headed

       Authentication
            Values needed for authentication of the FA sending the
            message

       Link Layer Address Extension
            Extension for the link layer address of an interface
            of the mobile node















Shim/Gitlin               Expires April 2001                         8

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   The format of the Forwarding Acknowledgement is the following.

      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      |  Reserved     |         Sequence              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 MN Home IP Address                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      /                                                               /
      |                 Authentication                                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Sequence
           Copied from the sequence number of the corresponding
           Forwarding Notification message

       MN Home IP Address
           Home IP Address of the MN for which the data forwarding is

       Authentication
            Values needed for authentication of the FA sending the
            message


   Using the sequence number and the MN Home IP Address, the old FA can
   match the Forwarding Acknowledgement message to the corresponding
   Forwarding Notification message. Since each FA puts its own IP
   address as the source address in the IP header, the FAs can figure
   out the sender of the Forwarding Notification message or the
   Forwarding Acknowledgement message.

   Data forwarding from the old FA to the Neighbor FAs is done using
   tunneling. Now the question is how the new FA can forward the data to
   the MN. While the new FA as a router forwards IP packets using its
   routing table, the new FA handles the IP packets destined for the IP
   addresses registered in the temporary forwarding table differently.
   It is the same mechanism how each FA forwards IP packets toward a MN
   bound to the FA. That is, the new FA is aware that the MN is or will
   be located in the local subnet and tries to find its L2 address using
   ARP(Address Resolution Protocol)[] or something similar. If the new
   FA finds the L2 address of the MN or a proxy, it forwards IP packets
   using a L2 protocol with the L2 headerÆs destination address set as
   the found L2 address. What we need is L2 connectivity between the new
   FA and the MN. How it is established is out of the scope of this
   memo. It is a standard problem in supporting IP in any network and
   thus there are already solutions for many situations or it would be
   possible to find a solution. One thing to be noticed is that it is
   not necessary to have the base station and the FA co-located or
   connected with a direct link. To illustrate the point, a case when
   the new FA and the MN is connected through multiple routing hops is
   investigated later. While the MN has not finished its L2 handoff, the


Shim/Gitlin               Expires April 2001                         9

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   new FA cannot find a corresponding L2 address of the MN and thus it
   may buffer the data or discard it.

   In some situations, the new FA may be able to forward IP packets to
   the MN relying on the MAC address of an interface of the MN. Since
   the MAC address is the same before and after the handoff, the old FA
   can provide the MAC addresses of the interfaces of the MN to the new
   FA and the new FA can forward IP packets to the MN using the provided
   MAC addresses. Then the new FA does not have to rely on the ARP or
   something similar. It would save time for the new FA to start
   forwarding data to the MN. Since it is not generally possible, each
   FA should be configured about whether it should try the MAC addresses
   or use the MNÆs home IP address with a kind of the ARP mechanism.

   The point here is that the MN can receive data even before it
   receives the new FAÆs Advertisement message. So the handoff latency
   becomes independent of the speed of the Mobile IP motion detection
   and registration process.


                                   ^
                                   H
                              +-----+
                              |     |
                              | oFA |===================H
                              +-----+                   H
                                   H                    H
        +----+                     H                   +----+
        |    |                     H Data              |    |
        | MN |                     H                   | HA |
        +----+                     H                   +----+
         |^ ^                      H                     | ^
         || H (7)Reg. Reply        V                     | |
         || H=================+-----+   (6)Reg. Reply    | |
         |+-------------------|     | <------------------+ |
         +------------------->| nFA | ---------------------+
              (4)Reg. Request +-----+   (5)Reg. Request




        ----> Signaling Message
        ====> Data

               Figure 3û Handoff Procedure, Scenario 1, Phase 2



   While the MN is receiving data, it follows the procedure described in
   RFC 2002[3], that is, motion detection and registration. The new FA
   sends an Agent Advertisement message periodically and the MN sends
   the Registration Request message to the new FA. One thing to be
   noticed is that the MN should not use co-located care-of address.

Shim/Gitlin               Expires April 2001                        10

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   ItÆs because the data forwarding mechanism described in the above
   requires that the FA is in the data path and the FA should know the
   data traffic destined for the MN. Also the Registration Request
   message [4] from the MN should contain Previous Foreign Agent
   Extension or a similar extension to let the new FA learn about the
   old FA as one of its Neighbor FAs. If the MN does not include the
   Previous FA Notification Extension, we would need a separate message
   to provide the information about the old FA to the new FA. Following
   the Registration Request message sent to the new FA, come another
   Registration Request message from the new FA to the HA, the
   Registration Reply message from the HA to the new FA, and then the
   Registration Reply message from the new FA to the MN. The details of
   the procedure are as described in RFC 2002[3].






                              +-----+
                              |     |
                              | oFA |
                              +-----+
                                 ^
        +----+                   | (8)                 +----+
        |    |                   | Neighbor FA         |    |
        | MN |                   | Notification        | HA |
        +----+                   |                     +----+
           ^                     |                       H
           H                  +-----+                    H
           H==================|     | <==================H
               Data           | nFA |     Data
                              +-----+




        ----> Signaling Message
        ====> Data

               Figure 4û Handoff Procedure, Scenario 1, Phase 3


   After the procedure described in RFC 2002 completes, the HA forwards
   the data to the new FA and then the new FA to the MN. The old FA will
   stop data forwarding shortly because no data is forwarded to the old
   FA from the HA any longer. The new FA may send the Neighbor FA
   Notification message to the old FA as described in the previous
   section if needed.





Shim/Gitlin               Expires April 2001                        11

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


3.2. Scenario 2

   Here we consider the case the MN could not send Handoff Notification
   to the old FA while it was bound to the old FA. We assume everything
   else is the same as in the scenario 1 described in the above.

   Actually the handoff scheme is almost the same as that of the
   scenario 1. We assume the MN gets informed that the L2 handoff has
   completed. Then it sends the Handoff Notification message to the old
   FA. That is, our proposal requires notifications from L2 stack before
   the L2 handoff starts and after it finishes. The MN does not have to
   know about the new FA yet. The Handoff Notification messageÆs IP
   header contains the old FAÆs IP address as the destination address
   and the new FA will function just as a router. So the same Handoff
   Notification message is forwarded to the old FA as shown in Figure 5.
   The old FA does not differentiate the Handoff Notification sent
   through the new FA from that sent over the direct link between the
   old FA and the MN. After that, everything is the same as the scenario
   1.





                              +-----+
                              |     |   Data
                              | oFA |<==================H
                              +-----+                   H
                                 ^                      H
        +----+                   |                     +----+
        |    |                   | (2)                 |    |
        | MN |                   | Handoff             | HA |
        +----+                   | Notification        +----+
          |                      |
          |                   +-----+
          |                   |     |
          +------------------>| nFA |
           (1) Handoff        +-----+
               Notification


        ----> Signaling Message
        ====> Data

               Figure 5û Handoff Procedure, Scenario 2, the first step



3.3. Handoff Scheme for Ipv6

   We can use the almost the same handoff scheme for Ipv6 while
   achieving the same effect for server disruption minimization. The
   details of the message format should be different because the IP

Shim/Gitlin               Expires April 2001                        12

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   address format is different first of all. The more details will be
   dealt with in the next version of this Memo.



3.4. Network Expansion or Removing Subnets

   When a new subnet and a new FA are added, the first MN doing handoff
   between the new subnet and other subnets can experience slow handoff
   and thus significant service disruption. But this is transitional and
   disappears from the second MN.
   The timeout period of the Neighbor FA Table entries can be adjusted
   easily to accommodate the usage pattern of the network. If the
   network topology change does not occur daily basis, one day can be a
   good example value for the timeout period. Setting a proper timeout
   period is out of the scope of this Memo.
   Since the Neighbor FA information is of soft state, the invalid
   entries of the Neighbor FA Table are removed automatically after the
   timeout occurs.







4. References


   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

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

   [3] C. Perkins.  IP Mobility Support.  Request for Comments
       (Proposed Standard) 2002, Internet Engineering Task Force,
       October 1996.

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

   [5] P. Calhoun, T. Hiller, J. Kempf, P. McCann, C. Pairla, A. Singh,
       S. Thalanany. Foreign Agent Assisted Hand-off. draft-calhoun-
       mobileip-proactive-fa-02.txt (work in progress), September 2000.


5. Author's Addresses

   Questions about this memo can also be directed to the authors:

   Eunsoo Shim

Shim/Gitlin               Expires April 2001                        13

Internet Draft        Fast Handoff Using Neighbor Info    November 2000


   Department of Electrical Engineering
   Columbia University
   530 West 120th Street
   New York, NY 10027
   Email: eunsoo@ctr.columbia.edu

   Richard D. Gitlin
   Department of Electrical Engineering
   Columbia University
   530 West 120th Street
   New York, NY 10027
   Email: rich@ee.columbia.edu










































Shim/Gitlin               Expires April 2001                        14

Internet Draft        Fast Handoff Using Neighbor Info    November 2000



Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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 implmentation 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






































Shim/Gitlin               Expires April 2001                        15