Network Working Group F. Xia
Internet-Draft B. Sarikaya
Expires: August 21, 2007 Huawei USA
February 17, 2007
Fast Handovers for Mobile IPv6 Operation on Point-to-Point Links
draft-xia-mipshop-fmip-ptp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Xia & Sarikaya Expires August 21, 2007 [Page 1]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
Abstract
FMIPv6 standard currently assumes that the mobile nodes are connected
to the access routers using a shared link and does not define the
operation over Point-to-Point links. In this document we define
FMIPv6 operation over the Point-to-Point links. A PAR advertises
PrRtAdv including one or more aggregate prefixes of a NAR to an MN;
The MN formulates it's provisional NCoAs with the aggregate
prefix(es); The MN initiates FMIPv6 procedure including the
provisional NCoAs. Once detecting provisional NCoAs of the MN, the
NAR assigns a unique prefix called the dedicated prefix to MN and the
MN configures it's final NCoAs. Both reactive and predictive modes
of FMIPv6 are explained.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4
4. FMIPv6 Operation on Point-to-Point Links . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative references . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Xia & Sarikaya Expires August 21, 2007 [Page 2]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
1. Introduction
Fast handovers for Mobile IPv6 (FMIPv6) [RFC4068] aims at reducing
the handover latency by reducing the time to configure a new
CoA(NCoA) for a mobile node (MN). In FMIPv6, MN formulates a
prospective NCoA when it is still present on the previous access
router (PAR)'s link. However, FMIPv6 assumes that MN is on a shared
link.
[I-D.ietf-16ng-ipv6-link-model-analysis] 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. [I-D.ietf-16ng-ipv6-over-ipv6cs] 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.
It is impossible to formulate a prospective NCoA as per [RFC4068]
when Point-to-Point model is adopted. MN configures its NCoA from
the prefix shared by NAR breaks the Point-to-Point link model.
In this document, we first explain the problems associated with
FMIPv6 on Point-to-Point links followed by a detailed explanation of
the modified FMIPv6 operation on Point-to-Point links.
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
[RFC4068], in addition to the ones specified in this section.
Point-to-Point Link Model: In this model, a set of MAC transport
connections between an MN and an AR are treated as a single link.
Each link is allocated one or more separate, unique prefixes by
the AR.
Aggregate Prefix: In Point-to-Point Link Model, AR should broadcast
the prefixes (MNs route information) dynamically upstream, and
this causes high routing protocol traffic ( OSPF, etc.). To solve
the problem, route aggregation should be used. For example, each
AR can be assigned a /48 prefix, while an MN's /64 prefix is
derived from the /48 prefix extension. The main, higher-level
prefix is called the Aggregate Prefix. An AR only broadcasts the
Xia & Sarikaya Expires August 21, 2007 [Page 3]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
aggregate prefix upstream.
Dedicated Prefix: The prefix derived from the aggregate prefix and
allocated for an MN is called a Dedicated Prefix.
Provisional NCoA: NCoA obtained from the aggregate prefix.
Modified NCoA: NCoA obtained from the dedicated prefix.
3. Problem Statement
The following are operations as per [RFC4068]:
o NCoA configuration. An MN sends a Router Solicitation for Proxy
Advertisement (RtSolPr) to its access router to resolve one or
more Access Point Identifiers 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.
AR-Info contains an NAR'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 an MN attaches 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.
In [RFC4068], the prefix in AR-Info is one of valid interfaces to
which the Access Point (identified by AP-ID) is attached, and the
prefix is not a dedicated prefix. An MN can't use the prefix in AR-
info to formulate it's NCoA. A PAR can't get NCoA's prefix of an MN
without complicated signaling exchange with NAR.
4. FMIPv6 Operation on Point-to-Point Links
The simplest fix 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.
The disadvantages of the simplistic approach are that it makes prefix
management complicated on NARs and that there are extra signaling
exchanges between PAR and NAR. If MN does not handover then the
prefix assigned should be reclaimed and assigned to another MN.
There could potentially be large number of such prefixes in high
mobility areas. Because of this we propose the following approach in
Xia & Sarikaya Expires August 21, 2007 [Page 4]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
which MN is assigned a dedicated prefix only if MN handovers to this
NAR.
The main idea of our solution is to include the aggregate prefix in
the AR-Info. Then the MN can use the prefix to formulate NCoA. We
call it provisional NCoA. Each aggregate prefix advertised by the
candidate NARs MUST be unique.
The following adaptation can be used in the predictive mode of
FMIPv6:
o An MN receives aggregate prefix in AR-Info of PrRtAdv, and
formulates its provisional NCoA. Then, the MN sends FBU message
to PAR with NCoA option, link layer information of the MN, and so
on. The PAR sends this information to an NAR in HI message.
o On receiving the HI, NAR processes the message as per [RFC4068] if
the prefix of the NCoA is not an aggregate prefix of the NAR.
Otherwise, the NAR allocates one or more dedicated prefixes for
the MN based on it's link-layer address (MAC). NAR generates a
new NCoA by replacing the provisional NCoA's prefix part with the
dedicated prefix. The modified NCoA is then delivered to the MN
through HAck and FBack message. The MN MUST use the modified
NCoA.
The following adaptation can be used in the reactive mode of FMIPv6:
o An MN encapsulates FBU in FNA and sends them together to NAR. The
source address of FNA is the provisional NCoA. If the prefix of
the NCoA corresponding to the FNA message is not an aggregate
prefix, the NAR processes the message as per [RFC4068].
Otherwise, the NAR assigns one or more prefixes for the MN based
on Mobility Header Link-Layer Address (MH-LLA) option in the FNA.
A modified NCoA is then formulated by replacing the provisional
NCoA's prefix part. The NAR sends a Router Advertisement with the
NAACK option in which it includes the modified NCoA. The MN then
sends another FNA with modified NCoA as source IP address to NAR.
The NAR processes the FNA as per [RFC4068].
5. Security Considerations
FMIPv6 operation on Point-to-Point links does not introduce any new
security threats and the security provided by FMIPv6 applies
completely.
6. IANA consideration
None.
Xia & Sarikaya Expires August 21, 2007 [Page 5]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
7. Acknowledgements
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.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.
[802.21] Institute of Electrical and Electronics Engineer, "Draft
IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE P802.21/
D00.05.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[I-D.haddad-mipshop-optisend]
Haddad, W., "Secure Neighbor Discovery (SEND) Optimization
and Adaptation for Mobility: The OptiSEND Protocol",
draft-haddad-mipshop-optisend-02 (work in progress),
October 2006.
[I-D.haddad-mipshop-fmipv6-auth]
Haddad, W. and S. Krishnan, "Authenticating FMIPv6
Handovers", draft-haddad-mipshop-fmipv6-auth-02 (work in
progress), September 2006.
[I-D.ietf-mipshop-fh80216e]
Jang, H., "Mobile IPv6 Fast Handovers over IEEE 802.16e
Networks", draft-ietf-mipshop-fh80216e-01 (work in
progress), January 2007.
[I-D.ietf-16ng-ipv6-over-ipv6cs]
Patil, B., "IPv6 Over the IP Specific part of the Packet
Convergence sublayer in 802.16 Networks",
draft-ietf-16ng-ipv6-over-ipv6cs-07 (work in progress),
January 2007.
[I-D.ietf-16ng-ipv6-link-model-analysis]
Xia & Sarikaya Expires August 21, 2007 [Page 6]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
based Networks",
draft-ietf-16ng-ipv6-link-model-analysis-02 (work in
progress), January 2007.
Xia & Sarikaya Expires August 21, 2007 [Page 7]
Internet-Draft FMIPv6 over Point-to-Point Links February 2007
Authors' Addresses
Frank Xia
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 100
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Xia & Sarikaya Expires August 21, 2007 [Page 8]
Internet-Draft FMIPv6 over Point-to-Point Links February 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).
Xia & Sarikaya Expires August 21, 2007 [Page 9]