Mobile IPv6 Extensions Group F. Zhao
Internet-Draft A. Damle
Expires: April 27, 2009 Marvell
October 24, 2008
Fast Handover for IP Flow Mobility
draft-zhao-mipshop-fho-flows-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 Fast Handover for IP Flow Mobility October 2008
Abstract
This document discusses and proposes some extensions to reduce
handover latency, especially when the mobile node or router handovers
IP flows between different access networks.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handover Scenarios . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The First IP Flow Handover Scenario . . . . . . . . . . . 6
4.2. The Second IP Flow Handover Scenario . . . . . . . . . . . 9
5. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 12
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Zhao & Damle Expires April 27, 2009 [Page 2]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
1. Introduction
As specified in RFC 5268, the Mobile IP Fast Handover protocol [1]
aims to reduce handover latency when the mobile node moves from one
source access network to one target access network with the Mobile IP
protocol used. Recently, the Mobile IPv6 protocol [2] has been
extended to allow a mobile node to bind multiple care-of addresses to
one home address [3], and furthermore, to bind a particular flow to a
care-of address [4]. Such extensions allows a mobile node to direct
a specific flow to one of its interfaces and exchange flows with a
home agent via different access networks simultaneously, since
certain flow may be better suited to the characteristics of a certain
access network. Furthermore, the PFMIP protocol [5] is proposed to
reduce handover latency when the mobile node handovers with the PMIP
used.
Such extensions introduce new handover scenarios, for example, a
mobile node may handover some flows from one access network to
another access network while still keeping other flows on the first
access network, by using the same or different mobility protocols.
Handover latency for a specific flow in such scenarios is expected to
be not different from that of Mobile IPv6. In order to reduce
handover latency in such new handover scenarios, we discuss and
propose some extensions in this document.
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 [6].
Throughout this document, we adopt mobility related terminology used
in RFC 3775 [2], RFC 5268 [1], [5], [3] and [4].
Zhao & Damle Expires April 27, 2009 [Page 3]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
3. Handover Scenarios
The Mobile IPv6 Fast Handover protocol focuses on the scenario where
the mobile node moves all its flows from one access router to another
access router. With the extensions of multiple CoAs and flow
bindings, new handover scenarios become possible.
+------+ +------+
| HA | HoA | HA | HoA
+------+ +------+
/\ /\
flow1 / \ ==> flow1 / \ flow2
+ flow2 / \ / \
/ \ / \
+-----+ +-----+ +-----+ +-----+
| AR1 | | AR2 | | AR1 | | AR2 |
+-----+ +-----+ +-----+ +-----+
~ ~ ~
~ +----+ ~ +----+ ~
IF1 ~ =| MN |= IF2 IF1 ~ =| MN |= ~ ~ IF2
CoA1 +----+ CoA1 +----+ CoA2
Figure 1: The first IP flow handover scenario
As shown in Figure 1, a mobile node previously exchanges both the
flow 1 and the flow 2 with the home agent via the access network 1;
and later when it discovers the access network 2, the mobile node
decides to move the flow 2 from the access network 1 to the access
network 2 and still keeps the flow 1 on the access network 1. An
example of such mobile node could be a cell phone equipped with both
a cellular radio and a Wifi interface. In this case, the mobile node
uses the MIP on both access networks.
Zhao & Damle Expires April 27, 2009 [Page 4]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
+------+ +------+
| HA | HoA/HNP | HA | HoA/HNP
+------+ +------+
/\ /\
flow1 / \ ==> flow1 / \ flow2
+ flow2 / \ / \
/ \ / \
+----+ +-----+ +----+ +-----+
| AR | | MAG | | AR | | MAG |
+----+ +-----+ +----+ +-----+
~ ~ ~
~ +----+ ~ +----+ ~
IF1 ~ =| MN |= IF2 IF1 ~ =| MN |= ~ IF2
CoA +----+ CoA +----+
Figure 2: The second IP flow handover scenario
As shown in Figure 2, a mobile node previously exchanges both the
flow 1 and the flow 2 with the home agent via the access network 1 by
using the MIP protocol; and later when it discovers the access
network 2 and chooses to use the PMIP there, the mobile node decides
to move the flow 2 from the access network 1 to the access network 2
and still keeps the flow 1 on the access network 1. A similar
scenario is also discussed in [7].
Zhao & Damle Expires April 27, 2009 [Page 5]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
4. Discussion
As stated in RFC 5268, the Mobile IPv6 Fast Handover protocol aims to
addresses the following problems: "how to allow a mobile node to send
packets as soon as it detects a new subnet link and how to deliver
packets to a mobile node as soon as its attachment is detected by the
new access router." In the context of IP flow mobility, the problem
to be addressed is slightly different: how to allow a mobile node to
send uplink packets via a better access link as soon as it detects
such a new access link and how to deliver downlink packets to a
mobile node via a better access link as soon as its attachment to
such a new access link is detected by the new access router. By
fulfilling such goals, not only can handover latency be largely
improved, but also applications running on the mobile node can take
full advantage of what underlying access networks can offer, and
therefore, to improve overall performance.
The handover scenarios as described in Figure 1 and Figure 2 are
similar to the typical scenario in the Mobile IPv6 Fast Handover
protocol, in the sense that certain flows are moved from the source
access network(s) to the target access networks. Therefore, the
motivation to optimize the Mobile IP operation to reduce handover
delay remains the same.
4.1. The First IP Flow Handover Scenario
To support IP flow mobility as shown in Figure 1, most messages
defined in the Mobile IPv6 Fast Handover protocol do not need to be
changed, such as the RtSolPr message, the PrRtAdv message, the UNA
message, the HI message and the HAck message. The most notable
differences are for the FBU message and FBA message. This is because
the mobile node needs to provide the flow information to the NAR and
receive the response from the NAR. In the following, we focus our
discussion on the predictive mode in the handover scenario shown in
Figure 1. In this scenario, the mobile node needs to tell the AR1
(i.e. the NAR) that the flow 1 needs to be forwarded to the CoA1
(i.e. the PCoA) and the flow 2 needs to be forwarded to the CoA2
(i.e. the NCoA). The BID mobility option [3] and the FID mobility
option [4] can be used to carry such information in the FBU and FBA
to bind the flow 1 to CoA1 and the flow 2 to CoA2 at the AR1 while
the Mobile IPv6 Fast Handover protocol currently only supports
binding the CoA2 with the CoA1. In other words, it seems that the
mobile node registers two flow bindings at the AR1 to direct two
different flows to the interface connecting to both a "home link"
(the access network 1 is a "home link" for the CoA1) and a "foreign
link" (the access network 2 is a "foreign link" for the CoA1)
simultaneously. The case can be handled by the Multiple CoA draft
where a 'H" bit is set in the BID option together with an empty
Zhao & Damle Expires April 27, 2009 [Page 6]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
care-of address field to indicate the simultaneous use of both the
home link and the foreign link. Furthermore, for a specific scenario
as shown in the Figure 1, it may look plausible that in the FBU
message the mobile node only specify the flow 2 together with the
CoA2 in the Alt-CoA option. However, the mobile node needs to also
specify either a default flow binding or a flow binding for the CoA1;
otherwise, the AR1 does not know where to forward the flow 1.
Another possible way is that the mobile node sends two separate FBU
messages to the AR1; however, it results in more packet overheads and
potential packet loss, for example, when the AR1 does not receive or
process these two messages all together, and therefore one flow
filter is installed long before another.
However, during fast handover, the prospective new CoA formulated by
the mobile node may not be valid at the NAR, therefore a new NCoA
needs to be provided in the FBA. Currently, there is no
corresponding status code defined in the multiple CoA draft (this is
because the multiple CoA draft is addressing a different issue).
Furthermore, with the solution for the point-to-point link mode
proposed in [8], the PAR and the NAR create states (i.e. allocating a
dedicated prefix) by exchanging the HI/HAck after the MN sends the
RtSolPr message and before sending the FBU message. In this
document, we propose that the mobile node provides information for
the stateless NCoA configuration in the FBU to the NAR, without
knowing the dedicated prefix valid at the NAR at first. Then the PAR
is informed about the dedicated prefix from the NAR when receiving a
HAck message as a response to the HI message exchange. Then, the PAR
returns such information to the MN by sending a FAck to the MN's
interface connecting to the PAR link. Finally, the MN configures
such IP address on the interface connecting to the NAR link. The
Mobile IPv6 Fast Handover protocol defines a LLA mobility option;
however, the BID option is not defined to carry such information for
stateless IP address configuration at the NAR link (In fact, the LLA
option used in such draft is for packet forwarding on the home link).
Therefore, we propose to extend the BID option to include the LLA
address inside. The predictive fast handover procedure for the first
scenario is shown as follows in Figure 3.
Zhao & Damle Expires April 27, 2009 [Page 7]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
MN AR1(PAR) AR2(NAR)
| | |
1) |------RtSolPr------->| |
2) |<-----PrRtAdv--------| |
3) |------FBU(IF1)------>| |
4) | |----------HI--------->|
5) | |<--------HAck---------|
6) |<------FBack(IF1)----|---FBack--> |
| | |
7) | forward |
|<================= packets ================>|
| | |
8) connect | |
| | |
9) |------------UNA(IF2)----------------------->|
10) |<=================================== deliver packets
| |
Figure 3: 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.
2) The MN may receive the PrRtAdv message either as a response or
as an unsolicited message sent by the AR1. The MN chooses to
perform handover and maintain session continuity by using the MIP
on the new access network. And it may configure a CoA2 (i.e.
NCoA).
3) The MN sends a FBU message to the AR1 (i.e. the PAR) to bind
the flow 1 to the CoA1 and bind the flow 2 to the CoA2. If the MN
knows the AR2 link is a point-to-point link, it provides the
information for stateless IP configuration in the BID and binds
the flow 2 to such BID even though it does not know about the
dedicated prefix valid at the AR2 link yet.
4) The AR1 sends a HI message to the AR2 based on the Mobile IPv6
Fast Handover protocol. It may request a dedicated prefix if the
AR1 receives a BID containing only the information for stateless
IP configuration instead of an IP address.
5) The AR2 returns a HAck message. It may also include a
dedicated prefix if requested.
Zhao & Damle Expires April 27, 2009 [Page 8]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
6) The AR1 sends a FBack message back to the MN (i.e. the IF1)
once it receives the HAck message. Based on the dedicated prefix,
if included, the AR1 then updates the IP address (i.e. the NCoA)
for the MN.
7) The AR1 forwards the corresponding packets in different flows
to the MN and the AR2 accordingly.
8) The IF2 on the MN connects to the AR2 link.
9) The MN may send a UNA message to the AR2.
10) The AR2 delivers buffered packets to the MN.
4.2. The Second IP Flow Handover Scenario
The reference [7] discusses the case when the MN uses different
mobility protocols on different access networks, and proposes some
extensions to allow the MN to tell the access router to forward
traffic through a tunnel established through the PFMIP protocol.
Similar extensions are also needed in the scenario illustrated in
Figure 2 except that in order to support IP flow mobility, such
indication needs to be provided in the BID option.
Zhao & Damle Expires April 27, 2009 [Page 9]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
5. Extensions
The following status code (TBD less than 128) is defined to be
carried in the status field of the FBA message:
FBU accepted but NCoA is invalid. Use NCoA supplied in the BID.
The following status code (TBD less than 128) is defined to be
carried in the status field of the BID option:
COA INVALID: Use CoA supplied in the BID instead.
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 = TBD | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding ID (BID) | Status |O|H|L|F|Reserved|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
: Different type of data when different flag is set :
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Extension to the BID option
L (1 bit)
This bit MUST be set to 1 when a LLA is provided in the option.
Note that the L bit and the F bit cannot be set as 1 at the
same time.
F (1 bit)
This bit MUST be set to 1 when a forwarding IP address is
provided in the option. Note that the L bit and the F bit
cannot be set as 1 at the same time.
Data
The LLA: The variable length link-layer address, used together
with the dedicated prefix allocated for the MN at the NAR link
by the NAR to generate a NCoA for flow binding.
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
Zhao & Damle Expires April 27, 2009 [Page 10]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
Length field. The format of such field is illustrated in
Figure 5.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +
: forwarding IP Address :
+ +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Data field for a forwarding IP address
Zhao & Damle Expires April 27, 2009 [Page 11]
Internet-Draft Fast Handover for IP Flow Mobility 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, [5], [3] and [4].
7. IANA Consideration
TBD.
8. Conclusions
In this document, we discuss and propose extensions to improve
latency during IP flow handover.
9. References
9.1. Normative References
[1] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-09 (work in progress),
August 2008.
[4] 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.
[5] 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.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[7] Zhao, F., "Interworking between FMIP and PFMIP",
draft-zhao-mipshop-fmip-pfmip-00 (work in progress),
October 2008.
[8] Xia, F. and B. Sarikaya, "Prefix Management for Mobile IPv6
Zhao & Damle Expires April 27, 2009 [Page 12]
Internet-Draft Fast Handover for IP Flow Mobility October 2008
Fast Handover on Point-to-Point Links",
draft-xia-mipshop-fmip-ptp-02 (work in progress),
February 2008.
[9] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[10] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
[11] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[12] Conta, A., Deering, S., and M. Gupta, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 4443, March 2006.
9.2. Informative References
[13] 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
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 Fast Handover for IP Flow Mobility 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]