Logical Interface Support for multi-mode IP Hosts
draft-ietf-netext-logical-interface-support-04

NETEXT WG                                                  T. Melia, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                        S. Gundavelli, Ed.
Expires: May 3, 2012                                               Cisco
                                                        October 31, 2011

           Logical Interface Support for multi-mode IP Hosts
           draft-ietf-netext-logical-interface-support-04.txt

Abstract

   A Logical Interface is a software semantic internal to the host
   operating system.  This semantic is available in all popular
   operating systems and is used in various protocol implementations.
   The Logical Interface support is required on the mobile node
   operating in a Proxy Mobile IPv6 domain, for leveraging various
   network-based mobility management features such as inter-technology
   handoffs, multihoming and flow mobility support.  This document
   explains the operational details of Logical Interface construct and
   the specifics on how the link-layer implementations hide the physical
   interfaces from the IP stack and from the network nodes on the
   attached access networks.  Furthermore, this document identifies the
   applicability of this approach to various link-layer technologies and
   analyzes the issues around it when used in context with various
   mobility management features.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on May 3, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Melia & Gundavelli         Expires May 3, 2012                  [Page 1]
Internet-Draft          Logical Interface Support           October 2011

   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 Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Hiding Link-layer Technologies - Approaches and
       Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Link-layer Abstraction - Approaches  . . . . . . . . . . .  6
     3.2.  Applicability Statement  . . . . . . . . . . . . . . . . .  7
       3.2.1.  Link layer support . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Logical Interface  . . . . . . . . . . . . . . . . . .  8

   4.  Technology Use cases . . . . . . . . . . . . . . . . . . . . . 10

   5.  Logical Interface Functional Details . . . . . . . . . . . . . 11
     5.1.  Configuration of a Logical Interface . . . . . . . . . . . 12
     5.2.  MTU considerations . . . . . . . . . . . . . . . . . . . . 13
     5.3.  Supported Link models for a logical interface  . . . . . . 13
     5.4.  Link-layer Identifier of a Logical Interface . . . . . . . 13
     5.5.  ND Considerations for Logical Interface  . . . . . . . . . 14
     5.6.  Logical Interface Forwarding Conceptual Data Structures  . 15

   6.  Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 17
     6.1.  Multihoming Support  . . . . . . . . . . . . . . . . . . . 17
     6.2.  Inter-Technology Handoff Support . . . . . . . . . . . . . 18
     6.3.  Flow Mobility Support  . . . . . . . . . . . . . . . . . . 20

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22

   9.  Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23

   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Melia & Gundavelli         Expires May 3, 2012                  [Page 2]
Internet-Draft          Logical Interface Support           October 2011

     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     11.2. Informative References . . . . . . . . . . . . . . . . . . 24

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

Melia & Gundavelli         Expires May 3, 2012                  [Page 3]
Internet-Draft          Logical Interface Support           October 2011

1.  Introduction

   Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol.
   Some of the key goals of the protocol include support for
   multihoming, inter-technology handoffs and flow mobility support.
   The base protocol features specified in [RFC5213] allow the mobile
   node to attach to the network using multiple interfaces
   (simultaneously or sequentially), or to perform handoff between
   different interfaces of the mobile node.  However, for supporting
   these features, the mobile node is required to be activated with
   specific software configuration that allows the mobile node to either
   perform inter-technology handoffs between different interfaces,
   attach to the network using multiple interfaces, or perform flow
   movement from one access technology to another.  This document
   analyzes from the mobile node's perspective a specific approach that
   allows the mobile node to leverage these mobility features.
   Specifically, it explores the use of the Logical Interface support, a
   semantic available on most operating systems.

   A Logical Interface is a construct internal to the operating system.
   It is an approach where the link-layer implementations hide the
   physical interfaces from the IP stack and from the network nodes on
   the attached access networks.  This semantic is widely available in
   all popular operating systems.  Many applications such as Mobile IP
   client [RFC6275] and IPsec VPN client [RFC4301] rely on this semantic
   for their protocol implementation and the same semantic can also be
   useful in this context.  Specifically, the mobile node can use the
   logical interface configuration for leveraging various network-based
   mobility management features provided by the Proxy Mobile IPv6 domain
   [RFC5213].

   The rest of the document provides the operational details of a
   Logical Interface on the mobile node and the inter-working between a
   mobile node using logical interface and network elements in the Proxy
   Mobile IPv6 domain when supporting some of the mobility management
   features.  It also analyzes the issues involved with this approach
   and characterizes the contexts in which such usage is appropriate.

Melia & Gundavelli         Expires May 3, 2012                  [Page 4]
Internet-Draft          Logical Interface Support           October 2011

2.  Terminology

   All the mobility related terms used in this document are to be
   interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213]
   and [RFC5844].  In addition, this document introduces the following
   terms:

   PIF  (Physical Interface) - a network interface card attached to an
      an host providing network connectivity (e.g. an Ethernet card, a
      WLAN card, an LTE interface).

   LIF  (Logical Interface) - It is a virtual interface in the IP stack.
      It appears just as any other physical interface, provides similar
      semantics with respect to packet transmit and receive functions to
      the upper layers in the IP stack.  However, it is only logical
      construct and is not a representation of an instance of any
      physical hardware.

   VLL-ID  (Virtual Link-layer ID) - a virtual link-layer address
      configured on the logical interface.  This identifier can be
      randomly generated, or configured based on the link-layer address
      of one of the physical interface.

   Sub-If  (Sub Interface) - a physical interface that is part of a
      logical interface construct.  For example, a logical interface may
      have been created abstracting two physical interfaces, LTE and
      WLAN.  These physical interfaces, LTE and WLAN are referred to as
      sub-interfaces of that logical interface.  In some cases, a sub-
      interface can also be another logical interface, such as an IPsec
      tunnel interface.

Melia & Gundavelli         Expires May 3, 2012                  [Page 5]
Internet-Draft          Logical Interface Support           October 2011

3.  Hiding Link-layer Technologies - Approaches and Applicability

   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.
   Later sections of this document analyze the applicability of these
   solution approaches for supporting features such as, inter-technology
   handovers and IP flow mobility support for a mobile node in a Proxy
   Mobile IPv6 domain [RFC5213].

3.1.  Link-layer Abstraction - Approaches

   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 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.
                   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 EPC [TS23401].  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

Melia & Gundavelli         Expires May 3, 2012                  [Page 6]
Internet-Draft          Logical Interface Support           October 2011

      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 LTE/EPC 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
      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 Logical interface, which is
      defined in this document, or the bonding driver (a Linux
      implementation).

3.2.  Applicability Statement

   We now focus on the applicability of the above solutions against the
   following requirements:

   o  multi technology support

   o  sequential vs. simultaneous access

Melia & Gundavelli         Expires May 3, 2012                  [Page 7]
Internet-Draft          Logical Interface Support           October 2011

3.2.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 access points 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
   access points 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. access points) 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
   network domains.  This solution does not impose any change at the IP
   layer since changes in the access technology occur at layer two.

3.2.2.  Logical Interface

   The use of a logical interface allows the mobile node to provide a
   single interface view to the layers above IP (thus not changing the
   IP layer itself).  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 special mechanisms are required to enable
   addressing a particular interface from the network (e.g. for flow
   mobility).  In particular extensions to PMIPv6 are required in order
   to enable the network (i.e., the MAG and LMA) to deal with logical
   interface, 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.

   It is therefore clear that the Logical Interface approach satisfies

Melia & Gundavelli         Expires May 3, 2012                  [Page 8]
Internet-Draft          Logical Interface Support           October 2011

   the multi technology and the sequential vs: simultaneous access
   support.

Melia & Gundavelli         Expires May 3, 2012                  [Page 9]
Internet-Draft          Logical Interface Support           October 2011

4.  Technology Use cases

   The 3GPP has defined the Evolved Packet Core (EPC) for heterogeneous
   wireless access.  A mobile device equipped with 3GPP and non-3GPP
   wireless technologies can simultaneously or sequentially connect any
   of the available devices and receive IP services through any of them.
   This document focuses on the simultaneous/sequential use of these
   technologies and on the use cases that derive.

   As mentioned in the previous sections the Logical Interface construct
   is required to hide the specifics of each technology in the context
   of network based mobility (e.g. in PMIPv6 deployments).  The LIF
   concept can be used with at least the following technologies: 3GPP
   access technologies (3G, LTE), WIMAX access technology and IEEE
   802.11 access technology.

   3GPP  In most OS implementations the connection setup establishes a
      PPP interface through the IPCP and IPv6CP protocol [RFC5072].  In
      this case the PPP interface does not have any L2 address assigned
      and does not generate any ARP or ND message for layer two address
      resolution.  Conversely recent implementations configure an
      ethernet alike interface at OS level hiding to the upper layers
      the PPP nature of the connection.  It has been verified (Android
      platform) that in these cases the ethernet alike interface
      configures a random L2 MAC address and uses this address as source
      link layer address in ND messages.  ARP is also run between the
      mobile device and the remote peer (the network is a /30 address
      space).

   WIMAX  In WiMAX system also, the connection between the mobile
      station (MS) and the access router (AR) is a point-to-point link.
      The MS auto configures an address based on the prefix advertised
      by the AR or is assigned an address via DHCPv6.  The stateless
      address auto-configuration is performed as per [RFC4861] and the
      IPv6 address is formed by adding an IID to the prefix learnt from
      Router Advertisement.  IPv6 packets sent or received by the MS are
      identified by specific IDs, by which the AR can map them to the
      corresponding tunnel in the network.

   WIFI  TBD

   IPsec  TBD

Melia & Gundavelli         Expires May 3, 2012                 [Page 10]
Internet-Draft          Logical Interface Support           October 2011

5.  Logical Interface Functional Details

   On most operating systems, a network interface is associated with a
   physical device that offers the services for transmitting and
   receiving IP packets to the applications on the host.  In some
   configurations, a network interface can also be implemented as a
   logical interface which does not have the inherent capability to
   transmit, or receive packets on a physical medium, but relies on
   other physical interfaces for such services.  Example of such
   configuration is an IP tunnel interface.  General overview of a
   logical interface is shown in Figure 3.  This section identifies the
   functional details of a logical interface and provides some
   implementation considerations.

   The logical interface allows heterogeneous attachment while leaving
   the change in the media transparent to the IP stack.  Simultaneous
   and sequential network attachment procedures are possible enabling
   inter-technology and flow mobility scenarios.

                                  +----------------------------+
                                  |          TCP/UDP           |
           Session to IP    +---->|                            |
           Address binding  |     +----------------------------+
                            +---->|             IP             |
           IP Address       +---->|                            |
           binding          |     +----------------------------+
                            +---->|     Logical Interface      |
           Logical to       +---->|       IPv4/IPv6 Address    |
           Physical         |     +----------------------------+
           Interface        +---->|  L2  |  L2  |       |  L2  |
           binding                |(IF#1)|(IF#2)| ..... |(IF#n)|
                                  +------+------+       +------+
                                  |  L1  |  L1  |       |  L1  |
                                  |      |      |       |      |
                                  +------+------+       +------+

              Figure 3: General overview of logical interface

   From the perspective of the IP stack and the applications, a Logical
   interface is just another interface.  In fact, the logical interface
   is only visible to the IP and upper layers when enabled.  A host does
   not see any operational difference between a Logical and a physical
   interface.  As with physical interfaces, a Logical interface is
   represented as a software object to which IP address configuration is
   bound.  However, the Logical interface has some special properties
   which are essential for enabling inter-technology handover and flow-
   mobility features.  Following are those properties:

Melia & Gundavelli         Expires May 3, 2012                 [Page 11]
Internet-Draft          Logical Interface Support           October 2011

   o  P1: The logical interface has a relation to a set of physical
      interfaces (sub-interfaces) on the host that it is abstracting.
      These sub-interfaces can be attached or detached from the Logical
      Interface at any time.  The sub-interfaces attached to a Logical
      interface are not visible to the IP and upper layers.

   o  P2: The logical Interface may either use a virtual interface
      identifier independent of the interface identifiers of its sub-
      interfaces, or it may use the link-layer identifier from one of
      its sub-interfaces.

   o  P3:The logical interface has the path awareness with respect to
      the attached IP networks.  For example, the logical interface may
      be bound to two IP networks, CAFE::/64 and BABA::/64, each of
      these prefixes may have been hosted on access networks attached
      through different sub-interfaces, WLAN and LTE.  The logical
      interface has the path awareness with respect to IP network to
      sub-interface mapping.

   o  P4: The logical interface may be attached to multiple access
      technologies with different link MTU values.  The adopted MTU
      value for the logical interface must be lowest MTU value across
      those access technologies.

   o  P5: The Transmit/Receive functions of the Logical interface are
      mapped to the Transmit/Receive services exposed by the sub-
      interfaces.  This mapping is dynamic and any change is not visible
      to the upper layers of the IP stack.

   o  P6:The logical interface adapts to the point-to-point link model.

   o  P7: The logical interface maintains IP flow information for each
      of its sub-interfaces.  A conceptual data structure can be
      maintained for this purpose.  The host may populate this
      information based on tracking each of the sub-interface for the
      active flows.

5.1.  Configuration of a Logical Interface

   A host may be statically configured with the logical interface
   configuration, or an application such as a connection manager on the
   host may dynamically create it.  Furthermore, the set of sub-
   interfaces that are part of a logical interface construct may be a
   fixed set, or may be kept dynamic, with the sub-interfaces getting
   added or deleted as needed.  The specifics on how a host creates a
   logical interface, or how it decides to add or delete a sub-interface
   to a logical interface is out side the scope of this document.

Melia & Gundavelli         Expires May 3, 2012                 [Page 12]
Internet-Draft          Logical Interface Support           October 2011

5.2.  MTU considerations

   The link MTU (maximum transmission unit) value configured on a
   logical interface should be the lowest of the MTU values supported
   across any of the physical interfaces that are part of that logical
   interface construct.  The MTU value should be configured as part of
   the logical interface creation on the host.

   Furthermore, this value must be updated any time there is a change to
   the logical interface construct, such as when interfaces are added or
   deleted from the logical interface setup.  Any time there is an
   inter-technology handover between two access technologies, the
   applications on the host bound to the IP address configuration on the
   logical interface will not detect the change and will continue to use
   the MTU value of the logical interface for the outbound packets,
   which is never greater than the MTU value on that supported access
   network.  However, the access network may continue to deliver the
   packets conforming to the MTU value supported on that access
   technology and the logical interface should be able to receive those
   packets from the physical interface attached to that network.  This
   approach of MTU configuration will ensure there is no IP packet
   fragmentation after inter-technology handovers.

5.3.  Supported Link models for a logical interface

   As per the base Proxy Mobile IPv6 specification [RFC5213] the media
   underneath the physical interface has to be bound to a point-to-point
   link [RFC5213].  Access technologies that provides a shared media
   (e.g., IEEE 802.11) can be supported as long as they provide a point-
   to-point link [RFC4861].  The details of how a shared media provides
   a point to point link are link layer specific and/or operational
   matters that are out of scope of this document.  For example IEEE
   802.11 media can provide a point-to-point link via the appropriate
   use of IEEE 802.1Q VLAN header where a distinct VLAN is configured
   between the MAG and each of the mobile node, or by the approach of
   MAG transmitting multicast packets as layer-2 unicast packets
   [RFC6085] and thereby preserving the point-to-point link properties
   on a shared link.

5.4.  Link-layer Identifier of a Logical Interface

   The logical Interface may or may not use the link-layer identifier
   from one of its sub-interfaces.  Following are the considerations.

   o  In access architectures where it is possible to adopt a virtual
      link-layer identifier and use it for layer-2 communications in any
      of the access networks, a virtual identifier (VLL-Id) may be used.
      The specifics on how that identifier is chosen is out side the

Melia & Gundavelli         Expires May 3, 2012                 [Page 13]
Internet-Draft          Logical Interface Support           October 2011

      scope of this document.  This identifier may be used for all link-
      layer communications.  This identifier may also be used for
      generating IPv6 global or link-local addresses on that interface.

   o  In access architectures, where the link-layer identifier is
      associated with a specific access technology, it will not be
      possible for the logical interface to adopt a virtual identifier
      and it use it across different access networks.  In such networks,
      the logical interface must adopt the identifier of the respective
      sub-interface through which a packet is being transmitted.

5.5.  ND Considerations for Logical Interface

   The following are the Neighbor Discovery related considerations for
   the logical interface.

   o  Any Neighbor Discovery messages, such as Router Solicitation,
      Neighbor Solicitation messages that the host sends to a multicast
      destination address of link-local scope such as, all-nodes, all-
      routers, solicited-node multicast group addresses, using either an
      unspecified (::) source address, or a link-local address
      configured on the logical interface will be replicated and
      forwarded on each of the sub-interfaces under that logical
      interface.  However, if the destination address is a unicast
      address and if that target is known to exist on a specific sub-
      interface, the message will be forwarded only on that specific
      sub-interface.

   o  Any Neighbor Discovery messages, such as Router Advertisement,
      that the host receives from any of its sub-interfaces, will be
      associated with the logical interface, i.e., in some
      implementations the message will appear on the input interface of
      the logical interface.

   o  When using Stateless Address Autoconfiguraion [RFC4862] for
      generating IPv6 address configuration on the logical interface,
      the host may use any of the IPv6 prefixes received from the Router
      Advertisement messages that it received from any of its sub-
      interfaces.

   o  The response to a Neighbor Discovery message received for a
      unicast, link-specific multicast group address, will be sent on
      the same sub-interface path where the packet was received.

   o  When using DHCPv4 [RFC2131] for obtaining address configuration
      for the logical interface, the value in the chaddr field in the
      DHCP messages will be based on the link-layer identifier scheme
      chosen by the logical interface.

Melia & Gundavelli         Expires May 3, 2012                 [Page 14]
Internet-Draft          Logical Interface Support           October 2011

   .

5.6.  Logical Interface Forwarding Conceptual Data Structures

   The logical interface should maintain the list of sub-interfaces that
   are part of the logical interface.  This information can be
   maintained in a conceptual data structure, LIF Table.  The logical
   interface should also maintain the list of flows associated with a
   given sub-interface.  This information can be maintained in a
   conceptual data structure, PIF Table.  Both of these data structures
   have to be associated with a logical interface, and are depicted in
   Figure 4

      LIF TABLE                           FLOW table
    +===============================+   +=============================+
    | PIF_ID | FLOW RoutingPolicies |   | FLOW ID | Physical_Intf_Id  |
    |        | Home Network Prefix  |   +-----------------------------+
    |        | Link Layer Address   |   | FLOW_ID | Physical_Intf_Id  |
    |        | Status               |   +=============================+
    +-------------------------------|
    | PIF_ID | FLOW RoutingPolicies |
    |        | Home Network Prefix  |
    |        | Link Layer Address   |
    |        | Status               |
    +-------------------------------+
    | ....   | ....                 |
    +===============================+

                                 Figure 4

   The LIF table maintains the mapping between the LIF and each PIF
   associated to the LIF (see P3).  For each PIF entry the table should
   store the associated Routing Policies, the Home Network Prefix
   received during the SLAAC procedure, the configured Link Layer
   Address (as described above) and the Status of the PIF (e.g. active,
   not active).  The method by which the Routing Policies are configured
   on the host is out of scope for this document.

   The FLOW table allows the logical interface to properly route each IP
   flow over the right interface.  The logical interface can identify
   the flows arriving on its sub-interfaces and associate them to those
   sub-interfaces.  This approach is similar to reflective QoS performed
   by the IP routers.  For locally generated traffic (e.g. unicast
   flows), the logical interface should perform interface selection
   based on the Flow Routing Policies.  In case traffic of an existing
   flow is suddenly received from the network on a different sub-
   interface than the one locally stored, the logical interface should

Melia & Gundavelli         Expires May 3, 2012                 [Page 15]
Internet-Draft          Logical Interface Support           October 2011

   interpret the event as an explicit flow mobility trigger from the
   network and it should update the PIF_ID parameter in the FLOW table.
   Similarly, locally generated events from the sub-interfaces, or
   configuration updates to the local policy rules can cause updates to
   the table and hence trigger flow mobility.

Melia & Gundavelli         Expires May 3, 2012                 [Page 16]
Internet-Draft          Logical Interface Support           October 2011

6.  Logical Interface Use-cases in Proxy Mobile IPv6

   This section explains how the Logical interface support on the mobile
   node can be used for enabling some of the Proxy Mobile IPv6 protocol
   features.

6.1.  Multihoming Support

   A mobile node with multiple interfaces can attach simultaneously to
   the Proxy Mobile IPv6 domain.  Each of the attachment links are
   assigned a unique set of IPv6 prefixes.  If the host is configured to
   use Logical interface over the physical interface through which it is
   attached, following are the related considerations.

                                           LMA Binding Table
                                    +================================+
                           +----+   | HNP   MN-ID  CoA   ATT   LL-ID |
                           |LMA |   +================================+
                           +----+   | HNP-1  MN-1  PCoA-1  5    ZZZ  |
                            //\\    | HNP-2  MN-1  PCoA-2  4    ZZZ  |
                 +---------//--\\-----------+
                (         //    \\           )
                (        //      \\          )
                 +------//--------\\--------+
                       //          \\
               PCoA-1 //            \\ PCoA-2
                   +----+          +----+
            (WLAN) |MAG1|          |MAG2| (WiMAX)
                   +----+          +----+
                      \               /
                       \             /
                  HNP-1 \           / HNP-2
                         \         /
                          \       /
                     +-------+ +-------+
                     | if_1  | | if_2  |
                     |(WLAN) | |(WiMAX)|
                     +-------+-+-------+
                     |     Logical     |
        (LL-ID: ZZZ) |    Interface    | HNP-1::zzz/128
                     +-----------------| HNP-2::zzz/128
                     |       MN        |
                     +-----------------+

                       Figure 5: Multihoming Support

Melia & Gundavelli         Expires May 3, 2012                 [Page 17]
Internet-Draft          Logical Interface Support           October 2011

   o  The mobile node detects the advertised prefixes from the MAG1 and
      MAG2 as the on link prefixes on the link to which the Logical
      interface is attached.

   o  The mobile node can generate address configuration using stateless
      auto configuration mode from any of those prefixes.

   o  The applications can be bound to any of the addresses bound to the
      Logical interface and that is determined based on the source
      address selection rules.

   o  The host has path awareness for the hosted prefixes based on the
      received Router Advertisement messages.  Any packets with source
      address generated using HNP_1 will be routed through the interface
      if_1 and for packets using source address from HNP_2 will be
      routed through the interface if_2.

6.2.  Inter-Technology Handoff Support

   The Proxy Mobile IPv6 protocol enables a mobile node with multiple
   network interfaces to move between access technologies, but still
   retaining the same address configuration on its attached interface.
   The protocol enables a mobile node to achieve address continuity
   during handoffs.  If the host is configured to use Logical interface
   over the physical interface through which it is attached, following
   are the related considerations.

Melia & Gundavelli         Expires May 3, 2012                 [Page 18]
Internet-Draft          Logical Interface Support           October 2011

                                           LMA's Binding Table
                                    +================================+
                           +----+   | HNP   MN-ID  CoA   ATT   LL-ID |
                           |LMA |   +================================+
                           +----+   | HNP-1   MN-1  PCoA-1  5    ZZZ |
                            //\\                   (pCoA-2)(4) <-change
                 +---------//--\\-----------+
                (         //    \\           )
                (        //      \\          )
                 +------//--------\\--------+
                       //          \\
               PCoA-1 //            \\ PCoA-2
                   +----+          +----+
            (WLAN) |MAG1|          |MAG2| (WiMAX)
                   +----+          +----+
                      \               /
                       \    Handoff  /
                        \    ---->  / HNP-1
                         \         /
                          \       /
                     +-------+ +-------+
                     | if_1  | | if_2  |
                     |(WLAN) | |(WiMAX)|
                     +-------+-+-------+
                     |     Logical     |
        (LL-ID: ZZZ) |    Interface    | HNP-1::zzz/128
                     +-----------------|
                     |       MN        |
                     +-----------------+

                Figure 6: Inter-Technology Handoff Support

   o  When the mobile node performs an handoff between if_1 and if_2,
      the change will not be visible to the applications of the mobile
      node.  It will continue to receive Router Advertisements from the
      network, but from a different sub-interface path.

   o  The protocol signaling between the network elements will ensure
      the local mobility anchor will switch the forwarding for the
      advertised prefix set from MAG1 to MAG2.

   o  The MAG2 will host the prefix on the attached link and will
      include the home network prefixes in the Router Advertisements
      that it sends on the link.

Melia & Gundavelli         Expires May 3, 2012                 [Page 19]
Internet-Draft          Logical Interface Support           October 2011

6.3.  Flow Mobility Support

   For supporting flow mobility support, there is a need to support
   vertical handoff scenarios such as transferring a subset of
   prefix(es) (hence the flows associated to it/them) from one interface
   to another.  The mobile node can support this scenario by using the
   Logical interface support.  This scenario is similar to the Inter-
   technology handoff scenario defined in Section 6.2, only a subset of
   the prefixes are moved between interfaces.

   Additionally, IP flow mobility in general initiates when the LMA
   decides to move a particular flow from its default path to a
   different one.  The LMA can decide on which is the best MAG that
   should be used to forward a particular flow when the flow is
   initiated e.g. based on application policy profiles) and/or during
   the lifetime of the flow upon receiving a network-based or a mobile-
   based trigger.

   As an example of mobile-based triggers, the LMA could receive input
   (e.g.by means of a layer 2.5 function via L3 signaling [RFC5677])
   from the MN detecting changes in the mobile wireless environment
   (e.g. weak radio signal, new network detected, etc.).  Upon receiving
   these triggers, the LMA can initiate the flow mobility procedures.
   For instance, when the mobile node only supports single-radio
   operation (i.e. one radio transmitting at a time), only sequential
   (i.e. not simultaneous) attachment to different MAGs over different
   media is possible.  In this case layer 2.5 signaling can be used to
   perform the inter-access technology handover and communicate to the
   LMA the desired target access technology, MN-ID, Flow-ID and prefix.

Melia & Gundavelli         Expires May 3, 2012                 [Page 20]
Internet-Draft          Logical Interface Support           October 2011

7.  IANA Considerations

   This specification does not require any IANA Actions.

Melia & Gundavelli         Expires May 3, 2012                 [Page 21]
Internet-Draft          Logical Interface Support           October 2011

8.  Security Considerations

   This specification explains the operational details of Logical
   interface on an IP host.  The Logical Interface implementation on the
   host is not visible to the network and does not require any special
   security considerations.

Melia & Gundavelli         Expires May 3, 2012                 [Page 22]
Internet-Draft          Logical Interface Support           October 2011

9.  Authors

   This document reflects contributions from the following authors
   (listed in alphabetical order):

   Carlos Jesus Bernardos Cano

      cjbc@it.uc3m.es

   Antonio De la Oliva

      aoliva@it.uc3m.es

   Yong-Geun Hong

      yonggeun.hong@gmail.com

   Kent Leung

      kleung@cisco.com

   Tran Minh Trung

      trungtm2909@gmail.com

   Hidetoshi Yokota

      yokota@kddilabs.jp

   Juan Carlos Zuniga

      JuanCarlos.Zuniga@InterDigital.com

10.  Acknowledgements

   The authors would like to acknowledge prior discussions on this topic
   in NETLMM and NETEXT working groups.  The authors would also like to
   thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil,
   Julien Laganier for all the discussions on this topic.

11.  References

11.1.  Normative References

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,

Melia & Gundavelli         Expires May 3, 2012                 [Page 23]
Internet-Draft          Logical Interface Support           October 2011

              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", September 2007.

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

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

11.2.  Informative References

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC5072]  Varada, S., "IP Version 6 over PPP", September 2007.

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

   [RFC6085]  Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
              "Address Mapping of IPv6 Multicast Packets on Ethernet",
              RFC 6085, January 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [TS23401]  "3rd Generation Partnership Project; Technical
              Specification Group Services and System Aspects; General
              Packet Radio Service (GPRS) enhancements for Evolved
              Universal Terrestrial Radio Access Network (E-UTRAN)
              access.", 2009.

Melia & Gundavelli         Expires May 3, 2012                 [Page 24]
Internet-Draft          Logical Interface Support           October 2011

Authors' Addresses

   Telemaco Melia (editor)
   Alcatel-Lucent
   Route de Villejust
   Nozay  91620
   France

   Email: telemaco.melia@alcatel-lucent.com

   Sri Gundavelli (editor)
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

Melia & Gundavelli         Expires May 3, 2012                 [Page 25]