Network Working Group H. Yokota
Internet-Draft KDDI Lab
Intended status: Standards Track K. Chowdhury
Expires: March 7, 2010 R. Koodli
Starent Networks
B. Patil
Nokia
F. Xia
Huawei USA
September 3, 2009
Fast Handovers for Proxy Mobile IPv6
draft-ietf-mipshop-pfmipv6-09.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 March 7, 2010.
Yokota, et al. Expires March 7, 2010 [Page 1]
Internet-Draft Proxy-based Fast Handover September 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Yokota, et al. Expires March 7, 2010 [Page 2]
Internet-Draft Proxy-based Fast Handover September 2009
Abstract
Mobile IPv6 (MIPv6) [RFC3775] provides a mobile node with IP mobility
when it performs a handover from one access router to another and
fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] are specified to
enhance the handover performance in terms of latency and packet loss.
While MIPv6 (and FMIPv6 as well) requires the participation of the
mobile node in the mobility-related signaling, Proxy Mobile IPv6
(PMIPv6) [RFC5213] provides IP mobility to mobile nodes that either
have or do not have MIPv6 functionality without such involvement.
Nevertheless, the basic performance of PMIPv6 in terms of handover
latency and packet loss is considered not any different from that of
MIPv6. When the fast handover is considered in such an environment,
several modifications are needed to FMIPv6 to adapt to the network-
based mobility management. This document specifies the usage of Fast
Mobile IPv6 (FMIPv6) when Proxy Mobile IPv6 is used as the mobility
management protocol. Necessary extensions are specified for FMIPv6
to support the scenario when the mobile node does not have IP
mobility functionality and hence is not involved with either MIPv6 or
FMIPv6 operations.
Yokota, et al. Expires March 7, 2010 [Page 3]
Internet-Draft Proxy-based Fast Handover September 2009
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proxy-based FMIPv6 Protocol Overview . . . . . . . . . . . . . 8
4.1. Protocol Operation . . . . . . . . . . . . . . . . . . . . 9
4.2. Inter-AR Tunneling Operation . . . . . . . . . . . . . . . 15
4.3. IPv4 Support Considerations . . . . . . . . . . . . . . . 16
5. PMIPv6-related Fast Handover Issues . . . . . . . . . . . . . 17
5.1. Manageability Considerations . . . . . . . . . . . . . . . 17
5.2. Expedited Packet Transmission . . . . . . . . . . . . . . 17
6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 19
6.1.1. Handover Initiate (HI) . . . . . . . . . . . . . . . . 19
6.1.2. Handover Acknowledge (HAck) . . . . . . . . . . . . . 21
6.2. Mobility Options . . . . . . . . . . . . . . . . . . . . . 23
6.2.1. Context Request Option . . . . . . . . . . . . . . . . 23
6.2.2. Local Mobility Anchor Address (LMAA) Option . . . . . 24
6.2.3. Mobile Node Interface Identifier (MN IID) Option . . . 25
6.2.4. Home Network Prefix Option . . . . . . . . . . . . . . 25
6.2.5. Link-local Address Option . . . . . . . . . . . . . . 25
6.2.6. GRE Key Option . . . . . . . . . . . . . . . . . . . . 25
6.2.7. IPv4 Address Option . . . . . . . . . . . . . . . . . 26
6.2.8. Vendor-Specific Mobility Option . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Applicable Use Cases . . . . . . . . . . . . . . . . 31
A.1. PMIPv6 Handoff Indication . . . . . . . . . . . . . . . . 31
A.2. Local Routing . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Yokota, et al. Expires March 7, 2010 [Page 4]
Internet-Draft Proxy-based Fast Handover September 2009
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 [RFC2119].
Yokota, et al. Expires March 7, 2010 [Page 5]
Internet-Draft Proxy-based Fast Handover September 2009
2. Introduction
Proxy Mobile IPv6 [RFC5213] provides IP mobility to a mobile node
that does not possess Mobile IPv6 [RFC3775] mobile node
functionality. A proxy agent in the network performs the mobility
management signaling on behalf of the mobile node. This model
transparently provides mobility for mobile nodes within a PMIPv6
domain. Nevertheless, the basic performance of PMIPv6 in terms of
handover latency and packet loss is considered not any different from
that of Mobile IPv6.
Fast Handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes the
protocol to reduce the handover latency for Mobile IPv6 by allowing a
mobile node to send packets as soon as it detects a new subnet link
and by delivering packets to the mobile node as soon as its
attachment is detected by the new access router. This document
describes necessary extensions to FMIPv6 to minimize handover delay
and packet loss as well as to transfer network-resident context for a
PMIPv6 handover.
Yokota, et al. Expires March 7, 2010 [Page 6]
Internet-Draft Proxy-based Fast Handover September 2009
3. Terminology
This document reuses terminology from [RFC5213], [RFC5568] and
[RFC3775]. The following terms and abbreviations are additionally
used in this document.
Access Network (AN):
A network composed of link-layer access devices such as access
points or base stations providing access to the Access Router
(AR) connected to it.
Previous Access Network (P-AN):
The access network to which the Mobile Node (MN) is attached
before handover.
New Access Network (N-AN):
The access network to which the Mobile Node (MN) is attached
after handover.
Previous Mobile Access Gateway (PMAG):
The MAG that manages mobility related signaling for the MN
before handover. In this document, the MAG and the Access
Router are collocated.
New Mobile Access Gateway (NMAG):
The MAG that manages mobility related signaling for the MN after
handover. In this document, the MAG and the Access Router (AR)
are collocated.
HO-Initiate:
A generic signaling message, sent from the P-AN to the PMAG that
indicates a MN handover. While this signaling is dependent on
the access technology, it is assumed that HO-Initiate can carry
the information to identify the MN and to assist the PMAG
resolve the NMAG and the new access point or the base station to
which the MN is moving to. The details of this message are
outside the scope of this document.
Yokota, et al. Expires March 7, 2010 [Page 7]
Internet-Draft Proxy-based Fast Handover September 2009
4. Proxy-based FMIPv6 Protocol Overview
If the MAGs can be informed of the detachment and/or attachment of
the MN in a timely manner via e.g. the lower layer signaling, it will
become possible to optimize the handover procedure, which involves
establishing a connection on the new link and signaling between
mobility agents, compared to the baseline specification of PMIPv6.
In order to further improve the performance during the handover, the
PFMIPv6 protocol in this document specifies a bi-directional tunnel
between the Previous MAG (PMAG) and the New MAG (NMAG) to tunnel
packets meant for the mobile node. In order to enable the NMAG to
send the Proxy Binding Update (PBU), the Handover Initiate (HI) and
Handover Acknowledge (HAck) messages in [RFC5568] are extended for
context transfer, in which parameters such as MN's Network Access
Identifier (NAI), Home Network Prefix (HNP), IPv4 Home Address, are
transferred from the PMAG. A new flag 'P' is defined for the HI and
HAck messages to distinguish from those in [RFC5568]. This flag MUST
be set in the entire document.
In this document, the Previous Access Router (PAR) and New Access
Router (NAR) are interchangeable with the PMAG and NMAG,
respectively. The reference network is illustrated in Figure 1.
Since a MN is not directly involved with IP mobility protocol
operations, it follows that the MN is not directly involved with fast
handover procedures either. Hence, the messages involving the MN in
[RFC5568] are not used when PMIPv6 is in use. More specifically, the
Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy
Router Advertisement (PrRtAdv), Fast Binding Update (FBU), Fast
Binding Acknowledgment (FBack) and the Unsolicited Neighbor
Advertisement (UNA) messages are not applicable in the PMIPv6
context.
Yokota, et al. Expires March 7, 2010 [Page 8]
Internet-Draft Proxy-based Fast Handover September 2009
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PAR |()_______)| NAR | .
. | (PMAG) | . . | (NMAG) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference network for fast handover
4.1. Protocol Operation
There are two modes of operation in FMIPv6 [RFC5568]. In the
predictive mode of fast handover, a bi-directional tunnel between the
PAR and NAR is established prior to the MN's attachment to the NAR.
In the reactive mode, this tunnel establishment takes place after the
MN attaches to the NAR. In order to alleviate the packet loss during
a MN's handover (especially when the MN is detached from both links),
the downlink packets for the MN need to be buffered either at the PAR
(PMAG) or NAR (NMAG), depending on when the packet forwarding is
performed. It is hence required that all MAGs have the capability
and enough resources to buffer packets for the MNs accommodated by
them. Note that the protocol operation specified in the document is
transparent to the LMA, hence there is no new functional requirement
or change on the LMA.
Since the MN is not involved in IP mobility signaling in PMIPv6, the
sequence of events illustrating the predictive fast handover are
shown in Figure 2.
Yokota, et al. Expires March 7, 2010 [Page 9]
Internet-Draft Proxy-based Fast Handover September 2009
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
| Report | | | | |
(a) |-(MN ID,-->| | | | |
| New AP ID)| | | | |
| | HO Initiate | | |
(b) | |--(MN ID, New AP ID)-->| | |
| | | | | |
| | | | HI | |
(c) | | | |-(MN ID, ->| |
| | | | MN IID, LMAA) |
| | | | | |
(d) | | | |<---HAck---| |
| | | | (MN ID) | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| | | | | |
(g) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
\ | | | | | | /
Figure 2: Predictive fast handover for PMIPv6 (PAR initiated)
The detailed descriptions are as follows:
(a) The MN detects that a handover is imminent and reports the
identifications of itself (MN ID) and the New Access Point
Identifier (New AP ID) [RFC5568] to which the MN is most likely
to move. The MN ID could be the NAI or a Link Layer Address
(LLA), or any other suitable identifier. This step is access
technology specific. In some cases, the P-AN will determine
Yokota, et al. Expires March 7, 2010 [Page 10]
Internet-Draft Proxy-based Fast Handover September 2009
which AP ID the MN is moving to.
(b) The previous access network (P-AN), to which the MN is currently
attached, indicates the handover of the MN to the PAR (PMAG).
Detailed definition and specification of this message are
outside the scope of this document.
(c) The PAR sends the HI to the NAR. The HI message MUST have the P
flag set and include the MN ID, the HNP, the MN IID and the
address of the LMA that is currently serving the MN.
(d) The NAR sends the HAck back to the PAR with the P flag set.
(e) If it is preferred that the timing of buffering or forwarding
should be later than step (c), the NAR may optionally request
the PAR at a later and appropriate time to buffer or forward
packets by setting U flag [RFC5568] or F flag in the HI message,
respectively.
(f) If the F flag is set in the previous step, a bi-directional
tunnel is established between the PAR and NAR and packets
destined for the MN are forwarded from the PAR to the NAR over
this tunnel. After decapsulation, those packets may be buffered
at the NAR. If the connection between the N-AN and NAR has
already been established, those packets may be forwarded towards
the N-AN, which then becomes responsible for them (e.g.,
buffering or delivering depending on the condition of the MN's
attachment); this is access technology specific.
(g) The MN undergoes handover to the New Access Network (N-AN).
(h) The MN establishes a physical link connection with the N-AN
(e.g., radio channel assignment), which in turn triggers the
establishment of a link-layer connection between the N-AN and
NAR if not yet established. An IP layer connection setup may be
performed at this time (e.g., PPP IPv6CP) or at a later time
(e.g., stateful or stateless auto address configuration). This
step can be a substitute for the UNA in [RFC5568], but since
they are all access technology specific, details are outside the
scope of this document.
(i) The NAR starts to forward packets destined for the MN via the
N-AN.
(j) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
Yokota, et al. Expires March 7, 2010 [Page 11]
Internet-Draft Proxy-based Fast Handover September 2009
(k) The NAR (NMAG) sends the Proxy Binding Update (PBU) to the LMA,
whose address is provided in (c). Steps (k) and (l) are not
part of the fast handover procedure, but shown for reference.
(l) The LMA sends back the Proxy Binding Acknowledgment (PBA) to the
NAR (NMAG). From this time on, the packets to/from the MN go
through the NAR instead of the PAR.
According to Section 4 of [RFC5568], the PAR establishes a binding
between the Previous Care-of Address (PCoA) and New Care-of Address
(NCoA) to forward packets for the MN to the NAR, and the NAR creates
a proxy neighbor cache entry to receive those packets for the NCoA
before the MN arrives. In the case of PMIPv6, however, the only
address that is used by the MN is MN-HoA (Mobile Node's Home
Address). Hence the PAR forwards MN's packets to the NAR instead of
the NCoA. FMIPv4 [RFC4988] specifies forwarding when the MN uses the
home address as its on-link address rather than the care-of address.
The usage in PMIPv6 is similar to that in FMIPv4, where the address
is used by the MN is based on Home Network Prefix. Hence the PAR
forwards MN's packets to the NAR instead of the NCoA. The NAR then
simply decapsulates those packets and delivers them to the MN. Since
the NAR obtains the LLA (MN IID) and HNP by the HI, it can create the
Neighbor Cache Entry for the MN and deliver packets to it even before
the MN can perform Neighbor Discovery. For the uplink packets from
the MN after handover in (j), the NAR forwards the packets to the PAR
through the tunnel established in step (f). The PAR then
decapsulates and sends them to the LMA.
The timing of the context transfer and that of packet forwarding may
be different. Thus, a new flag 'F' and Option Code values for it in
the HI and HAck messages are defined to request forwarding. To
request buffering, 'U' flag has already been defined in [RFC5568].
If the PAR receives the HI message with the F flag set, it starts
forwarding packets for the MN. The HI message with the U flag set
may be sent earlier if the timing of buffering is different from that
of forwarding. If packet forwarding is completed, the PAR MAY send
the HI message with the F flag set and the Option Code value being 2.
By this message, the ARs on both ends can tear down the forwarding
tunnel synchronously.
The IP addresses in the headers of those user packets are summarized
below:
In Step (f),
Yokota, et al. Expires March 7, 2010 [Page 12]
Internet-Draft Proxy-based Fast Handover September 2009
Inner source address: IP address of the CN
Inner destination address: HNP or Mobile Node's IPv4 Home
Address (IPv4-MN-HoA)
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the NAR (NMAG)
In Step (i),
Source address: IP address of the CN
Destination address: HNP or IPv4-MN-HoA
In Step (j),
- from the MN to the NMAG,
Source address: HNP or IPv4-MN-HoA
Destination address: IP address of the CN
- from the NMAG to the PMAG,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the NAR (NMAG)
Outer destination address: IP address of the PAR (PMAG)
- from the PMAG to the LMA,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the CN
Outer source address: IP address of the PAR (PMAG)
Outer destination address: IP address of the LMA
The encapsulation type for these user packets SHOULD follow that used
in the tunnel between the LMA and MAG (IPv6-in-IPv6 as specified in
[RFC2473], IPv6-in-IPv4, IPv6-in-IPv4-UDP as specified in
[IPv4PMIPv6], TLV-header UDP tunneling as specified in [GREKEY] or
any new method defined in the future).
Yokota, et al. Expires March 7, 2010 [Page 13]
Internet-Draft Proxy-based Fast Handover September 2009
In the case of the reactive handover for PMIPv6, since the MN does
not send either the FBU or UNA, it would be more natural that the NAR
sends the HI to the PAR after the MN has moved to the new link. The
NAR then needs to obtain the information of the PAR beforehand. Such
information could be provided, for example, by the MN sending the
AP-ID on the old link and/or by the lower-layer procedures between
the P-AN and N-AN. The exact method is not specified in this
document. Figure 3 illustrates the reactive fast handover procedures
for PMIPv6, where the bi-directional tunnel establishment is
initiated by the NAR.
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
|(MN ID, Old AP ID) | (MN ID, Old AP ID) | |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | HI | |
(c) | | | |<---(MN ID) ---| |
| | | | | |
| | | | HAck | |
(d) | | | |---(MN ID, --->| |
| | | | MN IID, LMAA) | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
\ | | | | | | /
Figure 3: Reactive fast handover for PMIPv6 (NAR initiated)
The detailed descriptions are as follows:
Yokota, et al. Expires March 7, 2010 [Page 14]
Internet-Draft Proxy-based Fast Handover September 2009
(a) The MN undergoes handover from the P-AN to the N-AN. The AP-ID
on the old link may be provided by the MN to help identify the
PMAG on the new link.
(b) The MN establishes a connection (e.g., radio channel) with the
N-AN, which triggers the establishment of the connection between
the N-AN and NAR. The MN ID is transferred to the NAR for the
subsequent procedures. The AP-ID on the old link may also be
provided by the MN to help identify the PMAG on the new link.
This can be regarded as a substitute for the UNA and FBU.
(c) The NAR sends the HI to the PAR. The HI message MUST have the P
flag set and include the MN ID. The Context Request Option MAY
be included to request additional context information on the MN
to the PAR.
(d) The PAR sends the HAck back to the NAR with the P flag set. The
HAck message MUST include the HNP and/or IPv4-MN-HoA that is
corresponding to the MN ID in the HI message and SHOULD include
the MN IID and the LMA address that is currently serving the MN.
The context information requested by the NAR MUST be included.
If the requested context is not available for some reason, the
PAR MUST return the HAck with the Code value 131. If the F flag
is set in the HI at step (c) and forwarding is nevertheless not
executable for some reason, the PAR MUST return the HAck with
the Code value 132.
(e) If the F flag in the HI is set at step (c), a bi-directional
tunnel is established between the PAR and NAR and packets
destined for the MN are forwarded from the PAR to the NAR over
this tunnel. After decapsulation, those packets are delivered
to the MN via the N-AN.
(f) The uplink packets from the MN are sent to the NAR via the N-AN
and the NAR forwards them to the PAR. The PAR then sends the
packets to the LMA that is currently serving the MN.
Steps (g)-(h) are the same as (k)-(l) in the predictive fast handover
procedures.
In step (c), The IP address of the PAR needs to be resolved by the
NAR to send the HI to the PAR. This information may come from the
N-AN or some database that the NAR can access.
4.2. Inter-AR Tunneling Operation
When the PMAG (PAR) or NMAG (NAR), depending on the fast handover
mode, receives the HI message with the F flag set, it prepares to
Yokota, et al. Expires March 7, 2010 [Page 15]
Internet-Draft Proxy-based Fast Handover September 2009
send/receive the MN's packets to/from the other MAG and returns the
HAck message with the same sequence number. The necessary
information MUST be transferred in the HI message to distinguish MN's
packets for forwarding in advance or at this time. Such information
includes the HoA of the MN and/or GRE key(s). For the downlink
packets, the PMAG redirects MN's packets from the LMA towards the
NMAG and if the MN is ready to receive those packets or the N-AN can
handle them regardless of the state of the MN, the NAR should
immediately send them towards the N-AN; otherwise it should buffer
them until the MN is ready. For the uplink packets, the NMAG SHOULD
reverse-tunnel them from the MN towards the PMAG and the PMAG sends
them to the LMA.
When the PMAG or NMAG receives the HI message with the U flag set, it
prepares to buffer the MN's packets and returns the HAck message with
the same sequence number. It MUST be followed by another HI message
with the F flag set at an appropriate time to forward the buffered
packets.
If the MAG that received the HI message encounters an erroneous
situation (e.g., insufficient buffer space), it SHOULD immediately
send the HAck message with the cause of the error and cancel all
tunneling operation.
4.3. IPv4 Support Considerations
The motivation and usage scenarios of IPv4 protocol support by PMIPv6
are described in [IPv4PMIPv6]. The scope of IPv4 support covers the
following two features:
o IPv4 Home Address Mobility Support, and
o IPv4 Transport Support.
As for IPv4 Home Address Mobility Support, the MN acquires IPv4 Home
Address (IPv4-MN-HoA) and in the case of handover, the PMAG needs to
transfer IPv4-MN-HoA to the NMAG, which is the inner destination
address of the packets forwarded on the downlink. For this purpose,
a new option called IPv4 Address Option is defined in this document.
In order to provide IPv4 Transport Support, the NMAG needs to know
the IPv4 address of the LMA (IPv4-LMAA) to send PMIPv6 signaling
messages to the LMA in the IPv4 transport network. In this case, a
new option called LMA Address (LMAA) option is used so as to convey
IPv4-LMAA from the PMAG to NMAG. The supported encapsulation type
follows Section 6.10.2 in [RFC5213], that is, IPv4, IPv4-UDP and
IPv4-UDP-TLV.
Yokota, et al. Expires March 7, 2010 [Page 16]
Internet-Draft Proxy-based Fast Handover September 2009
5. PMIPv6-related Fast Handover Issues
5.1. Manageability Considerations
This specification does not require any additional IP-level
functionality on the LMA and the MN running in the PMIPv6 domain. A
typical network interface that the MN could be assumed to have is one
with the cellular network, where the network controls the movement of
the MN. Different types of interfaces could be involved such as
different generations (3G and 3.9G) or different radio access
systems. This specification supports a MN with the single radio
mode, where only one interface is active at any given time. The
assigned IP address is preserved whether the physical interface
changes or not and the MN can identify which interface should be used
if there are multiple ones.
5.2. Expedited Packet Transmission
The protocol specified in this document enables the NMAG to obtain
parameters which would otherwise be available only by communicating
with the LMA. For instance, the HNP and/or IPv4-MN-HoA of a MN are
made available to the NMAG through context transfer. This allows the
NMAG to perform some procedures that may be beneficial. For
instance, the NMAG could send a Router Advertisement (RA) with the
HNP option to the MN as soon as its link attachment is detected
(e.g., via receipt of a Router Solicitation message). Such an RA is
recommended, for example, in scenarios where the MN uses a new radio
interface while attaching to the NMAG; since the MN does not have
information regarding the new interface, it will not be able to
immediately send packets without first receiving an RA with HNP.
Especially, in the reactive fast handover, the NMAG gets to know the
HNP assigned to the MN on the previous link at step (d) in Figure 3.
In order to reduce the communication disruption time, the NMAG SHOULD
expect the MN to keep using the same HNP and to send uplink packets
before that step upon the MN's request. However, if the HAck from
the PMAG returns a different HNP or the subsequent PMIPv6 binding
registration for the HNP fails for some reason, then the NMAG MUST
withdraw the advertised HNP by sending another RA with zero prefix
lifetime for the HNP in question. This operation is the same as
described in Section 6.12 of [RFC5213].
The protocol specified in this document is applicable regardless of
whether link-layer addresses are used between a MN and its access
router. A MN should be able to continue sending packets on the
uplink even when it changes link. When link-layer addresses are
used, the MN performs Neighbor Unreachability Detection (NUD)
[RFC4861], after attaching to a new link, probing the reachability of
its default router. The new router should respond to the NUD probe,
Yokota, et al. Expires March 7, 2010 [Page 17]
Internet-Draft Proxy-based Fast Handover September 2009
providing its link-layer address in the solicited Neighbor
Advertisement, which is common in the PMIPv6 domain. Implementations
should allow the MN to continue to send uplink packets while it is
performing NUD.
Yokota, et al. Expires March 7, 2010 [Page 18]
Internet-Draft Proxy-based Fast Handover September 2009
6. Message Formats
This document defines new Mobility Header messages for the extended
HI and Hack and new mobility options for conveying context
information.
6.1. Mobility Header
6.1.1. Handover Initiate (HI)
This section defines extensions to the HI message in [RFC5568]. The
format of the Message Data field in the Mobility Header is as
follows:
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
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
IP Fields:
Source Address
The IP address of PMAG or NMAG
Destination Address
The IP address of the peer MAG
Message Data:
Sequence # Same as [RFC5568].
S flag Defined in [RFC5568] and MUST be set to zero in this
specification.
Yokota, et al. Expires March 7, 2010 [Page 19]
Internet-Draft Proxy-based Fast Handover September 2009
U flag Buffer flag. Same as [RFC5568].
P flag Proxy flag. Used to distinguish the message from that
defined in [RFC5568] and to indicate that it follows the
specification in this document.
F flag Forwarding flag. Used to request to forward the packets
for the MN.
Reserved Same as [RFC5568].
Code [RFC5568] defines this field and its values 0 and 1. In
this specification, with the P flag set, this field can
be set to zero by default or the following values:
2: Indicate the completion of forwarding
3: All available context transferred
Code value 3 is set when the transfer of all necessary
context information is completed with this message. This
Code value is used in both cases where the context
information is fragmented into several pieces and the
last fragment is contained in this message and where the
whole information is transferred in one piece.
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [RFC3775].
Requested option
In order to uniquely identify the target MN, the MN
Identifier MUST be contained in the Mobile Node Identifier
Option.
The transferred context MUST be for one MN per message. In addition,
the NAR can request necessary mobility options by the Context Request
Option defined in this document.
Context Request Option
This option MAY be present to request context information
typically by the NAR to the PAR in the NAR-initiated fast
handover.
Yokota, et al. Expires March 7, 2010 [Page 20]
Internet-Draft Proxy-based Fast Handover September 2009
6.1.2. Handover Acknowledge (HAck)
This section defines extensions to the HAck message in[RFC5568]. The
format of the Message Data field in the Mobility Header is as
follows:
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
+-------------------------------+
| Sequence # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
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.
Message Data:
The usages of Sequence # and Reserved fields are exactly the same as
those in [RFC5568].
U flag Same as defined in Section 6.1.1.
P flag Used to distinguish the message from that defined in
[RFC5568] and to indicate that it follows the
specification in this document.
Yokota, et al. Expires March 7, 2010 [Page 21]
Internet-Draft Proxy-based Fast Handover September 2009
F flag Same as defined in Section 6.1.1.
Code
Code values 0 through 4 and 128 through 130 are defined
in [RFC5568]. In this specification, the meaning of Code
value 0 is modified, 128 through 130 are reused, and 5,
6, 131 and 132 are newly defined.
0: Handover Accepted or Successful
5: Context Transfer Accepted or Successful
6: All available Context Transferred
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
131: Requested Context Not Available
132: Forwarding Not Available
Mobility options:
This field contains one or more mobility options, whose encoding and
formats are defined in [RFC3775]. The mobility option that uniquely
identifies the target MN MUST be copied from the corresponding HI
message and the transferred context MUST be for one MN per message.
Requested option(s) All the context information requested by the
Context Request Option in the HI message SHOULD be present
in the HAck message. The other cases are described below.
In the case of the PAR-initiated fast handover, when the PAR sends
the HI message to the NAR with the context information and the NAR
successfully receives it, the NAR returns the HAck message with Code
value 5. In the case of the NAR-initiated fast handover, when the
NAR sends the HI message to the PAR with or without Context Request
Option, the PAR returns the HAck message with the requested or
default context information (if any). If all available context
information is transferred, the PAR sets the Code value in the HAck
message to 6. If more context information is available, the PAR sets
the Code value in the HAck to 5 and the NAR MAY send new HI
message(s) to retrieve the rest of the available context information.
If none of the requested context information is available, the PAR
returns the HAck message with Code value 131 without any context
Yokota, et al. Expires March 7, 2010 [Page 22]
Internet-Draft Proxy-based Fast Handover September 2009
information.
6.2. Mobility Options
6.2.1. Context Request Option
This option is sent in the HI message to request context information
on the MN. If a default set of context information is defined and
always sufficient, this option is not mandatory. This option is more
useful to retrieve additional or dynamically selected context
information.
Context Request Option is typically used for the reactive (NAR-
initiated) fast handover mode to retrieve the context information
from the PAR. When this option is included in the HI message, all
the requested context information SHOULD be included in the HAck
message in the corresponding mobility option(s) (e.g., HNP, LMAA or
MN IID mobility options).
The default context information to request is the Home Network Prefix
Option. If the Mobile Node link-layer is available and used, the
Mobile Node Link-layer Identifier Option MUST also be requested.
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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| ... |
Option-Type TBD1
Option-Length The length in octets of this option, not including the
Option Type and Option Length fields.
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Req-type-n The type value for the n'th requested option.
Req-length-n The length of the n'th requested option excluding the
Req-type-n and Req-length-n fields.
In the case where there are only Req-type-n and Req-length-n fields,
the value of the Req-length-n is set to zero. If additional
information besides the Req-type-n is necessary to uniquely specify
Yokota, et al. Expires March 7, 2010 [Page 23]
Internet-Draft Proxy-based Fast Handover September 2009
the requested context, such information follows after the
Req-length-n. For example, when the requested context is the Vendor-
Specific Option described in Section 6.2.8, the requested option
format looks as follows:
| ... |
+---------------+---------------+-------------------------------+
| Req-type-N=19 | Req-length-N=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |
The exact values in the Vendor-ID and Sub-Type are outside the scope
of this document.
6.2.2. Local Mobility Anchor Address (LMAA) Option
This option is used to transfer the Local Mobility Anchor IPv6
Address (LMAA) or its IPv4 Address (IPv4-LMAA), with which the MN is
currently registered. The detailed definition of the LMAA is
described in [RFC5213].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |
Option-Type TBD2
Option-Length 18 or 6
Option-Code
0 Reserved
1 IPv6 address of the LMA (LMAA)
2 IPv4 address of the LMA (IPv4-LMAA)
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Yokota, et al. Expires March 7, 2010 [Page 24]
Internet-Draft Proxy-based Fast Handover September 2009
Local Mobility Anchor Address
If Option-Code is 1, the LMA IPv6 address (LMAA) is
inserted. If Option-Code is 2, the LMA IPv4 address
(IPv4-LMA) is inserted.
6.2.3. Mobile Node Interface Identifier (MN IID) Option
This option is used to transfer the interface identifier of the MN
that is used in the P-AN.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option-Type TBD3
Option-Length 10
Reserved This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Interface Identifier
The Interface Identifier value of the MN that is used
in the P-AN.
6.2.4. Home Network Prefix Option
This option is used to transfer the home network prefix that is
assigned to the MN in the P-AN. The Home Network Prefix Option
defined in [RFC5213] is used for this.
6.2.5. Link-local Address Option
This option is used to transfer the link-local address of the PAR
(PMAG). The Link-local Address Option defined in [RFC5213] is used
for this.
6.2.6. GRE Key Option
This option is used to transfer the GRE Key for the MN's data flow
over the bi-directional tunnel between the PAR and NAR. The message
format of this option follows the GRE Key Option defined in [GREKEY].
Yokota, et al. Expires March 7, 2010 [Page 25]
Internet-Draft Proxy-based Fast Handover September 2009
The GRE Key value uniquely identifies each flow and the sender of
this option expects to receive packets of the flow from the peer AR
with this value.
6.2.7. IPv4 Address Option
As described in Section 4.3, if the MN runs in IPv4-only mode or
dual-stack mode, it requires IPv4 home address (IPv4-MN-HoA). This
option is used to transfer the IPv4 home address if assigned on the
previous link. The format of this option follows the IPv4 Home
Address Request Option defined in [IPv4PMIPv6].
6.2.8. Vendor-Specific Mobility Option
This option is used to transfer any other information defined in this
document. The format of this option follows the Vendor-Specific
Mobility Option defined in [RFC5094]. The exact values in the Vendor
ID, Sub-Type and Data fields are outside the scope of this document.
Yokota, et al. Expires March 7, 2010 [Page 26]
Internet-Draft Proxy-based Fast Handover September 2009
7. Security Considerations
Security issues for this document follow those for PMIPv6 [RFC5213]
and FMIPv6 [RFC5568]. In PMIPv6, the MAG and LMA are assumed to
share security associations. In FMIPv6, the access routers (i.e.,
the PMAG and NMAG in this document) are assumed to share security
associations.
The Handover Initiate (HI) and Handover Acknowledgement (HAck)
messages exchanged between the PMAG and NMAG MUST be protected using
end-to-end security association(s) offering integrity and data origin
authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301]
for protecting the HI and HAck messages. IPsec Encapsulating
Security Payload (ESP) [RFC4303] in transport mode with mandatory
integrity protection SHOULD be used for protecting the signaling
messages. Confidentiality protection SHOULD be used if sensitive
context related to the mobile node is transferred.
IPsec ESP [RFC4303] in tunnel mode MAY be used to protect the MN's
packets at the time of forwarding if protection of data traffic is
required.
Yokota, et al. Expires March 7, 2010 [Page 27]
Internet-Draft Proxy-based Fast Handover September 2009
8. IANA Considerations
This document defines three new mobility options, which are described
in Section 6.2. The Type value for these options are assigned from
the same numbering space as allocated for the other mobility options,
as defined in [RFC3775].
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
TBD1 Context Request Option Section 6.2.1
TBD2 Local Mobility Anchor Address Option Section 6.2.2
TBD3 Mobile Node Interface Identifier Option Section 6.2.3
Yokota, et al. Expires March 7, 2010 [Page 28]
Internet-Draft Proxy-based Fast Handover September 2009
9. Acknowledgments
The authors would like to specially thank Vijay Devarapalli and Sri
Gundavelli for their thorough reviews of this document.
The authors would also like to thank Charlie Perkins, Desire Oulai,
Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan
Zhao, Julien Laganier and Pierrick Seite for their passionate
discussions in the working group mailing list.
Yokota, et al. Expires March 7, 2010 [Page 29]
Internet-Draft Proxy-based Fast Handover September 2009
10. References
10.1. Normative References
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568,
July 2009.
[RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775,
June 2004.
[RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers",
RFC 4988, October 2007.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", RFC 5094, December 2007.
10.2. Informative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[IPv4PMIPv6]
Wakikawa, R., Ed. and S. Gundavelli, "IPv4 Support for
Proxy Mobile IPv6",
draft-ietf-netlmm-pmip6-ipv4-support-15.txt, August 2009.
[GREKEY] Muhanna, A., Ed., "GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-09.txt, May 2009.
Yokota, et al. Expires March 7, 2010 [Page 30]
Internet-Draft Proxy-based Fast Handover September 2009
Appendix A. Applicable Use Cases
A.1. PMIPv6 Handoff Indication
PMIPv6 [RFC5213] defines the Handoff Indicator Option and describes
the type of the handoff and the values to set to the option. This
document proposes one approach to determining the handoff type by the
NMAG when the handoff of the MN is executed.
According to [RFC5213], the following handoff types are defined:
0) Reserved
1) Attachment over a new interface
2) Handoff between two different interfaces of the mobile node
3) Handoff between mobile access gateways for the same interface
4) Handoff state unknown
5) Handoff state not changed (Re-registration)
By using the MN Interface Identifier (MN IID) option, which is
defined in this document, the following solution can be considered.
When the NMAG receives the MN IID used in the P-AN from the PMAG via
the HI or HAck messages, the NMAG compares it with the new MN IID
that is obtained from the MN in the N-AN. If these two MN IIDs are
the same, the handover type falls into 3) and the Handoff Indicator
value is set to 3. If these two MN IIDs are different, the handover
is likely to be 2) since the HI/HAck message exchange implies that
this is a handover not a multi-homing, therefore the Handoff
Indicator value can be set to 2. If there is no HI/HAck exchange
performed prior to the network attachment of the MN in the new
network, the NMAG may infer that this is a multi-homing case and set
the Handoff Indicator value to 1. In the case of re-registration,
the MAG, to which the MN is attached, can determine if the handoff
state is not changed, so the MAG can set the HI value to 5 without
any additional information. If none of them can be assumed, the NMAG
may set the value to 4.
A.2. Local Routing
Section 6.10.3 in [RFC5213] describes that if EnableMAGLocalRouting
flag is set, when two mobile nodes are attached to one MAG, the
traffic between them may be locally routed. If one mobile node moves
from this MAG (PMAG) to another MAG (NMAG) and if the PMAG does not
detect the MN's detachment, it will continue to forward packets
Yokota, et al. Expires March 7, 2010 [Page 31]
Internet-Draft Proxy-based Fast Handover September 2009
locally forever. This situation is more likely to happen in the
reactive fast handover with WLAN access, which does not have the
capability to detect the detachment of the MN in a timely manner.
PFMIPv6 can be applied to handle this case. When the MN attaches to
the NMAG, it sends the HI message to the PMAG, which makes it realize
the detachment of the MN. The PMAG immediately stops the local
routing and sends the packets for the MN towards the LMA, which in
turn forwards them to the NMAG over the PMIPv6 tunnel.
Yokota, et al. Expires March 7, 2010 [Page 32]
Internet-Draft Proxy-based Fast Handover September 2009
Appendix B. Change Log
Changes at -00
* Added separate sections for MH and ICMP.
* Clarified usage of HNP and IPv4-MN-HoA throughout the document.
* Added IANA Considerations.
* Added section on Other Considerations, including operation of
uplink packets when using link-layer addresses, multiple
interface usage and transmission of RA to withdraw HNP in the
event of failure of PMIP6 registration.
* Revised Security Considerations.
Changes from -00 to -01
* Removed ICMPv6-based message format.
* Clarified HI/HAck exchange in the predictive mode (step (e) in
Figure 2).
* Clarified information retrieval about the PMAG in the reactive
mode.
* Removed the extension to the GRE Key Option.
* Clarified the handoff type considerations in Appendix A.
* Home Network Prefix Option, Link-local Address Option and
Vendor-Specific Mobility Option are added.
Changes from -01 to -02
* Aligned HI/HAck message formats with
draft-ietf-mipshop-rfc5268bis-00.txt.
* Revised Section 8 removing the request for the type assignment
of HI/HAck Mobility Headers.
Changes from -02 to -03
* Updated HI/HAck message formats according to
draft-ietf-mipshop-rfc5268bis-01.txt.
Yokota, et al. Expires March 7, 2010 [Page 33]
Internet-Draft Proxy-based Fast Handover September 2009
* Cleaned up Figure 2 and Figure 3.
* Moved PMIP domain boundary crossing situation in Section 4.1 to
Appendix A.3.
* Removed the alternative protocol operation with an unsolicited
HAck from Section 4.1.
* Modified Code values in the HAck message in order to avoid
collision with those in draft-ietf-mipshop-rfc5268bis-01.txt.
* Clarified the usage scenarios of Context Request Option.
* Modified the description of Code values in the HAck message.
* Changed the container for the IPv4-LMAA from IPv4 Address
option to the LMAA option.
* Made Confidentiality protection "SHOULD" for context transfer.
Changes from -03 to -04
* Added more explanations about MIPv6, FMIPv6 and PMIPv6 in
Abstract.
* Moved Figure 1 to Section 4.
* More clearly indicated the FMIPv6 messages that are not
applicable in the PMIPv6 context.
* Mandated the support of IP Sec on the PMAG and NMAG in order to
protect signaling and user packets and the context information.
* Added a new section for the inter-AR tunneling operation
(Section 4.2).
* Added descriptions about the encapsulation type in Sections 4.1
and 4.3.
* Added a description about buffering requirements on the MAG in
Section 4.1.
* Added a description about the timing of L2 and L3 connection
establishments in Section 4.1.
* Added a new section for PMIPv6-related fast handover issues
(Section 5) and a description about preferable behaviors of the
MN and MAG to reduce packet loss.
Yokota, et al. Expires March 7, 2010 [Page 34]
Internet-Draft Proxy-based Fast Handover September 2009
* Added Acknowledgments section (Section 9).
* Added a new section for local routing in Appendix (A.2).
Changes from -04 to -05
* Fixed Figure 2 (step (i)).
* Defined the Mobile Network Interface Identifier (MN-IID)
mobility option in Section 6.2.4 (swapped with old Section
6.2.5), and added it to IANA considerations (Section 8).
* Changed from SHOULD to MUST regarding the inclusion of the
MN-ID, MN-HNP, MN-IID and the LMAA options in the HI message
(step (c) in Section 4.1).
* The optional behavior of the NMAG that allows it to send uplink
packets directly to the LMA before the PBU/PBA exchange was
removed from section 4.2 (as out of scope).
* In Section A.3, the description about the HA address assignment
from the NAR to the MN was removed (as out of scope).
Changes from -05 to -06
* Added 'P' flag in the HI and Hack messages to distinguish them
from those in FMIPv6.
* Made editorial corrections in Section 2 (Introduction), Section
3 (Terminology), Section 4 (Protocol Overview) and Section 4.2
(Inter-AR Tunneling Operation).
* Added a description on how forwarded packets should be handled
in the access network at step (f) in Section 4.1.
* Added all types of encapsulation methods that should be
supported in Section 4.1.
* Revised the Code values for the HI message in Section 6.1.1.
* Revised the Code values for the HAck message in Section 6.1.2
and added a description of its usage at step (d) of the
reactive handover mode in Section 4.1.
* Removed the definition of the IP Address Option in Section
6.2.3 and moved to Section 6.2.7, which currently refers to the
IPv4 Home Address Option defined by RFC5555. Revised the IANA
Consideration section accordingly.
Yokota, et al. Expires March 7, 2010 [Page 35]
Internet-Draft Proxy-based Fast Handover September 2009
* Removed the Option-Code from the Mobile Node Identifier (MN
IID) Option.
* Removed Appendix A.3 (Handling of PMIPv6/MIPv6 switching).
Changes from -06 to -07
* Added explanations about defining and setting the 'P' flag for
the HI and Hack messages in Sections 4 and 4.1.
* Corrected the references for the encapsulation types in Section
4.1.
* Modified the Code values for the HI message in Section 6.1.1 to
avoid overlapping with those in
draft-ietf-mipshop-rfc5268bis-01.txt.
* Modified the reference for the IPv4 Address Option from RFC5555
to [IPv4PMIPv6] in Section 6.2.7.
Changes from -07 to -08
* Corrected the reference for the TLV-header UDP encapsulation in
Section 4.1.
* Updated the version number of the reference document
[IPv4PMIPv6] and the option name defined by that document in
Section 6.2.7.
Changes from -08 to -09
* Added a paragraph at the beginning of Section 4 describing the
assumption related to the lower layer signaling.
* Added a new section on the manageability considerations in
Section 5 describing the configurations on the network and the
mobile node assumed in this document.
* Modified the assumed configuration of the MAG regarding its
link-layer address in Section 5 (Section 5.2 in version -09).
* Specified the requested option to identify the target MN for
the inter-AR tunneling in Section 6.1.1.
* Specified the default context information in the Context
Request Option in Section 6.2.1.
Yokota, et al. Expires March 7, 2010 [Page 36]
Internet-Draft Proxy-based Fast Handover September 2009
Authors' Addresses
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Email: yokota@kddilabs.jp
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Email: kchowdhury@starentnetworks.com
Rajeev Koodli
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Email: rkoodli@starentnetworks.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
US
Email: basavaraj.patil@nokia.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
US
Email: xiayangsong@huawei.com
Yokota, et al. Expires March 7, 2010 [Page 37]
