One document matched: draft-ietf-mobileip-fast-mipv6-06.txt
Differences from draft-ietf-mobileip-fast-mipv6-05.txt
Mobile IP Working Group Rajeev Koodli, Editor
INTERNET DRAFT Nokia Research Center
1 March 2003
Fast Handovers for Mobile IPv6
draft-ietf-mobileip-fast-mipv6-06.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 memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
Mobile IPv6 describes how a Mobile Node can maintain connectivity
to the Internet when it changes its Access Router for another, a
process referred to as handover. During this process, there is
a time period when the Mobile Node is unable to send or receive
IPv6 packets both due to link switching delay and IP protocol
operations. This time period is referred to as handover latency. In
many instances, the handover latency resulting from standard Mobile
IPv6 handover procedures could be greater than what is acceptable
to support real-time or delay sensitive traffic. Furthermore,
reducing the handover latency could be beneficial to non real-time,
throughput-sensitive applications as well. The intent of this
document is to describe protocol enhancements to reduce handover
latency due to IP protocol operations as small as possible in
comparison to the inevitable link switching latency.
Koodli (Editor) Expires 1 September 2003 [Page i]
Internet Draft Fast Handovers 1 March 2003
Contents
Status of This Memo i
Abstract i
1. Introduction 2
2. Terminology 2
3. Protocol Overview 4
3.1. Handover Initiation . . . . . . . . . . . . . . . . . . . 4
3.2. Tunnel Establishment and Packet Forwarding . . . . . . . 5
4. Protocol Details 6
4.1. Handover Initiation . . . . . . . . . . . . . . . . . . . 6
4.1.1. Anticipation . . . . . . . . . . . . . . . . . . 6
4.1.2. No Anticipation . . . . . . . . . . . . . . . . . 8
4.2. Tunnel Establishment between the Access Routers . . . . . 9
4.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 10
4.4. Three Party Handover . . . . . . . . . . . . . . . . . . 12
4.5. Optimization using link-layer assisted features . . . . . 12
4.5.1. Renewing Tunnel Lifetime . . . . . . . . . . . . 15
4.6. Three Party Handover with Layer 2 Trigger Support . . . . 15
5. Other Considerations 19
5.1. Handover Capability Exchange . . . . . . . . . . . . . . 19
5.2. Determining New Care of Address . . . . . . . . . . . . . 21
5.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 21
5.4. DAD Handling . . . . . . . . . . . . . . . . . . . . . . 22
5.5. Fast or Erroneous Movement . . . . . . . . . . . . . . . 22
6. Message Formats 24
6.1. New Neighbor Discovery Messages . . . . . . . . . . . . . 24
6.1.1. Router Solicitation for Proxy . . . . . . . . . . 24
6.1.2. Proxy Router Advertisement (PrRtAdv) . . . . . . 25
6.1.3. Fast Neighbor Advertisement (FNA) . . . . . . . . 28
6.2. Inter-Access Router Messages . . . . . . . . . . . . . . 28
6.2.1. Handover Initiate (HI) . . . . . . . . . . . . . 28
6.2.2. Handover Acknowledge (HACK) . . . . . . . . . . . 31
6.3. Handover To Third (HTT) . . . . . . . . . . . . . . . . . 33
6.4. New Mobility Header Messages . . . . . . . . . . . . . . 34
6.4.1. Fast Binding Update (FBU) . . . . . . . . . . . . 34
6.4.2. Fast Binding Acknowledgment (FBACK) . . . . . . . 36
6.5. New ICMP Options . . . . . . . . . . . . . . . . . . . . 38
6.5.1. IP Address Option . . . . . . . . . . . . . . . . 38
Koodli (Editor) Expires 1 September 2003 [Page ii]
Internet Draft Fast Handovers 1 March 2003
6.5.2. New Router Prefix Information Option . . . . . . 39
6.5.3. Link-layer Address (LLA) . . . . . . . . . . . . 40
6.5.4. Neighbor Advertisement Acknowledgment (NAACK) . . 41
6.5.5. Handover Capability Extension . . . . . . . . . . 42
7. Configurable Parameters 43
8. Security Considerations 43
9. Contributors 44
10. Acknowledgments 44
11. Contact Information 45
Koodli (Editor) Expires 1 September 2003 [Page 1]
Internet Draft Fast Handovers 1 March 2003
1. Introduction
Mobile IP describes the protocol operations for a mobile node to
maintain connectivity to the Internet during its handover from one
access router to another. These operations broadly involve movement
detection, IP address configuration, and location update phases.
The combined handover latency could be appreciable (especially) for
real-time applications and throughput-sensitive applications. This
document describes a protocol to reduce this latency.
This document addresses the following problem: how to allow a MN to
send packets as soon as it detects a new link, and how to deliver
packets to a MN as soon as its presence is detected by the MN's new
access router. The solution allows a MN to keep using its Care of
Address until it establishes itself as a Mobile IP end-point on its
new access router. The solution also allows a MN to expeditiously
establish a new Care of Address.
This protocol defines IP protocol messages necessary for its
operation on any link technology. It does this without depending
on specific link-layer features, while allowing link-specific
customizations, perhaps for even improved performance. By
definition, this specification considers handovers that inter-work
with Mobile IP: once attached to its new access router, a MN engages
in Mobile IP operations including Return Routability [3]. Hence,
there are no special requirements for a mobile node to behave
differently with respect to its standard Mobile IP operations.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described
in RFC 2119 [1].
The following terminology and abbreviations are used in this
document. The reference handover scenario is illustrated in
Figure 1.
Mobile Node (MN)
A Mobile IPv6 host
Access Router (AR)
The MN's default router
Previous Access Router (PAR)
The MN's default router prior to its handover
Koodli (Editor) Expires 1 September 2003 [Page 2]
Internet Draft Fast Handovers 1 March 2003
New Access Router (NAR)
The MN's anticipated default router subsequent to its
handover
Anchor Access Router (AAR)
The access router where the MN originally established
its CoA (i.e., the CoA that is known to the HA and the
Correspondent nodes).
Anchor CoA (ACoA)
The MN's Care of Address valid on AAR.
Previous CoA (PCoA)
The MN's Care of Address valid on PAR. The MN may reuse
this address while attached to NAR until it finishes
Mobile IP operations.
New CoA (NCoA)
The MN's Care of Address valid on NAR
Handover
A process of terminating existing connectivity and
obtaining new IP connectivity.
Router Solicitation for Proxy (RtSolPr)
A message from the MN to the PAR requesting information
for a potential handover
Proxy Router Advertisement (PrRtAdv)
A message from the PAR indicating a MN to undergo
handover
Fast Binding Update (FBU)
A message from the MN instructing its PAR to redirect its
traffic (towards NAR)
Fast Binding Acknowledgment (FBACK)
A message from the PAR in response to FBU
Fast Neighbor Advertisement (FNA)
A message from the MN to the NAR to confirm use of NCoA
when the MN has not received FBACK
Handover Initiate (HI)
A message from the PAR to the NAR to initiate handover
Handover Acknowledge (HACK)
A message from the NAR to the PAR as a response to HI
Koodli (Editor) Expires 1 September 2003 [Page 3]
Internet Draft Fast Handovers 1 March 2003
Bidirectional Tunnel (BT)
A tunnel for both PAR and NAR to forward packets to and
from MN's PCoA.
v +------------+
+-+ | Previous | <
| | ---------- | Access | ------ > ----\
+-+ | Router | < \
MN | (PAR) | \
| +------------+ +---------------+
| ^ IP | Correspondent |
| | Network | Node |
V | +---------------+
v /
v +------------+ /
+-+ | New | < /
| | ---------- | Access | ------ > ----/
+-+ | Router | <
MN | (NAR) |
+------------+
Figure 1: Reference Scenario for Handover
3. Protocol Overview
The key protocol operation involves setting up a routing path between
the two access routers to enable the MN to send and receive IP
packets while it establishes itself as a Mobile IPv6 end-point.
This tunnel establishment could be triggered by the MN requesting
a handover, or by the network (i.e., PAR). Once the tunnel is
established, packet forwarding on the tunnel to the MN begins when
the PAR receives a Fast Binding Update message from the MN. So, there
are three phases in the protocol operation: handover initiation,
tunnel establishment and packet forwarding.
3.1. Handover Initiation
The protocol is initiated when an event, such as a decision
to handover the MN to a new point of attachment, occurs. The
``trigger'' for protocol initiation may arrive from specific L2
events or from policy rules that might determine the need for
Koodli (Editor) Expires 1 September 2003 [Page 4]
Internet Draft Fast Handovers 1 March 2003
handover based on factors other than link connectivity alone (e.g.,
cost, bandwidth changes, etc.). These triggers themselves are not
specified in this document. Typically, it is the MN that responds
to such a trigger by requesting its AR (i.e., PAR) to assist in
handover by sending a Router Solicitation for a Proxy (RtSolPr)
message in which it includes the link-layer identifier (such as a
base station id or BSSID in IEEE 802.11 networks) of its prospective
attachment point. In response to RtSolPr message the PAR sends a
Proxy Router Advertisement (PrRtAdv) message, which provides the
link-layer address, and network prefix information about the NAR.
In the network-initiated handover, the PAR sends PrRtAdv message
without the MN sending RtSolPr message, and provides the parameters
necessary (i.e., link-layer address and IP address of the NAR) for
the MN to send IP packets, as well as the network prefix for the MN
to formulate a prospective new Care of Address.
The MN may include a wildcard link-layer identifier in the RtSolPr
message, and the PAR responds with an available list of corresponding
neighborhood access router parameters. Furthermore, the MN is
allowed to send the RtSolPr message at any appropriate time. For
instance, it may send the message after performing router discovery.
Such an allowance provides a MN the ability to move to any arbitrary
neighborhood router and immediately send protocol messages necessary
to receive and send packets meant for its previous Care of Address.
The purpose of RtSolPr is to request parameters necessary for the MN
to be able to send packets immeidately upon connecting to the NAR.
The purpose of PrRtAdv is to supply these parameters and the network
prefix information that would also allow the MN to formulate a NCoA.
When the underlying link layer provides these parameters (by means
outside the scope of this document), these messages are optional on
such links.
3.2. Tunnel Establishment and Packet Forwarding
Sometime (or any time) after it receives a PrRtAdv message, the MN
sends a Fast Binding Update (FBU) to PAR. The MN may also send an
FBU after attaching to the NAR. This FBU message associates the MN's
PCoA with NAR's IP address so that packets arriving at the PAR can be
tunneled to the NAR. In response, the PAR sends a Handover Initiate
(HI) message to the NAR. The HI message serves two purposes. First,
it initiates establishing a bidirectional tunnel between the two
routers so that the MN can continue to use PCoA for its existing
sessions. Second, it serves to verify if NCoA (either supplied
by the PAR or determined by the NAR when using stateful address
configuration), when present, can be used on NAR's link. In response
to processing the HI message, the NAR sets up a host route for the
MN's PCoA and responds with a Handover Acknowledge (HACK) message.
Koodli (Editor) Expires 1 September 2003 [Page 5]
Internet Draft Fast Handovers 1 March 2003
When the NCoA could be used, the NAR begins to proxy that address for
a short duration.
After it receives a HACK message, the PAR sends a Fast Binding
Acknowledgment (FBACK) message to the MN. The FBACK message confirms
whether NCoA could be used, only after which the MN must use NCoA on
the new link.
Immediately upon attaching to the NAR's link, the MN sends a
Router Solicitation message, in which it includes a Fast Neighbor
Advertisement (FNA) option. FNA includes the MN's PCoA and
link-layer addresses, and it serves to confirm the NCoA when FBACK
has not been received and in any case announces the MN's presence to
the NAR. As a response, the NAR sends a Router Advertisement with
Neighbor Advertisement Acknowledge (NAACK) option that indicates
whether the use of NCoA is acceptable.
It is worthwhile to observe, in the light of recent Return
Routability procedure for securing Binding Updates, that a
correspondent node rejects packets sent with NCoA until a valid
binding cache entry is established. Hence, it is highly desirable to
be able to continue using an address that exists in a correspondent's
binding cache until the new address can be updated. Furthermore,
such an update, accomplished through the Binding Update procedure,
itself should be expeditiously performed. Thus, the combined use
of tunneling (packets meant for PCoA) and anticipation (of NCoA) is
likely to offer performance benefits and will be elaborated in the
following sections.
The overall handover protocol is illustrated in Figure 2.
4. Protocol Details
There are three phases in the protocol operation: handover
initiation, tunnel establishment and packet forwarding on the
established tunnel. We describe each of these phases separately.
4.1. Handover Initiation
The handover initiation may occur while the MN is still attached to
the PAR, or it may take place after it attaches to the NAR.
4.1.1. Anticipation
Either the MN or the PAR may initiate a handover by sending protocol
messages defined in this document. External events, such as a
Koodli (Editor) Expires 1 September 2003 [Page 6]
Internet Draft Fast Handovers 1 March 2003
MN PAR NAR
| | |
|------RtSolPr------->| |
|<-----PrRtAdv--------| |
| | |
|------F-BU---------->|--------HI--------->|
| |<------HACK---------|
| <--F-BACK--|--F-BACK--> |
| | |
Disconnect | |
| forward |
| packets===============>|
| | |
| | |
Connect | |
| | |
RS (with FNA option)======================>|
|<-----------RA (with NAACK option)--------|
|<=================================== deliver packets
| |
Figure 2: Fast Handover Protocol Messages
determination at link layer to undergo handover or a policy decision
based on factors such as available bandwidth, cost etc, can cause
handover initiation. Such events oblige a MN to send a RtSolPr,
and the PAR to send a PrRtAdv (either in response to RtSolPr or
separately as a gratuitous message).
The RtSolPr message allows a MN to request the IP address, link-layer
address as well as network prefix of the NAR's interface to which the
MN may attach to. In a network-controlled handover, the PAR supplies
this information without the MN requesting it.
It is possible that the PAR itself may initiate handover by
gratuitously sending a PrRtAdv message. When the PAR sends such a
message without the MN sending a RtSolPr message first, the MN MUST
be prepared to process PrRtAdv message, and send an Fast Binding
Update message in response.
The PrRtAdv indicates one of the following possible conditions:
Koodli (Editor) Expires 1 September 2003 [Page 7]
Internet Draft Fast Handovers 1 March 2003
1. If the PAR does not have an entry corresponding to the new
attachment point, it MUST respond indicating that the new
point of attachment is unknown. The MN MUST stop fast handover
protocol operations on the current link. The MN MAY send an FBU
from its new link. See Section 4.2.
2. If the new point of attachment is connected to the PAR itself,
PAR MUST respond indicating that the point of attachment is known
but is connected to itself. This could happen, for example, when
the wireless access points are bridged into a wired network.
3. If the new point of attachment is known and the PAR has
information about it, then PAR MUST respond indicating that the
point of attachment is known. The message MUST contain the
new CoA that the MN should use or information on the network
prefix that should be used to form a new CoA. If the new point of
attachment is known, but does not support fast handover, the PAR
MUST indicate this with Code 3 (See Section 6.1.2).
4. If a wildcard is supplied as an identifier for the new point of
attachment, the PAR SHOULD supply neighborhood [AP, AR] tuples
subject to path MTU restrictions (i.e., provide any `n' tuples
without exceeding the link MTU).
The method by which Access Routers exchange information about
their neighbors and thereby allow construction of PrRtAdvs with
information about the new subnet is outside the scope of this
document. Furthermore, this document assumes that the access routers
share necessary security association established by means outside the
scope of this document.
The RtSolPr and PrRtAdv messages MUST be implemented by a MN and
an access router that supports fast handovers. However, when
the parameters necessary for the MN to send packets immediately
upon attaching to the NAR are supplied by the link layer handover
mechanism itself, the above messages are optional on such link
layers. See Section 4.5.
4.1.2. No Anticipation
Anticipating a handover is not always possible. Also, the interface
between the link-layer handover mechanism and IP stack may not be
well-defined or is available. In such cases, the MN may change
its link without engaging in protocol messages with the PAR on its
previous link. The MN SHOULD send a Fast Binding Update to the
PAR as soon as it establishes connectivity with the NAR. This FBU
message serves to establish a tunnel between the access routers.
Establishing tunnels subsequent to regaining a new link is useful,
Koodli (Editor) Expires 1 September 2003 [Page 8]
Internet Draft Fast Handovers 1 March 2003
for instance, in IEEE 802.11 wireless local area networks. See
Section 4.2.
4.2. Tunnel Establishment between the Access Routers
A bi-directional tunnel is established between the two access routers
for the following purpose. Since the MN cannot use NCoA until it
completes Binding Update with its Home Agent and the correspondents,
it is allowed to use PCoA until it establishes itself as a Mobile
IPv6 end-point. For this purpose, the NAR tunnels packets sent with
PCoA as source IP address to the PAR. And, until the correspondent
nodes establish a binding cache entry for NCoA, they continue to
send packets to PCoA, which need to be forwarded to the MN. The PAR
tunnels these packets to the NAR, which then forwards them using a
host route entry to the MN. Since it is desirable to deliver these
packets independent of NCoA configuration, the PAR tunnels packets to
the NAR instead of to the NCoA. However, the MN MAY include NCoA as
the target address for the tunnel.
The tunnel establishment is achieved through Handover Initiate (HI)
and Handover Acknowledge (HAck) messages. The PAR MUST send the HI
message to the NAR when PAR
1. determines through link-layer specific mechanisms that the MN is
attaching to NAR (See Section 4.5), or
2. receives an FBU message from a MN for which it has not previously
sent a HI message
The HI message contains the PCoA, link-layer address and the NCoA
(when known) of the MN. In response to processing the HI message, the
NAR
1. MUST create a host route for PCoA that allows it to forward
packets to the MN. This host route entry SHOULD be implemented
such that until the MN's presence is detected, either through
explicit announcement by the MN or by other means, arriving
packets do not invoke neighbor discovery.
2. MUST set up a tunnel for packets arriving with PCoA as source IP
address to be sent to PAR.
3. MUST verify if NCoA (when) supplied in the HI message is a valid
address for use, and if it is, it MUST also establish a proxy
neighbor cache entry for NCoA and begin defending it.
Koodli (Editor) Expires 1 September 2003 [Page 9]
Internet Draft Fast Handovers 1 March 2003
4. MUST allocate NCoA for the MN when stateful address configuration
is used, create a proxy neighbor cache entry and begin defending
it.
5. MUST provide the status of handover request in Handover
Acknowledge (HACK) message indicating whether the use of NCoA is
acceptable.
When the PAR receives HAck message, it completes the tunnel
establishment. In addition, the HAck message may also indicate
whether the use of NCoA is acceptable.
If the MN does not engage in protocol messages on its previous link
(for whatever reason(s)), it SHOULD send an FBU, with PCoA as source
IP address, as soon as it regains connectivity with the NAR. The NAR
SHOULD tunnel the FBU to the PAR subject to following considerations.
First, the ingress filtering rules allow packets sent with PAR's
prefix in a source address to be forwarded. Second, the destination
IP address is that of the PAR. Note that both these conditions must
be met for succesful completion of any HI and HAck message exchange
in any case.
When the PAR receives an FBU, it MUST send a HI message to the NAR.
Upon receiving a corresponding HACK message, the PAR MUST send FBACK
to the MN. Until the HACK is received, the PAR MAY buffer any packets
arriving for the MN. The New Access Router MUST NOT tunnel packets
from the MN with PCoA as source IP address destined for arbitrary
correspondent nodes to PAR until a HI message is received, and the
NAR MAY buffer any such packets.
If the MN does not receive an FBACK message even after
re-transmitting FBU for FBU_RX_TIMES, it MUST assume that
fast handover support is not available and it MUST stop fast handover
protocol operation.
When the tunnel is established after the MN attaches to the NAR,
there could be delay before packets are forwarded, and there could be
packet loss unless the access routers buffer packets. This delay and
potential packet loss could be avoided through anticipation.
4.3. Packet Forwarding
The MN SHOULD send a Fast Binding Update (FBU) message preferably
prior to disconnecting its link. Since a gratuitous PrRtAdv message
indicates network-controlled handover, the MN SHOULD send FBU
immediately as a response. The MN MUST use PCoA as its source IP
address in this message. If the MN is unable to send an FBU before
leaving the PAR, it SHOULD send it as soon as it regains connectivity
Koodli (Editor) Expires 1 September 2003 [Page 10]
Internet Draft Fast Handovers 1 March 2003
with the NAR. This allows the PAR to actually start tunneling packets
meant for the MN's PCoA. The MN SHOULD resend FBU if it has not
received an FBACK up to a maximum of FBU_RETRIES.
When the PAR receives an FBU, it must wait until the requested
handover is accepted by the NAR as indicated in the HACK message
status code. Then, it MUST verify that the source IP address in FBU
is PCoA for which PAR has forwarded packets previously. And, it
MUST create a tunnel for forwarding packets meant for PCoA to NAR.
Finally, it MUST send a Fast Binding Acknowledgment (FBACK) message
to the MN. This message SHOULD be sent on the old link as well.
As soon as the MN establishes link connectivity with the NAR, it
MUST send a Fast Neighbor Advertisement (FNA) message (See 6.1.3),
which is encoded as an option in the Router Solicitation message.
Only after it receives a confirmation to use NCoA in a Router
Advertisement with Neighbor Advertisement Acknowledge (NAACK)
option (See 6.5.4), the MN MUST use NCoA. If the MN has already
received confirmation to use NCoA via FBACK, it SHOULD include the
FNA option anyway to announce its presence to the NAR.
When it is acceptable to use NCoA corresponding to the FNA message,
the NAR MUST
1. delete the proxy neighbor cache entry.
2. create a neighbor cache entry and set its state to REACHABLE.
3. enable the host route entry so that any buffered packets could be
delivered.
4. send a router advertisement with Neighbor Advertisement Ack
(NAACK) option (See Section 6.5.4) confirming the use of NCoA.
When it is not acceptable to use NCoA, NAR MUST still send a router
advertisement with NAACK option in which it provides the error
code. The NAR MUST still enable the host route entry to deliver any
buffered packets. The MN MUST follow [6] in order to configure a new
IP address, and it should use the parameters supplied in the router
advertisement. Note that the MN is allowed to send packets using
PCoA during the time it is involved in confirming the use of NCoA.
Once the MN has confirmed its NCoA, it SHOULD send a Neighbor
Advertisement message. This message updates its neighbor's cache
entries with the MN's link-layer address.
Once the MN completes the Binding Update procedure with its
correspondent node(s), it SHOULD start using NCoA as its source IP
address. In any case, the bidirectional tunnel between the access
Koodli (Editor) Expires 1 September 2003 [Page 11]
Internet Draft Fast Handovers 1 March 2003
routers has a lifetime of BT_LIFETIME, after which time, packets
using PCoA as source IP address will be discarded unless there is
optional protocol support for tunnel lifetime renewal (See 4.5.1).
4.4. Three Party Handover
The MN may move from NAR to another AR (NAR') before completing
its Layer 3 handover and performing binding updates to its
correspondents. If the MN moves before configuring a NCoA on NAR,
PAR would still be considered its default router when it attaches
to NAR'. Hence, the MN SHOULD send an FBU to PAR to set up a tunnel
between PAR and NAR'. On the other hand, if the MN is able to
configure a NCoA on NAR, but is unable to update all or a partial
list of its correspondents, the MN MAY send an FBU to PAR. This FBU
may be in addition to the FBU it sends to NAR. The result in this
case is that the MN should be able to receive packets arriving at
PCoA and NCoA through potentially different tunnels. If the MN
returns to PAR without completing Mobile IPv6 updates, it MUST send
an FBU with lifetime set to zero so that PAR can disable any outgoing
tunnels.
The three party handover without IP signaling messages over the air
interface is described in Section 4.6.
4.5. Optimization using link-layer assisted features
In this section, we describe how the tunnel between the access
routers could be set up without IP signaling messages over
the air interface when the underlying link layer provides the
functionality of handover initiation messages defined in Section 4.1.
Specifically, a ``Source Link Layer Trigger'' or a ``Target Link
Layer Trigger'' could be used to initiate the HI and HAck exchange.
Note however, that actual packet forwarding takes place after an FBU
is processed. The exact time when packet forwarding begins, after
an FBU has been successfully processed, could make use of link-layer
triggers. The link layer triggers are described in [4].
We denote by L2-ST a Source Trigger at PAR prior to L2 handover, by
L2-TT a Target Trigger at NAR subsequent to L2 handover completion.
We also denote by L2-LD a Link Down trigger at PAR that indicates
when a link with the MN is terminated, and by L2-LU a Link Up trigger
at NAR that indicates that a MN has (just) established a new link.
The following diagram illustrates tunnel establishment without using
IP messages.
Koodli (Editor) Expires 1 September 2003 [Page 12]
Internet Draft Fast Handovers 1 March 2003
1a. L2-ST ~~~~> +------+ 2. HI +------+ <~~~ 1b. L2-TT
| PAR |<-------->| NAR |
4a. L2-LD~> +------+ 3. HACK +------+ <~~~ 4b. L2-LU
^ ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
4c. L2-LU ---> | MN | --------->
+------+
Figure 3: Tunnel Establishment without IP messages
The following describes the progress of a two party handover. The
numbered items refer to steps in Figure 3.
1. Either the PAR or NAR receives an L2 trigger informing it
that a certain MN is about to be moved. The two cases are:
a. The L2 trigger is a source trigger (L2-ST) at PAR. The
trigger contains the MN's L2 address and an IP identifier
(L2 address that can be mapped to an IP address or the IP
address directly) for NAR.
b. The L2 trigger is a target trigger (L2-TT) at NAR. The
trigger contains the MN's L2 address and an IP identifier
for PAR.
2. The AR receiving the trigger MUST send a HI to the other AR.
There two cases:
a. If PAR is sending the HI, the `H' bit MUST be set, indicating
it is based on source trigger. The HI MUST contain a
Lifetime option, an IP address option containing the MN's
PCoA, and an Link Layer Address (LLA) option containing the
MN's L2 address. The Lifetime option MUST contain the
amount of time the PAR is willing to extend tunnel service
to the MN's packets before the NAR must renew the tunnel. If
the lifetime is zero, the PAR is not willing to tunnel any
packets for MN.
Koodli (Editor) Expires 1 September 2003 [Page 13]
Internet Draft Fast Handovers 1 March 2003
b. If NAR is sending the HI, the `T' bit MUST be set, indicating
it is based on a target trigger. The HI MUST contain a
Lifetime option, and an LLA option containing the MN's L2.
The Lifetime option MUST contain
a request for the amount of time the PAR should extend
tunnel service for the MN's packets.
3. The AR receiving the HI MUST send a HAck to the other AR.
There are two cases:
a. If PAR is sending the HACK, the `T' bit MUST be set. The HAck
MUST contain a Lifetime option, an IP address option
containing the MN's PCoA, and an LLA containing the MN's L2
address. The Lifetime option MUST contain the amount of
time the oAR is willing to extend tunnel service to the
MN's packets before NAR must renew the request. If the
lifetime is zero, the PAR is not willing to extend tunnel
service to the MN.
b. If NAR is sending the HAck, the `H' bit MUST be set. No
additional information is required, the sequence number
identifies the reply.
4. Start of L2 handover is signaled by an L2-LD trigger at PAR
and MN. Completion of L2 handover is signaled by an L2-LU
trigger at NAR and MN. Each handles the trigger in the
following way:
a. When the PAR receives the L2-LD trigger, it MUST begin
forwarding MN-bound packets on the tunnel to NAR only if PAR
has successfully processed an FBU.
b. When the NAR receives the L2-LU trigger, it MUST begin
delivering packets to the MN and MUST forward any outbound
packets from MN through the tunnel to PAR.
c. Subsequent to establishing a new link, the MN SHOULD configure a
NCoA. The MN MAY defer obtaining a NCoA, however, using PCoA after the
tunnel lifetime expires would result in packet discarding unless an
optional protocol support for extensing the tunnel lifetime is
implemented.
5. The PAR becomes an AAR if MN should move again without having
changed CoA to NAR's subnet, PCoA becomes ACoA, and NAR
becomes PAR.
6. Should L2 handover fail in Step 4 and a ping-pong situation
arise, the PAR MUST cancel the tunnel by sending an HI with R
bit set to NAR and a Lifetime option having value zero. In
Koodli (Editor) Expires 1 September 2003 [Page 14]
Internet Draft Fast Handovers 1 March 2003
this case, the PAR simply continues delivering packets to MN
on the old link exactly as if no handover had been pending.
The tunnel between the access routers is terminated when BT_LIFETIME
expires. However, the following protocol in Section 4.5.1 can be
used to renew the tunnel lifetime.
4.5.1. Renewing Tunnel Lifetime
The support for protocol described in this section is optional.
In order to extend the lifetime of the tunnel, the NAR MUST send a
HI message including a proposed new lifetime to PAR, and PAR MUST
reply with a HAck indicating whether the tunnel can be extended.
An error code of 131 is returned if extension is not possible (See
Section 6.2.2). In order to terminate the tunnel, either PAR or NAR
MUST send a HI message with a lifetime of zero. The default tunnel
lifetime is BT_LIFETIME. NAR SHOULD send a tunnel renewal message
prior to the expiration of BT_LIFETIME_WARNING, in order that the
MN has sufficient time to complete NCoA configuration. Whether or
not the tunnel lifetime can be extended and how many times it can
be extended is subject to network operator policy and SHOULD be
configurable.
When a tunnel can no longer be renewed upon the expiration of
BT_LIFETIME_WARNING, the NAR MUST send the MN an unsolicited Router
Advertisement in the event it must terminate the tunnel for any
reason prior to the MN's configuring it's NCoA. The MN SHOULD
initiate NCoA configuration immediately upon receipt of the RA, or
risk losing forwarding service to PCoA.
4.6. Three Party Handover with Layer 2 Trigger Support
The support for protocol described in this section is optional.
Three party handover occurs when the MN is on AAR, then moves to PAR,
then moves to NAR before completing MIP registration at PAR. The lack
of MIP registration may result from either a specific decision by
the MN due to an ongoing real time media stream, or it may result
from rapid movement between PAR and NAR that does not allow enough
time for the registration to complete. This situation is shown in
Figure 4 below. In this case, PAR must inform NAR to contact AAR
about moving the radio directed end of the tunnel. This is performed
with the Handover To Third (HTT) message.
Koodli (Editor) Expires 1 September 2003 [Page 15]
Internet Draft Fast Handovers 1 March 2003
+------+
+--->| AAR |<---+
| +------+ |
4b. HI(r) | | 3. HI(t)
HACK (r) | | HACK(t)
| |
v 2a. HI v
1a. L2-ST ~~~> +------+ HTT +------+ <~~~ 1b. L2-TT
| PAR |<-------->| NAR |
4a. L2-LD ~~~> +------+ 2b. HTT +------+ <~~~ 5a. L2-LU
^ HACK ^
old L2 | | new L2
+-------+ +-----+
| |
| |
V V
+------+ movement
5b. L2-LU ~~~> | MN | --------->
+------+
Figure 4: Three Party Handover with L2 Triggers
The general idea behind the three party handover procedure is that
the PAR supplies NAR with the same information it would have obtained
via an L2-TT if handover had occurred with AAR, then the NAR performs
an HI/HACK sequence with AAR in order to move the BT to NAR. When the
L2 handover is complete, PAR sends an HI to AAR to terminate the BT.
The following describes the progress of a three party handover. The
numbered items refer to steps in Figure 4.
1. Either the PAR or NAR receives an L2 trigger informing it
that a certain MN is about to be moved. The two cases are:
a. The L2 trigger is a source trigger (L2-ST) at PAR. The
trigger contains the MN's L2 address and an IP identifier
(L2 address that can be mapped to an IP address or the IP
address directly) for NAR.
b. The L2 trigger is a target trigger (L2-TT) at NAR. The
trigger contains the MN's L2 address and an IP identifier
for PAR.
2. The PAR and NAR exchange a HTT/HI or HACK/HTT pair. There are
two cases:
Koodli (Editor) Expires 1 September 2003 [Page 16]
Internet Draft Fast Handovers 1 March 2003
a. The L2 trigger is an L2-ST. The PAR MUST send HTT to NAR
containing the IP address of AAR and two LLAs. The first
LLA MUST contain the L2 address of the MN, the second MUST
contain the L2 address of the AAR. This is enough
information for NAR to perform a target trigger handover
with AAR. The NAR MUST respond with a HACK.
b. The L2 trigger is an L2-TT. The NAR MUST send a HI to PAR,
exactly as if a two party target triggered handover were
occurring. The PAR MUST responds with HTT containing the IP
address of AAR and two LLAs. The first LLA MUST contain the
L2 address of the MN, the second MUST contain the L2
address of the AAR. This is enough information for NAR to
perform a target trigger handover with AAR.
3. The NAR MUST first check its routing tables to see whether
it is already tunneling for MN. If so, Step 6 is performed.
If not, NAR MUST perform a target trigger handover with AAR,
exactly as in Section 3.3, exchanging a HI/HACK pair. Because
AAR receives no L2 trigger indicating when to start handover,
it MAY place the BT to NAR upon transmission of the HACK, or
alternatively it MUST wait to establish the BT with NAR
until PAR signals that L2 handover has begun in Step 4.
4. At the start of L2 handover, AAR and PAR exchange messages
canceling tunnel service between AAR and PAR and allowing AAR
to start the tunnel with NAR.
a. The start of L2 handover is signaled at PAR by L2-LD.
b. The PAR MUST exchange a HI/HACK pair with AAR with a
Lifetime option having value zero. This cancels tunnel
service between PAR and AAR. If AAR has not already placed
a BT to NAR, it MUST do so immediately upon receipt of the
HI.
5. Completion of L2 handover is signaled by an L2-LU trigger at
NAR and MN. The NAR and MN handle the trigger in the
following ways:
a. The NAR MUST begin delivering packets to the MN, and
MUST tunnel any CN-bound packets from the MN to aFA.
b. Based on its current movement and traffic pattern, MN MAY
either defer obtaining a nCoA or begin the process of
obtaining an nCoA.
6. In the special case where NAR and AAR are the same, AAR
Koodli (Editor) Expires 1 September 2003 [Page 17]
Internet Draft Fast Handovers 1 March 2003
recognizes that it is tunneling to PAR when it checks its
routing tables in Step 3. In this case, there is no need for
AAR to send the HI/HACK with itself in Step 3. Upon receipt
of the L2-LU trigger on handover completion, the AAR MUST
begin routing packets directly to MN and the tunnel to NAR
MUST be torn down. The AR MUST still exchangesthe HI/HACK
with PAR in Step 4b because PAR can't know a priori that AAR
and NAR are the same, but AAR MUST NOT need not gate old
tunnel tear down or delivery of MN packets on this exchange.
Unlike two party handover, the timing of BT establishment between
AAR and NAR cannot fully depend on the availability of L2 trigger
information because AAR does not receive an L2 trigger when L2
handover begins. The two timing extremes at which AAR can place the
BT with NAR are:
1. At the earliest, AAR MAY establish the BT with PAR after
sending the HACK(t) to NAR in response to the request for
target-triggered handover,
2. At the latest, AAR MUST establish the BT with NAR and tear
down the BT with PAR when receiving the HI(r) from PAR
indicating the L2 handover has begun.
In addition, AAR MAY contine tunnel service with PAR if 1) is
selected, until the HI is received. If 1) is selected and the AAR
continues to tunnel to PAR, the result may be duplicated packets at
the MN, because the MN will receive packets through PAR on the old L2
until L2 handover begins. If 2) is selected, the additional latency
of the HI added to the L2 handover latency may result in additional
packets being dropped while the MN is not receiving L3 networking
service. Of course, AAR can choose to place the BT some time between
1) and 2) if the network can give reasonable bounds. The exact
selection of when to establish the BT is likely to be influenced by
network engineering and implementation considerations, including
whether a handover smoothing solution is deployed, and is beyond the
scope of this specification.
Figure 5 and Figure 6 show timing diagrams for source trigger (L2-ST)
and target trigger (L2-TT) three party handover, respectively in
order to further illustrate the protocol shown in Figure 4.
Koodli (Editor) Expires 1 September 2003 [Page 18]
Internet Draft Fast Handovers 1 March 2003
MN NAR PAR AAR
| | | |
| | L2-ST ~~~~~> | |
| | | |
| |<-------------| |
| | HTT | |
| |------------->| |
| | HACK(s) | |
| | | |
| |------------------------------>|
| | HI(t) | |
| | | |
| |<------------------------------|
| | HACK(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handover | HI(r) |
| |
|<---------------|
| HACK(r) |
| |
----------------------------------<~~~ L2-LU |
| | | |
|<-------------->| | |
| MN's traffic | | |
| on aCoA | | |
| | | |
Figure 5: Three Party Source Trigger Handover Timing
5. Other Considerations
5.1. Handover Capability Exchange
A MN, when it attaches to its access router needs to know whether the
access router supports fast handover. Similarly, the access router
needs to know whether the MN is capable of fast handover protocol.
For this purpose, a new Hanodver Capability Extension is defined.
See Section 6.5.5. The MN MUST include this extension in a Router
Solicitation message if it supports fast handover protocol. The
access router MUST include the extension in the corresponding Router
Advertisement if it supports the fast handover protocol.
Koodli (Editor) Expires 1 September 2003 [Page 19]
Internet Draft Fast Handovers 1 March 2003
MN NAR PAR AAR
| | | |
| |<~~~ L2-TT | |
| | | |
| |------------->| |
| | HI(t) | |
| |<-------------| |
| | HTT | |
| |------------------------------>|
| | HI(t) | |
| | | |
| |<------------------------------|
| | HACK(t) | |
| | | |
----------------------------------<~~~ L2-LD |
|--------------->|
L2 Handover | HI(r) |
| |
|<---------------|
| HACK (r) |
| |
----------------------------------<~~~ L2-LU |
| | | |
|<-------------->| | |
| MN's traffic | | |
| on aCoA | | |
Figure 6: Three Party Target Trigger Handover Timing
The access router MUST NOT send a gratuitous PrRtAdv message if the
MN does not include the Handover Capability Extension. If the Router
Advertisement does not include the Handover Capability Extension, the
MN MUST not send a RtSolPr message.
Even if a MN's current access router is capable of fast handover,
the access router into which the MN is handing over to may not
be capable of fast handover. This is indicated to the MN during
``runtime'', through the PrRtAdv message with a Code value of 3. See
Section 6.1.2.
Koodli (Editor) Expires 1 September 2003 [Page 20]
Internet Draft Fast Handovers 1 March 2003
5.2. Determining New Care of Address
When stateless address configuration is used, the PAR MUST formulate
NCoA using the MN's interface identifier and the NAR's subnet prefix
according to [6] and include NCoA in the HI message. The New Access
Router MUST verify that NCoA is unique before beginning to defend
that address. If the address is not unique, a status code in the
required HACK message indicates it. And, PAR MUST convey that the
proposed NCoA is not acceptable to MN in the FBACK message.
If stateful address configuration is being used, NCoA is returned
by the NAR, instead of being proposed by the PAR. The HI and HACK
message exchange precedes the transmission of PrRtAdv from the PAR to
the MN, because NAR allocates the new IP address. The rest of the
process is identical to the stateless approach.
If the MN is unable to use anticipation to form a NCoA when attached
to PAR, it SHOULD begin the process of configuring its NCoA as soon
as it determines that it has moved to NAR. The NCoA configuration
process follows either stateless (which could include DAD) or
statefull IPv6 address configuration procedure. In order to use
NCoA with its correspondents however, the MN has to first send a BU
to its Home Agent, and perform return routability prior to sending
BU to its correspondents with which the MN is interested in route
optimization. These steps are specified in [3]. The MN MAY defer
NCoA configuration for some period of time if the MN's traffic
conditions or movement patterns do not allow it to perform NCoA
configuration. An example of such a condition is if the MN would
be required to linger on the link solely in order to complete NCoA
configuration.
If the MN moves to another AR before completion of CoA configuration,
either during the configuration process or prior to beginning the
process, the considerations in Section 4.4, and Section 4.6 apply.
In particular, if protocol support specified in Section 4.6 is
available, the NAR SHOULD arrange for the MN's tunnel to be handed
over to the MN's next destination router.
The NAR MUST send the MN an unsolicited RA in the event it must
terminate the tunnel for any reason prior to the MN's configuring
it's NCoA. The MN SHOULD initiate NCoA configuration immediately upon
receipt of the RA, or risk losing forwarding service to PCoA.
5.3. Packet Loss
Handover involves link switching. It is understandably difficult
to exactly co-ordinate fast handover signaling with link switching.
Furthermore, arrival pattern of packets is dependent on many factors,
Koodli (Editor) Expires 1 September 2003 [Page 21]
Internet Draft Fast Handovers 1 March 2003
including application characteristics, network queuing behavior etc.
Hence, packets may arrive at NAR before the MN is able to attach to
it. These packets will be lost unless they are buffered by the NAR.
Similarly, if the MN attaches to NAR and then sends an FBU message,
packets arriving at PAR will be lost unless they are buffered. This
protocol provides an option to indicate request for buffering at the
NAR in the HI message. When the PAR does request this feature, it
SHOULD also provide its own support for buffering.
5.4. DAD Handling
Duplicate Address Detection (DAD) was defined in [6] to avoid address
duplication on links when stateless address auto- configuration is
used. The use of DAD to verify the uniqueness of an IPv6 address
configured through stateless autoconfiguration may add delays to a
MIPv6 handover.
The probability of an interface identifier duplication on the
same subnet is very low, however it can not be ignored. In this
draft certain precautions are proposed to minimize the effects of
a duplicate address occurrence. On links wherein the uniqueness
of the interface identifier is ensured within the subnet (by means
beyond the scope of this document), DAD handling procedures SHOULD be
avoided.
In some cases the NAR may already have the knowledge required to
assess whether the MN's address is a duplicate or not before the MN
moves to the new subnet. For example, the NAR can have a list of all
nodes on its subnet, perhaps for access control, and by searching
this list, it can confirm whether the MN's address is a duplicate
or not. The result of this search is sent back to the PAR in the
HACK message. If such knowledge is not available at the NAR, it may
indicate this by not confirming NCoA in the HACK message. In such
a case, the MN would have to follow stateless address configuration
rules after attaching to the NAR. Since this specification allows the
MN to continue to use PCoA, the delay due to DAD is not a concern.
However, the transmission epoch of Binding Update to the Home Agent
will be delayed.
5.5. Fast or Erroneous Movement
Although this specification is for fast handover, the protocol has
its limits in terms of how fast a MN can move. A special case
of fast movement is ping-pong, where a MN moves between the same
two access points rapidly. Another instance of the same problem
is erroneous movement i.e., the MN receives information prior to
a handover that it is moving to a new access point and but it is
Koodli (Editor) Expires 1 September 2003 [Page 22]
Internet Draft Fast Handovers 1 March 2003
either moved to a different one or it aborts movement altogether.
All of the above behaviors are usually the result of link layer
idiosyncrasies and thus are often tackled at the link layer itself.
IP layer mobility, however, introduces its own limits. IP layer
handovers should be in a frequency that allows enough time for the
MN to update the binding of, at least, its HA and preferably that
of every CN with which it is in communication. A MN that moves
faster than necessary for this signaling to complete may start losing
packets and ultimately connectivity. The signaling overhead over
the air and in the network may increase significantly, especially in
the case of rapid movement between two access routers. To avoid the
signaling overhead, the following measures are suggested.
A MN returning to the PAR before updating the necessary bindings
in the NAR MUST send a Fast Binding Update with Home Address equal
to the MN's PCoA and a lifetime of zero, to the PAR. The MN should
have a security association with the PAR since it performed a
fast handover from it to the NAR. The PAR, on receiving this Fast
Binding Update, will check its set of outgoing (temporary fast
handover) tunnels and if it finds a match it SHOULD drop that tunnel;
i.e., stop forwarding packets for this MN and start delivering
packets directly to the node instead. The MN SHOULD NOT make any
attempt to use any of the fast handover mechanisms described in this
specification and SHOULD revert back to standard Mobile IPv6.
Temporary tunnels for the purposes of fast handovers should use short
lifetimes (in the order of a small number of seconds or less). The
lifetime of such tunnels should be enough to allow a MN to update
all its active bindings. A long life times increases the chance of
a circular tunnel from PAR to NAR and back again to PAR which could
essentially result in a routing loop, especially if the PCoA is used
with tunnels between ARs themselves, rather than forwarding to NCoA.
Erroneous movement is not likely to damage the network but it may
cause loss of packets since routing can change and the PAR may
forward packets towards another AR before the MN actually connects to
that AR. If the MN discovers itself on the wrong AR, a Fast Binding
Update to the PAR SHOULD be sent. Since Fast Binding Updates are
authenticated, they MUST supersede the existing binding and packets
SHOULD be redirected to the new confirmed location of the MN. No
attempt should be made to recover packets from the AR the MN was
supposed to connect to.
Koodli (Editor) Expires 1 September 2003 [Page 23]
Internet Draft Fast Handovers 1 March 2003
6. Message Formats
6.1. New Neighbor Discovery Messages
6.1.1. Router Solicitation for Proxy
Mobile Nodes send Router Solicitation for Proxy in order to prompt
routers for Proxy Router Advertisements. For all the ICMP messages,
the checksum is defined in [2].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: Router Solicitation for Proxy (RtSolPr) Message
IP Fields:
Source Address
An IP address assigned to the sending interface
Destination Address
The address of the Access Router or the all routers
multicast address.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type TBA
Koodli (Editor) Expires 1 September 2003 [Page 24]
Internet Draft Fast Handovers 1 March 2003
Code 0
Checksum The ICMP checksum.
Identifier MUST be set by the sender so that replies can be
matched to this Solicitation.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Source link-layer address
The link-layer address of the sender, if known.
It SHOULD be included on link layers that have
addresses.
New Attachment Point Link-Layer Address
The link-layer address or identification of the
attachment point for which the MN requests routing
advertisement information. It MUST be included
in all RtSolPr messages. This can be a wildcard
address with all bits set to zero.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the rest of the message.
A MN sends this message if it wishes to initiate fast handover. It
indicates its destination with the New Attachment Point Link-Layer
Address. A Proxy Router Advertisement message should be received in
response. If such a message is not received in a short time period
but no less than twice the typical round trip time (RTT) over the
access link or 100 ms if RTT is not known, it SHOULD resend RtSolPr
message at most twice, waiting for the same time during each instance
of retransmission. If Proxy Router Advertisement is not received by
the time the MN disconnects from the PAR, the MN SHOULD attempt to
send FBU as described in Section 4.2.
6.1.2. Proxy Router Advertisement (PrRtAdv)
Access routers send out Proxy Router Advertisement message
gratuitously if the handover is network-initiated or as a response to
RtSolPr message from a MN.
IP Fields:
Koodli (Editor) Expires 1 September 2003 [Page 25]
Internet Draft Fast Handovers 1 March 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-
Figure 8: Proxy Router Advertisement (PrRtAdv) Message
Source Address
MUST be the link-local address assigned to the
interface from which this message is sent.
Destination Address
The Source Address of an invoking Router
Solicitation for Proxy or the address of the node
the Access Router is instructing to handover.
Hop Limit 255
Authentication Header
If a Security Association for the IP Authentication
Header exists between the sender and the
destination address, then the sender SHOULD include
this header.
ICMP Fields:
Type TBA
Code 0, 1, or 2
Checksum The ICMP checksum.
Identifier Copied from Router Solicitation for Proxy or set to
Zero if unsolicited.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Koodli (Editor) Expires 1 September 2003 [Page 26]
Internet Draft Fast Handovers 1 March 2003
Valid Options:
Source link-layer address
The link-layer address of the sender, if known.
It SHOULD be included on link layers that have
addresses.
Link-layer address of proxied originator (i.e., NAR)
The link-layer address of the Access Router for
which this message is proxied for. This option MUST
be included when Code is 0.
New Router Prefix Information Option.
These options specify the prefixes of the Access
Router the message is proxied for and are used
for address autoconfiguration. This option SHOULD be
included when Code is 0.
New CoA Option
In stateful configuration, this option MUST be sent
to allocate an address on behalf of the Access
Router this message is proxied for (i.e.,NAR).
In stateless address auto-configuration this option
MAY be present.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the message.
A Proxy Router Advertisement with Code 0 but without a New CoA Option
means that the MN SHOULD construct a NCoA out of its Interface ID
(used in the Destination Address in this Proxy Router Advertisement)
and the Prefix in the New Router Prefix Information Option (See
Section 6.5.2. A Proxy Router Advertisement with Code 0 and a New
CoA Option means that the MN SHOULD use the CoA indicated as a NCoA
at the NAR. The New CoA MUST be used when Stateful CoA configuration
is indicated and MAY be used to assist the PAR and MN calculate the
same NCoA when Stateless address configuration is used.
A Proxy Router Advertisement with Code 1 is sent if handover to the
New Attachment Point, as indicated by the New Attachment Point Link
Layer address in the corresponding RtSolPr message, does not require
change of CoA. No options are required in this case.
A Proxy Router Advertisement with Code 2 means that the PAR is not
aware of the Prefix Information requested. The MN SHOULD attempt to
Koodli (Editor) Expires 1 September 2003 [Page 27]
Internet Draft Fast Handovers 1 March 2003
send FBU as soon as it regains connectivity with the NAR. Processing
of such a FBU follows the description in Section 4.2. No options are
required in this case.
A Proxy Router Advertisement with Code 3 means that the NAR does
not support fast handover. The MN MUST stop fast handover protocol
operations. No options are required in this case.
When a wildcard AP identifier is supplied in the RtSolPr message,
the PrRtAdv message should include any 'n' [Access Point Identifier,
Link-layer address option, Prefix Information Option] tuples
corresponding to the PAR's neighborhood.
6.1.3. Fast Neighbor Advertisement (FNA)
A MN sends a Fast Neighbor Advertisement to announce itself to the
NAR. This message is encoded as an IPv6 address option (see 6.5.1) in
the Router Solicitation message, in which the PCoA is sent.
Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize and
continue processing the rest of the message.
The MN sends Fast Neighbor Advertisement to the NAR, as soon as it
gains connectivity on the new link. The Fast Neighbor Advertisement
is sent because the MN is still unsure about the NCoA it should be
using on its new link. Using PCoA and the MN's link-layer address,
the NAR checks its host route entry and proxy neighbor cache. The
NAR SHOULD enable the host route entry so that packets sent to PCoA
can be forwarded. If a proxy neighbor cache entry is found, the NAR
SHOULD create a neighbor cache entry, set it to REACHABLE state and
then delete the proxy neighbor cache entry. In any case, the NAR
MUST send a Router Advertisement to PCoA as destination address with
NAACK option(See Section 6.5.4). The NAACK option indicates if it is
acceptable to use NCoA or not. When use of NCoA is not acceptable,
the MN MUST fallback to IPv6 address configuration.
6.2. Inter-Access Router Messages
6.2.1. Handover Initiate (HI)
The Handover Initiate (HI) is a new ICMPv6 message sent by an Access
Router (typically PAR) to another Access Router (typically NAR) to
initiate the process of a MN's handover.
IP Fields:
Koodli (Editor) Expires 1 September 2003 [Page 28]
Internet Draft Fast Handovers 1 March 2003
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |S|U|H|T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 9: Handover Initiate (HI) Message
Source Address
The IP address of the PAR
Destination Address
The IP address of the NAR
Hop Limit 255
Authentication Header
A Security Association MUST exist between the
sender and the receiver of this message. This
message MUST be authenticated and so the authentication
header MUST be used when this message is sent.
ICMP Fields:
Type TBA
Code 0
Checksum The ICMP checksum.
Identifier MUST be set by the sender so replies can be matched
to this message.
S Stateful address configuration flag. When set, this
message requests a new CoA to be returned by the
destination.
U Buffer flag. When set, the destination SHOULD buffer
Koodli (Editor) Expires 1 September 2003 [Page 29]
Internet Draft Fast Handovers 1 March 2003
any packets towards the node indicated in the options
of this message.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
Link-layer address of MN
The link-layer address of the MN that is
undergoing handover to the destination. This option
SHOULD be included to help the destination
recognize the MN when it connects to the
destination.
Previous Care of Address
The IP address used by the MN while
attached to the originating router. This option
MUST be included so that packets sent to PCoA can
always be redirected to NAR.
New Care of Address
The IP address the MN wishes to use when
connected to the destination. Used in stateless
configuration to request NAR to confirm whether the
MN can use this address. When the `S' bit is zero,
and if this option is not present, it indicates that
the MN is not anticipating a new CoA through this
message. This is useful when PAR has to initiate a HI
after the MN attaches to NAR and sends FBU.
In addition, the following additional flags in the Reserved field are
present and the Lifetime option MAY be present when the tunnel is
established using the link layer triggers. The default lifetime for
the bidirectional tunnel between the access routers is BT_LIFETIME.
H Set if the message was triggered by an L2-ST in
a two party handover. All other bits are unset.
T Set if the message was triggered by an L2-TT.
All other bits are unset.
R Set if a request to extend or cancel tunnel
service. All other bits are unset.
Lifetime Option
The lifetime, in seconds, for which the requester
would like tunnel service extended. If the field is
Koodli (Editor) Expires 1 September 2003 [Page 30]
Internet Draft Fast Handovers 1 March 2003
zero, the request is to cancel tunnel service. If
the field is 0xffffffff, the request is for infinity.
If Handover Acknowledge (HACK) message is not received as a response,
the Handover Initiate SHOULD be resent up to HI_RETRIES times using a
short retransmission timer with a value no less than twice the round
trip time between source and destination or 100 ms if RTT is not
known. Failure to receive a Handover Acknowledgment means that no
fast handover can be performed (See Section 4.2).
6.2.2. Handover Acknowledge (HACK)
The Handover Acknowledgment message is a new ICMPv6 message that MUST
be sent (typically by NAR to PAR) in reply to the Handover Initiate
message.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier |H|T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 10: Handover Acknowledge (HAck) Message
IP Fields:
Source Address
Copied from the destination address of the Handover
Initiate Message to which this message is a
response.
Destination Address
Copied from the source address of the Handover
Initiate Message to which this message is a
response.
Koodli (Editor) Expires 1 September 2003 [Page 31]
Internet Draft Fast Handovers 1 March 2003
Hop Limit 255
Authentication Header
A Security Association MUST exist between the
sender and the receiver of this message. This message
MUST be authenticated and so the authentication
header MUST be used when this message is sent.
ICMP Fields:
Type TBA
Code
0: Handover Accepted, NCoA valid
1: Handover Accepted, NCoA not valid
2: Handover Accepted, NCoA in use
3: Handover Accepted, NCoA assigned (Stateful)
4: Handover Accepted, NCoA not assigned (Stateful)
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
131: Tunnel Lifetime Renewal failed
Checksum The ICMP checksum.
Identifier Copied from the corresponding field in the Handover
Initiate message this message is in response to.
Reserved MUST be set to zero by the sender and ignored by
the receiver.
Valid Options:
New Care of Address
If the S flag in the Handover Initiate message is set,
this option MUST be used to provide NCoA the MN should
use when connected to this router.
In addition, the following flags are present Lifetime option MAY be
present when using link layer triggers. The default lifetime for the
bidirectional tunnel between the access routers is BT_LIFETIME.
H Set if in response to HRqst(s) in a two party
handover. All other bits are unset.
T Set if in response to an HRqst(t) in a two party
handover, or when sent by aAR in a three party
handover. All other bits are unset.
Koodli (Editor) Expires 1 September 2003 [Page 32]
Internet Draft Fast Handovers 1 March 2003
R Set if in response to a HRqst(r). All other bits
are unset.
Lifetime Option
The lifetime, in seconds, for which the sender is
willing to grant tunnel service. If the field is zero,
the request for tunnel service is denied. If the field
is 0xffffffff, the tunnel service is guaranteed until
canceled.
Upon receiving the HI message, the NAR MUST respond with a Handover
Acknowledge message. If the `S' flag is set in the HI message, the
NAR SHOULD include the New Care of Address option and a Code of 3.
If the `S' flag is not set in the HI message, the NAR MUST check the
validity of the NCoA when sent with HI, and reply with appropriate
Code values enumerated above. If NCoA is valid, the NAR SHOULD
insert NCoA in its Proxy Neighbor Cache and defend NCoA for
PROXY_ND_LIFETIME period of time during which the MN is expected to
connect to NAR. If the NCoA is not valid or not assigned, the NAR
MUST respond with an appropriate Code value.
If the `S' flag is not set and NCoA is not present, it indicates that
the PAR is requesting NAR to neither verify NCoA nor allocate one.
In any case, the NAR MUST establish a host route entry for PCoA and
set up a tunnel to the PAR to forward MN's packets sent with PCoA as
source IP address. This host route entry SHOULD be used to forward
packets once the NAR detects that the particular MN is attached to
its link.
Finally, the new access router can always refuse handover, in which
case it should indicate the reason in one of the available Code
values.
6.3. Handover To Third (HTT)
This is a message used in the optional Three Party Handover protocol
described in Section 4.6.
HTT message is an extension of both HI and HACK. If HTT is triggered
by an L2-ST, then it is an extension of HI. If HTT is sent in
response to an HI with T bit set, then it is an extension of the
HACK. The message can be distinguished as an HTT because it has
both the H and T bits set regardless of whether it is received as a
request or sent as a reply. No other bits are set in HTT.
Koodli (Editor) Expires 1 September 2003 [Page 33]
Internet Draft Fast Handovers 1 March 2003
In addition, the HTT MUST contain the following options in the
specified order:
Valid Options:
IP Address Option containing AAR's Address.
LLA Option containing the L2 address of the MN.
LLA Option containing the L2 address of AAR.
6.4. New Mobility Header Messages
Note: the format of these messages is dependent on [3].
Mobile IPv6 uses a new IPv6 header type called Mobility Header [3].
The Fast Binding Update and Fast Binding Acknowledgment messages both
use the Mobility Header.
6.4.1. Fast Binding Update (FBU)
The Fast Binding Update message is identical to the Mobile IPv6
Binding Update (BU) message. However, the processing rules are
slightly different. The Mobility Header Type value for FBU is 8.
IP fields:
Source address The PCoA
Destination Address
The IP address of the Previous Access
Router
`A' flag MUST be set to one to request PAR to send a Fast
Binding Acknowledgement message.
`H' flag MUST be set to one. See [3].
`S' flag See [3].
`D' flag
SHOULD be set to zero (since ``home address'' is
the address in use (i.e., PCoA).
Reserved This field is unused. MUST be set zero.
Koodli (Editor) Expires 1 September 2003 [Page 34]
Internet Draft Fast Handovers 1 March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Fast Binding Update (FBU) Message
Sequence Number
A 16-bit number used by the receiving node
to sequence Fast Binding Updates and by the
sending node to match a returned Fast Binding
Acknowledgment with this Fast Binding Update.
Each Fast Binding Update sent by a mobile node
MUST use a Sequence Number greater than the
Sequence Number value sent in the previous Fast
Binding Update (if any) to the same destination
address (modulo 2**16, as defined in [3]). The
processing rules for this field are the same as
those described in [3].
Lifetime
32-bit unsigned integer. The number of seconds
remaining before the binding MUST be considered
expired. A value of all one bits (0xffffffff)
indicates infinity. A value of zero indicates
Koodli (Editor) Expires 1 September 2003 [Page 35]
Internet Draft Fast Handovers 1 March 2003
that the binding for the mobile node MUST be
deleted.
Home Address The Previous Care of Address.
Mobility Options
MUST contain alternate CoA option set to NAR's IP
address.
The MN MUST send a FBU message after receiving a PrRtAdv message. If
the MN moves prior to receiving a PrRtAdv message, it SHOULD send a
FBU to the PAR.
Since the source IP address in FBU is PCoA, then the Home Address
field is redundant. In addition, if FBU is sent after PrRtAdv
is received, PAR can determine the target address for traffic
redirection, namely the NAR's IP address from the HI and HACK
sequence. Since both of these addresses can be inferred, these
fields MAY be omitted in a FBU message providing that a PrRtAdv
message has been received. The absence of these fields can be
determined by observing the Option Length value in the Mobility
Header. The Previous Access Router SHOULD process a FBU that does
not contain these fields.
A FBU message MUST be protected in a way appropriate for MN and PAR
communication. That is, PAR MUST be able to determine that the FBU
message is sent by a genuine MN.
6.4.2. Fast Binding Acknowledgment (FBACK)
The Fast Binding Acknowledgment message is sent by the PAR to
acknowledge receipt of a Fast Binding Update message in which the `A'
bit is set. The Fast Binding Acknowledgment message MUST NOT be sent
to the MN before the PAR receives a Handover Acknowledge message from
the NAR. If HACK contains a validation of NCoA, FBACK MUST be sent
with the MN's PCoA as the destination address with a status code 0.
The Fast Binding Acknowledgment MAY also be sent to the MN on the old
link. The Mobility Header Type value for FBACK is 9.
IP fields:
Source address The IP address of the Previous Access
Router
Destination Address The PCoA
Status
8-bit unsigned integer indicating the
Koodli (Editor) Expires 1 September 2003 [Page 36]
Internet Draft Fast Handovers 1 March 2003
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Fast Binding Acknowledgment (FBACK) Message
disposition of the Fast Binding Update. Values
of the Status field less than 128 indicate that
the Binding Update was accepted by the receiving
node. The following such Status values are
currently defined:
0 Fast Binding Update accepted
1 Fast Binding Update accepted but nCOA is
invalid
Values of the Status field greater than or equal
to 128 indicate that the Binding Update was
rejected by the receiving node. The following
such Status values are currently defined:
128 Reason unspecified
129 Administratively prohibited
130 Insufficient resources
131 Incorrect interface identifier length
Reserved An unused field. MUST be set to zero.
Sequence Number Copied from FBU message for use by the MN in
matching this acknowledgment with an outstanding
FBU.
Koodli (Editor) Expires 1 September 2003 [Page 37]
Internet Draft Fast Handovers 1 March 2003
Lifetime
The granted lifetime in seconds for which the
sender of this message will retain a binding for
traffic redirection.
Mobility Options Currently, none specified.
6.5. New ICMP Options
6.5.1. IP Address Option
This option is sent in the Proxy Router Advertisement, the Handover
Initiate, Handover Acknowledge and FNA messages. The Proxy Router
Advertisement and Handover Acknowledgment messages only contain the
NCoA while the Handover Initiate message may include both NCoA and
PCoA. The FNA message includes the PCoA only. The format is based
on [5].
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 | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPv6 Address Option
Type
TBA
Length
size of this option units of 8 octets (i.e., 3)
Koodli (Editor) Expires 1 September 2003 [Page 38]
Internet Draft Fast Handovers 1 March 2003
Sub-Type
1 Old Care-of Address
2 New Care-of Address
Prefix Length
The Length of the IPv6 Address Prefix
IPv6 address
The IP address for the unit defined by the Type field.
6.5.2. New Router Prefix Information Option
This option is sent in the PrRtAdv message in order to provide the
prefix information valid on the NAR.
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 | Length | Sub-Type | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: New Router Prefix Information Option
Type
TBA
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Sub-Type
0
Koodli (Editor) Expires 1 September 2003 [Page 39]
Internet Draft Fast Handovers 1 March 2003
Prefix Length
8-bit unsigned integer. The number of leading bits in the
Prefix that are valid. The value ranges from 0 to 128.
Prefix
An IP address or a prefix of an IP address. The Prefix Length
field contains the number of valid leading bits in the prefix.
The bits in the prefix after the prefix length are reserved
and MUST be initialized to zero by the sender and ignored by
the receiver.
6.5.3. Link-layer Address (LLA)
The format of this message is based on [5].
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 | Length | Sub-Type | LLA ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Link-Layer Address Option
Type
TBA
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Sub-Type
1 for the Link-layer Address of the new Attachment Point.
2 for the Link-layer Address of the MN.
3 for the Link-layer Address of the Proxied Originator
LLA
The variable length link-layer address. The content and format
of this field (including byte and bit ordering) is expected to
be specified in specific documents that describe how IPv6
operates over different link layers.
Koodli (Editor) Expires 1 September 2003 [Page 40]
Internet Draft Fast Handovers 1 March 2003
The New Attachment Point Link Layer address contains the link-layer
address of the attachment point for which handover is about to
be attempted. This is used in the Router Solicitation for Proxy
message.
The MN Link-Layer address option contains the link-layer address of a
MN. It is used in the Handover Initiate message.
The Proxied Originator Link-Layer address option contains the
Link Layer address of the Access Router for which the Proxy Router
Solicitation message refers.
These options MUST be silently ignored when used with other Neighbor
Discovery messages.
6.5.4. Neighbor Advertisement Acknowledgment (NAACK)
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 | Length | Sub-Type | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Neighbor Advertisement Acknowledgment Option
Type
TBA
Length
8-bit unsigned integer. Length of the option, in 8 octets,
excluding the Option Type and Option Length fields.
Sub-Type
0
Status
8-bit unsigned integer indicating the disposition of the Fast
Binding Update. Values of the Status field less than 128
indicate that the Binding Update was accepted by the receiving
node. The following such Status values are currently defined:
0 The New CoA is valid
Koodli (Editor) Expires 1 September 2003 [Page 41]
Internet Draft Fast Handovers 1 March 2003
1 The New CoA is invalid
128 Link Layer Address unrecognized
The NAR uses NAACK option, to confirm the validity of NCoA, in a
Router Advertisement sent as a response the FNA message. The PAR
also provides such a confirmation in the FBACK message. If the NCoA
is valid, the Router Advertisement MUST use NCoA as the destination
address and the MN SHOULD use it as its new CoA as defined in [3].
If the NCoA is invalid, the Router Advertisement MUST use the PCoA
as the destination address. The MN MAY use PCoA as source address,
however, it SHOULD start the process of obtaining a NCoA at the NAR.
If the NAACK indicates that the Link Layer Address is unrecognized
the MN MUST NOT use the NCoA or the PCoA and SHOULD start immediately
the process of acquiring a NCoA at the NAR.
In the future, new option types may be defined.
6.5.5. Handover Capability Extension
The Handover Capabilities extension is used in the IPv6 Router
Solicitation and Router Advertisement to indicate whether or not a MN
and its access router are capable of supporting fast handovers.
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 | Length | Sub-Type | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Handover Capability Extension Option
Type
TBD
Length
The length of the option (including the type, sub-type and
length fields) in units of 8 octets.
Sub-Type
0
Code
Koodli (Editor) Expires 1 September 2003 [Page 42]
Internet Draft Fast Handovers 1 March 2003
0 The node supports fast handover
7. Configurable Parameters
Parameter Name Default Value Definition
------------------- ---------------------- -------
FBU_RETRIES 3 Section 4
BT_LIFETIME 2 seconds Section 4
BT_LIFETIME_WARNING 500 ms Section 4.5.1
PROXY_ND_LIFETIME 1 second Section 6.2.2
HI_RETRIES 4 Section 6.2.1
8. Security Considerations
The PAR MUST ensure that the FBU packet arrived from a node that
legitimately owns the PCoA. Otherwise, a bogus node, either on-link
or off-link, could attempt to disrupt packets meant for the MN and
redirect them to some access router. When FBU is sent on-link
(i.e., it is not tunneled), the default security is what Neighbor
Discovery offers. The access router and its hosts may use any
available mechanism to establish a security association. When a
pre-established security association is available, it MUST be used to
secure FBU.
If an access router can ensure that the source IP address in an
arriving packet could only have originated from the node whose
link-layer address is in the router's neighbor cache, then a bogus
node cannot use a victim's IP address for malicious redirection of
traffic. Such an operation should be performed at least on neighbor
discovery messages including the RtSolPr message.
When FBU is sent off-link (i.e., arrives in a tunnel), it MUST be
protected by a security association established between the node
sending FBU and the PAR.
The target of malicious traffic redirection is limited to an access
router only with which the PAR has a security association. Because
of this, traffic could only be redirected to NAR's IP address
(and not to any other address), and the possibility of spamming an
unsuspecting node is eliminated.
Koodli (Editor) Expires 1 September 2003 [Page 43]
Internet Draft Fast Handovers 1 March 2003
9. Contributors
This document originated from the fast handover design team effort.
The members of this design team in alphabetical order are; Gopal
Dommety, Karim El-Malki, Mohammed Khalil, Charles Perkins, George
Tsirtsis and Alper Yegin.
10. Acknowledgments
The editor would like to thank the design team for all their hard
work. Also, warm thanks to Basavaraj Patil and Phil Roberts for
supporting this effort and the whole Mobile IP WG for participating
in the initial discussion.
The WG would like to thank James Kempf, Pat Calhoun, Gopal Dommety,
Sebastian Thalanany, Ajoy Singh, Peter J. McCann and Tom Hiller for
proposing the BETH method which is the basis of Section 4.5 and
Section 4.6. James Kempf also contributed text in Section 4.5.1 and
Section 5.2.
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] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[3] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6
(work in progress). Internet Draft, Internet Engineering Task
Force, 2002.
[4] (editor) Kempf, J. Requirements for Layer 2 Protocols to Support
Optimized Handover for IP Mobility (work in progress). Internet
Draft, Internet Engineering Task Force.
draft-manyfolks-l2-mobilereq-00.txt, January 2000.
[5] M. Khalil, R. Narayanan, H. Akhtar, and E. Qaddoura. Mobile IP
Extensions Rationalization (MIER) (work in progress). Internet
Draft, Internet Engineering Task Force.
draft-ietf-mobileip-mier-05.txt, February 2000.
Koodli (Editor) Expires 1 September 2003 [Page 44]
Internet Draft Fast Handovers 1 March 2003
[6] S. Thomson and T. Narten. IPv6 Stateless Address
Autoconfiguration. Request for Comments (Draft Standard)
2462, Internet Engineering Task Force, December 1998.
11. Contact Information
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Megisto Systems,Inc
6000 Connection Drive 20251 Century Blvd
M/S M8-540 Germantown, MD 20874
Irving, Texas 75039 USA
USA Phone: +1 301-444-1700
Phone: +1 972-894-6709 Fax: +1 301-515-3675
Fax : +1 972-894-5349 E-Mail: proberts@megisto.com
E-Mail: Basavaraj.Patil@nokia.com
The design team member's contact information:
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone:+1 408 525 1404
E-Mail: gdommety@cisco.com
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Mohamed Khalil
Nortel Networks
E-Mail: mkhalil@nortelnetworks.com
Charles E. Perkins
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
Koodli (Editor) Expires 1 September 2003 [Page 45]
Internet Draft Fast Handovers 1 March 2003
USA
Phone: +1-650 625-2986
E-Mail: charliep@iprg.nokia.com
Fax: +1 650 625-2502
Hesham Soliman
Ericsson Radio Systems AB
Torshamnsgatan 23,
Kista, Stockholm 16480
SWEDEN
Phone: +46 8 4046619
Fax: +46 8 4047020
E-mail: Hesham.Soliman@era.ericsson.se
George Tsirtsis
Flarion Technologies
E-Mail: G.Tsirtsis@flarion.com
Alper E. Yegin
Sun Microsystems
901 San Antonio Rd, UMPK17-202
Palo Alto, CA, 94303,USA
Phone: +1 650 786 4013
E-mail: alper.yegin@sun.com
The editor's contact information:
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043 USA
Phone: +1 650 625 2359
Fax: +1 650 625 2502
E-Mail: Rajeev.Koodli@nokia.com
Koodli (Editor) Expires 1 September 2003 [Page 46]
| PAFTECH AB 2003-2026 | 2026-04-21 09:55:22 |