Network Working Group H. Yokota
Internet-Draft KDDI R&D Laboratories, Inc.
Expires: August 5, 2006 G. Dommety
Cisco Systems, Inc.
February 2006
Mobile IPv6 Fast Handovers for 3G CDMA Networks
draft-yokota-mipshop-3gfh-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-Draft will expire on August 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Mobile IPv6 is designed to maintain its connectivity while moving
from one network to another. It is adopted in 3G CDMA networks as a
way to maintain connectivity when the mobile node moves between
access provider networks. However, this handover procedure requires
not only movement detection, but also the acquisition of a new
care-of address and the sending of a binding update message to the
home agent before the traffic begins to direct to the new location.
Yokota & Dommety Expires August 5, 2006 [Page 1]
Internet-Draft 3G CDMA Fast Handover February 2006
During this period, packets destined for the mobile node will be
lost, which may not be acceptable for real-time application such as
Voice over IP (VoIP) or video telephony. This document specifies
fast handover methods and selective bi-casting methods in the 3G
context in order to reduce latency and packet loss during handover.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Network reference model for Mobile IPv6 over 3G networks . . . 6
5. Fast handover procedures . . . . . . . . . . . . . . . . . . . 10
5.1 Predictive fast handover . . . . . . . . . . . . . . . . . 10
5.2 Reactive fast handover . . . . . . . . . . . . . . . . . . 14
6. Selective bi-casting . . . . . . . . . . . . . . . . . . . . . 18
6.1 Bi-casting by the PAR to the MN with multiple
interfaces (A-1) . . . . . . . . . . . . . . . . . . . . . 20
6.2 Bi-casting by the HA to the MN with multiple
interfaces (A-2) . . . . . . . . . . . . . . . . . . . . . 21
6.3 Bi-casting by the PAR to the MN with a single
interface (B-1) . . . . . . . . . . . . . . . . . . . . . 22
6.4 Bi-casting by the HA to the MN with a single
interfaces (B-2) . . . . . . . . . . . . . . . . . . . . . 24
6.5 Message Format . . . . . . . . . . . . . . . . . . . . . . 26
6.5.1 Simultaneous bindings flag and the HI message
indication flag extensions to (F)BU message . . . . . 26
6.5.2 New mobility option for bi-casting lifetime . . . . . 27
6.5.3 New status code for simultaneous bindings . . . . . . 27
6.5.4 New Option for vendor-specific information . . . . . . 28
6.6 MN and AR/HA operations . . . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . . 33
Yokota & Dommety Expires August 5, 2006 [Page 2]
Internet-Draft 3G CDMA Fast Handover February 2006
1. Requirements notation
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 [1].
Yokota & Dommety Expires August 5, 2006 [Page 3]
Internet-Draft 3G CDMA Fast Handover February 2006
2. Introduction
Mobile IPv6 allows mobile nodes (MNs) to maintain persistent IPv6
addresses while roaming around in IPv6 networks and it is adopted in
3G CDMA networks for handing off between different access provider
networks [2]. During handover, however, the mobile node (MN) needs
to switch the radio networks, to obtain a new Care-of Address (CoA)
and to re-register with the home agent (HA), which causes a
communication disruption. This is not desirable for real-time
applications such as VoIP and video telephony. To reduce this
disruption time or latency, a fast handover protocol for Mobile IPv6
[3] is proposed. In this proposal, there are two modes called
"predictive" fast handover and "reactive" fast handover. This
document first specifies how these fast handover modes can be applied
in the 3G context and shows that several Mobile IPv6 bootstrapping
procedures can be omitted. If the MN has more than one network
interface, even smoother handover can be realized by transmitting
packets destined for the MN to both networks, where the mobile node
resides and will move to. This document defines this mechanism as
selective bi-casting and shows several use cases with their handover
procedures.
Yokota & Dommety Expires August 5, 2006 [Page 4]
Internet-Draft 3G CDMA Fast Handover February 2006
3. Terminology
This document refers to [2] for Mobile IPv6 fast handover
terminology. Terms that first appear in this document are defined
below:
Forward Pilot Channel:
A portion of the Forward Channel that carries the pilot. The
Forward Channel is a portion of the physical layer channels
transmitted from the access network to the MN.
Sector:
Part of the access network that provides one CDMA channel. The
area covered by one base station may be split into several
sectors.
Home Link Prefix (HLP):
The prefix address assigned to the home link where the MN should
send the binding update message. This is one of the bootstrap
parameters for the MN.
Packet Data Serving Node (PDSN):
An entity that routes MN originated or MN terminated packet data
traffic. A PDSN establishes, maintains and terminates link
layer sessions to MNs [2]. A PDSN can be the access router in
the visited access provider network.
Yokota & Dommety Expires August 5, 2006 [Page 5]
Internet-Draft 3G CDMA Fast Handover February 2006
4. Network reference model for Mobile IPv6 over 3G networks
Figure 1 shows a simplified reference model of the Mobile IP enabled
3G networks. The home agent (HA) of the mobile node (MN) resides in
the home IP network and the MN roams around the access provider
networks. The home network and the access provider networks are
managed by either the same or different operator(s). Prior to the
Mobile IPv6 registration, the MN establishes a link-layer connection
with the access router (AR), which is also called PDSN (Packet Data
Serving Node) in 3G networks, of the access provider network to which
the MN is attached. When the MN moves from one access provider
network to another, a Mobile IPv6 handover is performed. The figure
shows the situation, where the MN moves from the PAR (previous access
router) to the NAR (new access router) and in the case of 3G
networks, the PAR and the NAR are equivalent to the oPDSN (old PDSN)
and the nPDSN (new PDSN).
Home IP Network
+........................+
. +--------+ +--------+ .
. | HA |--| AAA | .
. +--------+ +--------+ .
+../......\..............+
/ \
Access Provider Network Access Provider Network
+.............+ +.............+
. +---------+ . . +---------+ .
. | PAR | . . | NAR | .
. | (oPDSN) | . . | (nPDSN) | .
. +---------+ . . +---------+ .
. | :| . . :| | .
. | :|L2link L2link:| | .
. | :| . . :| | .
. +--+ +:--+ . . +:--+ +--+ .
. |BS| |:BS| . . |:BS| |BS| .
. +--+ +:--+ . . +:--+ +--+ .
. :| . . :| .
. +----+ . . +----+ .
. | MN |---------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Model for Mobile IP
Yokota & Dommety Expires August 5, 2006 [Page 6]
Internet-Draft 3G CDMA Fast Handover February 2006
In 3G CDMA networks, pilot channels transmitted by base stations
allow the MN to obtain a rapid and accurate C/I (carrier to
interference) estimate. This estimate is based on measuring the
strength of the Forward Pilot Channel or the pilot, which is
associated with a sector of a base station (BS). The MN searches for
the pilots and maintains those with sufficient signal strength in the
pilot sets. The MN sends measurement results, which include the
offsets of the PN (pseudorandom) code in use and the C/Is in the
pilot sets, to provide the access network (AN) with the estimate of
sectors in its neighborhood. There are several triggers for the MN
to send those estimates, e.g. when the strength of a pilot in the
pilot sets is higher enough than that of the current pilot, the MN
sends the estimates to the access network. If the serving access
network finds that the sector associated with the highest pilot
strength belongs to a different AR, it attempts to close the
connection with the MN. The MN then attempts to get a new traffic
channel assigned in the new access network, which is followed by
establishing a new connection with the new AR. The MN can
continually search for pilots without disrupting the data
communication and a timely handover is assisted by the network. If
the air interface information can be used as a trigger for the
handover between access routers, fast and smooth handover of Mobile
IPv6 can be realized in 3G CDMA networks.
To assist the handover of the MN to the new AR, various types of
information can be considered: the pilot sets, which include the
candidates of the target sectors or BSs, the cell information where
the MN resides, the serving nodes in the radio access network and the
location of the MN if available. In this document, a collection of
such information is called "handover assist information". In 3G
networks, the link-layer address of the new access point defined in
[3] may not be available. If this is the case, the handover assist
information SHOULD be used instead.
Figure 2 shows the protocol sequence from the attachment to the
network to the Mobile IPv6 registration. After the traffic channel
is assigned, the MN first establishes a link-layer connection between
itself and the access router. As the link-layer protocol, PPP can be
considered and in this figure, a PPP handshake is depicted as an
example. Then the MN registers with the HA by sending a Binding
Update message. There are several parameters for using Mobile IPv6
such as the home address (HoA), the care-of address (CoA), the home
agent address (HA) and the home link prefix (HLP). These addresses
are required prior to sending a Binding Update and obtaining these
values is called bootstrapping. One such method is proposed in [5],
where the bootstrapping information is obtained during the link-layer
establishment phase.
Yokota & Dommety Expires August 5, 2006 [Page 7]
Internet-Draft 3G CDMA Fast Handover February 2006
MN AR HA AAA
+-- | (PDSN) | |
| | LCP | | |
|(1) |<-------------------->| | |
| | CHAP or PAP | Access-Request/Accept |
|(2) |<-------------------->|<---------|----------------->|
| | +------------+ | | |
|(3) | | HA,HLP,HoA |<--+ | |
| | +------------+ | |
| | IPv6CP(IF-ID) | | |
|(4) |<--------|----------->| | |
(a)< +---------+ | | | |
|(5) | LL-addr |<--+ | | |
| +---------+ | | |
| | RA(prefix) | | |
|(6) |<-----|---------------| | |
| +-----+ | | | |
|(7) | CoA |<--+ | | |
| +-----+ | | |
| | DHCPv6(HA,HLP,HoA) | | |
|(8) |<-----------|-------->| | |
| +------------+ | | | |
|(9) | HA,HLP,HoA |<--+ | | |
| +------------+ | | |
*-- | | BU | |
(b) |------------------------------------>|Authentication|
| | | query/reply |
(c) | | |<------------>|
| | BA | |
(d) |<------------------------------------| |
| | | |
Figure 2: MIPv6 operation in 3G network
The procedure for the initial registration is as follows:
(a) The link-layer connection establishment and the bootstrapping
phase
(a-1) The LCP configure-request/response messages are exchanged.
(a-2) CHAP or PAP authentication is conducted.
(a-3) The bootstrapping parameters are conveyed from the HA and
stored in the AR (PDSN).
(a-4) Unique interface IDs are negotiated in IPv6CP.
Yokota & Dommety Expires August 5, 2006 [Page 8]
Internet-Draft 3G CDMA Fast Handover February 2006
(a-5) The MN configures its link-local address based on the
obtained interface ID.
(a-6) A router advertisement containing the prefix is received by
the MN.
(a-7) The MN configures its CoA based on the obtained prefix.
(a-8) DHCPv6 is used to obtain the bootstrap parameters such as
the home agent address, the home link prefix and the home address.
(a-9) The MN configures its HoA based on the obtained parameters.
(b) A binding update is sent to the HA.
(c) The HA asks the AAA to authenticate the MN for the initial
registration.
(d) The binding acknowledgment is sent back to the MN.
As is shown in Figure 2, it takes a considerable amount of time to
establish a link-layer connection and all of the above sequences run
every time the MN attaches to a new access network. It is therefore
beneficial if packets on the fly to the MN are saved not only during
the time period where the MN switches to the new radio channel but
also during the time period where the MN establishes the link-layer
connection.
Yokota & Dommety Expires August 5, 2006 [Page 9]
Internet-Draft 3G CDMA Fast Handover February 2006
5. Fast handover procedures
There are two modes defined in [3] according to the timing of sending
FBU (Fast Binding Update); one is called "predictive mode," where the
MN sends FBU and receives FBAck (Fast Binding Ack) on PAR (Previous
Access Router)'s link and the other is called "reactive mode," where
the MN sends FBU from NAR (New Access Router)'s link. In the
predictive mode, the time and place the MN hands off is indicated
sufficiently before the time it actually happens. In cellular
systems, handovers are controlled by the network and the predictive
mode is well applied although the reactive mode is possible as well.
On the other hand, in wireless LAN networks, for example, the MN
controls its handover and it is not easy to know where it moves to
until it starts to scan the channels. In this case, the reactive
mode is well applied.
5.1 Predictive fast handover
Figure 3 shows the predictive mode of MIPv6 fast handover operation.
When the MN finds a sector or a BS whose pilot signal is sufficiently
strong, it initiates handover according to the following sequence:
(a) A router solicitation for proxy router advertisement is sent
to the PAR.
(b) A proxy router advertisement containing the prefix in the NAR
is sent back to the MN.
(c) The MN creates an NCoA (new CoA) and sends the Fast Binding
Update (FBU) storing the NCoA to the PAR, which in turn sends the
Handover Initiate (HI) to the NAR.
(d) The NAR sends the Handover Acknowledge (HAck) back to the PAR,
which in turn sends the FBU acknowledgment (FBAck) to the MN.
(e) The PAR starts forwarding packets toward the NCoA and the NAR
captures and buffers them.
(f) The connection associated with the PAR is closed and the
traffic channel is assigned in the new access network.
(g) The MN establishes the link layer connection with or without
authentication.
(h) The MN sends the Fast Neighbor Advertisement (FNA).
(i) The NAR starts delivering packets to the MN.
Yokota & Dommety Expires August 5, 2006 [Page 10]
Internet-Draft 3G CDMA Fast Handover February 2006
(j) The MN sends the BU to the HA.
(k) The HA sends the BA back to the MN.
(l) The HA starts delivering packets to the MN via the NAR.
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | Hl | | |
(c) |------------->|-------------->| | |
| FBack | HAck | | |
(d) |<-------------|<--------------| | |
| |forward packets| | |
(e) | |==============>| | |
| | +-----------+ | |
| | | buffering | | |
| | +-----------+ | |
(f) handover | | | |
| | link layer connection | |
(g) |/----------------------------\|/...........................\|
|\----------------------------/|\.........................../|
| FNA | | |
(h) |----------------------------->| | |
| deliver packets | | |
(i) |<=============================| | |
| | BU | | |
(j) |-------------------------------------------->| |
| | BA | | |
(k) |<--------------------------------------------| |
| deliver packets | | |
(l) |<=============================|<=============| |
Figure 3: MIPv6 Fast handover operation (predictive mode)
It is assumed that the NAR can be identified by the PAR leveraging
the handover assist information from the MN. To perform the
predictive mode, the FBAck MUST be received by the MN before the
connection with the current access network is closed. If the MN
fails to send the FBU before handover, it SHOULD fall back to the
reactive mode. Even if the MN successfully sends the FBU, its
reception by the PAR may be delayed for various reasons such as
congestion. If the NAR receives the HI triggered by the delayed FBU
after the reception of the FNA ((c) comes after (h)), then the NAR
Yokota & Dommety Expires August 5, 2006 [Page 11]
Internet-Draft 3G CDMA Fast Handover February 2006
SHOULD send the HAck with handover not accepted.
In (a), RtSolPr MUST include the MN and the New Access Point Link-
Layer Address (LLA) options according to [3]. As for the MN-LLA
option, the only available identifier is the interface ID, so it
SHOULD be used for the MN-LLA. As for the New AP-LLA, the handover
assist information may be applied. Since the LLA is assumed to be an
IEEE identifier, even if the length field of the LLA option is in
units of 8 octets, the actual length can be obtained by knowing that
the length of an IEEE identifier is 6 octets. If the interface ID of
the MN is generated in the EUI-64-based format, the MN-LLA can be
constructed from it. However, if the LLA is not well-known, the
length of the LLA becomes ambiguous. If this is the case, it is
necessary to use a new option defined in Section 6.5.4 and the
corresponding length in it.
In (b), PrRtAdv MUST include options for the LLA, IP address and
prefix of the NAR. The PAR SHOULD be able to identify the NAR from
the handover assist information provided by the MN.
There are several ways to configure a unique IP address for the MN.
If a globally unique prefix is assigned per each link as introduced
in [5], the MN can use any interface ID except that of the other peer
to create a unique IP address. If this is the case, however, the PAR
cannot provide the MN with a correct prefix for the new network since
such a prefix is selected by the NAR and provided in the router
advertisement ((a-6) in Figure 2). Still, the NCoA MUST be included
in the FBU for the PAR to resolve the IP address of the NAR, so that
the MN configures a temporary NCoA with the prefix of the NAR and the
correct NCoA MUST be assigned by the NAR. Therefore, in (c), the PAR
MUST send the HI with the S flag set when it receives the FBU from
the MN. On the other hand, if more than one MN connected to an AR
share the same prefix, each MN MUST have a unique interface ID.
Unless it is guaranteed that each MN connected to the network
including a roaming case is preconfigured with a unique interface ID,
it MUST be agreed or provided by the NAR via the HI/Hack exchange.
In [3], the FNA MUST include the LLA of the MN, but the point-to-
point link layer connection makes it unnecessary. The only required
information is the NCoA to check if there is a corresponding buffer,
thus in (h), the function of the FNA can be realized in several ways.
o Since the establishment of the link layer connection in (g)
indicates readiness of data communication on the MN side, the NAR
immediately checks if there is a buffer that has packets destined
for the NCoA and starts delivering if any. (elimination of FNA)
Yokota & Dommety Expires August 5, 2006 [Page 12]
Internet-Draft 3G CDMA Fast Handover February 2006
o The FNA equivalent information can be conveyed in the phase of the
link layer connection, e.g. by conveying the NCoA in a PPP IPCP
with vendor specific extension as defined in [6]. Only when this
message is received by the NAR, it checks if there is a buffer for
the NCoA. (L2 implementation of FNA)
o The MN sends the FNA as defined in [3] with the LLA of the MN,
which may be derived from the EUI-64 based interface ID. (standard
implementation of FNA)
When PPP IPCP option is used as the means for the L2 implementation
of FNA, it SHOULD be confirmed that the NAR supports this option,
otherwise it may cause a longer delay by the Configure-Reject
message.
The primary benefit of this mode is that the packets destined for the
MN can be buffered at the NAR, and packet loss due to handover will
be much lower than that of the normal MIPv6 opration. Regarding the
bootstrapping, the following benefits can be obtained, too:
o Since the HA, HLP and HoA are not changed during the fast
handover, bootstrapping information is not required.
o Since the NCoA including the interface ID can be obtained or
configured via the fast handover procedures, a router
advertisement is not required.
Therefore, as shown in Figure 4, bootstrapping procedures (a-3) to
(a-9) can be omitted from the standard MIPv6 operation in Figure 2.
Also, if the security policy permits, the NAR can know the MN by the
NAI in the PPP link setup and the authentication in (2) may be
omitted. Note that another authentication is conducted in the MIPv6
registration phase and presumably the same AAA is referred to.
Yokota & Dommety Expires August 5, 2006 [Page 13]
Internet-Draft 3G CDMA Fast Handover February 2006
MN oPDSN nPDSN HA AAA
+-- | (PAR) (NAR) | |
| | LCP | | | |
| (1) |<----------------------->| | |
| | CHAP | | Access-Request/Accept |
| (2) |<----------------------->|<-------|------------->|
|+...................................+ | | |
|. | +------------+ | . | | |
|.(3)* | | HA,HLP,HoA |<------------+ | |
|. | +------------+ | . | |
|. | | . | |
|. | IPv6CP(IF-ID) | . | |
|.(4)* |<---------|------------->| . | |
(a)< . +---------+ | | | . | |
|.(5)*| LL-addr |<-+ | | . | |
|. +---------+ | | . | |
|. | | . | |
|. | RA(prefix) | . | |
|.(6)* |<---------|--------------| . | |
|. +-----+ | | | . | |
|.(7)*| CoA |<-----+ | | . | |
|. +-----+ | | . | |
|. | | . | |
|. | HCPv6(HA,HL,HoA) | . | |
|.(8)* |<---------|------------->| . | |
|. +-----+ | | | . | |
|.(9)*| HoA |<-----+ | | . | |
|. +-----+ | | . | |
|+...................................+ | |
*-- | | | | |
Figure 4: Procedures that can be omitted in the link-layer connection
5.2 Reactive fast handover
When the MN cannot receive the FBAck on the PAR's link or the network
does not support the predictive fast handover, the reactive fast
handover can be applied. To support the predictive fast handover,
the PAR must accurately resolve the address of the NAR from the lower
layer information such as the link-layer address of the new access
point or the base station, which is not always feasible in some
cases. To minimize packet loss in this situation, the PAR instead of
the NAR can buffer packets for the MN until the MN regains
connectivity with the NAR. The NAR obtains the information of the
PAR from the MN on the NAR's link and receives packets buffered at
the PAR. In this case, the PAR does not need to know the IP address
of the NAR or the NCoA and just waits for the NAR to contact the PAR.
Yokota & Dommety Expires August 5, 2006 [Page 14]
Internet-Draft 3G CDMA Fast Handover February 2006
However, since the PAR needs to know when to buffer packets for the
MN, the PAR obtains the timing of buffering from the MN via the FBU
or the lower layer signaling, e.g. an indication of the release of
the connection with the MN. Details of the procedure are as follows:
(a) A router solicitation for proxy router advertisement MAY be
sent to the PAR.
(b) The proxy router advertisement MAY be sent to the MN, but the
prefix of the NAR MAY not be included.
(c) The MN sends the FBU or the access network indicates the close
of the connection with the MN by the lower layer signaling. The
PAR MAY start buffering packets destined for the PCoA.
(d) The connection associated with the PAR is closed and the
traffic channel is assigned in the new access network.
(e) The MN establishes the link layer connection. Since the IP
address of the MN is guaranteed to be unique, the MN SHOULD not
perform DAD
(f) The MN sends the Fast Binding Update (FBU) to the NAR either
or not being encapsulated by the Fast Neighbor Advertisement
(FNA).
(g) The NAR decapsulates the FBU if encapsulated and sends it to
the PAR.
(h) The PAR sends the Handover Initiate (HI) to the NAR with the
Code set to 1.
(i) The NAR sends the Handover Acknowledge (HAck) back to the PAR.
(j) The PAR sends the FBAck to the NAR.
(k) If the PAR buffers packets destined for the PCoA, it starts
forwarding them as well as newly arriving ones to the NAR.
(l) The NAR delivers the packets to the MN.
(m) The MN sends the BU to the HA.
(n) The HA sends the BA back to the MN.
(o) The HA starts delivering packets to the MN via the NAR.
Yokota & Dommety Expires August 5, 2006 [Page 15]
Internet-Draft 3G CDMA Fast Handover February 2006
MN oPDSN nPDSN HA AAA
| (PAR) (NAR) | |
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU/lower-layer sig. | | |
(c) | . . . . . . >| | | |
| +-----------+ | | |
| | buffering | | | |
| +-----------+ | | |
(d) handover | | | |
| | link layer connection | |
(e) |/----------------------------\|/...........................\|
|\----------------------------/|\.........................../|
| FNA[FBU]/FBU | | |
(f) |----------------------------->| | |
| | FBU | | |
(g) | |<--------------| | |
| | HI | | |
(h) | |-------------->| | |
| | HAck | | |
(i) | |<--------------| | |
| | FBack | | |
(j) | |-------------->| | |
| |forward packets| | |
(k) | |==============>| | |
| deliver packets | | |
(l) |<=============================| | |
| | BU | | |
(m) |-------------------------------------------->| |
| | BA | | |
(n) |<--------------------------------------------| |
| deliver packets | | |
(o) |<=============================|<=============| |
Figure 5: MIPv6 Fast handover operation (reactive mode)
To indicate the PAR to buffer packets destined for the PCoA, in (c),
the MN SHOULD not include information on the NCoA in the FBU and the
PAR SHOULD accept it. Or, when the PAR is indicated that the session
with the MN has been closed by the lower layer signaling when the PAR
attempts to send the FBAck, the PAR MAY start buffering.
An L2-based fast handover is possible as defined in [7] by extending
the L2 link from the previous access network to the new access
network via the PAR and the NAR. The timing of the fast handover
trigger is the same as the reactive fast handover method (without
Yokota & Dommety Expires August 5, 2006 [Page 16]
Internet-Draft 3G CDMA Fast Handover February 2006
buffering) in this section. In the case of the L2-based fast
handover, however, once the L2 link is extended to the new location,
it is maintained until the MN becomes inactive (dormant) and the link
is released. As long as the L2 link is extended, the path, on which
packets are conveyed, is not optimal in length. In the case of
Mobile IPv6 fast handover, when the new location is registered with
the HA, the packets are directed to the NAR.
Yokota & Dommety Expires August 5, 2006 [Page 17]
Internet-Draft 3G CDMA Fast Handover February 2006
6. Selective bi-casting
If the MN has the capability to receive more than one radio signal,
even smoother handover can be realized. This situation happens when,
for instance, the MN can receive multiple channels of the same radio
system at the same time, or the MN has multiple interfaces of
different radio systems such as 3G and WiFi. Especially, when the MN
is running a real-time and interactive application, long-time
buffering at the PAR or NAR is not always beneficial for the MN. If
this is the case, it will be helpful to deliver packets destined for
the MN via both the old and new points of attachment at the same time
during handover. Even if the MN has only a single interface, the
above function has some benefits when the timing of handover cannot
be acquired precisely in advance. This type of use case was
originally proposed in [9]. Mobile IPv4 allows simultaneous bindings
[8] and bi-casting is realized by retaining the old care-of address
in the binding cache and sending packets destined for the MN towards
both the old and new care-of addresses. Since bi-casting consumes
double the network resources, it must be limited to smooth handover.
In this document, bi-casting used for a short period of time for
smooth handover is called "selective bi-casting." Figure 6 shows
that the simultaneous bindings and bi-casting are performed at the
PAR, which copies packets destined for the MN and transmits them not
only to the old point of attachment but also to the new point of
attachment via the NAR. The above operation is more effective when
the predictive fast handover is applied because in the case of the
reactive fast handover, all the actions are taken after the MN has
moved to the new location. By that time, it is not necessary to
deliver packets to the old point of attachment. As another scenario,
Figure 7 shows that simultaneous bindings are performed at the HA.
This scenario is likely to happen when the MN is connected to
multiple different networks such as 3G and WiFi at the same time.
Also, if the access networks in Figure 1 are operated by different
providers, it may be difficult for the ARs in these networks to
cooperate with each other. In this case as well, the HA must handle
simultaneous bindings and bi-casting.
Yokota & Dommety Expires August 5, 2006 [Page 18]
Internet-Draft 3G CDMA Fast Handover February 2006
+----------+
| HA |
+----------+
/
/
+------/-+ +--------+
| PAR --|------|-- NAR |
+------|-+ +-|------+
| |
| |
+----|+ +|----+
| BS || || BS |
+----|+ +|----+
\ /
\ | /
> |<
+------+
| MN |-->
+------+
Figure 6: Selective bi-casting scenario 1
+----------+
| HA |
+----------+
/ \
/ \
+------/-+ +-\------+
| PAR | | | | NAR |
+------|-+ +-|------+
| |
| |
+----|+ +|----+
| BS || || BS |
+----|+ +|----+
\ /
\ | /
> |<
+------+
| MN |-->
+------+
Figure 7: Selective bi-casting scenario 2
Yokota & Dommety Expires August 5, 2006 [Page 19]
Internet-Draft 3G CDMA Fast Handover February 2006
From the above observations, selective bi-casting can be categorized
from the following viewpoints:
[No. of interfaces on the MN]
(A) multiple interfaces
(B) single interface
[the node where bi-casting is performed]
(1) at the PAR
(2) at the HA
The procedures for each combination are described in the following
section.
6.1 Bi-casting by the PAR to the MN with multiple interfaces (A-1)
As shown in Figure 8, the MN has two interfaces with the link layer
addresses: LLA1 and LLA2. This case is typical of handover between
different access systems such as 3G and WiFi. Details of the
sequence are as follows:
(a) The interface with LLA1 acquires the global IP address PCoA.
(b) The MN sends the BU to the HA from the link with PCoA with S=0
and N=0 (the default behavior), which are defined in
Section 6.5.1, and receives the BA from the HA.
(c) The MN receives packets destined for PCoA from the link with
LLA1 via the PAR.
(d) When the MN detects that handover is imminent, it opens the
interface with LLA2 and acquires the global IP address NCoA.
(e) The MN inserts NCoA into the FBU and sends it with S=1 and N=0
from the link with PCoA to the PAR.
(f) The MN receives the FBack from the PAR.
(g) The PAR sends packets destined for PCoA directly to the link
with LLA1 and also forwards them to the NAR. The forwarded
packets are received by the MN on the link with NCoA.
(h) When the MN is ready to use the link with LLA2 as the primary
one, it sends the BU to the HA with S=0 and N=0.
(i) The MN starts to receive packets via the NAR.
As shown in this example, since the NCoA is assigned on the link with
Yokota & Dommety Expires August 5, 2006 [Page 20]
Internet-Draft 3G CDMA Fast Handover February 2006
LLA2 and the NAR has the neighbor cache entry (NCE) for the NCoA,
there is no need to send the HI from the PAR. To suppress sending
the HI, a new flag 'N' is defined in the FBU. Also, to indicate the
PAR to bi-cast packets, a new flag 'S' is defined in the FBU. If the
MN requests selective bi-casting and the valid NCoA has been
assigned, the MN SHOULD send the FBU to the PAR with the S flag set
and the N flag unset requesting bi-casting but not sending the HI.
If the PAR receives this FBU, it SHOULD not send the HI to the NAR.
+..MN..+
LLA1 LLA2 PAR NAR HA
| | | | |
|link-layer connection | | |
(a) |/--------------------\| | |
|\--------------------/| | |
| | BU(S=0,N=0)/BA |
(b) |<---------------------------------------------------------->|
| | | | |
(c) |<=====================|<====================================|
| | link-layer connection | |
(d) | |/--------------------------------\| |
| |\--------------------------------/| |
| FBU(S=1,N=0) | | |
(e) |--------------------->| | |
| FBack | | |
(f) |<---------------------| | |
| | | | |
(g) |<====================+|<====================================|
| | +=================>+| |
| |<================================+| |
| | | | |
| | BU(S=0,N=0)/BA |
(h) | |<--------------------------------------------------->|
: | | | |
(i) : |<=================================|<=================|
Figure 8: Combination (A-1)
6.2 Bi-casting by the HA to the MN with multiple interfaces (A-2)
This case happens when the access network where the PAR belongs and
the one where the NAR belongs are administrated by different
providers or are different access systems. The cellular network is
typically a closed network and the ARs can access external nodes only
via the HA. If this is the case, the PAR and the NAR cannot directly
communicate with each other. Details of the sequence of this case
are shown in Figure 9 and below:
Yokota & Dommety Expires August 5, 2006 [Page 21]
Internet-Draft 3G CDMA Fast Handover February 2006
(a) through (d) are the same as those in the case (A-1).
(e) The MN sends the BU to the HA from the link with NCoA with S=1
and N=0, which means that the MN requests the HA to bi-cast but
not to send the HI.
(f) The HA forwards packets destined for the MN to both the PAR
and the NAR. Those packets can be received by the MN on either
one or both of the links.
(g) When the bi-casting lifetime, which is defined in
Section 6.5.2, is expired, packets are forwarded only to the NAR.
+..MN..+
LLA1 LLA2 PAR NAR HA
| | | | |
|link-layer connection | | |
(a) |/--------------------\| | |
|\--------------------/| | |
| | BU(S=0,N=0)/BA | |
(b) |<---------------------------------------------------------->|
| | | | |
(c) |<=====================|<====================================|
| | link-layer connection | |
(d) | |/--------------------------------\| |
| |\--------------------------------/| |
| | | | |
| | BU(S=1,N=0)/BA |
(e) | |<--------------------------------------------------->|
| | | | |
(f) |<=====================|<====================================|
| |<=================================|<=================|
: | | | |
(g) : |<=================================|<=================|
Figure 9: Combination (A-2)
6.3 Bi-casting by the PAR to the MN with a single interface (B-1)
This case is typical of handover with the same access system within
the same provider network. Details of the sequence of this case are
shown in Figure 10 and below:
(a) through (c) are the same as those in the case (A-1).
Yokota & Dommety Expires August 5, 2006 [Page 22]
Internet-Draft 3G CDMA Fast Handover February 2006
(d) The MN sends the RtSolPr to the PAR.
(e) The MN receives the PrRtAdv with a valid NCoA from the PAR.
(f) The MN sends the FBU with S=1 and N=1 to the PAR.
(g) The PAR sends the HI to the NAR. The 'U' bit MUST not be set
if the 'S' bit of the FBU is set.
(h) The PAR receives the HAck with a valid NCoA from the NAR.
(i) The PAR sends the FBack both to the MN and the NAR.
(j) The PAR sends packets destined for PCoA directly to the MN and
also forwards them to the NAR.
(k) The MN moves to the new access network and configures NCoA by
establishing the link-layer connection. At this point, the MN can
receive the forwarded packets from the NAR.
(l) The MN sends the BU with S=0 and N=0 to the HA.
(m) The MN starts to receive packets only via the NAR.
In (g), it is necessary that the PAR sends the HI to the NAR to
create the neighbor cache entry (NCE) for the NCoA on the NAR.
Yokota & Dommety Expires August 5, 2006 [Page 23]
Internet-Draft 3G CDMA Fast Handover February 2006
MN PAR NAR HA
| | | |
|link-layer connection | | |
(a) |/--------------------\| | |
|\--------------------/| | |
| BU(S=0,N=0)/BA |
(b) |<---------------------------------------------------------->|
| | | |
(c) |<=====================|<====================================|
| RtSoIPr | | |
(d) |--------------------->| | |
| PrRtAdv | | |
(e) |<---------------------| | |
| FBU(S=1,N=1) | | |
(f) |--------------------->| | |
| | HI | |
(g) | |----------------->| |
| (new link) | HAck | |
(h) | | |<-----------------| |
| | FBAck | FBack | |
(i) |<---------------------|----------------->| |
| | | | |
(j) |<====================+|<====================================|
|.....>| +=================>+| |
: |<================================+| |
: | | | |
: | link-layer connection | |
(k) : |/--------------------------------\| |
: |\--------------------------------/| |
: | BU(S=0,N=0)/BA |
(l) : |<--------------------------------------------------->|
: | | | |
(m) : |<=================================|<=================|
Figure 10: Combination (B-1)
6.4 Bi-casting by the HA to the MN with a single interfaces (B-2)
This case is typical of handover with the same access system between
different provider networks. Details of the sequence of this case
are shown in Figure 11 and below:
(a) through (d) are the same as those in the case (A-3).
(e) The MN receives the PrRtAdv without a valid NCoA from the PAR.
Yokota & Dommety Expires August 5, 2006 [Page 24]
Internet-Draft 3G CDMA Fast Handover February 2006
(f) The MN sends the FBU with S=1 and N=1 to the HA.
(g) The HA sends the HI to the NAR. The 'U' bit MUST not be set
if the 'S' bit of the FBU is set.
(h) The HA receives the HAck from the NAR.
(i) The HA sends the FBack to the MN and the NAR.
(j) The HA sends packets destined for the MN to both the PAR and
the NAR. They can be received by the MN on either one or both of
the links.
(k) The MN moves to the new access network and configures NCoA by
establishing the link-layer connection. At this point, the MN can
receive the forwarded packets from the NAR.
(l) The MN sends the BU with S=0 and N=0 to the HA.
(m) The MN starts to receive packets only via the NAR.
(k) The MN moves to the new access network and configures NCoA by
establishing the link-layer connection. At this point, the MN can
receive the forwarded packets from the NAR.
(l) The MN sends the BU with S=0 and N=0 to the HA.
(m) The MN starts to receive packets only via the NAR.
In (e), by receiving the PrRtAdv without a valid NCoA (the Code is
typically 2), the MN judges that the PAR does not have information on
the NAR or can not send the HI directly to the NAR. Then the MN
sends the FBU to the HA.
In (g), it is necessary that the HA sends the HI to the NAR to make
the NCE for the NCoA on the NAR.
Yokota & Dommety Expires August 5, 2006 [Page 25]
Internet-Draft 3G CDMA Fast Handover February 2006
MN PAR NAR HA
| | | |
|link-layer connection | | |
(a) |/--------------------\| | |
|\--------------------/| | |
| BU(S=0,N=0)/BA |
(b) |<---------------------------------------------------------->|
| | | |
(c) |<=====================|<====================================|
| RtSoIPr | | |
(d) |--------------------->| | |
| PrRtAdv | | |
(e) |<---------------------| | |
| FBU(S=1,N=1) |
(f) |----------------------------------------------------------->|
| | | HI |
(g) | | |<-----------------|
| | | HAck |
(h) | (new link) | |----------------->|
| | | | FBack |
(i) | | | FBack |<-----------------|
|<-----------------------------------------------------------|
| | | | |
(j) |<=====================|<====================================|
| |<=================================|<=================|
|.....>| link-layer connection | |
(k) : |/--------------------------------\| |
: |\--------------------------------/| |
: | BU(S=0,N=0)/BA |
(l) : |<--------------------------------------------------->|
: | | | |
(m) : |<=================================|<=================|
Figure 11: Combination (B-2)
6.5 Message Format
6.5.1 Simultaneous bindings flag and the HI message indication flag
extensions to (F)BU message
When the MN requests simultaneous bindings and bi-casting to the HA
or the PAR, the MN sets the newly defined simultaneous bindings flag
in the Binding Update (BU) [10] or FBU, respectively. To suppress
sending the HI when it is unnecessary, the HI message indication flag
is defined in the (F)BU as well.
Yokota & Dommety Expires August 5, 2006 [Page 26]
Internet-Draft 3G CDMA Fast Handover February 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|S|N| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
S: Simultaneous bindings. If the 'S' bit is set, the mobile
node is requesting that the HA or the PAR retain its prior
mobility bindings and bi-cast packets destined for the MN.
N: Indication to send the HI. On the condition that the 'S'
bit is set, if the 'N' bit is set, the receiver (the PAR or
the HA) SHOULD send the HI to the NAR, otherwise the
receiver SHOULD not send the HI. If the 'S' bit is not
set, the 'N' bit MUST be ignored.
If the 'S' bit is supported, the 'N' MUST also be supported. When
S=0 and N=0, the AR and the HA perform according to [3] and [10],
respectively (the default behavior).
6.5.2 New mobility option for bi-casting lifetime
The MN may request how long the HA or the PAR should retain the
simultaneous bindings (and therefore bi-casting) by attaching the
following mobility option in the binding update 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 = T.B.D | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bi-casting Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bi-casting Lifetime:
The time period when the PAR or the HA retains the previous
CoA (PCoA).
6.5.3 New status code for simultaneous bindings
If the AR or the HA receives more (fast) binding update messages with
Yokota & Dommety Expires August 5, 2006 [Page 27]
Internet-Draft 3G CDMA Fast Handover February 2006
different CoAs for the same HoA than it can support, it should send a
binding acknowledgement message with the following status code:
Status T.B.D.
too many simultaneous mobility bindings
6.5.4 New Option for vendor-specific information
If the lower layer information of the new point of attachment is not
represented as the Link-Layer Address, the following option SHOULD be
used. The primary purpose of this option is to convey the handover
assist information described in Section 4.
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 | Option-Code | VS-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VS-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type T.B.D.
Length The size of this option in 8 octets including the
Type, Length, Option-Code and VS-Length fields.
Option-Code Indicates the particular type of vendor-specific
information. This value is administrated by the
vendor or organization that uses this option.
VS-Length The size of the VS-Value field in octets.
VS-Value Zero or more octets of vendor-specific information
data.
This option MUST be understood by the sender (typically the MN) and
the receiver (typically the AR or the HA). If nodes in between do
not support this option, they SHOULD treat this option as opaque and
MUST not drop it.
Depending on the size of the VS-Value field, appropriate padding MUST
be used to ensure that the entire option size is a multiple of 8
octets. The VS-Length is used to disambiguate the size of the VS-
Value.
Yokota & Dommety Expires August 5, 2006 [Page 28]
Internet-Draft 3G CDMA Fast Handover February 2006
6.6 MN and AR/HA operations
In order to enable bi-casting, the MN sends a BU or FBU by setting
the 'S' flag to the HA or the PAR, respectively. When the PAR/HA
allows bi-casting, a successful (F)Back is returned and bi-casting is
started. The MN can request a desirable bi-casting lifetime to the
PAR/HA with the bi-casting lifetime option in the (F)BU. If the
requested lifetime is acceptable, the PAR/HA sends an (F)Back with
the accepted bi-casting lifetime, which is determined by the policies
of the PAR/HA. When bi-casting is performed at the HA, the MN is
likely to receive duplicate packets from multiple interfaces. In the
case of audio or video applications, it may be necessary to
synchronize the bi-cast flows coming from different access networks
so that the user does not have to experience a communication
disruption. This may take longer than just the time for a handover.
If this is the case, the MN may request a longer bi-cast lifetime.
After the flows are synchronized and successfully switched on the
application level, the MN may explicitly de-register the PCoA by
sending an (F)BU with the lifetime field being zero. On the side of
the PAR/HA, the maximum value of the bi-casting lifetime must be
configured and even if the MN does not request a bi-casting lifetime
or does not successfully de-register the PCoA, it is deleted after
the maximum value of the bi-casting lifetime elapses.
Yokota & Dommety Expires August 5, 2006 [Page 29]
Internet-Draft 3G CDMA Fast Handover February 2006
7. Security Considerations
The security considerations for Mobile IPv6 fast handover are
described in [3]. When a 3G network is considered, the PAR and the
NAR have a trusting relationship and the links between them and those
between the ARs and the MN are usually secured. When the MN is
authenticated at the phase of the link-layer connection, the AR can
distinguish the authenticated users from the others. This may be not
the case, however, if the access networks are operated by different
providers.
Yokota & Dommety Expires August 5, 2006 [Page 30]
Internet-Draft 3G CDMA Fast Handover February 2006
8. Conclusions
The handover performance of the standard Mobile IPv6 is not
sufficient for real-time communications that are not resilient to
packet loss. The Mobile IPv6 fast handover methods are effective for
these applications. This document specifies how these methods can be
applied to 3G networks. By introducing fast handover, not only are
more packets saved which otherwise would be dropped, but also some of
the bootstrapping parameters can be omitted at the link establishment
phase, which can expedite the handover process. For interactive
real-time applications, in which excessive buffering is
inappropriate, selective bi-casting is also proposed. By retaining
the PCoA and the NCoA in the binding cache, packets destined for the
MN are transmitted to both the old and new points of attachment at
the same time, whereby the applications on the MN can choose which
flow to adopt considering the media continuity.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] 3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000
Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0,
February 2005.
[3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068,
July 2005.
[4] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
Introduction", X.P0011-001-D v.0.5, November 2004.
[5] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
and Mobile IP services", X.P0011-002-D v.0.5, November 2004.
[6] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[7] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet
Data Mobility and Resource Management", X.P0011-003-D v.0.5,
November 2004.
[8] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[9] Malki, K., "Simultaneous Bindings for Mobile IPv6 Fast
Handovers", draft-elmalki-mobileip-bicasting-v6-05.txt,
October 2003.
Yokota & Dommety Expires August 5, 2006 [Page 31]
Internet-Draft 3G CDMA Fast Handover February 2006
[10] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.
Authors' Addresses
Hidetoshi Yokota
KDDI R&D Laboratories, Inc.
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Phone: +81 49 278 7894
Fax: +81 49 278 7510
Email: yokota@kddilabs.jp
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
Phone: +1 408 525 1404
Email: gdommety@cisco.com
Yokota & Dommety Expires August 5, 2006 [Page 32]
Internet-Draft 3G CDMA Fast Handover February 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Yokota & Dommety Expires August 5, 2006 [Page 33]