One document matched: draft-ietf-mipshop-3gfh-03.txt
Differences from draft-ietf-mipshop-3gfh-02.txt
Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Standards Track G. Dommety
Expires: January 10, 2008 Cisco Systems, Inc.
July 9, 2007
Mobile IPv6 Fast Handovers for 3G CDMA Networks
draft-ietf-mipshop-3gfh-03.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 January 10, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Yokota & Dommety Expires January 10, 2008 [Page 1]
Internet-Draft 3G CDMA Fast Handover July 2007
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 routers. 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. 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 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 . . . . . . . . . . . . . . . . . . . 8
5.1. Predictive fast handover . . . . . . . . . . . . . . . . . 8
5.2. Reactive fast handover . . . . . . . . . . . . . . . . . . 13
5.3. Network-controlled fast handover . . . . . . . . . . . . . 16
6. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. New Option for access-specific handover information . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Yokota & Dommety Expires January 10, 2008 [Page 2]
Internet-Draft 3G CDMA Fast Handover July 2007
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 January 10, 2008 [Page 3]
Internet-Draft 3G CDMA Fast Handover July 2007
2. Introduction
Mobile IPv6 [2] 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 [4]. 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. In the case where the lower layer can
provide necessary information for handover, network-controlled fast
handover defined in this document can also be applied.
Yokota & Dommety Expires January 10, 2008 [Page 4]
Internet-Draft 3G CDMA Fast Handover July 2007
3. Terminology
This document refers to [4] 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:
A typical cell divides its coverage area into several sectors.
In 3G CDMA systems, each sector uses a different PN (Pseudo
Noise) code offset.
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 [4]. A PDSN can be the access router in
the visited access provider network.
Yokota & Dommety Expires January 10, 2008 [Page 5]
Internet-Draft 3G CDMA Fast Handover July 2007
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) and AAA server (AAA) of the mobile
node (MN) reside in the home IP network and the MN roams within or
between the access provider network(s). Usually, the home IP network
is not populated by the MNs, which are instead connected only to the
access provider networks. Prior to the Mobile IPv6 registration, the
MN establishes an access technology specific link-layer connection
with the access router (AR). When the MN moves from one AR to
another, the link-layer connection is re-established and a Mobile
IPv6 handover is performed. Those ARs reside in either the same or
different access provider network(s). The figure shows the
situation, where the MN moves from the previous access router (PAR)
to the new access router (NAR) via the radio access network (RAN).
Home IP Network
+........................+
. +--------+ +--------+ .
. | HA |--| AAA | .
. +--------+ +--------+ .
+../......\..............+
/ \
Access Provider Network(s)
+.............+ +.............+
. +---------+ . . +---------+ .
. | PAR | . . | NAR | .
. +---------+ . . +---------+ .
. |: . . :| .
. |:L2link L2link:| .
. |: . . :| .
. +----+:---+ . . +---:+----+ .
. | RAN | . . | RAN | .
. +----+:---+ . . +---:+----+ .
. |: . . :| .
. +----+ . . +----+ .
. | MN | ---------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Model for Mobile IP
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
Yokota & Dommety Expires January 10, 2008 [Page 6]
Internet-Draft 3G CDMA Fast Handover July 2007
pilot sets. The MN sends measurement results, which include the
offsets of the PN 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. To identify the access network that
the MN moves to or from, the Access Network Identifiers (ANID), which
is composed of the System ID (SID), Network ID (NID) and Packet Zone
ID (PZID) can be used [5]. 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.
Yokota & Dommety Expires January 10, 2008 [Page 7]
Internet-Draft 3G CDMA Fast Handover July 2007
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 must be
indicated sufficiently before the time it actually happens. In
cellular systems, since handovers are controlled by the network, the
predictive mode is well applied. However, if the network is not
configured to be able to identify the new AR, to which the MN is
moving next, in a timely manner, the reactive mode is better applied.
5.1. Predictive fast handover
Figure 2 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 link-layer connection associated with the PAR is closed
and a new traffic channel is assigned in the new access network.
(g) The MN attaches to the new access network. The attachment
procedure is access technology specific.
(h) The MN sends the Fast Neighbor Advertisement (FNA).
(i) The NAR starts delivering packets to the MN.
(j) The MN sends the BU to the HA to update the BCE with the NCoA
and the HA sends back the BA to the MN. The AAA server may be
Yokota & Dommety Expires January 10, 2008 [Page 8]
Internet-Draft 3G CDMA Fast Handover July 2007
involved for authentication.
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | Hl | | |
(c) |------------->|-------------->| | |
| FBack | HAck | | |
(d) |<-------------|<--------------| | |
| |forward packets| | |
(e) | |==============>|(buffering) | |
| | | | |
(f) handover | | | |
| | | | |
+--------------------------------------------------------------+
(g) | Attachment procedure |
+--------------------------------------------------------------+
| FNA | | |
(h) |----------------------------->| | |
| deliver packets | | |
(i) |<=============================| | |
| | BU/BA | (Authentication)
(j) |<------------------------------------------->|<- - - - - - >|
| | | | |
Figure 2: 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 MN MUST send the FBU 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 SHOULD send the HAck with
handover not accepted and behave as the reactive mode.
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
Yokota & Dommety Expires January 10, 2008 [Page 9]
Internet-Draft 3G CDMA Fast Handover July 2007
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.1 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.
Figure 3 shows the call flow for the initial attachment in 3G CDMA
network [6]. 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. In [6], obtaining these values is called
bootstrapping and the bootstrapping information is obtained during
the link-layer establishment phase.
The procedure for the initial attachment is as follows:
(g) The link-layer connection establishment and the bootstrapping
phase
(g-1) The LCP configure-request/response messages are exchanged.
(g-2) User authentication (e.g. CHAP or PAP) is conducted.
(g-3) The bootstrapping parameters (e.g. HA, HLP or HoA) are
conveyed from the AAA and stored in the NAR (target PDSN).
(g-4) Unique interface IDs are negotiated in IPv6CP.
(g-5) The MN configures its link-local address based on the obtained
interface ID.
(g-6) A router advertisement containing the prefix is received by
the MN.
(g-7) The MN configures its CoA based on the obtained prefix.
Yokota & Dommety Expires January 10, 2008 [Page 10]
Internet-Draft 3G CDMA Fast Handover July 2007
(g-8) DHCPv6 is used to obtain the bootstrap parameters such as the
HA, HLP or HoA.
(g-9) The MN configures its HoA based on the obtained parameters.
If a new HoA is provided at (g-8), the MN adopts it (stateful
auto-configuration); otherwise, the MN generates the HoA based
on the HLP and its Interface ID (stateless auto-
configuration).
MN PAR NAR HA AAA
/ | (serving PDSN) (target PDSN) | |
| | LCP | | | |
| (1) |<----------------------->| | |
| | CHAP/PAP | Access-Request/Accept |
| (2) |<----------------------->|<-------------|------->|
|+........................................+ | | |
|. | | +------------+ . | | |
|.(3)* | | | HA,HLP,HoA |<-------+ |
|. | | +------------+ . | |
|. | | . | |
|. | IPv6CP(IF-ID) | . | |
|.(4)* |<---------|------------->| . | |
(g)< . +---------+ | | | . | |
|.(5)*| LL-addr |<-+ | | . | |
|. +---------+ | | . | |
|. | | . | |
|. | RA(prefix) | . | |
|.(6)* |<---------|--------------| . | |
|. +-----+ | | | . | |
|.(7)*| CoA |<-----+ | | . | |
|. +-----+ | | . | |
|. | | . | |
|. | DHCPv6(HA,HLP,HoA) | . | |
|.(8)* |<---------------+------->| . | |
|. +------------+ | | | . | |
|.(9)*| HoA,HLP,HoA |<---+ | . | |
|. +------------+ | | . | |
|+........................................+ | |
\ | | | | |
Figure 3: Attachment procedure in 3G CDMA network
As is shown in Figure 3, 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
Yokota & Dommety Expires January 10, 2008 [Page 11]
Internet-Draft 3G CDMA Fast Handover July 2007
also during the time period where the MN establishes the link-layer
connection.
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 [6], 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. 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, at step (c) in Figure 2, 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)
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 [8]. 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 operation. Regarding the
Yokota & Dommety Expires January 10, 2008 [Page 12]
Internet-Draft 3G CDMA Fast Handover July 2007
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, the bootstrapping procedures (g-3) to (g-9) can be omitted
from the standard MIPv6 operation in Figure 3. Also, if the security
policy permits, the NAR can know the MN by the NAI in the PPP link
setup and the authentication in (g-2) may be omitted. Note that
another authentication is conducted in the MIPv6 registration phase
and presumably the same AAA is referred to.
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.
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 link-layer connection associated with the PAR is closed
and a new traffic channel is assigned in the new access network.
Yokota & Dommety Expires January 10, 2008 [Page 13]
Internet-Draft 3G CDMA Fast Handover July 2007
(e) The MN attaches to the new access network. The attachment
procedure is access technology specific. 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 is buffering 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 to update the BCE with the NCoA
and the HA sends back the BA to the MN. The AAA server may be
involved for authentication.
Yokota & Dommety Expires January 10, 2008 [Page 14]
Internet-Draft 3G CDMA Fast Handover July 2007
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | | | |
(c) |- - - - - - ->|(buffering) | | |
| | | | |
(d) handover | | | |
| | | | |
+--------------------------------------------------------------+
(e) | Attachment procedure |
+--------------------------------------------------------------+
| FNA[FBU]/FBU | | |
(f) |----------------------------->| | |
| | FBU | | |
(g) | |<--------------| | |
| | HI | | |
(h) | |-------------->| | |
| | HAck | | |
(i) | |<--------------| | |
| | FBack | | |
(j) | |-------------->| | |
| |forward packets| | |
(k) | |==============>| | |
| deliver packets | | |
(l) |<=============================| | |
| | BU/BA | (Authentication)
(m) |<------------------------------------------->|<- - - - - - >|
| | | | |
Figure 4: 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
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
Yokota & Dommety Expires January 10, 2008 [Page 15]
Internet-Draft 3G CDMA Fast Handover July 2007
Mobile IPv6 fast handover, when the new location is registered with
the HA, the packets are directed to the NAR.
5.3. Network-controlled fast handover
If the lower layer can provide necessary information for handover and
support handover triggering, the fast handover can also be provided
to MNs that do not support FMIPv6. RtSolPr, FBU and FNA, which are
initiated by the MN, may be replaced by such lower layer protocols
and the fast handover can be performed without explicit involvement
of the MN. This type of fast handover has been proposed, for
example, in [9] and called the network-controlled fast handover in
this document. The detailed sequence is shown in Figure 5.
(a) The MN initiates the handover procedure with the currently
connected network, which may interact with the new network. The
handover intiation procedure is access technology specific.
(b) The PAR (typically) sends the HI to the NAR; however, the NAR
may instead send the HI to the PAR based on the lower-layer
interworking.
(c) The AR that received the HI sends back the HAck to the peer
AR.
(d) The AR that received the HAck MAY send the Unsolicited HAck to
the peer AR to confirm the reception of the HAck and/or to send
access technology specific information.
(e) The PAR starts forwarding packets to the NAR and the NAR MAY
buffers them.
(f) The link-layer connection associated with the PAR is closed
and a new traffic channel is assigned in the new access network.
(g) The MN attaches to the new network. The attachment procedure
is access technology specific.
(h) The NAR starts delivering packets to the MN.
(i) The MN sends the BU with the CoA being the NCoA to the HA and
the HA sends back the BA to the MN after successful authentication
of the BU. From this time on, the HA starts sending packets
directly to the MN via the NAR.
Yokota & Dommety Expires January 10, 2008 [Page 16]
Internet-Draft 3G CDMA Fast Handover July 2007
MN PAR NAR HA AAA
| | | | |
+--------------------------------+ | |
(a) | Lower-layer HO initiation | | |
+--------------------------------+ | |
| | HI | | |
(b) | |<------/------>| | |
| | HAck | | |
(c) | |<------/------>| | |
| | (UHAck) | | |
(d) | |<- - - /- - - >| | |
| |forward packets| | |
(e) | |==============>|(buffering) | |
| | | | |
(f) handover | | | |
| | | | |
+--------------------------------------------------------------+
(g) | Attachment procedure |
+--------------------------------------------------------------+
| deliver packets | | |
(h) |<=============================| | |
| | BU/BA | (Authentication)
(i) |<------------------------------------------->|<- - - - - - >|
| | | | |
Figure 5: Network-controlled fast handover operation
Even after the MN has moved to the new network, the PAR continues to
send the packets to the MN by forwarding them to the NAR. The NAR is
responsible for delivering packets whose destination address is the
PCoA to the MN in the new network. As far as the PAR is involved,
however, the path from the HA to the MN is not optimal. In order to
optimize the path towards the MN, the binding cache in the HA needs
to be updated. At an appropriate point after the NCoA has been
assigned to the MN, the MN sends the BU to the HA to update the
binding cache in the HA to the NCoA.
Yokota & Dommety Expires January 10, 2008 [Page 17]
Internet-Draft 3G CDMA Fast Handover July 2007
6. Message Format
6.1. New Option for access-specific handover 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 | AS-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type T.B.D.
Length The size of this option in 8 octets including the
Type, Length, Option-Code and AS-Length fields.
Option-Code Indicates the particular type of access-specific
information. This value is administrated by the
vendor or organization that uses this option.
AS-Length The size of the AS-Value field in octets.
AS-Value Zero or more octets of access-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 AS-Value field, appropriate padding MUST
be used to ensure that the entire option size is a multiple of 8
octets. The AS-Length is used to disambiguate the size of the AS-
Value.
Yokota & Dommety Expires January 10, 2008 [Page 18]
Internet-Draft 3G CDMA Fast Handover July 2007
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 not be
the case, however, if the access networks are operated by different
providers.
Yokota & Dommety Expires January 10, 2008 [Page 19]
Internet-Draft 3G CDMA Fast Handover July 2007
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.
Yokota & Dommety Expires January 10, 2008 [Page 20]
Internet-Draft 3G CDMA Fast Handover July 2007
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068,
July 2005.
9.2. Informative References
[4] 3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000
Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0,
February 2005.
[5] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability
Specification", A.S0001-A v.2.0, June 2001.
[6] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
and Mobile IP services", X.S0011-002-D v.1.0, February 2006.
[7] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet Data
Mobility and Resource Management", X.S0011-003-D v.1.0,
February 2006.
[8] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[9] 3GPP2 TSG-X, "Fast Handoff for HRPD", X.P0043 v.0.3, 2006.
Yokota & Dommety Expires January 10, 2008 [Page 21]
Internet-Draft 3G CDMA Fast Handover July 2007
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
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 January 10, 2008 [Page 22]
Internet-Draft 3G CDMA Fast Handover July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Yokota & Dommety Expires January 10, 2008 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-24 04:35:33 |