Netext BOF S. Krishnan
Internet-Draft Ericsson
Intended status: Informational H. Yokota
Expires: January 13, 2010 KDDI Lab
T. Melia
Alcatel-Lucent
C. Bernardos
UC3M
July 12, 2009
Issues with network based inter-technology handovers
draft-krishnan-netext-intertech-ps-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 13, 2010.
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
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.
Krishnan, et al. Expires January 13, 2010 [Page 1]
Internet-Draft Network based Inter-technology handovers July 2009
Abstract
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
protocol that enables IP mobility for a host without requiring its
participation in any mobility-related signaling. While the PMIPv6
protocol itself supports handover across interfaces and between
access types, there are several issues with effectively performing
inter-technology handovers with network based mobility protocols.
This document aims to enumerate some known issues with such
handovers.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. Issues occuring in the MN . . . . . . . . . . . . . . . . . . . 3
2.1. Formation of interface identifier for SLAAC . . . . . . . . 3
2.2. Use of DHCP for address configuration . . . . . . . . . . . 3
2.3. Usage of the same address on multiple interfaces . . . . . 3
2.4. Limitations of interfaces . . . . . . . . . . . . . . . . . 4
2.5. Interface between MN and MAG . . . . . . . . . . . . . . . 4
3. Issues occuring in the network . . . . . . . . . . . . . . . . 4
3.1. Access selection . . . . . . . . . . . . . . . . . . . . . 5
3.2. Handover vs. multi-homing . . . . . . . . . . . . . . . . . 5
3.3. Predictive handovers . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
Krishnan, et al. Expires January 13, 2010 [Page 2]
Internet-Draft Network based Inter-technology handovers July 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network based mobility
management protocol enables IP mobility for a host without requiring
its participation in any mobility-related signaling. While the
PMIPv6 protocol itself supports handover across interfaces and
between access types, there are several issues with effectively
performing inter-technology handovers with network based mobility
protocols. This document aims to enumerate some known issues with
such handovers. On a high level these can be classified into those
issues occurring on the MN and those issues occurring in the network.
1.1. Conventions used in this document
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].
2. Issues occuring in the MN
2.1. Formation of interface identifier for SLAAC
The IPv6 address of the MN is composed of two parts, the prefix and
the interface identifier. Even if the network correctly identified
the handover and allocated the same prefix on the new interface, the
MN might come up with a different interface identifier on the new
interface than it was using on the old interface. This is usually in
several link-layer technologies because the interface identifier is
formed based on a unique identifier of the link-layer interface.
E.g. the modified EUI-64 based interface identifiers based on the MAC
address of the link-layer interface. If this is the case, the
resulting address on the new interface is different than the address
the MN was using prior to the handover and hence the applications
bound to the earlier IPv6 address will lose connectivity.
2.2. Use of DHCP for address configuration
If the MN uses DHCP to configure the IP address and as long as it
complies to recommendations highlighted in RFC 5213 the issue raised
in the previous section does not apply.
2.3. Usage of the same address on multiple interfaces
Several MN operating system implementations do not allow the
configuration of the same address on multiple interfaces. Even on
those that do, the resulting behavior is usually not predictable.
e.g. after a handover all the traffic might still be directed to the
Krishnan, et al. Expires January 13, 2010 [Page 3]
Internet-Draft Network based Inter-technology handovers July 2009
old interface (hence getting dropped) because the default route was
pointing towards that interface.
2.4. Limitations of interfaces
Certain types of point-to-point interfaces are tightly bound to the
underlying interface and could be torn down even if there is another
viable interface that can carry the traffic. For instance, some
operating system dynamically creates a PPP interface with an IP
address assigned to it when its connection is established and all
transport sessions over that connection are maintained only while
that PPP interface exists. This implies that the address should not
be bound directly to an interface that can go down during handovers
but something a bit more stable.
2.5. Interface between MN and MAG
The PMIPv6 protocol needs to receive the right information fro the MN
to form the PBU message for the LMA. In particular the MN should
indicate to the access network if the interface attachment
corresponds to an initial attachment or to an handover. This
information is contained in the Handover Indicator option in the PBU
message. Conveying this information from the MN to the MAG implies
discussing mobile node involvement in the mobility procedure.
The MN to MAG interface can be based upon L2 signalling or L3
signalling.
If L2 signalling is used it is necessary that each wireless access
technology connected to the PMIPv6 domain supports transferring of
such information (e.g. HI). Although no changes to the IP stack
would be required, the main drawback is that each L2 technology will
need to implement their own mechanisms.
If L3 signalling is used the MN can then include such info in IP
based signalling being technology agnostic. Major drawback is the
modification of the IP stack.
In any case to support inter-technology the MN needs to send the
information required to fill the PBU message. Withount this support,
it might be hard to implement inter-hechnology handovers.
3. Issues occuring in the network
Krishnan, et al. Expires January 13, 2010 [Page 4]
Internet-Draft Network based Inter-technology handovers July 2009
3.1. Access selection
The network nodes may not always be aware of the complete set of
access technologies available to the MN. This is especially true if
the multiple accesses are administered by different entities. Only
the MN is guaranteed to have this information. The network may also
not know about the characteristics that the MN desires from the
selected access technology. Because of these reasons it is almost
impossible for the network to perform access selection without some
amount of co-operation from the MN.
3.2. Handover vs. multi-homing
The network nodes may not always be aware of the intent of the MN
when it attaches to a new attachment point. The MN may be performing
a handover, or may wish to be simultaneously connected. The access
router at the new attachment point is unable to distinguish between
these cases, but needs to communicate this information to the
mobility anchor. The mobility anchor point needs this information to
determine whether to handover an existing mobility session or to
create a new one.
3.3. Predictive handovers
An MN that is capable of being attached to multiple accesses can
perform a predictive handover attaching to the target access even
before detaching from the previous access. This is done in order to
reduce the handover latency and to reduce packet loss. Most of the
time, the intent of the MN is to continue using the previous access
until it explicitly signals to the network to start using the new
access. The target access router cannot determine if this is the
case and may end up prematurely moving the MNs binding over to the
new access even while the MN is sending outgoing packets onto the old
access.
4. Security Considerations
This document discusses issues with inter-technology handovers with
network based mobility protocols, and does not raise any new security
issues.
5. IANA Considerations
This document does not require any IANA action.
Krishnan, et al. Expires January 13, 2010 [Page 5]
Internet-Draft Network based Inter-technology handovers July 2009
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
6.2. Informative References
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Email: suresh.krishnan@ericsson.com
Hidetoshi Yokota
KDDI Lab
Email: yokota@kddilabs.jp
Telemaco Melia
Alcatel-Lucent
Route de Villejust
Nozay 91620
France
Email: telemaco.melia@alcatel-lucent.com
Krishnan, et al. Expires January 13, 2010 [Page 6]
Internet-Draft Network based Inter-technology handovers July 2009
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Krishnan, et al. Expires January 13, 2010 [Page 7]