One document matched: draft-zhao-mipshop-fmip-pfmip-00.txt
MIPSHOP Group F. Zhao
Internet-Draft A. Damle
Expires: April 27, 2009 Marvell
October 24, 2008
Interworking between FMIP and PFMIP
draft-zhao-mipshop-fmip-pfmip-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 April 27, 2009.
Zhao & Damle Expires April 27, 2009 [Page 1]
Internet-Draft Interworking between FMIP and PFMIP October 2008
Abstract
This document discusses and proposes extensions to enable
interworking between the FMIP and the PFMIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handover Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The First Scenario . . . . . . . . . . . . . . . . . . . . 6
4.1.1. The Predictive Mode . . . . . . . . . . . . . . . . . 6
4.1.2. The Reactive Mode . . . . . . . . . . . . . . . . . . 7
4.2. The Second Scenario . . . . . . . . . . . . . . . . . . . 7
4.2.1. The Predictive Mode . . . . . . . . . . . . . . . . . 7
4.2.2. The Reactive Mode . . . . . . . . . . . . . . . . . . 8
5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 11
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 11
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Zhao & Damle Expires April 27, 2009 [Page 2]
Internet-Draft Interworking between FMIP and PFMIP October 2008
1. Introduction
As specified in RFC 5268, the FMIP protocol [1] aims to reduce
handover latency when the MIP is used as the mobility management
protocol. Recently, the PFMIP protocol [2] has been proposed to
reduce handover latency when the PMIP is used. It is expected that
both PMIP and MIP will be deployed in networks; however, how to
reduce handover latency when the MN uses different mobility protocols
during handover has not addressed. In this document, we discuss and
propose some extensions to address this issue.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
Throughout this document, we adopt mobility related terminology used
in RFC 3775 [4], RFC 5231 [5], RFC 5268 [1], and [2].
Zhao & Damle Expires April 27, 2009 [Page 3]
Internet-Draft Interworking between FMIP and PFMIP October 2008
3. Handover Scenarios
A MN may support both the MIP and the PMIP. There are the following
two different handover scenarios.
+------+ +------+
| HA | HoA/HNP | HA | HoA/HNP
+------+ +------+
/\ /\
/ \ ==> / \
/ \ / \
/ \ / \
+----+ +-----+ +----+ +-----+
| AR | | MAG | | AR | | MAG |
+----+ +-----+ +----+ +-----+
~ ~
~ +----+ +----+ ~
~ =| MN |= =| MN |= ~ ~
CoA +----+ +----+
Figure 1: The first handover scenario
As shown in Figure 1, before handover, a MN connects to the access
network 1 where it gains IP connectivity by using MIP. When the MN
detects the access network 2 and decides to perform handover, the MN
may choose to use the PMIP on the access network 2, for example, due
to its configuration, preference or policy. In order to reduce
handover latency, the MN starts the FMIP procedure on the access
network 1 and provides the indication of using the PMIP on the access
network 2, the access router in the access network 1 starts the PFMIP
procedure with the MAG2 located in the access network 2. Note that
it is possible that the access router in the access network 1 has the
MAG functionality.
Zhao & Damle Expires April 27, 2009 [Page 4]
Internet-Draft Interworking between FMIP and PFMIP October 2008
+------+ +------+
| HA | HoA/HNP | HA | HoA/HNP
+------+ +------+
/\ /\
/ \ ==> / \
/ \ / \
/ \ / \
+-----+ +----+ +-----+ +----+
| MAG | | AR | | MAG | | AR |
+-----+ +----+ +-----+ +----+
~ ~
~ +----+ +----+ ~
~ =| MN |= =| MN |= ~ ~
+----+ +----+ CoA
Figure 2: The second handover scenario
As shown in Figure 2, before handover, a MN connects to the access
network 1 where it gains IP connectivity by using PMIP. When the MN
detects the access network 2 and decides to perform handover, the MN
may choose to use the MIP on the access network 2, for example, due
to its configuration, preference or policy. In order to reduce
handover latency, with some indication, the MAG on the access network
1 starts the FMIP procedure.
Note that a general discussion on the interaction between MIP and
PMIP is provided in [13].
Zhao & Damle Expires April 27, 2009 [Page 5]
Internet-Draft Interworking between FMIP and PFMIP October 2008
4. Proposals
4.1. The First Scenario
4.1.1. The Predictive Mode
MN AR(PAR) MAG(NAR)
| | |
1) |------RtSolPr------->| |
2) |<-----PrRtAdv--------| |
3) |------FBU----------->| |
4) | |----------HI--------->|
5) | |<--------HAck---------|
6) | <--FBack---|---FBack--> |
7) | ...... |
Figure 3: The predictive fast handover procedure for the first
scenario
The Figure 3 shows the predictive fast handover procedure for the
first scenario.
1) When the MN detects available new access network by using some
link layer specific mechanisms, it may request more information by
sending a RtSolPr message. Note that this message may be skipped
if the MN knows about this new access network based on the AP-ID.
2) The MN may receive the PrRtAdv message either as a response or
as an unsolicited message sent by the AR. The MN chooses to
perform handover and maintain session continuity by using the PMIP
on the new access network. How the MN selects the mobility
protocol is not specified in this document. For example, the MN
may be pre-configured with the information regarding the AP-ID,
including if the PMIP should be used on such access network, or
the PrRtAdv message provides such indication to the MN.
3) The MN sends a FBU message to the AR (i.e. the PAR) to register
a binding between its home address and the current PCoA (the home
address from the perspective of the AR). In addition, the MN
indicates that the AR should perform the PFMIP with the MAG (i.e.
NAR) in the access network 2. The information provided by the MN
in this message includes the MN_ID, MN-HoA, MN IID, the HA address
etc. Therefore, data packets sent to the MN through the HA, i.e.
HA->CoA || CN->HoA, will be encapsulated by the AR firstly, i.e.,
AR->HoA || HA->CoA|| CN->HoA, and then forwarded through the
tunnel between the AR and the MAG.
Zhao & Damle Expires April 27, 2009 [Page 6]
Internet-Draft Interworking between FMIP and PFMIP October 2008
4) The AR sends a HI message to the MAG based on the PFMIP
protocol.
5) The MAG replies with a HAck message based on the PFMIP
protocol.
6) The AR may send a FBack message once it receives the HAck
message.
7) The rest of the procedure is the same as described in the PFMIP
protocol. Note that when the AR sends the HI message to indicate
that the packet forwarding is completed, the AR also deletes the
binding between the CoA (i.e. the PCoA) and the HoA. The MN may
send the FBU through the access network 2 to trigger such actions
at the AR, for example after a configurable length of time.
4.1.2. The Reactive Mode
The procedure in the reactive mode for the first handover scenario is
similar to that described in the PFMIP protocol.
4.2. The Second Scenario
4.2.1. The Predictive Mode
MN MAG(PAR) AR(NAR)
| | |
1) |-Report/HO Initiate->| |
2) | |----------HI--------->|
3) | |<--------HAck---------|
4) | <-HO Response-|-HO Response-> |
5) | ...... |
Figure 4: The predictive fast handover procedure for the second
scenario
The Figure 4 shows the predictive fast handover procedure for the
second scenario.
1) When the MN detects available new access network by using some
link layer specific mechanisms, it may decide to perform handover.
Besides what is described in the PFMIP protocol, the MN may
provide the indication of using the MIP on the target access
network. How the MN make such decision is not specified in this
document. Furthermore, additional information may be provided to
the MAG to trigger the FMIP protocol in a link specific way or in
one or more appropriate signaling messages. A binding between the
Zhao & Damle Expires April 27, 2009 [Page 7]
Internet-Draft Interworking between FMIP and PFMIP October 2008
HoA and the NCoA can be considered being created at the MAG.
2) The MAG sends the HI message to the AR as specified in the FMIP
protocol.
3) The AR replies with a HAck message as specified in the FMIP
protocol.
4) The MAG provides some notification to the MN in a similar way
to the FBack message. Such notification may be provided in a link
specific way or in one or more appropriate signaling messages.
5) The rest of the procedure is similar to what is specified in
the FMIP protocol.
4.2.2. The Reactive Mode
The procedure in the reactive mode for the first handover scenario is
similar to that described in the FMIP protocol.
Zhao & Damle Expires April 27, 2009 [Page 8]
Internet-Draft Interworking between FMIP and PFMIP October 2008
5. Extensions
The PFMIP protocol has described some options for both ICMP messages
and the Mobility Headers. Such options can be used in the FBU
message. However, it is not clear how the MN indicates to the AR
that certain packets need to be forwarded through a tunnel
established between the AR and the (new) MAG. In the following, we
show the format of a forwarding IP address mobility option that can
be used in either the FBU message or the FBA message. When such
option is present, the Alt-CoA option MUST not be used.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Prefix Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ forwarding IP Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Forwarding IP Address option
P (1 bit)
This bit MUST be set to 1 when the MN requests the traffic
destined at this forwarding IP address must be forwarded
through a tunnel set up by the PFMIP protocol.
The Forwarding IP address
One IPv6 or one IPv4 address used for packet forwarding. It
can be the home address of the MN. The type of the address in
this field can be determined by the Length field.
Status
The status of such request.
Zhao & Damle Expires April 27, 2009 [Page 9]
Internet-Draft Interworking between FMIP and PFMIP October 2008
Prefix Length
The length of the included forwarding IP address. Such prefix
information may be needed in the HI/HAck messages for the
target MAG to know the prefix length.
One new status code is defined for the FBA message.
132: The Alt-CoA option is missing the received FBU message.
This can be used for the MN to detect that the AR does not support
the forwarding IP address option since normally with the FMIP
protocol, the Alt-CoA option must be included in the FBU message if
sent from the PAR link, and with the extension described in this
document, the forwarding IP address option replaces the Alt-CoA
option.
Zhao & Damle Expires April 27, 2009 [Page 10]
Internet-Draft Interworking between FMIP and PFMIP October 2008
6. Security Consideration
The extensions described in this document do not introduce any new
vulnerability. The security related issues are discussed in the
"Security Considerations" section of RFC 5268, and [2].
7. IANA Consideration
TBD.
8. Conclusions
In this document, we discuss and propose extensions to enable the
interworking of the FMIP protocol and the PFMIP protocol.
9. References
9.1. Normative References
[1] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[2] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia,
"Fast Handovers for PMIPv6", draft-yokota-mipshop-pfmipv6-03
(work in progress), July 2008.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[5] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and
B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[6] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[7] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[8] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
Zhao & Damle Expires April 27, 2009 [Page 11]
Internet-Draft Interworking between FMIP and PFMIP October 2008
[9] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006.
[10] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-09 (work in progress),
August 2008.
[11] Soliman, H., Montavont, N., Fikouras, N., and K. Kuladinithi,
"Flow Bindings in Mobile IPv6 and Nemo Basic Support",
draft-ietf-mext-flow-binding-00 (work in progress), May 2008.
[12] Xia, F. and B. Sarikaya, "Prefix Management for Mobile IPv6
Fast Handover on Point-to-Point Links",
draft-xia-mipshop-fmip-ptp-02 (work in progress),
February 2008.
9.2. Informative References
[13] Giaretta, G., "Interactions between PMIPv6 and MIPv6: scenarios
and related issues", draft-giaretta-netlmm-mip-interactions-02
(work in progress), November 2007.
[14] Lim, B., Ng, C., Aso, K., and S. Krishnan, "Verification of
Care-of Addresses in Multiple Bindings Registration",
draft-lim-mext-multiple-coa-verify-02 (work in progress),
July 2008.
Authors' Addresses
Fan Zhao
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: fanzhao@marvell.com
Zhao & Damle Expires April 27, 2009 [Page 12]
Internet-Draft Interworking between FMIP and PFMIP October 2008
Ameya Damle
Marvell Semiconductor, Inc.
5488 Marvell Lane
Santa Clara, CA 95054
US
Email: adamle@marvell.com
Zhao & Damle Expires April 27, 2009 [Page 13]
Internet-Draft Interworking between FMIP and PFMIP October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Zhao & Damle Expires April 27, 2009 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:39 |