[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Mobile IP Working Group                                    Rajeev Koodli
INTERNET DRAFT                                        Charles E. Perkins
5 October 2000                          Communication Systems Laboratory
                                                   Nokia Research Center

                     Fast Handovers in Mobile IPv6

Status of This Memo

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

   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:
   The list of Internet-Draft Shadow Directories can be accessed at:

   This document is an individual submission for the mobile-ip Working
Group of the Internet Engineering Task Force (IETF).  Comments should be
submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.

   Distribution of this memo is unlimited.

Koodli, Perkins              Expires 5 April 2001               [Page i]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000


Status of This Memo                                                    i

 1. Fast Handover Definition                                           2

 2. Proposal                                                           3

 3. Relation to Link Switching Failures                                6

 4. Security Considerations                                            6

Addresses                                                              6

Koodli, Perkins              Expires 5 April 2001               [Page 1]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

1. Fast Handover Definition

   When a Mobile Node (MN) undergoes handover from a link to another, it
needs to obtain a new IP address at the New Router as soon as possible
in order to be able to send and receive IP packets.  See Figure 1 for a
reference diagram of handover assumed in the rest of this document.  The
latency involved in forming a new CoA in IPv6 comes mainly from Neighbor
Discovery, which includes Router Advertisement and possibly Router
Solicitation, and Duplicate Address Detection (DAD) when stateless
auto-configuration is used.  After the MN forms a new CoA, it can send
packets using the new CoA, but not receive packets at that address until
its mobility agent(s) and correspondent nodes are notified through
Binding Updates.  This is illustrated in Figure 2.  Thus, the delay
involved in forming a new CoA must be reduced so that the MN can resume
IP packet transmission quickly, and, the latency involved in getting
the BU to its receipients must be optimized.  In this proposal, we
outline means to optimize these two design points when handovers are
network-controlled, i.e., some network entity instructs the MN to
undergo handover from an access router to another, and hence is assumed
to know the IP addresses and network prefixes of those routers.

             v            +------------+
           +-+            |  Previous  |        <
           | | ---------- |   Router   | ------ > ----\
           +-+            |   (Prtr)   |        <      \
               MN         |            |                \
            |             +------------+            +---------------+
            |                   ^            IP     | Correspondent |
            |                   |         Network   |  Node         |
            V                   |                   +---------------+
                                v                        /
             v            +------------+                /
           +-+            |    New     |        <      /
           | | ---------- |   Router   | ------ > ----/
           +-+            |   (Nrtr)   |        <
              MN          |            |

               Figure 1: Reference Scenario for Handover

Koodli, Perkins              Expires 5 April 2001               [Page 2]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

        X-------X-----X--------------X--------> Time
        ^       ^     ^              ^
        |       |     |              |
        |       |     |              |
      Handover  |     |              |
   start epoch  |     |              |
                |     |              |
               New    |              |
               link   |              |
           formation  |              |
                      |              |
                      |              |
                    ND+DAD           |
                  MN forms new       |
                  CoA and sends      |
                  Binding Update     |
                                 Binding Update
                                 received. MN can receive
                                 packets at new CoA

                       Figure 2: Handover Delays

2. Proposal

   When the handovers are triggered by the network, with possible
assistance from the MN regarding the decision to undergo handover,
the Previous Router determines the network prefix of the New Router
to which the MN will get attached to next.  The Previous Router can
obtain network prefix(s), e.g., from a network entity that controls
the handover.  Subsequently, Previous Router sends a modified Neighbor
Discovery Redirect message to the MN in which it provides one or
more network prefixs of the New Router as well as the New Router's
link-local IP address.  The MN then forms a new CoA using address
auto-configuration, includes it as an alternate CoA and sends a
Proactive Previous Router Notification message to the Previous Router.
In this message, the MN supplies its new CoA and possibly its security
credentials.  The effect of this message is to set up forwarding from
Previous Router to the MN's new CoA at the New Router.  Note that the
Previous Router may set up this forwarding subsequent to issuing the
Redirect message without waiting for, or expecting a Notification

Koodli, Perkins              Expires 5 April 2001               [Page 3]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

message from the MN when it is desirable not to send this control
message over the air interface.

   After this process, the MN undergoes Layer 2 handover to establish
a new link to the New Router.  The MN then directly sends a Neighbor
Solicitation message to determine the New Router's link-layer address.
When the New Router responds back with a Neighbor Advertisement message,
it indirectly verifies if the IP address of the MN as derived from
the Source Address field in Neighbor Solicitation message is already
in use when it updates its Neighbor Cache.  In this way, (partial)
Duplicate Address Detection can also be performed.  After the Neighbor
Solicitation and Neighbor Advertisement messages, the MN is ready to
send and receive IP packets at its new CoA. With these optimizations,
the handover delays are as shown in Figure 3.

   Subsequent to Neighbor Discovery, the MN sends a Binding Update
towards its mobility agent.  Note that since the Previous Router already
has an association from the previous CoA to the new CoA, the packets
could be arriving at the New Router almost as soon as a new link is
established for the MN. Some of these packets that arrive earlier than
the MN's establishment of IP connectvity at the New Router could be lost
without appropriate support for buffering.  The number of such packets
lost can also be reduced by instrumenting the forwarding epoch at the
Previous Router appropriately (e.g, by sending the Proactive Previous
Router Notification message just ahead of the impending link disruption
in L2 handover process or by other means).

        X-------X-----X--X------------------> Time
        ^       ^     ^  ^
        |       |     |  |
        |       |     |  MN ready to
      Handover  |     |  send and receive
   start epoch  |     |  packets
                |     |
               New    |
               link   |
           formation  |

                  Figure 3: Optimized Handover Delays

Koodli, Perkins              Expires 5 April 2001               [Page 4]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

   Note that some sites may disable DAD through setting a per-interface
configuration flag [3].  In such sites, delay due to DAD is not an issue
for faster IP connectivity.  When DAD is used, this document proposes
couple of ways to handle it.

   First, after issuing the Redirect message, the Previous Router
sends a message to the New Router supplying it the new CoA. The New
Router verifies if the new CoA is already in use by simply verifying
if an entry exists in its ND cache entry.  If an entry exists, it does
nothing.  If an entry does not exist, the New Router begins to act as
a Proxy so that it can respond to any potential DAD conflicts on its
link for the new CoA. This provides means for avoiding potential DAD
conflicts due to selecting an address while not on-link.

   Second, subsequent to attaching to the new link, the MN performs
Neighbor Solicitation to determine the New Router's link-layer address.
When it does this, it sets an ``O''ptimistic flag in the Reserved field
of the Neighbor Solicitation message indicating to the Traget (New
Router) that the address in the Source IP address is optimistic, and if
the New Router already has an entry for that address in its ND cache,
it must not overwrite that entry, and that the New Router must respond
back with a Neighbor Advertisement message indicating that the address
is in use.  The MN should then proceed to form a new link-local address
according to the rules specified in [3].  This provides an optimized way
of reducing latency due to DAD after the MN attaches to the new link.

   The modifications to the ND Redirect message are as follows.  The
Destination Address field is set to zero to indicate that the MN should
use the address specified in the Target Address field as the New Router
subsequent to handover.  The Redirected Header option is also set to
zero to minimize space.  In addition, a new option type is defined that
allows inclusion of one or more network prefixes.  This option type
follows the format specification in [2].  Note that the Redirect message
implicitly assumes that the Router parameters remain the same for the
target (New Router).  Thus, the MN should continue to use its existing
Router parameters until it hears a new Router Advertisement by the New
Router and take actions according to [2].

   The Previous Router MAY send a message to the New Router providing
security keys to validate the neighbor cache at the New Router.  The New
Router MAY NOT respond back to the MN's Neighbor Solicitation message
until its credentials are validated, e.g., through the receipt of a
suitable message from the Previous Router.  The Previous Router MAY use
an unsolicited SHREP message [1], in response to the Proactive Previous
Router notification message, to supply this security information (as
well as an indication to buffer packets) and it MAY also include any
other useful context information in the same message.

Koodli, Perkins              Expires 5 April 2001               [Page 5]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

3. Relation to Link Switching Failures

   In some radio networks, it is possible that the MN is not able to
establish the link with the New Router after deciding to undergo new
link establishment.  In such a case, the MN may revert back to the
Previous Router resulting in a ``link reversal''.  When this happens,
the MN has to send a Previous Router Notification message requesting to
disable forwarding to the new CoA that is no longer valid.  Note that
since a Binding Update has not been delivered yet, packets will still be
arriving at the Previous Router, and by disabling forwarding to the new
CoA, those packets can be delivered again at the MN's current location.

   When link reversals are not a concern, the MN MAY send a binding
update prior to leaving the Previous Router itself.

4. Security Considerations

   To be added.


   [1] R. Koodli and C. Perkins.  A Framework for Smooth Handovers
       with Mobile IPv6 (work in progress).  Internet Draft, Internet
       Engineering Task Force.
       draft-ietf-koodli-smoothv6-00.txt, July 2000.

   [2] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
       IP Version 6 (IPv6).  Request for Comments (Draft Standard) 2461,
       Internet Engineering Task Force, December 1998.

   [3] S. Thomson and T. Narten.  IPv6 Stateless Address
       Autoconfiguration.  Request for Comments (Draft Standard)
       2462, Internet Engineering Task Force, December 1998.


   The working group can be contacted via the current chairs:

        Basavaraj Patil                     Phil Roberts
        Nokia Corporation                   Motorola
        6000 Connection Drive               1501 West Shure Drive
        M/S M8-540
        Irving, Texas 75039                 Arlington Heights, IL 60004
        USA                                 USA
        Phone:  +1 972-894-6709             Phone:  +1 847-632-3148
        Fax :  +1 972-894-5349
        EMail:  Basavaraj.Patil@nokia.com   EMail:  QA3445@email.mot.com

Koodli, Perkins              Expires 5 April 2001               [Page 6]

Internet Draft       Fast Handovers in Mobile IPv6        5 October 2000

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

      Rajeev Koodli                      Charles E. Perkins
      Communications Systems Lab         Communications Systems Lab
      Nokia Research Center              Nokia Research Center
      313 Fairchild Drive                313 Fairchild Drive
      Mountain View, California 94043    Mountain View, California 94043
      USA                                USA
      Phone:  +1-650 625-2359            Phone:  +1-650 625-2986
      EMail:  rajeev.koodli@nokia.com    EMail:  charliep@iprg.nokia.com
      Fax:  +1 650 625-2502              Fax:  +1 650 625-2502

Koodli, Perkins              Expires 5 April 2001               [Page 7]

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