Internet DRAFT - draft-ietf-mipshop-fmip-ptp
draft-ietf-mipshop-fmip-ptp
Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Informational Huawei USA
Expires: June 17, 2013 December 14, 2012
Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links
draft-ietf-mipshop-fmip-ptp-05
Abstract
Mobile IPv6 Fast Handovers specification currently does not
explicitly define prefix management over point-to-point links when a
mobile node uses a prefix to formulate a new care-of-address. In
this document a mechanism is developed for a previous access router
to request unique prefixes from a new access router, and in turn, the
previous access router advertises the prefixes to the mobile node for
a new care-of-address configuration. Extensions to Mobile IPv6 Fast
Handovers specification are also specified in this document.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 17, 2013.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Xia & Sarikaya Expires June 17, 2013 [Page 1]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
4. Prefix Management on Point-to-Point Links . . . . . . . . . . . 5
4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . . 6
5. HI and Hack Extensions . . . . . . . . . . . . . . . . . . . . 7
5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative references . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Xia & Sarikaya Expires June 17, 2013 [Page 2]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
1. Introduction
Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568] aims at reducing the
handover latency by reducing the time to configure a new care-of
address (NCoA) for a mobile node(MN). In FMIPv6, the MN formulates a
prospective NCoA when it is still present on a link of a previous
access router (PAR).
[RFC4968] provides different IPv6 link models that are suitable for
IEEE802.16 based networks and provides analysis of various
considerations for each link model and the applicability of each link
model under different deployment scenarios. [RFC5121] specifies the
addressing and operation of IPv6 over the IPv6 specific part of the
packet convergence sublayer of IEEE Std 802.16e [802.16e], and point-
to-point link model is recommended. Also, 3GPP and 3GPP2 have
adopted the point-to-point link model based on the recommendations in
[RFC3314].
In this document, we first explain the problems associated with
FMIPv6 on point-to-point links followed by a detailed description of
prefix management for FMIPv6 operation on point-to-point links.
In Section 3 we describe why the point-to-point link address
formation procedures are needed in FMIPv6, in Section 4 we define a
procedure that a new access router (NAR) can use to dynamically
assign unique prefixes in point-to-point links and in Section 5 we
define necessary messages/options for the operation in Section 4.
2. Terminology
The terminology in this document is based on the definitions in
[RFC5568], in addition to the ones specified in this section.
point-to-point link model: In this model, a set of layer 2 transport
connections between a MN and an access router (AR) are treated as
a single link. Each link is allocated a separate, unique prefix
or a set of unique prefixes by the AR. Please refer to [RFC4968]
for details.
shared link model: In this model, one or more prefixes are shared by
mobile nodes for constructing their global IPv6 addresses. Please
refer to [RFC4968] for details.
Xia & Sarikaya Expires June 17, 2013 [Page 3]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
dedicated prefix: In point-to-point link model, a unique prefix used
by a MN for formulating a NCoA while the MN is still on a PAR's
link.
3. Problem Statement
The following are operations relating to prefix management as per
[RFC5568]:
o Movement detection. The protocol enables a MN to quickly detect
that it has moved to a new subnet by providing the new access
point and the associated subnet prefix information when the MN is
still connected to its current subnet. For instance, the MN may
discover available access points using link-layer specific
mechanisms (i.e., a "scan" in WLAN) and then request subnet
information corresponding to one or more of those discovered
access points. The MN sends a Router Solicitation for Proxy
Advertisement (RtSolPr) to its access router to resolve one or
more Access Point Identifiers (AP-ID)to subnet-specific
information. In response, the access router sends a Proxy Router
Advertisement (PrRtAdv) message containing one or more [AP-ID, AR-
Info] tuples, which the MN can use in readily detecting movement:
when attachment to an access point with AP-ID takes place, the MN
knows the corresponding new router's coordinates including its
prefix, IP address, and L2 address. In this document, there is no
changes to the movement detection procedure specified in
[RFC5568].
o NCoA configuration. AR-Info contains the access router's L2 and
IP addresses, and the prefix valid on the interface to which the
Access Point (identified by AP-ID) is attached. With the prefix
provided in the PrRtAdv message, the MN formulates a prospective
NCoA.
In the shared link mode, the PAR only needs to figure out what IPv6
prefix is advertised by the NAR. In most cases, there would only be
a small set of adjacent NARs and the PAR would be able to obtain this
information easily. In the point-to-point link mode, the NAR has
access to a pool of IPv6 prefixes and these prefixes are assigned
dynamically to each mobile node's point-to-point link. Therefore it
becomes difficult for the PAR to figure out which IPv6 prefix is
going to be assigned to a particular mobile node when point-to-point
link mode is used.
For the mobile node to configure an NCoA, the PAR sends a Proxy
Router Advertisement to the mobile node. This requires that for
Xia & Sarikaya Expires June 17, 2013 [Page 4]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
point-to-point links, the PAR must first contact the NAR to for the
dedicated prefix and then advertise the prefix to the mobile node.
This is an extension to [RFC5568] to support point-to-point links.
4. Prefix Management on Point-to-Point Links
Upon the indication of handover from the PAR to the NAR, the PAR uses
Handover Initiate (HI)/ Handover Acknowledge (HAck) message exchange
to get a dedicated prefix from the NAR. The PAR then sends this
prefix in the PrRtAdv message to the MN as described in [RFC5568].
In the PrRtAdv message, A-bit and L-bit must be turned on. The MN
thus uses this prefix for movement detection and NCoA configuration
as per [RFC5568].
4.1. Predictive mode
New FMIPv6 message exchange is introduced for the PAR to ask for MN's
dedicated prefix as shown in Figure 1. The MN sends an RtSolPr
message to the PAR to resolve one or more Access Point Identifiers to
subnet-specific information. The PAR in turn requests dedicated
prefixes from the NAR through modified HI/HAck message exchange
described in Section 5. With the information provided in the PrRtAdv
message, the MN formulates a prospective NCoA and sends an FBU
message to the PAR. The following operation is exactly the same as
these specified in [RFC5568].
Lifetime in Dedicated Prefix Option Section 5.3 is used to prevent
prefix depletion because of erroneous movement in which the mobile
node receives a dedicated prefix prior to a handover that it is
moving to a new access point but it either moves to a different one
or it aborts movement altogether. Not until timeout of the prefix
does the NAR release it.
Xia & Sarikaya Expires June 17, 2013 [Page 5]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
MN PAR NAR
| | |
| | |
|------RtSolPr------->| |
| | HI(Prefix Request) |
| |----------------------->|
| | |
| | |
| | HAck(Prefix Response) |
| |<-----------------------|
|<-----PrRtAdv--------| |
| | |No FBU
| | |Release
| | |Prefix
|------FBU----------->|--------HI------------->|
| |<------HAck-------------|
| <--FBack---|--FBack---> |
disconnect forward |
| packets===================>|
| | |
| | |
connect | |
| | |
|--------- UNA ------------------------------->|
|<=================================== deliver packets
| |
Figure 1: Prefix Signaling
In some wireless networks, the handover control may reside in the
network even though the decision to undergo handover may be mutually
agreed between the MN and the network. In such a case, the PAR can
send an unsolicited PrRtAdv containing the link-layer address, IP
address, and dedicated prefix of the mobile node when the network
decides that a handover is imminent. In this network-initiated
handover scenario, there isn't explicit RtSolPr to trigger PAR to
request a prefix and implementation specific trigger must be used by
PAR to send HI message for prefix request.
4.2. Reactive Mode
In the reactive mode, there are two cases.
o In the first case, the MN receives the PrRtAdv message while still
attached to the PAR. The MN is then able to formulate NCoA before
attaching to the NAR. The MN and the NAR operate as per the
procedures defined in [RFC5568].
Xia & Sarikaya Expires June 17, 2013 [Page 6]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
o In the second case, the MN does not receive a PrRtAdv before
attaching to the NAR. The MN can configure its IP address using
stateless or stateful address configuration. In the former case,
the NAR should send un-solicited RA to expedite MN's address
configuration. Once NCoA formulation is finished, the MN operates
according to [RFC5568].
In both cases, the MN formulates NCoA from the dedicated prefix.
Since the MN has already handed over to the NAR, this prefix is
retained.
5. HI and Hack Extensions
5.1. HI Extension
The Handover Initiate (HI),defined in [RFC5568], is a Mobility Header
message sent by one Access Router to another to initiate the process
of a MN's handover.
In [RFC5568], the PAR uses a Code value of 0 when it processes an FBU
with PCoA as source IP address, while uses a Code value of 1 when it
processes an FBU whose source IP address is not PCoA. A Code value
is used for the dedicated prefix request. Dedicated Prefix Option
defined in Section 5.3 may be included as a hint for a requested
preference. The NAR may allocate a dedicated prefix based on the
prefix preference in the option. If the option is not included, the
NAR allocates a prefix according to it's discretion.
5.2. HAck Extension
Handover Acknowledgment message defined in [RFC5568] is a Mobility
Header message that must be sent as a reply to the Handover Initiate
message. In this document, HAck is extended as follows to respond to
a dedicated prefix request:
o One new Code value is defined. Here, a Code value is used for
dedicated prefix response.
o Dedicated Prefix Option defined in Section 5.3 must be included
for prefix delegation.
5.3. Dedicated Prefix Option
This option is of the form shown in Figure 2.
Xia & Sarikaya Expires June 17, 2013 [Page 7]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
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 | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dedicated Prefix Option
Type The type of the option
Length The length of the option in units of 8 octets.
Reserved
must be set to zero by the sender and ignored by the
receiver.
Prefix Length
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Lifetime 32-bit unsigned integer. The length of time in seconds
(relative to the time the packet is sent). A value of
all one bits (0xffffffff) represents infinity.
Prefix An IP address or a prefix of an IP address. A MN uses it
to formulate a NCoA.
6. Security Considerations
Prefix management for FMIPv6 operation on point-to-point links uses
two messages (HI/Hack) for prefix request and response. These
messages are secured using FMIPv6 security mechanisms and hence do
Xia & Sarikaya Expires June 17, 2013 [Page 8]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
not introduce any new security threats and the security provided by
FMIPv6 applies completely.
7. IANA considerations
None.
8. Acknowledgements
The authors would like to thank Heejin Jang, Daniel Park, Vijay
Devarapalli, Rajeev Koodli, Subir Das, Spencer Dawkins, and Dirk Von-
Hugo for valuable comments.
9. References
9.1. Normative References
[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.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
February 2008.
9.2. Informative references
[802.16e] Institute of Electrical and Electronics Engineer,
"Amendment for Physical and Medium Access Control Layers
for Combined Fixed and Mobile Operation in Licensed
Bands", IEEE 802.16e/D12.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
Xia & Sarikaya Expires June 17, 2013 [Page 9]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links December 2012
Authors' Addresses
Frank Xia
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
5340 Legacy Dr. Building 3
Plano, TX 75024
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires June 17, 2013 [Page 10]
