Network Working Group B. Sarikaya
Internet-Draft F. Xia
Expires: December 5, 2008 Huawei USA
June 3, 2008
Proxy Mobile IPv6 Inter-Technology Handover Issue
draft-sarikaya-netlmm-itho-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 December 5, 2008.
Sarikaya & Xia Expires December 5, 2008 [Page 1]
Internet-Draft PMIP Inter-Technology Handovers June 2008
Abstract
Proxy Mobile IPv6 (PMIPv6) is a mobile node agnostic mobility
management protocol, that is, a mobile node does not take part in any
mobility signaling. In inter-technology handovers, mobile node input
is required in moving IP sessions from one interface to the other.
This document discusses the impact of the mobile node involvement
during inter-technology handover.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Proposed Solutions . . . . . . . . . . . . . . . . . . . . . . 4
5. Multi-homing Issues . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative references . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Sarikaya & Xia Expires December 5, 2008 [Page 2]
Internet-Draft PMIP Inter-Technology Handovers June 2008
1. Introduction
Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] supports multi-homing
and therefore enables inter-technology handovers. Prefixes assigned
to the mobile node (MN) on one interface can be transferred to the
other interface thus achieving session continuity is only possible if
the new Mobile Access Gateway (MAG) sets the handoff indicator (HI)
parameter in the Proxy Binding Update (PBU) correctly. So far two
approaches have been proposed in order to help MAG set the parameter
correctly: MAG gets the link layer support during handover and MN
directly signals its willingness to move its sessions to the new
interface. However there are concerns that MN signaling which is
needed for MAG to do this contradicts PMIPv6 design principle of no
MN involvement.
Link layer support proposals include using the same interface
identifier in [I-D.ietf-netlmm-mn-ar-if] and handover extensions to
PMIPv6, e.g. using Fast Mobile IPv6 in [I-D.yokota-mipshop-pfmipv6].
[I-D.premec-netlmm-intertech-handover] proposes a solution for MN
signaling to enable session continuity in inter-technology handovers.
[I-D.soliman-netlmm-harmful] states that the use of one technology
over the other is a policy decision and MN should make such a
decision. Since PMIPv6 singles out any MN involvement, PMIPv6 can
not help MN to use the different technologies properly.
Issues related to supporting IPv4
[I-D.ietf-netlmm-pmip6-ipv4-support] during inter-technology handover
are discussed in [I-D.premec-netlmm-intertech-handover].
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-netlmm-proxymip6], in addition to the ones specified in
this section:
Single-Radio MN: Consider MN with two interfaces. These interfaces
are implemented in such a way that MN can keep one radio module on
at a given time.
Sarikaya & Xia Expires December 5, 2008 [Page 3]
Internet-Draft PMIP Inter-Technology Handovers June 2008
Dual/multiple-Radio MN: Consider MN with two interfaces. These
interfaces are implemented in such a way that both radio modules
can receive and transmit simultaneously.
Inter-technology handover: Sometimes called vertical handover. A
multi-homed MN communicates with one interface at any time to
conserve power. Each interface can support different access
technology. Inter-technology handover occurs when MN moves out of
coverage of one technology and moves into the coverage area of
another technology which will result in switching of the
communicating interface on MN [I-D.irtf-mobopts-mpa-framework].
3. Problem Statement
When MN does an inter-technology handover, the new MAG sends a Proxy
Binding Update (PBU) message to the local mobility anchor (LMA) to
register the new care-of address. In the PBU, MAG sets the access
technology type (ATT) and handoff indicator (HI) values. If ATT is
different from the one stored in the existing binding cache entry for
this MN and if HI is set to 2 (Handoff between two different
interfaces of the mobile node), LMA concludes that an inter-
technology handover happened and assigns the same home network
prefix(es) to MN which enables IP session continuity.
Setting the access technology type correctly might prove easier for
MAGs that are connected to a single technology. Currently this could
be the most popular case. However with the advent of fixed mobile
convergence this is likely to change. MAGs in the future are
expected to serve more than one access technologies.
Setting the handoff indicator correctly is also not so easy. Most
MAGs would tend to set HI to 1 (Attachment over a new interface)
which would result in LMA setting new prefix(es) to MN.
4. Proposed Solutions
There are two categories of solutions: link layer input and MN input.
One of the link layer based solutions suggests using the same
interface identifier, i.e. MAC address on the new interface.
Previous MAG (PMAG) can then send MN's interface identifier to the
new MAG using context transfer. Also the access technology type
could be sent by the previous MAG. This together with the access
technology type being different enables the new MAG to conclude that
MN is capable and has intention to move its IP sessions to the new
interface. NMAG then sets the parameters correctly enabling IP
session continuity [I-D.ietf-netlmm-mn-ar-if].
Sarikaya & Xia Expires December 5, 2008 [Page 4]
Internet-Draft PMIP Inter-Technology Handovers June 2008
Using the same interface identifier on a different interface means
changing the MAC address of that interface. MAC addresses in some
technologies like WiMAX [802.16e] are tied to certificates and thus
can not be changed.
In [I-D.yokota-mipshop-pfmipv6], the new MAG (NMAG) can receive MN
interface identification (IID) information and based on the values
received NMAG sets correctly the handoff indicator parameter. Fast
Mobile IPv6 allows MAGs to receive link layer data about the MN
during handoff from the access nodes (AN) such as base stations.
NMAG receives MN IID on the new interface.
[I-D.yokota-mipshop-pfmipv6] defines context transfer from PMAG to
NMAG which includes MN IID of the previous interface. This value is
compared with IID value received of the new interface and set HI
value to 2 if the two values are different.
The values could be different but MN may be connecting simultaneously
to another network. This case is detected by NMAG if there was no
context transfer because no handoff happened. In this case NMAG sets
HI to 1. This scenario is valid for a dual-radio MN.
This link layer input based solution does not require any changes on
the link layer addresses. However an additional handover protocol
needs to be used in order for MAGs to receive the link layer data for
MNs during handover. The use of a different handover protocol could
invalidate the solution.
MN input based solution is proposed in
[I-D.premec-netlmm-intertech-handover]. Router solicitation (RS)
message is modified to include two bits, C flag which is set by MN to
indicate that MN is capable of performing itw own mobility management
and P flag which is set by MN to indicate that MN is willing to move
its IP sessions accross interfaces.
MAG first waits until it receives an RS message from MN and then
sends an initial PBU message. If P flag is set in RS, MAG will set
HI to 2. This will result in LMA assigning the same prefix(es) to MN
which are returned in PBA. MAG will advertise the same prefix(es) in
its router advertisement message to MN. MN will move its IP sessions
to the new interface.
MN input-based solution is better than link layer input based
solutions because MAG knows what MN wants and acts accordingly.
However the requirement for MN input defeats the purpose of PMIPv6
which is a mobility solution that does not involve MN in any mobility
signaling. Also the solution is based on a single bit input from MN.
As discussed later in Section 5 such a simple input is hardly enough
for MN to convey its needs in case of multi-homing.
Sarikaya & Xia Expires December 5, 2008 [Page 5]
Internet-Draft PMIP Inter-Technology Handovers June 2008
5. Multi-homing Issues
Multiple/dual radio MNs require simultaneous operations of radios
which is more complex than single-radio operation. When the radio
frequencies are close to each other single-radio could be the only
mode of operation due to the interference. However in other cases
multiple/dual mode of operation increases MN's capabilities to
communicate.
For single-radio MNs or when the coverage of two radios is not
overlapping the inter-technology handover is simpler to handle. It
is clear that IP sessions need to be moved to the new interface.
[I-D.soliman-netlmm-harmful] points out several deficiences of netlmm
(in this document called PMIPv6) in case of multiple/dual radio
operation.
If the networks are operated by different companies, i.e. inter-
domain handover and both networks support PMIPv6 then in case of
inter-technology handover the current network will try to keep IP
sessions rather than moving them to the next network. In case of
link layer input solutions discussed in Section 4 PMAG can simply
refuse to context transfer the required interface identifier and
access technology type information to NMAG. Only MN input can enable
NMAG to move IP sessions to the new interface.
For multiple/dual radio MNs, inter-technology handover brings the
possibility of partially moving IP sessions to each interface even in
intra-domain handover where the networks are operated by the same
company. MN should be able to use different links for different
applications depending on link quality/capabilities. Recent work,
e.g. [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding]
shows how this can be done. The main component of these solutions is
that MN input is required which is singled out in PMIPv6.
For multiple/dual radio MNs, in inter-technology handover the use of
one interface or the other becomes a policy decision. Leaving this
decision to MN is the right thing to do because MN knows the
applications that it wants to run and MN can best decide which link
layer is best to run each application. Using PMIPv6, such a
possibility would totally disappear.
PMIPv6 protocol operation will not encounter any difficulties if MN
has a single interface or if MN is single-radio and the coverage of
different radios is not overlapping. For multiple/dual mode MNs it
is better to use host mobility protocols [RFC3775] in order to fully
utilize its interface capabilities to run the applications and manage
the flows by itself. Using PMIPv6 even if MN input is allowed, the
Sarikaya & Xia Expires December 5, 2008 [Page 6]
Internet-Draft PMIP Inter-Technology Handovers June 2008
amount of data that can be passed to MAG will be very limited.
6. Security Considerations
This document is informational and does not define any new messages.
PMIPv6 security procedures apply.
7. IANA considerations
None.
8. Acknowledgements
TBD.
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.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 2008.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[I-D.yokota-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for PMIPv6",
draft-yokota-mipshop-pfmipv6-02 (work in progress),
February 2008.
[I-D.ietf-netlmm-mn-ar-if]
Laganier, J., Narayanan, S., and P. McCann, "Interface
between a Proxy MIPv6 Mobility Access Gateway and a Mobile
Node", draft-ietf-netlmm-mn-ar-if-03 (work in progress),
Sarikaya & Xia Expires December 5, 2008 [Page 7]
Internet-Draft PMIP Inter-Technology Handovers June 2008
February 2008.
[I-D.premec-netlmm-intertech-handover]
Premec, D. and T. Savolainen, "Inter-technology handover
in netlmm domain",
draft-premec-netlmm-intertech-handover-00 (work in
progress), April 2008.
[I-D.irtf-mobopts-mpa-framework]
Dutta, A., Fajardo, V., Ohba, Y., Taniuchi, K., and H.
Schulzrinne, "A Framework of Media-Independent Pre-
Authentication (MPA) for Inter- domain Handover
Optimization", draft-irtf-mobopts-mpa-framework-02 (work
in progress), February 2008.
[I-D.soliman-netlmm-harmful]
Soliman, H., "Network-based mobility considered harmful",
draft-soliman-netlmm-harmful-00 (work in progress),
May 2006.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-08 (work in progress),
May 2008.
[I-D.ietf-mext-flow-binding]
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.
[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.
9.2. Informative references
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03
(work in progress), May 2008.
Sarikaya & Xia Expires December 5, 2008 [Page 8]
Internet-Draft PMIP Inter-Technology Handovers June 2008
Authors' Addresses
Behcet Sarikaya
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: sarikaya@ieee.org
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Sarikaya & Xia Expires December 5, 2008 [Page 9]
Internet-Draft PMIP Inter-Technology Handovers June 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.
Sarikaya & Xia Expires December 5, 2008 [Page 10]