NETEXT Working Group                                       CJ. Bernardos
Internet-Draft                                            A. de la Oliva
Intended status: Informational                                      UC3M
Expires: September 2, 2010                                    JC. Zuniga
                                        InterDigital Communications, LLC
                                                                T. Melia
                                                Alcatel-Lucent Bell Labs
                                                           March 1, 2010


 Applicability Statement on Link Layer implementation/Logical Interface
                   over Multiple Physical Interfaces
                 draft-bernardos-netext-ll-statement-00

Abstract

   The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6).  PMIPv6
   enables mobile devices to connect to a PMIPv6 domain and roam across
   gateways without changing the IP address.  PMIPv6 also provides
   limited multi-homing support to multi-mode mobile devices.

   Proxy mobility is based on the assumption that changes in host IP
   stacks are undesirable.  However, link layer implementations can hide
   the actually used physical interfaces from the IP stack.  These
   techniques can be used to achieve inter-access handovers or flow
   mobility, i.e., the movement of selected flows from one access
   technology to another.  It is assumed that an IP layer interface can
   simultaneously and/or sequentially attach to multiple MAGs (possibly
   over multiple media).  This document provides an informational
   applicability statement that analyzes the issues involved with this
   approach and characterizes the contexts in which such use is or is
   not appropriate.

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




Bernardos, et al.       Expires September 2, 2010               [Page 1]

Internet-Draft     Link Layer Applicability Statement         March 2010


   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 September 2, 2010.

Copyright Notice

   Copyright (c) 2010 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.





























Bernardos, et al.       Expires September 2, 2010               [Page 2]

Internet-Draft     Link Layer Applicability Statement         March 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   2.  Hiding access technology changes  . . . . . . . . . . . . . . . 4
   3.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6







































Bernardos, et al.       Expires September 2, 2010               [Page 3]

Internet-Draft     Link Layer Applicability Statement         March 2010


1.  Introduction

   Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
   based mobility management to hosts connecting to a PMIPv6 domain.
   PMIPv6 introduces two new functional entities, the Local Mobility
   Anchor (LMA) and the Mobile Access Gateway (MAG).  The MAG is the
   first layer three hop detecting Mobile Node's (MN) attachment and
   providing IP connectivity.  The LMA is the entity assigning one or
   more Home Network Prefixes (HNPs) to the MN and is the topological
   anchor for all traffic from/to the MN.

   Proxy mobility is based on the assumption that changes in host IP
   stacks are undesirable.  However, link layer implementations can hide
   the actually used physical interfaces from the IP stack.  These
   techniques can be used to achieve inter-access handovers or flow
   mobility, i.e., the movement of selected flows from one access
   technology to another.  It is assumed that an IP layer interface can
   simultaneously and/or sequentially attach to multiple MAGs (possibly
   over multiple media).  This document provides an informational
   applicability statement that analyzes the issues involved with this
   approach and characterizes the contexts in which such use is or is
   not appropriate.


2.  Hiding access technology changes

   TO BE COMPLETED

   There are several techniques/mechanisms that allow to hide access
   technology changes from host IP layer.  This section classifies these
   existing techniques into a set of generic approaches, according to
   their most representative characteristics.  This would allow to refer
   to these generic mechanisms later in the document, when analyzing
   their applicability to inter-tech and flow mobility purposes in
   PMIPv6.

   So far, we have identified the following generic mechanisms to hide
   access technology changes from host IP layer:

   o  Link layer support: certain link layer technologies are able to
      hide physical media changes from the upper layers.  For example,
      IEEE 802.11 is able to seamlessly change between IEEE 802.11abg
      physical modulations without the IP stack even being aware, as the
      IEEE 802.11 MAC layer takes care of it, making the mecia change
      transparent to the upper layers.  Another example ies IEEE 802.3,
      that support changing the rate from 10Mbps to 100Mbps and to
      1000Mbps. (e.g.  EPS solution, IEEE 802.11).  While the previous
      two changes might seem simple, as they "just" involve physical



Bernardos, et al.       Expires September 2, 2010               [Page 4]

Internet-Draft     Link Layer Applicability Statement         March 2010


      media changes (mainly modulation schemes) between the same two
      communication nodes (e.g., STA and AP in IEEE 802.11), there are
      other examples, with a more complicated architecture.  As an
      example of those, we can refer to 3GPP Rel-8.  A UE can move
      (inter-RAT handover) between GERAN/UTRAN/E-UTRAN, being this
      movement transparent to the IP layer at the UE, and also to the
      LMA logical component at the PGW.  The link layer stack at the UE
      (i.e.  PDCP and RLC layers), and the GTP between the RAN and the
      SGW (which plays the role of inter-3GPP AN mobility anchor) hide
      this kind of mobility, which is not visible to the IP layer of the
      UE.

   o  Logical interface: by this name we can group the solutions than
      logically group/bond several physical interfaces so they appear to
      the upper layers (i.e.  IP) as one single interface (where
      application sockets bind).  Depending on the OS support, it might
      be possible to use more than one physical interface at a time --
      so the node is simultaneously attached to different media -- or
      just to provide a fail-over mode.  Controlling the way the
      different media is used (simultaneous, sequential attachment, etc)
      is not trivial and requires additional intelligence and/or
      configuration at the logical interface device driver.  An example
      of this type of solution is the virtual interface or the bonding
      driver.

   o  Layer 2.5 solution: another potential solution is to add a layer
      2.5 on top of the multiple L2 media, that takes care of making
      inter-media support transparent.


3.  Applicability Statement

   TBD.


4.  IANA Considerations

   This document makes no request of IANA.


5.  Security Considerations

   TBD


6.  Acknowledgments

   The research of Carlos J. Bernardos and Antonio de la Oliva leading



Bernardos, et al.       Expires September 2, 2010               [Page 5]

Internet-Draft     Link Layer Applicability Statement         March 2010


   to these results has received funding from the European Community's
   Seventh Framework Programme (FP7/2007-2013) under grant agreement n.
   214994 (CARMEN project).  The work of Carlos J. Bernardos has also
   received funding from the Ministry of Science and Innovation of
   Spain, under the QUARTET project (TIN2009-13992-C02-01


7.  References

7.1.  Normative References

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

7.2.  Informative References

   [RFC5164]  Melia, T., "Mobility Services Transport: Problem
              Statement", RFC 5164, March 2008.


Authors' Addresses

   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/


   Antonio de la Oliva
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 8803
   Email: aoliva@it.uc3m.es
   URI:   http://www.it.uc3m.es/aoliva/









Bernardos, et al.       Expires September 2, 2010               [Page 6]

Internet-Draft     Link Layer Applicability Statement         March 2010


   Juan Carlos Zuniga
   InterDigital Communications, LLC

   Email: JuanCarlos.Zuniga@InterDigital.com


   Telemaco Melia
   Alcatel-Lucent Bell Labs

   Email: Telemaco.Melia@alcatel-lucent.com









































Bernardos, et al.       Expires September 2, 2010               [Page 7]