[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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


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

Abstract

   The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6) as [RFC5213].
   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.  Link layer implementations can hide the
   actually used physical interfaces from the IP stack.  These
   techniques can be used to achieve inter-access technology 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 (i.e. hiding access technology changes
   from host IP layer) and characterizes the contexts in which such use
   is or is not appropriate to achieve inter-access handovers or flow
   mobility.

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



Bernardos, et al.       Expires September 9, 2010               [Page 1]


Internet-Draft     Link Layer Applicability Statement         March 2010


   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 September 9, 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 9, 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 . . . . . . . . . . . . . . . . . . . . 7
     3.1.  Link Layer Support  . . . . . . . . . . . . . . . . . . . . 7
     3.2.  Logical Interface . . . . . . . . . . . . . . . . . . . . . 8
     3.3.  Layer 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . 8
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9




































Bernardos, et al.       Expires September 9, 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.  Link layer implementations can hide the
   actually used physical interfaces from the IP stack.  These
   techniques can be used to achieve inter-access technology 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

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

   The following generic mechanisms can 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 (see Figure 1).
      For example, IEEE 802.11 is able to seamlessly change between IEEE
      802.11a/b/g physical layers.  Also, an 802.11 STA can move between
      different Access Points (APs) within the same domain without the
      IP stack being aware of the movement.  In this case, the IEEE
      802.11 MAC layer takes care of the mobility, making the media
      change invisible to the upper layers.  Another example is IEEE
      802.3, that supports changing the rate from 10Mbps to 100Mbps and
      to 1000Mbps.




Bernardos, et al.       Expires September 9, 2010               [Page 4]


Internet-Draft     Link Layer Applicability Statement         March 2010


               Mobile Node
         +-----------------------+
         |        TCP/UDP        |              AR1        AR2
         +-----------------------+            +-----+    +-----+
         |          IP           |            | IP  |    | IP  |
         +-----------------------+            +-----+    +-----+
         |    Link Layer (L2)    |            | L2  |    | L2  |
         +-----+-----+-----+-----+            +-----+    +-----+
         | L1a | L1b | L1c | L1d |<---------->| L1d |    | L1b |
         +-----+-----+-----+-----+            +-----+    +-----+
                  ^                                         ^
                  |_________________________________________|

              Figure 1: Link layer support solution architecture

      There are also other examples with more complicated architectures,
      like for instance, 3GPP Rel-8.  In this case, a UE can move
      (inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this
      movement invisible 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 (see Figure 2).

    ---------
    | Appl. |<----------------------------------------------------->
    ---------                                             ----------
    |       |<+ - - - - - - - - - - - - - - - - - - - - +>|        |
    |  IP   | . ----------------- . ------------------- . |   IP   |
    |       |<+>|     relay     |<+>|      relay      | . |        |
    --------- . ----------------- . ------------------- . ----------
    | PDCP  |<+>| PDCP | GTP-U  |<+>| GTP-U  | GTP-U  |<+>| GTP-U  |
    --------- . ----------------- . ------------------- . ----------
    | RLC   |<+>| RLC  | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP |
    --------- . ----------------- . ------------------- . ----------
    | MAC   |<+>| MAC  |   L2   |<+>|   L2   |   L2   |<+>|   L2   |
    --------- . ----------------- . ------------------- . ----------
    |  L1   |<+>|  L1  |   L1   |<+>|   L1   |   L1   |<+>|   L1   |
    --------- . ----------------- . ------------------- . ----------
       UE     Uu     E-UTRAN     S1-U       SGW       S5/S8a  PGW

          Figure 2: 3GPP Rel-8 data plane architecture (GTP option)

   o  Logical interface: this refers to solutions (see Figure 3) that
      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



Bernardos, et al.       Expires September 9, 2010               [Page 5]


Internet-Draft     Link Layer Applicability Statement         March 2010


      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
      [I-D.yokota-netlmm-pmipv6-mn-itho-support] or the bonding driver.

                                   +----------------------------+
                                   |          TCP/UDP           |
                Session to IP   +->|                            |
                address binding |  +----------------------------+
                                +->|             IP             |
                 IP to logical  +->|                            |
              interface binding |  +----------------------------+
                                +->|      Logical interface     |
            logical to physical +->|           (MN-HoA)         |
             interface binding  |  +----------------------------+
                                +->|  L2  |  L2  |       |  L2  |
                                   |(IF#1)|(IF#2)| ..... |(IF#n)|
                                   +------+------+       +------+
                                   |  L1  |  L1  |       |  L1  |
                                   |      |      |       |      |
                                   +------+------+       +------+

                   Figure 3: Logical interface architecture

   o  Layer 2.5: another potential solution is to add a layer 2.5 (e.g.,
      shim-layer) on top of multiple L2 media.  In this case, the so-
      called layer 2.5 takes care of making inter-media support
      transparent to upper layers (i.e.  IP).  The layer 2.5
      functionality can reside only in the mobile node or it can also
      have a layer 2.5 counterpart in the network (see Figure 4).
      Communication between the layer 2.5 functionality in the mobile
      node and in the network can either take place over L2 or L3
      signaling, as described in RFC5164 [RFC5164] and RFC5677
      [RFC5677].













Bernardos, et al.       Expires September 9, 2010               [Page 6]


Internet-Draft     Link Layer Applicability Statement         March 2010


               Mobile Node
         +-----------------------+
         |        TCP/UDP        |              AR1         AR2
         +-----------------------+            +------+    +------+
         |          IP           |            |  IP  |    |  IP  |
         +-----------------------+            +------+    +------+
         |      Layer 2.5        |            | L2.5 |    | L2.5 |
         +-----------------------+            +------+    +------+
         | L2a | L2b | L2c | L2d |            | L2d  |    | L2b  |
         +-----+-----+-----+-----+            +------+    +------+
         | L1a | L1b | L1c | L1d |<---------->| L1d  |    | L1b  |
         +-----+-----+-----+-----+            +------+    +------+
                  ^                                           ^
                  |___________________________________________|

              Figure 4: Layer 2.5 support solution architecture


3.  Applicability Statement

   This section analyzes the issues involved with the approaches
   described in Section 2 and characterizes the contexts in which their
   use is or is not appropriate.

3.1.  Link Layer Support

   Link layer mobility support applies to cases when the same link layer
   technology is used and mobility can be fully handled at these layers.
   One example is the case where several 802.11 APs are deployed in the
   same subnet and all of them share higher layer resources such as DHCP
   server, IP gateway, etc.  In this case the APs can autonomously (or
   with the help of a central box) communicate and control the STA
   association changes from one AP to another, without the STA being
   aware of the movement.  This type of scenario is applicable to cases
   when the different points of attachment (i.e.  APs) belong to the
   same network domain, e.g. enterprise, hotspots from same operator,
   etc.

   This type of solution does not typically allow for simultaneous
   attachment to different access networks, and therefore can only be
   considered for inter-access technology handovers, but not for flow
   mobility.  Existing RFC 5213 handover hint mechanisms could benefit
   from link layer information (e.g. triggers) to detect and identify MN
   handovers.

   Link layer support is not applicable when two different access
   technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the
   same is true when the same access technology expands over multiple



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


Internet-Draft     Link Layer Applicability Statement         March 2010


   network domains.

3.2.  Logical Interface

   The use of a logical interface allows the mobile node to provide a
   single interface view to the layers above IP.  Upper layers can bind
   to this interface, which hides inner inter-access technology
   handovers or data flow transfers among different physical interfaces.

   This type of solution may support simultaneous attachment, in
   addition to sequential attachment.  It requires additional support at
   the node and the network in order to benefit from simultaneous
   attachment.  For example, since the IP stack at the mobile does only
   "see" one interface, special mechanisms are required to enable
   addressing a particular interface from the network.  Unmodified
   standard Neighbor Discovery cannot be used to detect MN attachment,
   since all physical interfaces are bound to the same logical IP
   interface.  Extensions to PMIPv6 would be required in order to enable
   the network (i.e., the MAG and LMA) deal with physical interfaces,
   instead to IP interfaces as current RFC5213 does.  RFC5213 assumes
   that each physical interface capable of attaching to a MAG is an IP
   interface, while the logical interface solution groups several
   physical interfaces under the same IP logical interface.

3.3.  Layer 2.5

   The layer 2.5 mobility support applies to cases similar to the ones
   described in Section 3.1, although in this case heterogeneous
   networks can be considered (i.e. 802.11 WLAN and 802.16 WiMAX
   networks), as well as networks of the same access technology that
   expand over multiple network domains.

   Hints from the layer 2.5 can help both the network and the mobile
   node perform inter-access technology handovers while ensuring the
   mobile node keeps using the same IP address.


4.  IANA Considerations

   This document makes no request of IANA.


5.  Security Considerations

   TBD






Bernardos, et al.       Expires September 9, 2010               [Page 8]


Internet-Draft     Link Layer Applicability Statement         March 2010


6.  Acknowledgments

   The research of Carlos J. Bernardos and Antonio de la Oliva leading
   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

   [I-D.yokota-netlmm-pmipv6-mn-itho-support]
              Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K.
              Leung, "Virtual Interface Support for IP Hosts",
              draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in
              progress), March 2010.

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

   [RFC5677]  Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
              "IEEE 802.21 Mobility Services Framework Design (MSFD)",
              RFC 5677, December 2009.


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/







Bernardos, et al.       Expires September 9, 2010               [Page 9]


Internet-Draft     Link Layer Applicability Statement         March 2010


   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/


   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 9, 2010              [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/