Internet Engineering Task Force MIPv6 Handover Design Team
INTERNET DRAFT 20 November 2000
Fast Handovers for Mobile IPv6
draft-perkins-mobileip-handover-00.txt
Charles E. Perkins
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
This document identifies (OR BETTER: specifies) protocol enhancements
that enable mobile nodes to more quickly become connected at new
points of attachment to the Internet. These protocol enhancements
are intended to minimize the time during which the mobile node is
unable to send or receive IPv6 packets (i.e., the handover latency).
Mobile IPv6 is considered to be the base protocol, but Mobile
IPv6 does not mandate any mechanism which gives assurances about
minimizing the handover latency. The protocol enhancements in this
document should be considered as protocol enhancements to Mobile
IPv6.
Perkins, editor Expires 20 May 2001 [Page i]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
Contents
Status of This Memo i
Abstract i
1. Introduction and Overview 1
2. Requirements 2
3. Scope of the Solution 2
4. Terminology 3
5. Interaction between Layer 2 and Layer 3 5
5.1. Anticipate Mobile Node Movement . . . . . . . . . . . . . 5
5.2. Indication of layer 2 handover completion . . . . . . . . 5
5.3. User Data Processing at layer 2 . . . . . . . . . . . . . 6
5.4. Carrying layer 2 parameters . . . . . . . . . . . . . . . 6
6. Binding Updates in Mobile IPv6 6
7. Interactions with Localized Bindings 7
8. Routing to Multiple Care-of Addresses 8
9. Network-Controlled vs_Mobile-Controlled Handover 8
9.1. Mobile-controlled Handovers . . . . . . . . . . . . . . . 9
9.2. Network-Controlled Handovers . . . . . . . . . . . . . . 10
10. Tunnel Extension 11
11. Handover Features 11
12. Handover Between Two Operator Domains 11
13. Ping-Pong Effect 12
14. Obtaining a new CoA 13
15. Latency of DAD 14
16. Handover Scenarios 14
16.1. Mobile Node sends PD with Link Connectivity to New Access
Router . . . . . . . . . . . . . . . . . . . . . . . . 15
Perkins, editor Expires 20 May 2001 [Page ii]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
16.2. New Access Router sends PD with Link Connectivity to Mobile
Node . . . . . . . . . . . . . . . . . . . . . . . . . 15
16.3. Mobile Node sends PD with Link Connectivity to Previous Access
Router . . . . . . . . . . . . . . . . . . . . . . . . 16
16.4. Previous Access Router sends PD with Link Connectivity to
Mobile Node . . . . . . . . . . . . . . . . . . . . . 18
17. Message flows 19
18. Message Extension and Option Formats 19
19. Security Considerations 20
20. Acknowledgements 20
21. References 20
A. Application signaling 21
B. Context Transfer 21
Addresses 23
1. Introduction and Overview
Mobile IPv6 already offers a handover procedure, which is recognized
to have sufficient in certain circumstances that makes it unsuitable
for real-time applications. It is the purpose of this draft to
define a solution that reduces handover latency, so that Mobile
IPv6 is a better candidate for handling mobility for mobile nodes
hosting real-time applications. Additional signaling procedures
and optimizations are proposed to be used in addition to the basic
handover procedure specified in Mobile IPv6. Note that the fast
handover techniques are not limited for use with only real-time
applications, and might offer substantial benefits for many other
kinds of communications.
There are a number of standard and proposed protocols involved with
establishing link connectivity for IPv6 networks, and each of them
has to be carefully considered to determine the possible effects
of each smooth handover technique proposal. For instance, IPv6
Duplicate Address Detection inserts a timeout before link operations
can begin. The effect of this has to be studied and perhaps
counteracted as part of any reasonable fast handover proposal.
This draft has several sections that are far from complete.
In particular, design consensus has not been reached
for most of the material that belongs in sections 17, 18
Perkins, editor Expires 20 May 2001 [Page 1]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
Section 16.4 needs more work, which could not be finished in
the time before the Internet Draft deadline.
Many issues remain unresolved.
2. Requirements
The main requirement for this solution is to reduce or eliminate any
handover latency when a mobile node moves from one care-of address
to another care-of address. This is valuable, because when a mobile
node experiences loss of connection for any appreciable duration of
time, it can adversely affect the operation of applications which
have real-time response characteristics. The solution selected MUST
be compatible with Mobile IPv6.
Secondary or Non-goals include:
- Context transfers
- Protection against loss of packets
- Minimizing signaling for delivery of binding updates
These goals may be considered during the development of the fast
handover protocol specification, but tradeoffs will be made to favor
fast handovers. If two proposals are otherwise equal, the selection
process SHOULD prefer the proposal that offers benefits for the above
secondary items.
The handover solution should work whether or not the serving
domain operates using a hierarchical mobility agent model in MIPv6.
However, if hierarchical mobility agents are available, the handover
solution should work well with the protocols needed to maintain
routing through the agent hierarchy (see section 7).
The time taken for allocation of a new care-of address at the new
access router is an important consideration in fast handover. Both
stateful and stateless address allocation methods add considerable
latency in the overall procedure. The Fast Handover procedure
solution should reduce the latency involved in the allocation of a
new CoA.
The handover solution should not depend on the specifics of any
air-interface or layer two (L2) technologies (but, see section 5).
Triggers from L2 can be incorporated into the solution space. The
solution MAY allow for later extensions to account for layer two
specific features.
Perkins, editor Expires 20 May 2001 [Page 2]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
3. Scope of the Solution
We will consider just the packet routing aspect of the problem and
not focus (initially) on transfering any context related information
that a mobile node may have at its previous point of attachment (but
see appendix B).
Multiple scenarios need to be considered. The solution is required
to enable improved handovers in the following scenarios:
a). Intra-technology handover (same administrative domain)
b). Intra-technology handover (between administrative domains)
c). Inter-technology handover (same administrative domain)
d). Inter-technology handover (between administrative domains)
The handover solution should also be specified to work whether the
mobile node is in idle or in active mode. The handover solution
should not introduce any changes to the current MIPv6 model. No new
network elements should be required, but the solution may specify new
features that would be needed at access routers.
4. Terminology
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 [1].
This document uses terms defined in Mobile IPv6 [2], Neighbor
Discovery [3], and Stateless Address Autoconfiguration [4]. In
addition, this document uses the following terms:
Access Router
the router offering connectivity to the mobile node at
some point of attachment to the Internet.
Active Mode
a mode in which a mobile node is fully enabled to send or
receive packets.
Context Transfer
the operation of transferring the value of state
variables, which had been established at the previous
access router, to the new access router
Perkins, editor Expires 20 May 2001 [Page 3]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
Current Access Router
the router offering connectivity to the mobile node at
its current point of attachment to the Internet. In this
document, the current access router is usually the point
of departure for the mobile node as it makes its way
towards the new access router.
Fast Handover
a handover operation that minimizes or eliminates latency
for establishing new communications paths to the mobile
node at the new access router
Handover Latency
Handover latency is the time difference between when a
mobile node is last able to send and/or receive a packet
to/from a correspondent node by way of the previous
access router, until when the mobile node is able to send
and/or receive a packet to/from a correspondent node, by
way of the new access router.
Idle Mode
a mode in which a mobile node has to perform additional
procedures before it is fully enabled for sending or
receiving packets. Typically a mobile node enters idle
mode to save battery power or air interface bandwidth.
New Access Router
the router offering connectivity to the mobile node at a
new point of attachment to the Internet.
Predictive handover
Predictive handover is initiated through the source
access router. Handover latency can be reduced by using
predictive handover procedure, since the predictive
handover procedure can set up the new access router for
the handover before the handover actually occurs.
Previous Access Router
the router offering connectivity to the mobile node at
its previous point of attachment to the Internet.
Reactive handover
Reactive handover is initiated through the new access
router.
Serving Domain
the administrative network domain which contains the
access router serving the mobile node.
Perkins, editor Expires 20 May 2001 [Page 4]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
Smooth Handover
a handover operation that minimizes data loss during the
time that the mobile node is establishing its link to the
new access point
Seamless Handover
a handover that is both fast and smooth
Note that, in the definition for Fast Handover, it is not specified
what the maximum allowable delay value should be. For the purposes
of seamless handovers for two-way voice (telephony) applications,
the value should be minimized. Current discussion indicates that
making any precise measurement for the delay value is difficult, so
no allowable maximum value will be specified in this document.
Note further that the handover latency is the time from the last
layer-3 connectivity between the mobile node and its previous access
router, to the time when the layer-3 connectivity to the new access
router has been established. Thus, it is possible for some handover
operations to cause zero latency. Negative values are not considered
useful for discussion in this document.
This Internet Draft is intended to become a standards track
document after completion of sections 17 and 18.
5. Interaction between Layer 2 and Layer 3
Although the handover procedure is developed at layer 3, it is
important to see the interaction between layer 2 and layer 3 to
better understand and implement the procedure. This section lists
some of the layer 2 interactions.
We should also point out that Layer 3 is where Mobile IP works.
5.1. Anticipate Mobile Node Movement
If layer 2 has the link evaluation capability, when it sees link
degradation it MAY send an trigger to layer 3 for handover. Layer 2
may also provide prioritized possible new candidates in the handover
initiation request.
5.2. Indication of layer 2 handover completion
The indication of layer 2 handover completion is desired by layer
3 at new access router and mobile node, so they can start layer 2
processing of IP packets. The source access router may also need the
Perkins, editor Expires 20 May 2001 [Page 5]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
layer 2 handover completion indication to release layer 2 resources
associated with the mobile node.
5.3. User Data Processing at layer 2
Real-time applications are expected to benefit from the fast handover
procedure. Such applications often do not require acknowledgement
of layer 2 packet delivery. In that case, there may be no need to
resend unacknowledged layer 2 packets from new access router.
5.4. Carrying layer 2 parameters
Some of the layer 2 attributes which were set on the source link
between mobile node and access router may need to be transferred and
set at the new link. Layer 3 handover signaling between the old and
new access router can be used to carry these layer 2 parameters.
For this purpose, an envelope field for layer 2 parameters might be
helpful in the layer 3 message.
6. Binding Updates in Mobile IPv6
In Mobile IPv6, a mobile node informs correspondent nodes and
mobility agents about its new care-of address by using a Binding
Update Destination Option. A correspondent node receiving the
Binding Update will begin to use Routing Headers to deliver data to
the mobile node. Mobility Agents receiving the Binding Update with
the 'H' bit set will begin to tunnel packets to the care-of address
given by the mobile node in the option.
However, aside from this use as suggested above, the mobile node
can send a Binding Update that is not so closely related to the
abovementioned use with its home agent. Between the time when the
mobile node moves from the old to the new access router and when it
sends a Binding Update to its correspondent nodes, the forward link
packets which are in flight go to the previous access router. These
packets will be lost unless they are handled and redirected to the
new care-of address. If the mobile node sends a Binding Update to
its previous access router, the access router subsequently tunnels
packets sent to the previous care-of address to the mobile node at
its new care-of address, acting as a home agent for the previous
care-of address. This is expected to be a transitional phenomenon,
and the binding between the care-of addresses typically has a short
lifetime. See [2] for details.
It is also noteworthy that most link establishment protocols are,
naturally, concerned with the mobile node's care-of address, with
Perkins, editor Expires 20 May 2001 [Page 6]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
hardly any consideration given to the mobile node's home address.
For this reason, it is reasonable to design smooth handovers that
identify the mobile node by its care-of address, if any IPv6 address
is to be used for that purpose. However, it is not easy to see how
any other kind of identifier could be used to identify the mobile
node without introducing non-local operations, or else additional
state at the access routers.
For mobile-controlled handovers (see section 9.1), any additional
handover features may be associated to this Binding Update, since it
may be the first opportunity that the mobile node has to communicate
such requests to its previous access router. Furthermore, just as
with the Binding Update, handover request messages are likely to
require authentication data, so that the previous router can make
sure that the handover request has indeed been issued by the intended
mobile node.
7. Interactions with Localized Bindings
Seamless handover has to do with enabling the mobile node to move
from one point of attachment to another within a serving domain.
Localized Binding has to do with limiting any signaling needed for
distributing Mobile IPv6 Binding Updates to interested parties
elsewhere in the network. Seamless handovers have to do with
managing delivery of packets to a new access router instead of the
previous access router. Localized Binding has to do with localized
techniques for associating a care-of address with the mobile node's
home address, along with some relevant timing information. The
timing considerations that are relevant to seamless handovers are not
closely related to the timing information associated to the binding
between the home address and the care-of address, although the latter
SHOULD provide an upper bound on how long the mobile node can have
use of its care-of addresses.
Several techniques which have been recently proposed may have
interactions with seamless handovers. Bicasting (or, "IP diversity")
refers to the process of duplicating packets and sending them to the
mobile node at both its previous and new points of attachment. This
is semantically allowed by IP because it does not guarantee packet
uniqueness, and higher level protocols are assumed to eliminate
duplicates whenever that is important for the application.
Anchor chaining refers to creating a chain of access routers, all
of which cooperate to forward a packet to the mobile node as it
moves from one access router to the next, even though the packet is
initially delivered to an access router that the mobile node was
attached to at some point in the perhaps distant past. The previous
access routers notionally form the links in the chain, which is
Perkins, editor Expires 20 May 2001 [Page 7]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
anchored by some access router which supports the concept, and is
known to the home agent or some nearer router as the latest effective
care-of address for the mobile node.
Lastly, and as exemplified by the anchor chaining approach, the path
taken towards the home agent by Binding Update (for the mobile node's
home address, not its care-of address) may be affected by the way
seamless handovers are carried out. It could be that the Binding
Update could conceivable be forwarded by either the new access
router, or the previous access router, towards the home agent or a
regional mobility-aware agent.
8. Routing to Multiple Care-of Addresses
Several solutions have been proposed that can route packets to more
than one care-of address. One solution, mentioned previously, is
known as "bicasting" or "IP diversity". Bicasting means to send the
same IPv6 packet to more than one access router. If the mobile node
is able to receive the packet at one or both of the access routers,
but there has not yet been time for the routing infrastructure to
settle on a particular route to the mobile node, then this method
can eliminate some guesswork about which actual care-of address
should receive the packet. The bicast request can be done as an
extension to the BU. If the MN has an entry in its Binding Update
List (BUL) indicating that a BU was sent with a bicasting request,
the MN may not need to resend BUs whenever a new router advertisement
is received from one of the ARs it is moving in between.
Another approach, known as "neighborhood routing", allows a packet to
be sent to several possible care-of addresses, which are provided by
the mobile node as simultaneous care-of addresses, and delivered in
a modified binding update to its correspondent nodes and home agent.
When the packet arrives at one of the specified care-of addresses,
then the access router determines whether to deliver the packet to
the mobile node directly, or whether instead to relay the packet to
the next care-of address. To facilitate this process, all potential
care-of addresses are included in the data packets.
9. Network-Controlled vs_Mobile-Controlled Handover
Generally, handovers are considered to fall into one of two
classifications:
- Network-Controlled, whereby some entity in the serving domain
directs the establishment of a new link between the mobile node
at some point of attachment determined by the network elements
Perkins, editor Expires 20 May 2001 [Page 8]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
- Mobile-Controlled, whereby the mobile node is responsible for
determining its new point of attachment and carries out the
necessary protocol for making the determination as well as
establishing the link at the new attachment point.
Designs for IPv6 network-controlled handover have various
interactions with Stateless Address Autoconfiguration, Neighbor
Discovery, and any other protocols relevant to link establishment.
Features of these protocols of the most particular interest include
Duplicate Address Detection, Neighbor Unreachability Detection, and
Router Advertisement and Solicitation.
In all cases, however, authentication of the mobile node is crucial.
Mechanisms that trigger the network-controlled handover have to be
safe against bogus nodes masquerading as the mobile node for which
the network is providing a controlled handover. When the mobile node
provides the signal that causes the network elements to finalize (or
commit) the results of the handover, that finalizing signal also has
to be authenticated in order to avoid losing handover state.
When wireless links are used, it is often required that the mobile
node report or keep track of the relative signal strength from
multiple network entities. While the mechanisms for making such
reports is beyond the scope of this document, it is still worthwhile
to keep in mind that such measurements can provide a good basis for
determining when a handover is likely to be beneficial.
9.1. Mobile-controlled Handovers
There is no sharp dividing line between network-controlled and
mobile-controlled handovers. For instance, the network may initiate
a mobile controlled handover by providing precise information to the
mobile node about how and when to carry out the handover operations.
The choice of handover strategy also depends on characteristics
of the physical medium and MAC layer protocols. For instance, if
the mobile can receive packets from multiple access routers at the
same time, then it is easier to design a mobile-controlled handover
operation that can avoid packet losses. "Make-before-break" schemes
are likely to depend on the viability of receiving packets over
multiple communications links during the handover.
In some wireless networks, an AR may not be closely coupled to the
radio link layer protocols. In these scenarios the initiation of the
handoff my need to be done by the MN. Based on L2 indications, the
MN may solicit the router for a special advertisement that includes
the "next" subnet prefix(es). To indicate the need for such special
advertisement, the solicitation message would need to include a new
option showing an identifier for the "new" AP. This identifier may
Perkins, editor Expires 20 May 2001 [Page 9]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
then be mapped in the AR to a neighbouring or the current subnet.
Hence the appropriate information can be communicated to the MN.
If the AP identifier is mapped to the existing subnet, the AR
will send an advertisement containing the current set of prefixes,
implying that no L3 handoff is needed. On the other hand, if the AP
is mapped to the "next" subnet, the appropriate set of prefixes will
be sent with the necessary extensions shown below.
9.2. Network-Controlled Handovers
If, on the other hand, the mobile node has to completely relinquish
access from one communications channel before it can have access
to a new one (say, from a new access router), then it is more
difficult for the mobile node to avoid packet losses and delays
without assistance from network entities. If the network delivers
information about the new point of attachment to the mobile node
before the previous point of attachment is deallocated, then
the mobile node can proceed to establish its new link. In some
circumstances, this still requires a noticeable delay while the
mobile retunes its physical network interface electronics.
In some cases, the access routers, possibly along with other
mobility-aware support points away from the periphery of the network,
may be able to take actions independently of the mobile node in
order to reduce the signaling load over the wireless links. This
would allow a mobile node to benefit from much faster establishment
of connection state at the new access router, because the handover
state would be available right away without having to wait for the
completion of a request message to be sent to the previous access
router.
If the handoff intiation is done by the access routers, then the AR
needs to get the relevant L2 indication regarding the MN's movement.
When the L2 indication is received, the AR will need to determine
if the MN is moving within its subnet or to a new one (whether L3
handoff is taking place or not). If L3 handoff is taking place, the
AR should send the set of prefixes relevant to the "next subnet.
For the previous access router to be able to provide subnet prefix
information to the mobile node, it has to be able to determine
the information. This can be done by manual configuration, or
alternatively by another protocol related to router advertisement and
solicitation.
If there is time for the mobile node or the previous access router
to solicit the information after a layer-2 trigger for handover is
received, then additional steps can be taken at that time, reducing
Perkins, editor Expires 20 May 2001 [Page 10]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
the need for automatic protocols between the access routers or static
configuration.
10. Tunnel Extension
When a mobile node moves to a new access router, it is possible
that a routing path or tunnel should be established between the old
and the new access router for the purpose of relaying packets still
in flight towards the previous care-of address. This tunnel can
help achieve a smooth handover by avoiding dropped packets. The
tunnel can be established either by direct action of the mobile
node, as with Mobile IPv6, as mentioned in section 6. It may
also be established by any of several techniques associated with
network-controlled handovers.
11. Handover Features
There are many kinds of features that may be associated with
handovers. Some of them MAY be described in a later revision this
document. However, as a general rule, a feature should only be
considered for inclusion along with a Binding Update if it satisfies
two properties:
- It is associated with operation of the mobile node at the network
layer. An example might be packet marking for diff-serv.
- It has time-critical performance requirements. Any feature
that can be satisfied after the mobile node has established
its new care-of address should be handled separately, in order
to avoid delaying the other features that have more stringent
requirements.
Note that inclusion of a handover feature with a Binding Update
makes the implicit assumption that the mobile node actively
requests handover for that feature. For considerations about
network-controlled handovers, see section 9.
12. Handover Between Two Operator Domains
The users may need to roam between two operator domains. These
operators may have roaming agreements with each other. Even though
the roaming agreements are valid, the new domain may need to check
the identity of the user before it provides service. Hence the new
domain may need to contact the old domain via AAA server etc.
Perkins, editor Expires 20 May 2001 [Page 11]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
These procedures take an significant amount of time, and that could
adversely affect mobile's real-time applications. It is proposed
that in situations like this the mobile is first allowed into
the new domain without any authentication, to avoid disruption of
service. Once the mobile is allowed in, the new domain may decide to
authenticate the mobile via AAA. If it determines that this mobile
is a legitimate user the service continues, if not the service is
terminated.
13. Ping-Pong Effect
A mobile node might conceivably keep performing handovers in a rapid
manner between two adjacent access points. This effect is commonly
known as the ping-pong effect or thrashing in cellular systems.
Cellular systems have various layer 2 mechanisms in place to deal
with the ping-pong effect. While this phenomenon may be transparent
to the IP layer if both APs belong to the same coverage area of an
AR, it is certainly an important issue to address if the APs are
associated with two different ARs.
What are the considerations and issues for a layer 3 handover when a
mobile node gets into a ping-pong scenario? One possibility is to
let layer 2 deal with it and not do anything special at layer 3. The
problem at layer 3 is that a mobile node may believe that it is about
to perform a handover and initiate handover signaling as it moves
from the previous access router to the new access router. However
as soon as the mobile node performs a handover and is attached to
the new access router, either the mobile node or the network again
initiates a handover back to the previous access router. This may
cause the mobile node to lose packets from CNs and the HA and also
introduces unnecessary signaling in the network. Layer 2 schemes
for dealing with the ping-pong effect may work when both the access
points are of the same technology. Ping-pong between two access
points of different technologies cannot be solved at layer 2, and
should be handled by layer-3 Fast Handover scheme. One solution is
to have the mobile node maintain a history of the access routers
that it is visiting. If the mobile node realizes that it is doing a
many rapid handovers between the same two access routers, it should
stabilize its connectivity at one of the access routers.
To successfully avoid the negative impacts of ping pong, it is
important to avoid sending BUs every time the MN attaches to a new
AR. In addition it is important to avoid packet routing deficiences
which may result in packets dropped for the duration of the ping
pong.
Bicasting (see section 7) is intended to be a solution to this
problem. To be able to handle this phenomenon, the MN may issue a
Perkins, editor Expires 20 May 2001 [Page 12]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
bicast request through the "old" AR and before the MN moves to the
"new" AR. In this case the old AR will act as an anchor point for the
MN and forward packets to both COAs.
This will ensure that the MN will continue receiving packets
addressed to it irrespective of its current AR. Hence the packet
losses due to IP mobility can be reduced to zero.
This type of dynamic hierarchy is best suited to routers serving
large coverage areas, where IP mobility may not occur very
frequently. For other mobility scenarios where handoffs are
frequent, it may be more beneficial to place the anchor point on a
topologically higher level resulting in a more static hierarchy.
However, in either architecture (flat or hierarchical) bicasting from
an anchor point can be achieved using the same extensions.
14. Obtaining a new CoA
One of the factors contributing to the latency during handoff is the
latency to obtain the CoA in the new subnet. CoA in the new subnet
can be obtained by stateful or stateless mechanisms. Optimizations
to reduce the latency involved in this process should be considered.
The procedure to obtain an CoA involves creating an interface address
(stateless mechanism) or obtaining an interface address in the case
of a stateful mechanism, and verifing that the address is unique.
The Duplicate Address Detection algorithm is performed on all
addresses, independent of whether they are obtained via stateless or
stateful autoconfiguration. It is possible that a site/access medium
believes that the overhead of performing Duplicate Address Detection
outweighs its benefits, the use of Duplicate Address Detection can be
disabled. Although it is possible for creating unique address most
of the time, with out mechanisms having to execute prodecures such as
DAD, the fast handoffs mechanisms should not be based on the premise
that it is possible to create such unique addresses. If mechanisms
such as DAD are latency intensive optimizations/alternatives such be
considered.
There are several problems of obtaining a CoA while the mobile is
not in the subnet to perform its own DAD. If this is assumed the
following need to be solved in a practical way.
If the Mobile performs it own DAD, the following issues arise:
- How does the node know the prefix of the AR?
- How is the neighbor solicitation messages sent to the new subnet?
Perkins, editor Expires 20 May 2001 [Page 13]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
- How are the Neighbor Advertisements relayed to the Mobile?
- What happens if the mobile moves in the middle of the DAD?
Alternatively the new AR could perform DAD and act as a proxy for the
mobile node before it moves to the new link.
15. Latency of DAD
In order to perform Duplicate Address Detection, the node sends to
Neighbor Solicitation a configured number of times and after the last
Neighbour Solication is sent a configured about of has to elapse
prior to assuming the unique ness of the address. This involves
considerable latency. Possible solutions are:
1. Perform stateful autoconfiguration without DAD
2. Use AR CoA as specified in draft-dommety-mobileip-lma-ipv6-02.txt
3. Create the CoA, assume that it is unique but perform DAD later
(might create some problems).
4. Perform stateless autoconfiguration without DAD, by
optimistically assuming that the mobile node's lower-order 64
bits address bits are very unlikely to experience any duplication
in the network link served by the new access router.
Note that DAD does not prevent a malicious user from using an address
even thought DAD fails.
16. Handover Scenarios
In this document, we classify the various handover cases according
to how the initial network-layer message is sent. This first
network-layer message is called the PD. It may be sent in response to
various kinds of stimuli at lower layers protocols. For instance,
signal strength measurements carried out at the link layer or below
may provide a handover trigger which causes the PD to be sent.
There are four cases:
1. mobile node sends PD to new access router with link connectivity
to the new access router
2. new access router sends PD to mobile node with link connectivity
to the mobile node
Perkins, editor Expires 20 May 2001 [Page 14]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
3. mobile node sends PD to previous access router with link
connectivity to the previous access router
4. previous access router sends PD to mobile node with link
connectivity to the mobile node
In the following subsections, we enumerate various sub-cases for each
of the above cases. In section 17, we outline message control flows
corresponding to appropriate subcases of the most interest. Finally,
in section 18, we specify message formats for the messages in those
control flows.
16.1. Mobile Node sends PD with Link Connectivity to New Access Router
If the mobile sends an unauthenticated message, it can be formulated
as part of router discovery; subsequent messaging would be the same
as in subsection 16.2. Assuming that the mobile node sends out an
authenticated message, the following possibilities exist.
1. Mobile node makes up a CoA and performs DAD and asks the old AR
to forward the packets to the new CoA.
2. Mobile node makes up a CoA and does not perform DAD and asks the
old AR to forward to the new CoA.
3. Mobile node does not get a CoA and asks the old AR to tunnel the
packets to the new AR. The New AR delivers the packets based on
old CoA.
4. Mobile node requests the new AR for a new CoA (Stateful) and the
old AR asks the new AR to forward packets to the new CoA
Questions: How does the mobile node know the new AR?
One suggested method is: The IP address for this AR+ should be
included in the router advertisement. When the MN has a data link
connection to the new sub-net it will get this new AR+ address from
the RA. The AR+ functionality should support:
- AAA interface in the future.
- new messages which we will propose.
- proxy for the MN (e.g. allocating COA in behalf of the MN).
Perkins, editor Expires 20 May 2001 [Page 15]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
16.2. New Access Router sends PD with Link Connectivity to Mobile Node
There are three subcases:
1. The new AR sends PD only to tell the mobile that it moved.
2. The new AR sends its Address in PD, that is used by the mobile
for two purposes: to detect movement and to ask the old AR to
forward packets to the new AR.
3. The new AR assigns a new unique CoA and sends it to the mobile.
Here there are two subcases:
- The mobile asks the old AR to forward packets to the new CoA
- The new AR asks the old AR to forward packets to the new CoA
(on behalf of the mobile).
16.3. Mobile Node sends PD with Link Connectivity to Previous Access
Router
This is a Mobile Initiated Handoff. The previous access router in
this case is still the MNs current default router, that is, the MN
has not yet moved to the target AR or is not link layer connected
(via some access point) to the target AR. The mobile has link layer
connectivity to the Previous AR. The previous AR can either process
the PD or forward it to the New AR.
Two cases arise due to timing of the link-layer disconnect
- The link layer connection to the old AR is intact until the PD is
acknowledged. If the handoff scheme is assuming that the mobile
is receiving some information such as new CoA etc from the old
AR, then the link layer to the old AR is assumed to be intact
until the PD is acknowledged, under normal conditions.
- The link layer connection to the old AR could be torn down
before the acknowledgment is received. In this case the
normal operation of the protocol does not assume that the PD is
acknowledged.
There are two cases that arise depending on the amount of processing
done by the previous AR.
- The Old AR processes the PD. After the processing it could
initiate a message sequence with the New AR (if known).
Perkins, editor Expires 20 May 2001 [Page 16]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
- The Old AR simply routes the PD. The PD is forwarded to the New
AR with out processing.
Three levels of information are available to the mobile; ways to
obtain this information is discussed later.
1. Mobile Node knows the new AR unicast address and network prefix
In this situation, there are two subcases, as follows:
- The mobile node gets a new CoA in the new subnet. The
New CoA can be acquired statelessly by the mobile or can
be statefully assigned by the new AR. The advantage of
stateful method is that the new AR might cache some addresses
which are already known to be unique, so it can offer one
immediately when MN asks for it.
According to RFC 2462 [4] DAD may be required for addresses
obtained via stateful auto-configuration:
"All addresses obtained manually or via stateful
address auto configuration SHOULD be tested for
uniqueness individually".
For either stateless or stateful address autoconfiguration,
there are two cases, depending on whether DAD is to be
performed. The time to perform DAD is likely to be a
concern. If DAD is needed in this case, the New AR has to
perform DAD on the behalf of the mobile. It may be necessary
to have an indication that tells the Mobile/Old AR that DAD
is required on the new subnet.
This applies to scenarios where CoA can be constructed
uniquely using some mechanisims.
- Mobile does not get a new CoA. Packets are forwded to the
current CoA for a while. In this scheme the old AR forwards
packets to the new AR. The new AR delivers the packets to the
mobile based on the old CoA. Since there is connectivity, the
mobile does not see a break in communication. At a later
point in time, the mobile acquires a new CoA and performs a
binding update.
2. Mobile Node knows the prefix of the New AR but does not know the
New AR addess. This makes DAD difficult, so we can assume that
DAD is not performed. In that case, the mobile node might be
able to formulate a new CoA and ask the previous AR to bicast, or
unicast to the new CoA.
Perkins, editor Expires 20 May 2001 [Page 17]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
If the MN does not know its new AR, then it is very costly to
figure it out, so this scenario may be a little bit unrealistic.
We should figure out a scheme to calculate the address of the
new AR if we know the network prefix. One way is to calculate
any-cast address for the new AR and forward our messages to this
any-cast address. On the other hand, if the mobile node gets
the prefix information, it might not be a substantially greater
effort to configure the new AR corresponging to the prefix.
DISCUSSION NOTE: Alper, Mohamed Khalil, and Gopal feel that
this is unrealistic. Hesham feels otherwise.
3. Mobile Node does not know the new AR or the prefix of the New AR
In this case the mobile can request information from another
entity (such as Old AR), if its get either the new AR unicast
address or the prefix information, that scenario can be reduced
to the above mentioned scenarions (3.1, and 3.2).
Getting the New AR information at the mobile.
A. No information about new AR.
B. L2 has enough information embeded. This helps the mobile to
get L3 details such as new AR or Prefix.
C. Mobile sends a L3 information to the old access router and
asks for information. An illustration of this is as follows:
* MN figures out the link it's moving to.
* Then it sends a message (an RS with an extension) to
current AR. This message contains the link id (an L2
info) to AR.
* AR maps this link id to newAR and newPrefix.
* AR sends this info in another message (possible an RA
with an extension).
16.4. Previous Access Router sends PD with Link Connectivity to Mobile
Node
One possibility is that the previous access router sends the message
to the Mobile Node, and then all the subcases for scenario 3 (i.e.,
section 16.3) are applied. Another possibility is that the previous
access router needs no further messages from the mobile node before
Perkins, editor Expires 20 May 2001 [Page 18]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
making handover arrangements with the new access router by way of an
inter-AR handover message.
17. Message flows
In this section, we display some proposed message flows to take
care of the most important scenarios and subscenarios detailed in
section 16.
The design decision has been taken to consider that scenarios 1
and 2 are already well-enough provided for by the smooth handover
features of Mobile IPv6 [2]. These are the scenarios in which the
PD cannot be sent until the mobile node has layer-2 connectivity to
the new access router. Not much additional performance is likely
to be gained, because there isn't any possibility to save time by
anticipating mobile node movement, by definition.
However, it is noted that schemes involving buffering can reduce
packet loss even in these scenarios.
For scenarios 3 and 4, in which the PD is issued while the mobile
node still has layer-2 connectivity at the previous access router,
another design decision has been taken. Since this specification
deals with layer-3 issues, the handover is considered to require
some layer three information relevant to the new access router.
Specifically, the handover at layer 3 requires acquiring a new
Care-of Address on the new link (see section 14), as well as prefix
lifetime information and possibly other link parameters typically
advertised by the new access router.
Situations where the mobile node would be expected to acquire this
information from advertisements from the new access router while
still maintaining layer-2 connectivity with the previous access
router are excluded from consideration in this specification.
Otherwise, the protocol would actually become a special case of
either scenario 1 or scenario 2. These have already been excluded as
noted above.
Thus, all solutions in this section are designed for use in
situations falling under either scenario 3 or scenario 4.
Furthermore, in scenario 3, the mobile node is presumed to require a
care-of address before it can migrate to the new point of attachment.
Thus, in scenario 3, the mobile node is presumed to require a
response to its PD.
Perkins, editor Expires 20 May 2001 [Page 19]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
18. Message Extension and Option Formats
In this section, message and option formats are specified. The
description for each message extension and option will specify which
message or option it may be used with.
19. Security Considerations
The security needed for smooth handover is almost the same as is
needed for handling Binding Updates in IPv6. If a handover could
be initiated by a node masquerading as the mobile node, a range of
undesirable effects might result. The malicious node could usurp
traffic destined from the mobile node, diverting it to a nearby
router and possibly an unauthorized care-of address. The exact
details of the possible effects would depend on the kinds of handover
data available as part of the smooth handover process.
20. Acknowledgements
Thanks to Yousuf Saifullah, Shavantha Kularatna, and Basavaraj for
contributing the underlying text for section 5, as well as other
supporting text.
21. References
- Mobile IPv6 [2]
- Stateless Address Autoconfiguration [4]
- Neighbor Discovery [3]
- Relevant drafts
* draft-yegin-mobileip-nrouting-00.txt
* draft-oneill-craps-handoff-00.txt
* draft-elmalki-handoffsv6-00.txt
* draft-mkhalil-mobileip-ipv6-handoff-00.txt
* draft-koodli-mobileip-smoothv6-00.txt
* draft-krishnamurthi-mobileip-buffer6-00.txt
* draft-koodli-mobileip-fastv6-00.txt
Perkins, editor Expires 20 May 2001 [Page 20]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
* draft-dommety-mobileip-lma-ipv6-01.txt
* draft-oneill-handoff-state-00.txt
And also the solutions proposed for MIPv4:
- draft-calhoun-mobileip-proactive-fa-02.txt
- draft-elmalki-mobileip-fast-handoffs-03.txt
A. Application signaling
When a handover event occurs, several immediate actions are likely
to occur, as described in the main part of this draft. However, it
is also likely that other programs may be affected by the handover.
If the new access router has any significant new features, or
if there are any significant features no longer available, then
applications running on the mobile node may need to react to the
changing conditions. Mobile IPv6, even with network-layer handover
features, cannot operate on behalf of all possible applications.
Thus, for those applications that need the information, a handover
signal should be defined and made available. This will be have to be
done in a system-dependent manner, so any further specification is
outside the scope of this document. However, it may be appropriate
for this signal to emanate from the same software that processes the
network-layer handover features.
B. Context Transfer
In order to make link utilization more efficient, and to counteract
certain known features of slow and/or lossy transmission media such
as radio, mobile devices frequently establish some local state with
the access router. For instance, a device may be identified by some
means other than its IEEE MAC address, because the latter takes up
too many bits over the slow medium. As another example, it may
be advantageous to transfer security associations between access
routers instead of having to re-establish those associations with
distant entities in the network. Each particular piece of local
state is potentially liable to be created separately at each new
link establishment if steps are not taken otherwise. As the mobile
node move from one access router to another in the IPv6 Internet,
each kind of context and state is a candidate for handover from the
previous access router to the new access router.
As another example of context being used to improve performance for
a mobile node, one may use buffering at either the new access router
or the old access router (or both) to avoid dropping packets during
Perkins, editor Expires 20 May 2001 [Page 21]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
the (presumably quite short) time during which a mobile node may be
disconnected from both network links.
Mobile IPv6 already offers some rudimentary handover features. For
instance, a mobile node may send a Binding Update to its previous
router. This causes the previous router to redirect packets towards
the new care-of address of the mobile node. It is reasonable to view
this process as assigning new state information (at the previous
router) indexed by the care-of address of the mobile node. The
previous router redirects packets by tunneling them to the mobile
node's new care-of address, which is provided by the mobile node in
the Binding Update.
It is worthwhile to note that all such bits of state and context
that are established by the mobile node with its access router tend
to encumber the connectionless nature of IP itself. If there were
no state at all, the mobile node could just send data at the new
access router, and all packets sent to the previous router would
be lost because the mobile node is not receiving packets there any
more. In a pure connectionless architecture, losing packets is
not necessarily a violation of protocol. Making the data stream
reliable is viewed as a higher-level function. The intention in
this draft is to explore ways to introduce the minimal amount of
connection-oriented behavior into Mobile IPv6 so that the recognized
pitfalls of unassisted handovers can be avoided. In this way,
performance enhancements are possible that may be unavailable from
higher level protocols.
Perkins, editor Expires 20 May 2001 [Page 22]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
References
[1] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[2] D. Johnson and C. Perkins. Mobility Support in IPv6 (work in
progress).
draft-ietf-mobileip-ipv6-12.txt, April 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.
[4] 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
Perkins, editor Expires 20 May 2001 [Page 23]
Internet Draft Fast Handovers for Mobile IPv6 20 November 2000
The authors of this document are:
Gopal Dommety Cisco
Mohamed Khalil Nortel
Basavaraj Patil Nokia
Charles E. Perkins Nokia
Phil Roberts Motorola
Hesham Soliman Ericsson
George Tsirtsis Flarion
Alper Yegin Sun Microsystems
Questions about this memo can also be directed to the editor:
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
Phone: +1-650 625-2986
EMail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Perkins, editor Expires 20 May 2001 [Page 24]