Netext BOF                                                   S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Informational                                 H. Yokota
Expires: August 13, 2009                                        KDDI Lab
                                                                T. Melia
                                                          Alcatel-Lucent
                                                        February 9, 2009


          Issues with network based inter-technology handovers
                 draft-krishnan-netext-intertech-ps-00

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 August 13, 2009.

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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.





Krishnan, et al.         Expires August 13, 2009                [Page 1]


Internet-Draft  Network based Inter-technology handovers   February 2009


Abstract

   Proxy Mobile IPv6 (PMIPv6) 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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Conventions used in this document . . . . . . . . . . . . . 3
   2.  Issues occuring in the MN . . . . . . . . . . . . . . . . . . . 4
     2.1.  Formation of interface identifier . . . . . . . . . . . . . 4
     2.2.  Usage of the same address on multiple interfaces  . . . . . 4
     2.3.  Limitations of interfaces . . . . . . . . . . . . . . . . . 4
   3.  Issues occuring in the network  . . . . . . . . . . . . . . . . 5
     3.1.  Access selection  . . . . . . . . . . . . . . . . . . . . . 5
     3.2.  Detecting handovers . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Predictive handovers  . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9























Krishnan, et al.         Expires August 13, 2009                [Page 2]


Internet-Draft  Network based Inter-technology handovers   February 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 occuring on the MN and those issues occuring 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].


































Krishnan, et al.         Expires August 13, 2009                [Page 3]


Internet-Draft  Network based Inter-technology handovers   February 2009


2.  Issues occuring in the MN

2.1.  Formation of interface identifier

   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 that 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.  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
   old interface (hence getting dropped) because the default route was
   pointing towards that interface.

2.3.  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.




















Krishnan, et al.         Expires August 13, 2009                [Page 4]


Internet-Draft  Network based Inter-technology handovers   February 2009


3.  Issues occuring in the network

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 multple 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.  Detecting handovers

   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, 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.















Krishnan, et al.         Expires August 13, 2009                [Page 5]


Internet-Draft  Network based Inter-technology handovers   February 2009


4.  Security Considerations

   This document discusses issues with inter-technology handovers with
   network based mobility protocols, and does not raise any new security
   issues.














































Krishnan, et al.         Expires August 13, 2009                [Page 6]


Internet-Draft  Network based Inter-technology handovers   February 2009


5.  IANA Considerations

   This document does not require any IANA action.
















































Krishnan, et al.         Expires August 13, 2009                [Page 7]


Internet-Draft  Network based Inter-technology handovers   February 2009


6.  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.












































Krishnan, et al.         Expires August 13, 2009                [Page 8]


Internet-Draft  Network based Inter-technology handovers   February 2009


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 August 13, 2009                [Page 9]