[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
MIF Working Group                                             JC.Zuniga
Internet Draft                         InterDigital Communications, LLC
Intended status: Best Current Practice                          T.Melia
Expires: April 18, 2011                                  Alcatel-Lucent
                                                       October 18, 2010


             Logical Interface (LIF) Implementation Guidelines
           draft-zuniga-mif-lif-implementation-guidelines-00.txt


Abstract

   A Logical Interface is a software module internal to the host that is
   available in all popular operating systems. The use of this Logical
   Interface allows supporting different network-based mobility
   management solutions. In the NETEXT WG, work has been carried out to
   define ways in which a Logical Interface can help IP flow mobility
   (IFOM) for Proxy Mobile IPv6 [I-D.draft-ietf-netext-logical-
   interface-support]. The same Logical Interface construct can help
   other mobility management solutions like 3GPP GPRS Tunnelling
   Protocol (GTP), and it can add benefits to multi-access scenarios
   such as 3GPP Multi Access PDN Connectivity (MAPCON). This document
   provides guidelines for the implementation and configuration of a
   generic Logical Interface.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 18, 2011.



Zuniga, et al.          Expires April 18, 2011                 [Page 1]


Internet-Draft      LIF Implementation Guidelines          October 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.



Table of Contents


   1. Introduction...................................................2
   2. Conventions and Terminology....................................3
   3. Logical Interface (LIF)........................................3
      3.1. Description...............................................3
         3.1.1. Usage in PMIPv6......................................4
         3.1.2. Usage in GTP.........................................4
         3.1.3. Usage in MAPCON......................................5
      3.2. Implementation Guidelines.................................6
         3.2.1. Policy management....................................6
         3.2.2. Interface configuration..............................6
         3.2.3. Flow mapping.........................................6
   4. Security Considerations........................................7
   5. IANA Considerations............................................7
   6. References.....................................................7
      6.1. Normative References......................................7
      6.2. Informative References....................................7
   7. Acknowledgments................................................8
   Authors' Addresses................................................8



1. Introduction

   A Logical Interface (LIF) is a construct internal to the operating
   system. It is an approach where the link-layer implementation hides
   the physical interfaces from the IP stack in the host. The IP stack
   can bind one or many IPv4 and/or IPv6 addresses onto this interface.


Zuniga, et al.          Expires April 18, 2011                 [Page 2]


Internet-Draft      LIF Implementation Guidelines          October 2010


   The basic LIF function is widely available in all popular operating
   systems. Many applications such as Mobile IP client [RFC3775], IPsec
   VPN client [RFC4301] and L2TP client [RFC3931] rely on this semantic
   for their protocol implementation.

   This basic LIF functionality can be expanded for achieving more
   advanced mobility features. For instance, in the NETEXT WG work has
   been carried out to define requirements on this Logical Interface to
   support IP flow mobility (IFOM) for Proxy Mobile IPv6 [I-D.draft-
   ietf-netext-logical-interface-support]. Beyond Proxy Mobile IPv6, the
   use of a LIF can also help supporting IP flow mobility for 3GPP GPRS
   Tunnelling Protocol (GTP), and similarly it can add benefits to other
   multi-access scenarios such as 3GPP Multi Access PDN Connectivity
   (MAPCON) [TD S2-103593].

   This document describes the guidelines to implement and configure a
   generic LIF module to enable the aforementioned mobility and multi-
   access features.

2. Conventions and Terminology

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

   This document uses the terminology defined in [RFC5213], [RFC3775],
   and [RFC3810].

3. Logical Interface (LIF)

3.1. Description

   The LIF is a software construct that presents itself to higher layers
   (i.e. IP) as a normal single interface. However, instead of providing
   access to a single physical or network interface (i.e. NIC), it can
   bond one or several network interfaces. As a result, an IP layer that
   binds to a single LIF will potentially encompass access to several
   physical interfaces. The actual specific data packet delivery to the
   different network interfaces is fully controlled by the LIF and it is
   also hidden to the IP layer.

   For some implementations, the LIF is known as the master, and the
   different sub-interfaces that are bonded below it are referred to as
   slaves. In most cases, the LIF will bond several physical network
   interfaces. Nevertheless, virtual interfaces (e.g. VPN) can also be
   treated as slaves and be bonded by the LIF.



Zuniga, et al.          Expires April 18, 2011                 [Page 3]


Internet-Draft      LIF Implementation Guidelines          October 2010


   Although the main purpose of the available LIF modules is to provide
   for link aggregation and redundancy, it has been shown that some of
   the LIF functionalities can be expanded to support more advanced
   features, like multi-access handovers and IP flow mobility.

3.1.1. Usage in PMIPv6

   Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving
   the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the
   Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the
   network and performs the mobility management on behalf of the Mobile
   Node (MN) or IP host. The Local Mobility Anchor (LMA) is the home
   agent for the MN and the topological anchor point.

   At present, there is work going on in the NETEXT working group to
   extend the basic PMIPv6 functionality to support inter-access
   handovers and IP flow mobility [I-D.draft-bernardos-netext-pmipv6-
   flowmob-00]. As part of this work, the LIF has been identified as a
   critical element in the MN required to support these IP flow mobility
   and inter-access handover features. A basic set of LIF
   functionalities has been identified in the group to support multi-
   homing, inter-technology handovers and IP flow mobility in a Proxy
   Mobile IPv6 network [I-D.draft-ietf-netext-logical-interface-
   support].

3.1.2. Usage in GTP

   Another network-based mobility approach proposed in 3GPP is based on
   the GPRS Tunnelling protocol (GTP) [TS 23.402]. Similarly to the
   PMIPv6 architecture, the PDN-GW behaves as a single anchor point and
   the Serving Gateway and ePDG perform the attachment functions on
   behalf of the MN.

   Since GTP tunnels between the gateways and the anchor are transparent
   to the mobile, the LIF at the MN can perform the exact same actions
   on traffic flows regardless of the network-based mobility solution.
   This means that a LIF configured to support the PMIPv6 case can also
   support the GTP scenario without any modifications.











Zuniga, et al.          Expires April 18, 2011                 [Page 4]


Internet-Draft      LIF Implementation Guidelines          October 2010


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

              Figure 3: LIF for Proxy Mobile IPv6 / 3GPP GTP


3.1.3. Usage in MAPCON

   MAPCON is a 3GPP technology and refers to the capability of the
   Evolved Packet Core (EPC)network to configure and maintain two or
   more PDN connections for a given mobile device across heterogeneous
   wireless access networks. According to 3GPP, a one to one mapping
   exists between a PDN connection and an APN. That is, every time that
   a UE requests to activate a specific APN (either resolved to the same
   P-GW or to different P-GWs) the network assigns a new IP address (v4,
   v6 or v4v6). This APN (or IP address) can be configured on a 3GPP
   network at time T0 and moved at time T1 to the WLAN network. It
   derives that all the sessions associated to this IP address (alias
   Home Network Prefix) are handed over from the 3GPP to the non 3GPP
   access network. If the UE has configured two different APNs on the
   3GPP access network, after the handover procedure takes place it will
   continue to use one APN for each wireless channel.

   In a 3GPP context and from an application perspective, the selection
   of an IP address corresponds to map a specific application to a given
   APN. In the IETF world the APN concept does not exists and IP address
   selection has been studied in [RFC3484] and [RFC5014]. In particular
   [RFC5014] provides socket API extensions to influence the rules
   specified in [RFC3484] (e.g. prefer a public IPv4 address over a
   private one, prefer a HoA over a CoA). However, such extensions do
   not consider the particular requirements imposed by 3GPP.




Zuniga, et al.          Expires April 18, 2011                 [Page 5]


Internet-Draft      LIF Implementation Guidelines          October 2010


   The use of the LIF in the context of the MAPCON scenario simplifies
   the operations executed at the mobile device. The routing of flows to
   interfaces is achieved by means of the policies in the LIF layer and
   not according to the IP address destination. In this sense the
   routing operations at the MN are extremely simplified with respect to
   the extensive use of multiple interfaces and advance routing
   capabilities. The granularity for routing can for instance be based
   on prefixes or flows, providing great flexibility to the LIF
   implementation and associated CM operations.


3.2. Implementation Guidelines

3.2.1. Policy management

   LIF policies can be either pre-configured or dynamically configured
   on a host through some external protocol or function (e.g. OMA DM,
   IEEE 802.21 IS, etc). Normally, these policies MAY be configured and
   enforced onto the LIF by a Connection Manager (CM) [I-D.draft-seite-
   mif-connection-manager]. The CM SHOULD be in charge of managing the
   different sets of policies and enforcing them in a coherent manner.

   The mapping between physical and virtual network interfaces and the
   LIF SHOULD first follow the appropriate network-based policies and
   then the user-based policies. In this manner, network-based features
   such as IFOM can be supported.

3.2.2. Interface configuration

   A LIF MUST accept packets arriving on any of its sub-interfaces, as
   long as the destination IP address is a valid local address.

   The LIF CAN by default bond all available sub-interfaces. However, if
   a policy is defined where only some interfaces are considered, for
   instance for IFOM purposes, the LIF SHOULD only bond the sub-
   interfaces defined in the policy.

   When the link layer technology of the sub-interface encapsulates IP
   packets into frames, the link-layer identifier of the LIF SHOULD be
   used in the link-layer header of frames transmitted over this sub-
   interface.

3.2.3. Flow mapping

   In order for the LIF to support IFOM, independent flows need to be
   monitored at the LIF. Flows can be identified by a 5-tuple comprised
   of source address, destination address, source port, destination port


Zuniga, et al.          Expires April 18, 2011                 [Page 6]


Internet-Draft      LIF Implementation Guidelines          October 2010


   and protocol. Once a flow is identified, it is mapped to the sub-
   interface that has first been used to perform the packet transmission
   and reception functions for this specific flow. This mapping SHOULD
   be kept for the lifespan of the flow (e.g. TCP session).

   For IPv6, the LIF MUST be aware of the hosted prefixes based on the
   received Router Advertisement (RA) messages.  For instance, provided
   that RAs HNP1 are received on interface if1, any packet with source
   address generated using HNP1 SHOULD be forwarded through interface
   if1.

   In case packets from a certain flow are suddenly received on a
   different sub-interface, an update to the flow mapping table COULD be
   done so that the corresponding packets are now forwarded though this
   new sub-interface. This case is especially needed to support the IFOM
   as described in [I-D.draft-ietf-netext-logical-interface-support].

4. Security Considerations

   This draft discusses the operations of existing protocols without
   modifications. It does not introduce new security threats beyond the
   current security considerations of PMIPv6 [RFC5213].

5. IANA Considerations

   This document makes no request of IANA.

6. References

6.1. Normative References

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

6.2. Informative References

   [RFC3484]  Draves, R., "Default Address Selection for Internet
             Protocol version 6 (IPv6)", RFC 3484, February 2003.

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


Zuniga, et al.          Expires April 18, 2011                 [Page 7]


Internet-Draft      LIF Implementation Guidelines          October 2010


   [RFC5014]  Nordmark, E., Chakrabarti, S., and Laganier, J. "IPv6
             Socket API for Source Address Selection", RFC 5014,
             September 2007.

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

   [I-D.draft-ietf-netext-logical-interface-support]

             Melia, T. Ed., Gundavelli, S. Ed., "Logical Interface
             Support for multi-mode IP Hosts", draft-netext-logical-
             interface-support-00 (work in progress), August 2010.

   [I-D.draft-seite-mif-connection-manager]

             Seite, P., Feige, G. "Connection Manager Requirements",
             draft-seite-mif-connection-manager-01 (work in progress),
             July 2010.

   [TD S2-103593]

             3GPP TD S2-103593, Cisco, "Virtual Interface Support on UE
             - Requirements & Properties", 2010.

   [TS 23.402]

             3GPP, "3GPP TS 23.402; Architecture enhancements for non-
             3GPP accesses", 2010.

7. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



   Authors' Addresses

   Juan Carlos Zuniga
   InterDigital Communications, LLC
   Email: JuanCarlos.Zuniga@InterDigital.com

   Telemaco Melia
   Alcatel-Lucent
   Email: telemaco.melia@alcatel-lucent.com





Zuniga, et al.          Expires April 18, 2011                 [Page 8]