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

Versions: 00 01

NETEXT WG                                                  T. Melia, Ed.
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                        S. Gundavelli, Ed.
Expires: January 6, 2011                                           Cisco
                                                               H. Yokota
                                                                KDDI Lab
                                                            C. Bernardos
                                        Universidad Carlos III de Madrid
                                                            July 5, 2010


           Logical Interface Support for multi-mode IP Hosts
          draft-melia-netext-logical-interface-support-01.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 desirable 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.
   Furthermore, this document identifies the applicability of this
   approach to various link-layer technologies and analyses 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 January 6, 2011.




Melia, et al.            Expires January 6, 2011                [Page 1]


Internet-Draft          Logical Interface Support              July 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 Simplified BSD License.


Table of Contents

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

   2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5

   3.  Hiding link layer technologies - Approaches and
       Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Link-layer Abstraction - Approaches  . . . . . . . . . . .  6
     3.2.  Applicability Statement  . . . . . . . . . . . . . . . . .  8
       3.2.1.  Link layer support . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Logical Interface  . . . . . . . . . . . . . . . . . .  8
       3.2.3.  Conclusion . . . . . . . . . . . . . . . . . . . . . .  9

   4.  Logical Interface Operation  . . . . . . . . . . . . . . . . . 10

   5.  Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 12
     5.1.  Multihoming Support  . . . . . . . . . . . . . . . . . . . 12
     5.2.  Inter-Technology Handoff Support . . . . . . . . . . . . . 13
     5.3.  Flow Mobility Support  . . . . . . . . . . . . . . . . . . 15

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17

   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 19



Melia, et al.            Expires January 6, 2011                [Page 2]


Internet-Draft          Logical Interface Support              July 2010


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19


















































Melia, et al.            Expires January 6, 2011                [Page 3]


Internet-Draft          Logical Interface Support              July 2010


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 PMIPv6 extensions chartered in the NETEXT WG) allow the mobile
   node to attach to the network using multiple interfaces
   (simultaneously or sequentally), 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 (sequentially or
   simultaneously), or perform flow movement from one access technology
   to another.  This document analyses 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.
   This semantic is widely available in all popular operating systems.
   Many applications such as Mobile IP client [RFC3775], IPsec VPN
   client [RFC4301] and L2TP client [RFC3931] all rely on this semantic
   for their protocol implementation and the same semantic can also be
   useful in this context.  Specifically, the mobile node [RFC5213] can
   use the logical interface configuration for leveraging various
   network-based mobility management features provided by the Proxy
   Mobile IPv6 domain.  The rest of the document provides the
   operational details of the 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.  It also analyzes
   the issues involved with this approach and characterizes the contexts
   in which such use is appropriate.















Melia, et al.            Expires January 6, 2011                [Page 4]


Internet-Draft          Logical Interface Support              July 2010


2.  Requirements Language

   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC2119].














































Melia, et al.            Expires January 6, 2011                [Page 5]


Internet-Draft          Logical Interface Support              July 2010


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

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

                   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



Melia, et al.            Expires January 6, 2011                [Page 6]


Internet-Draft          Logical Interface Support              July 2010


      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

               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
      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 [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  |
                                      |      |      |       |      |
                                      +------+------+       +------+



Melia, et al.            Expires January 6, 2011                [Page 7]


Internet-Draft          Logical Interface Support              July 2010


                             Logical IP Interface

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

   o  no impact to the IP layer (e.g.  Neighbor Discovery, path MTU)

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




Melia, et al.            Expires January 6, 2011                [Page 8]


Internet-Draft          Logical Interface Support              July 2010


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

   Neighbor discovery in conjunction with the logical interface concept
   has been widely studied for IPv4.  Link awareness and gratuitous ARP
   messages ensure neighbor reachability in case of media change.  The
   same apply to IPv6 where Router Solicitation/Router Advertisement can
   be sent/received to efficiently manage neighbor cache population.

3.2.3.  Conclusion

   From the above it is clear that the logical interface is the best
   most appropriate solution.  It allows heterogeneous attachement while
   leaving the change in the meadi transparent to the IP stack.
   Simultaneous and sequential network attachment procedures are
   possible enabling inter-technology and flow mobility scenarios.
   Thorugh link awareness the logical interface can keep consistent
   neighbor caches and move flows across access networks transparently
   to the upper layers.























Melia, et al.            Expires January 6, 2011                [Page 9]


Internet-Draft          Logical Interface Support              July 2010


4.  Logical Interface Operation

   On most operating systems, a network interface is associated with a
   physical device that provides the capability for transmitting and
   receiving network packets.  In some cases a network interface can
   also be implemented as a logical interface which does not feature any
   packet transmission or receive capabilities, but relies on other
   network interfaces for such capabilities.  This logical interface can
   be realized by means of a Logical interface.

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

                Figure 1: Logical Interface Implementation

   From the perspective of the IP stack and the applications, a Logical
   interface is just another interface.  A host does not see any
   difference between a Logical and a physical interface.  All
   interfaces are represented as software objects to which IP address
   configuration is bound.  However, the Logical interface has some
   special properties which are essential for enabling intert-technology
   handover and flow-mobility features.  Following are those properties:

   o  Logical interface is a logical interface that appears to the host
      stack as any other interface.  IP address configuration can be
      bound to this interface by configuring one or more IPv4 and/or
      IPv6 addresses to this interface.

   o  Logical interface has a relation to a set of physical interfaces
      on the host.  These physical interfaces in the context of Logical
      interface are known as sub-interfaces.  These sub-interfaces
      provide transmit and receive functions for sending and receiving
      packets over physical links.  A Logical interface can receive
      packets sent to any of its sub-interfaces.  In other words the MN



Melia, et al.            Expires January 6, 2011               [Page 10]


Internet-Draft          Logical Interface Support              July 2010


      ccepts packets on any physical interface as long as the IP address
      is valid (downlink).

   o  The link-layer identifier of the Logical interface is used in the
      link-layer header of the IP packets sent through this interface,
      and the link-layer address of the physical interface will not be
      used.

   o  The send/receive vectors of a Logical interface are managed
      dynamically and are tied to the sub-interfaces.  The mapping
      between this Logical interface and the sub-interfaces can change
      dynamically and this change will not be visible to the
      applications.  The side effect of this is the ability for the
      application bound to the address configuration on the Logical
      interface, to survive across inter-technology handoffs.
      Applications will survive across the mapping change between a
      Logical interface and its sub interfaces.

   o  An IP link as seen by the applications that the Logical interface
      is being part of through specific sub interface(s), when changed
      to be as part of through a different set of sub interface(s), will
      not trigger session loss, address loss, as long as the prefix is
      valid, and the host continues to exchange Neighbor Discovery
      meesages [RFC4861] from the IP routers to the Logical interface
      over the sub-interface(s).

   o  The host has the path awareness of an IPv4/IPv6 link through a
      sub-interface and standard routing table(s) lookup (via the
      logical interface) uses the sub-interfaces for packet forwarding.
      Addresses from Prefix P1, P2 tied to the Logical interface, may
      have two different link paths, Prefix P1 over E0, Prefix P2 over
      E1, and this mapping may be reversed, without applications being
      aware of, and with the needed path changes on the network side.

   o  The Logical interface MUST transmit uplink packets on the same
      physical interface on which the downlink packet was received for
      the particular prefix/flow.  This will guarantee that packets
      belonging to the same session (e.g.  TCP connection) are routed
      along the same path (downlink and uplink).  In other words a flow
      mobility decision taken at the LMA will be understood at the MN as
      an implicit decision when packets belonging to the same flow will
      arrive at a new interface.









Melia, et al.            Expires January 6, 2011               [Page 11]


Internet-Draft          Logical Interface Support              July 2010


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

5.1.  Multihoming Support

   A mobile node in the Proxy Mobile IPv6 domain can potentially attach
   to the Proxy Mobile IPv6 domain, simultaneously through multiple
   interfaces.  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's 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 2: Multihoming Support




Melia, et al.            Expires January 6, 2011               [Page 12]


Internet-Draft          Logical Interface Support              July 2010


   o  The mobile node detects the advertised prefixes from the MAG1 and
      MAG2 as the onlink 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.

5.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, et al.            Expires January 6, 2011               [Page 13]


Internet-Draft          Logical Interface Support              July 2010


                                           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 3: 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, et al.            Expires January 6, 2011               [Page 14]


Internet-Draft          Logical Interface Support              July 2010


5.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 Section 5.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 signalling [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 signalling 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, et al.            Expires January 6, 2011               [Page 15]


Internet-Draft          Logical Interface Support              July 2010


6.  IANA Considerations

   This specification does not require any IANA Actions.
















































Melia, et al.            Expires January 6, 2011               [Page 16]


Internet-Draft          Logical Interface Support              July 2010


7.  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, et al.            Expires January 6, 2011               [Page 17]


Internet-Draft          Logical Interface Support              July 2010


8.  Contributors

   This document reflects contributions from the following authors.  We
   sincerely acknowledge their contributions.

   Tran Minh Trung

      trungtm2909@gmail.com

   Yong-Geun Hong

      yonggeun.hong@gmail.com

   Kent Leung

      kleung@cisco.com

   Antonio de la Oliva

      aoliva@it.uc3m.es

   Juan Carlos Zuniga

      JuanCarlos.Zuniga@InterDigital.com


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


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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




Melia, et al.            Expires January 6, 2011               [Page 18]


Internet-Draft          Logical Interface Support              July 2010


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

10.2.  Informative References

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

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

   [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

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

   Email: telemaco.melia@alcatel-lucent.com


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

   Email: sgundave@cisco.com











Melia, et al.            Expires January 6, 2011               [Page 19]


Internet-Draft          Logical Interface Support              July 2010


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara
   Fujimino, Saitama  356-8502
   Japan

   Phone:
   Fax:
   Email: yokota@kddilabs.jp
   URI:


   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid,   28911
   Spain

   Phone: +34 91624 6236
   Fax:
   Email: cjbc@it.uc3m.es
   URI:   http://www.it.uc3m.es/cjbc/





























Melia, et al.            Expires January 6, 2011               [Page 20]


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