Network Working Group F. Xia
Internet-Draft B. Sarikaya
Intended status: Informational Huawei USA
Expires: September 5, 2009 March 4, 2009
Prefix Management for Mobile IPv6 Fast Handover on Point-to-Point Links
draft-xia-mipshop-fmip-ptp-03
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 September 5, 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
Xia & Sarikaya Expires September 5, 2009 [Page 1]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
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.
Xia & Sarikaya Expires September 5, 2009 [Page 2]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
Abstract
The Mobile IPv6 Fast Handovers (FMIPv6) specification currently does
not explicitly define prefix management over point-to-point links
when a Mobile Node (MN) uses a prefix to formulate a new Care-of-
Address (CoA). In this document a mechanism is developed for
assigning unique prefixes to the MN by the Previous Access Router
(PAR). The New Access Router (NAR) dynamically assigns a unique
prefix called dedicated prefix to any MN that is performing a
handover. Both reactive and predictive modes of FMIPv6 are
explained.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Prefix Management on Point-to-Point Links . . . . . . . . . . 6
4.1. Predictive mode . . . . . . . . . . . . . . . . . . . . . 6
4.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 7
5. HI and Hack Extension . . . . . . . . . . . . . . . . . . . . 8
5.1. HI Extension . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. HAck Extension . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Dedicated Prefix Option . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative references . . . . . . . . . . . . . . . . . . 10
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Xia & Sarikaya Expires September 5, 2009 [Page 3]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
1. Introduction
Mobile IPv6 Fast Handovers (FMIPv6) [I-D.ietf-mipshop-rfc5268bis]
aims at reducing the handover latency by reducing the time to
configure a new care-of address (NCoA) for a MN. In FMIPv6, the MN
formulates a prospective NCoA when it is still present on the PAR's
link.
[RFC4968] provides different IPv6 link models that are suitable for
802.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 earlier
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 NAR can use to dynamically assign unique prefixes in point-
to-point links and in Section 5 we define necessary messages/option
for the operation in Section 4.
2. Terminology
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].
The terminology in this document is based on the definitions in
[I-D.ietf-mipshop-rfc5268bis], in addition to the ones specified in
this section.
Point-to-Point Link Model: In this model, a set of MAC transport
connections between a MN and an 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 detail.
In this model, a host's only neighbor is its default router.
Xia & Sarikaya Expires September 5, 2009 [Page 4]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
Dedicated Prefix: A unique prefix used by a MN in point-to-point
link model.
3. Problem Statement
The following are operations as per [I-D.ietf-mipshop-rfc5268bis]:
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. A 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 a 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.
o NCoA configuration. AR-Info contains an 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 point-to-point link model, each MN has one or more dedicated
prefixes, that is, different MNs have different prefixes. The
prefixes could be allocated dynamically. When a MN attaches to an
AR, the AR should delegate one or more dedicated prefixes for it;
when the MN detaches from the AR, the MN's prefixes are released, and
can be reused by other MNs. The number of unique prefixes in this
operation can be huge.
NCoA formulation in point-to-point links requires a PAR to
dynamically request a dedicated prefix from a NAR, and then advertise
it to the MN through a Proxy Router Advertisement (PrRtAdv) message.
[I-D.ietf-mipshop-rfc5268bis] does not specify such dependencies.
After NCoA is formulated from a dedicated prefix, other operations
such as proxying NCoA with proxy neighbor cache at the NAR and
duplicate address detection need to be specified.
Xia & Sarikaya Expires September 5, 2009 [Page 5]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
4. Prefix Management on Point-to-Point Links
The best solution to the problem described in the previous section is
as follows: NARs assign a unique prefix to each MN that could
handover under this NAR. This prefix will be included in AR-Info.
PAR sends this prefix in the PrRtAdv message to MN. In the PrRtAdv
message, A-bit and L-bit MUST be turned on. MN creates its NCoA
based on the prefix received in PrRtAdv message.
4.1. Predictive mode
New FMIPv6 message exchange is introduced for PAR to ask for MN's
dedicated prefix as shown in Figure 1. In
[I-D.ietf-mipshop-rfc5268bis], HI is assumed to be sent after the FBU
for handover indication. Here, modified HI/Hack messages are used
for prefix request/response. Details are described in Section 5.
NAR MAY use DHCP prefix delegation (PD) to request/ release prefixes
from a DHCP server. The DHCP messages are triggered by the HI for
prefix request. NAR MAY also use AAA prefix delegation (PD) to
request/ release prefixes for this MN from an AAA server. The
mechanisms for NAR to acquire the prefixes are outside the scope of
this document.
Lifetime in Dedicated Prefix Option Figure 1 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 September 5, 2009 [Page 6]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
MN PAR NAR DHCP/AAA
| | | Server
| | | |
|------RtSolPr------->| | |
| | HI(Prefix Request) | |
| |----------------------->|Prefix |
| | |-Request->|
| | |<-Reply---|
| | 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. A MN receives PrRtAdv
message or otherwise.
o The MN receives PrRtAdv message and formulates NCoA before
attaching to the NAR. The MN and the NAR operate in line with the
procedure defined in [I-D.ietf-mipshop-rfc5268bis].
Xia & Sarikaya Expires September 5, 2009 [Page 7]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
o The MN can't formulate NCoA before attaching to the NAR. IP
connectivity should be established first. The MN can configure
its IP address using stateless address configuration, or using
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 [I-D.ietf-mipshop-rfc5268bis].
In both cases, MN formulates NCoA from the dedicated prefix. Since
MN has already handed over to NAR this prefix is retained.
5. HI and Hack Extension
5.1. HI Extension
The Handover Initiate (HI),defined in [I-D.ietf-mipshop-rfc5268bis],
is a Mobility Header message sent by an Access Router (typically PAR)
to another Access Router (typically NAR) to initiate the process of a
MN's handover.
In [I-D.ietf-mipshop-rfc5268bis], 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 new Code value of 2 is used for the dedicated prefix
request. Dedicated Prefix Option defined in Section 5.3 MAY be
included. NAR allocates dedicated prefix based on the prefix
preference in the option. If the option is not included, NAR
allocates a prefix according to it's discretion.
5.2. HAck Extension
Handover Acknowledgment message defined in
[I-D.ietf-mipshop-rfc5268bis] is a Mobility Header message that MUST
be sent (typically by NAR to PAR) as a reply to the Handover Initiate
message. In this document, HAck is extended to respond to a
dedicated prefix request.
o One new Code value is defined. Here, a Code value of 6 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 September 5, 2009 [Page 8]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
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 | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dedicated Prefix Option
Type To be assigned by IANA
Length The length of the option in units of 8 octets.
Prefix Length
8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges from 0
to 128.
Option-Code
1 Dedicated Prefix
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 NCoA.
6. Security Considerations
Prefix management for FMIPv6 operation on point-to-point links
introduces two messages (HI/Hack) for prefix request and response.
These messages are secured using FMIPv6 security mechanisms and hence
do not introduce any new security threats and the security provided
Xia & Sarikaya Expires September 5, 2009 [Page 9]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
by FMIPv6 applies completely.
7. IANA consideration
This document extends existing HI/HAck messages, new Code values need
to be assigned by IANA.
The document defines one new Mobility Option which needs type
assignment from the Mobility Options Type registry at
http://www.iana.org/assignments/mobility-parameters:
1. Dedicated Prefix Option described in Section 5.3.
8. Acknowledgements
The authors would like to thank Heejin Jang, Daniel Park, Vijay
Devarapalli, Rajeev Koodli, and Spencer Dawkins 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.
[I-D.ietf-mipshop-rfc5268bis]
Koodli, R., "Mobile IPv6 Fast Handovers",
draft-ietf-mipshop-rfc5268bis-00 (work in progress),
February 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",
Xia & Sarikaya Expires September 5, 2009 [Page 10]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
RFC 3314, September 2002.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
Xia & Sarikaya Expires September 5, 2009 [Page 11]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
Appendix A. Change Log
o v03 Dedicated Prefix Option made compatible with
[I-D.ietf-mipshop-rfc5268bis].
Xia & Sarikaya Expires September 5, 2009 [Page 12]
Internet-Draft Prefix Mgmt for FMIPv6 over P2P Links March 2009
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires September 5, 2009 [Page 13]