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]