One document matched: draft-koodli-mobileip-fastv6-01.txt
Differences from draft-koodli-mobileip-fastv6-00.txt
Mobile IP Working Group Rajeev Koodli
INTERNET DRAFT Charles E. Perkins
28 October 2000 Communication Systems Laboratory
Nokia Research Center
Fast Handovers in Mobile IPv6
draft-koodli-mobileip-fastv6-01.txt
Status of This Memo
This document is a submission by 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.
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.
Abstract
When a mobile node moves to a new point of attachment in the
Internet, relying on router advertisements may be insufficient to
insure adequate performance of time-critical applications running on
the mobile node. In many cases, other indications are available to
trigger handover of the mobile node to a new point of attachment,
at a new access router. The mobile node and the access router may
then be able to take steps, in addition to those specified for Mobile
IPv6, to reduce the time during which the mobile node is effectively
disconnected from the Internet. This specification defines the fast
handover problem and outlines a proposed solution to the problem.
Koodli, Perkins Expires 28 April 2001 [Page i]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
Contents
Status of This Memo i
Abstract i
1. Fast Handover Definition 2
2. Proposal 3
3. New Access Router Processing 6
4. ICMP Handover Redirect Message Format 6
5. ICMP Handover Message Format 8
6. ICMP Handover Authentication Suboption Format 9
7. ICMP Handover Error Format 9
8. Security Considerations 9
A. Link Failure 10
B. Alternative to ICMP Handover Message 11
Addresses 11
Koodli, Perkins Expires 28 April 2001 [Page 1]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
1. Fast Handover Definition
When a Mobile Node (MN) undergoes handover from one link to another,
it needs to obtain a new care-of 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 mobile node forms a new CoA, it may be able send packets using
the new CoA, but it cannot receive packets at that address until
its mobility agent(s) and correspondent nodes are notified with
Binding Updates. The timeline for these operations is illustrated
in Figure 2. Thus, the delay involved in forming a new CoA must be
reduced so that the mobile node can resume IP packet transmission
quickly, and, the latency involved in forwarding packets to the
mobile node until it successfully informs its mobility agent(s) and
correspondent Node(s) must be reduced as well. We outline a proposal
to reduce these two latencies when handovers are network-controlled,
i.e., some network entity instructs the mobile node to undergo
handover from one access router to another. This network entity
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 28 April 2001 [Page 2]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
X-------X-----X--------------X--------> Time
^ ^ ^ ^
| | | |
| | | |
Handover | | |
epoch start | | |
| | |
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 Milestones and Latencies
2. Proposal
Our proposal has the following key components. First, the Previous
Router informs the mobile node to undergo handover, using a new form
of the Neighbor Discovery Redirect message. In this message, the
Previous Router supplies the required information for the mobile
node to form a new CoA as well as obtain the New Router's link-local
and link-layer addresses. Second, subsequent to delivering the
Redirect message, the Previous Router sends a message to the New
Router supplying the mobile node's new CoA and requesting it to act
as a ND Proxy for that address. This message could also include the
mobile node's previous CoA as well as security keys that the New
Router can use to validate the ND cache entry when the mobile node
establishes connectivity. This message sets up a forwarding path
from the Previous Router to the mobile node's new CoA. Finally, after
establishing the link connectivity, the mobile node sends a message
to the New Router which has the effect of resolving any potential
address conflicts and validating the mobile node's entry in the
Koodli, Perkins Expires 28 April 2001 [Page 3]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
New Router's ND cache. This message includes Binding Update as an
encapsulation, so that if the ND cache entry can be validated, the
Binding Update can be sent right away.
In addition to reducing the latencies mentioned earlier (using basic
IPv6 and Mobile IPv6 extensions), the above operations involve
sending minimal number of messages over an air interface, which could
be an important consideration in bandwidth-constrained links.
When the handovers are triggered by the network, with possible
assistance from the mobile node regarding the decision to undergo
handover, the Previous Router determines the network prefix of the
New Router to which the mobile node will get attached to next.
The Previous Router has to obtain one or more network prefix(es),
e.g_from a network entity that controls the handover. Subsequently,
the Previous Router sends a Handover Redirect message (which is
a modified ICMP Redirect) to the mobile node, containing the new
access router's IPv6 address as well as its link-layer IP address
and (implicitly) its link-local address. This typically allows the
mobile node to determine its new CoA while still being attached to
the Previous Router. Optionally, the previous access router MAY
supply a specific care-of address for the mobile node to use when it
establishes its new link to the new access router. The mobile node
should use this new CoA after establishing link connectivity at the
New Router. The Handover Redirect message is specified in section 4.
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 28 April 2001 [Page 4]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
After transmitting the Handover Redirect message to the mobile node,
the Previous Router sends a ICMP Handover message (see section 5 to
the New Router, containing the mobile node's 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 (See below). 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. The behavior of the New Router as a Proxy is according
to the specifications in [3].
As mentioned earlier, the above message from the Previous Router to
the New Router SHOULD include security keys (see section 6) that the
latter could use when the mobile node establishes connectivity with
it. This message may also include additional control information,
such as an indication to buffer packets sent to the new CoA, as well
as any other useful context information.
After receiving the Handover Redirect message and forming a new
CoA, the mobile node undergoes Layer 2 handover to establish a new
link to the New Router. Note that the mobile node already has the
New Router's link-local and link-layer addresses. It can thus
send IP packets (including a Binding Update) directly to the New
Router (to forward). However, since the ND cache entry at the New
Router must be verified to ensure a unique address and possibly
validated through authentication, the mobile node first sends a
message to the New Router containing its link-layer address and
an authentication header. This message also includes the Binding
Update as an encapsulated packet. If the New Router can successfully
validate the ND cache entry, then the Binding Update is delivered
right away. If not, an appropriate error message is sent back to the
mobile node, which then has to resort to forming a new CoA if the
address is already in use.
The above message has the effect of propagating the mobile node's
link-layer address (and the security credentials) to the New
Router with the assumption that the IP address is valid. Thus, it
effectively reduces handover latency by the amount of time necessary
for two messaging round-trips -- once, for DAD, and and again for
Neighbor Solicitation and Neighbor Advertisement to determine New
Router's link-layer address. Besides saving handover time, the
handover message also serves to eliminate the bandwidth overhead
which would otherwise be consumed as the mobile node and new access
router perform DAD and Neighbor Discovery messages.
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 mobile
Koodli, Perkins Expires 28 April 2001 [Page 5]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
node. Some of these packets that arrive earlier than the mobile
node's establishment of IP connectivity at the New Router could be
lost without appropriate support for buffering.
3. New Access Router Processing
When the new access router receives the ICMP Handover message,
it SHOULD first check for the existence and validity of an AH
header, with authentication data computed according to the security
association between the previous access router and the new access
router.
If the handover message does not have the `M' bit set, the new
access router SHOULD compute the layer-2 address of the mobile node
by masking off the bits corresponding to the given Mobile Node
Care-of Address field. This will allow the new access router to send
messages to the mobile node at its new care-of address without having
to perform Neighbor Solicitation.
If the new access router receives a handover message containing a
new Care-of Address that is already in use by another node in its
Neighbor Cache, the new access router SHOULD return a ICMP Handover
Error message (see section 7) to the previous access router.
4. ICMP Handover Redirect Message Format
Routers send Handover Redirect packets to inform a mobile node of
a better access router. The redirect message SHOULD also contain
information enabling the mobile node to determine the layer-2 address
for the new access router, as well as its new care-of address for
attachment to the Internet at the new access router.
Koodli, Perkins Expires 28 April 2001 [Page 6]
Internet Draft Fast Handovers in Mobile IPv6 28 October 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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Size |M|C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Access Router IPv6 Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Access Router MAC Address (64 bits) (if present) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ New Care-of Address (128 bits) (if present) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD
Code 0
M If the `M' bit is set, the 64-bit Access Router MAC
Address field is present.
C If the `C' bit is set, the 128-bit New Care-of Address
field is present.
If the `M' bit is not set, then the Access Router's MAC address
may be determined by applying the value in the Prefix Size to mask
off the routing prefix bits of the value in the Access Router IPv6
Address field.
If the `C' bit is not set, then the mobile node may determine its new
care-of address by applying the value in the Prefix Size to select
the routing prefix from the the address in the Access Router IPv6
Address field. This routing prefix may then be prepended to the
lower-order bits of the mobile node's current care-of address.
The mobile node determines the new router's link-local address by
replacing Prefix-Size bits by the well-known link-local address
prefix FE80:.
Whether or not the `C' bit is set, the mobile node MAY attempt to
acquire a new care-of address once connectivity is established at the
new access router, or else it MAY continue to use the care-of address
Koodli, Perkins Expires 28 April 2001 [Page 7]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
implicitly or explicitly formed as above. Such care-of address
acquisition follows the Mobile IPv6 specification [1].
5. ICMP Handover Message Format
An access router sends an ICMP Handover message to inform a new
access router that it will soon be the default (edge) router for a
mobile node. The handover message contains enough information so
that the new access router can create the appropriate entry in its
Neighbor Cache for the prospective mobile node.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Size |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobile Node's New Care-of Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Mobile Node MAC Address (64 bits) (if present) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Type TBD
Code 0
M If the `M' bit is set, the 64-bit Mobile Node MAC Address
field is present.
If the `M' bit is not set, then the mobile node's MAC address may be
determined by using the routing prefix to mask off the leading bits
of the mobile node's care-of address.
Available suboptions include a Mobile Node Authentication suboption.
Other suboptions may be defined to handle necessary context
transfers.
The previous router needs to determine the correct address for
inclusion as the Mobile Node's New Care-of Address field. This can
be done by consulting its local tables to determine the correct
routing prefix for the new access router's service area. Determining
Koodli, Perkins Expires 28 April 2001 [Page 8]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
the assocation between neighboring access routers, and their prefixes
which are to be used for creating new care-of addresses, is carried
out by techniques beyond the scope of this specification. It
should be noted, however, that manual configuration is a realistic
possibility at the time the access routers are installed.
When the new access router receives a ICMP Handover message that
does not contain the Mobile Node MAC Address field, the new access
router determines the mobile node's layer-2 address by masking off
the leading bits according to the appropriate prefix size for that
subnet. The routing prefix is naturally known to the new access
router, since it is the default router for that subnet.
6. ICMP Handover Authentication Suboption Format
TBD
7. ICMP Handover Error Format
A prospective new access router sends the ICMP Handover Error message
to inform the previous access router that the handover is likely to
fail, and that the mobile node should not expect to consider the
sending access router as its new default router. The Handover Error
message contains enough information so that the previous access
router can determine which Handover Message caused the error.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobile Node's New Care-of Address (128 bits) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The previous access router uses its cached handover information to
determine which of its visiting mobile nodes is indicated by the
value given in the Mobile Node's New Care-of Address field.
8. Security Considerations
Any handover message has to be made secure against malicious nodes
wishing to fraudulently redirect traffic away from the mobile node.
Koodli, Perkins Expires 28 April 2001 [Page 9]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
Messages from the mobile node have to be authenticated so that an
access router does not erroneously redirect traffic to a malicious
interloper.
Messages, if any, to the previous access router have to be
authenticated so that the previous access router does not erroneously
redirect traffic away from the mobile node.
Messages to the new access router SHOULD be authenticated to enable
detection of malicious attempts to cause the new access router to
wastefully reserve resources for a mobile node that is unlikely to
arrive.
References
[1] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-12.txt, April 2000.
[2] R. Koodli and C. Perkins. A Framework for Smooth Hand-overs in
IP Mobile Networks (work in progress).
draft-ietf-koodli-smoothv6-00.txt, July 2000.
[3] 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.
A. Link Failure
In some radio networks, it is possible that the mobile node is not
able to establish the link with the New Router after deciding to
undergo new link establishment. In such a case, the mobile node may
revert back to the Previous Router resulting in a ``link reversal''.
When this happens, the mobile node has to send a message requesting
to disable forwarding to the new CoA that is no longer valid. When
this happens, the Previous Router may determine, through the Handover
Error message, that it has to stop forwarding packets to the MN's
new CoA. It may then determine if the mobile node is present on its
link and resume forwarding packets as appropriate. Alternatively,
the mobile node itself may send a 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 mobile node's current location.
Koodli, Perkins Expires 28 April 2001 [Page 10]
Internet Draft Fast Handovers in Mobile IPv6 28 October 2000
B. Alternative to ICMP Handover Message
The Previous Router MAY use an unsolicited SHREP message defined
in [2] to supply the mobile node's new CoA and security information
to the New Router. The mobile node MAY use a SHIN message defined
in the same document when it sends a message to propagate its
link-layer address to the New Router. The Previous Router MAY use
the unsolicited SHREP message to also supply any control information
(such as an indication to buffer packets) as well as any useful
context information (such as header compression state variables).
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
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 28 April 2001 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:51:30 |