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
draft-koodli-mobileip-fastv6-00.txt
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:
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.
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
Contents
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 |
|
|
ND(+DAD)
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.
References
[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.
Addresses
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]