Internet Engineering Task Force (IETF) T. Melia, Ed. Request for Comments: 7847 Kudelski Security Category: Informational S. Gundavelli, Ed. ISSN: 2070-1721 Cisco May 2016 Logical-Interface Support for IP Hosts with Multi-Access Support
AbstractA 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. Logical-interface support is required on the mobile node attached to 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 the logical-interface construct and the specifics on how 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 conjunction with various mobility management features. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7847.
Copyright Notice Copyright (c) 2016 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Hiding Link-Layer Technologies -- Approaches and Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Link-Layer Abstraction -- Approaches . . . . . . . . . . 4 3.2. Link-Layer Support . . . . . . . . . . . . . . . . . . . 5 3.3. Logical Interface . . . . . . . . . . . . . . . . . . . . 6 4. Technology Use Cases . . . . . . . . . . . . . . . . . . . . 6 5. Logical-Interface Functional Details . . . . . . . . . . . . 7 5.1. Configuration of a Logical Interface . . . . . . . . . . 8 5.2. Logical-Interface Conceptual Data Structures . . . . . . 9 6. Logical-Interface Use Cases in Proxy Mobile IPv6 . . . . . . 11 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 6.2. Inter-technology Handoff Support . . . . . . . . . . . . 12 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
RFC5213] is a network-based mobility management protocol standardized by IETF. One of the key goals of the PMIPv6 protocol is to enable a mobile node to perform handovers across access networks based on different access technologies. The protocol was also designed with the goal to allow a mobile node to simultaneously attach to different access networks and perform flow- based access selection [RFC7864]. The base protocol features specified in [RFC5213] and [RFC5844] have support for these capabilities. However, to support these features, the mobile node is required to be enabled with a specific software configuration known as logical-interface support. The logical-interface configuration is essential for a mobile node to perform inter-access handovers without impacting the IP sessions on the host. A logical-interface construct is internal to the operating system. It is an approach of interface abstraction, where a logical link- layer implementation hides a variety of physical interfaces from the IP stack. This semantic was used on a variety of operating systems to implement applications such as Mobile IP client [RFC6275] and IPsec VPN client [RFC4301]. Many host operating systems have support for some form of such logical-interface construct. But, there is no specification that documents the behavior of these logical interfaces or the requirements of a logical interface for supporting the above- mentioned mobility management features. This specification attempts to document these aspects. The rest of the document provides a functional description of a logical interface on the mobile node and the interworking between a mobile node using a logical interface and the network elements in the Proxy Mobile IPv6 domain. It also analyzes the issues involved with the use of a logical interface and characterizes the contexts in which such usage is appropriate. RFC5213] and [RFC5844]. In addition, this document uses the following terms: PIF (Physical Interface): A network interface module on the host that is used for connecting to an access network. A host typically has a number of network interface modules, such as Ethernet, Wireless LAN, LTE, etc. Each of these network interfaces can support specific link technology.
LIF (Logical Interface): A virtual interface in the IP stack. A logical interface appears to the IP stack just as any other physical interface and provides similar semantics with respect to packet transmit and receive functions to the upper layers of the IP stack. However, it is only a logical construct and is not a representation of an instance of any physical hardware. SIF (Sub-Interface): A physical or logical interface that is part of a logical-interface construct. For example, a logical interface may have been created by 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. TS23401] where the User Equipment (UE) can perform inter-access handovers between three different access technologies (2G GSM/EDGE Radio Access Network (GERAN), 3G Universal Terrestrial Radio Access Network (UTRAN), and 4G Evolved UTRAN (E-UTRAN)) that are invisible to the IP layer at the UE.
o A logical interface denotes a mechanism that logically groups several physical interfaces so they appear to the IP layer as a single interface (see Figure 1). Depending on the type of access technologies, it might be possible to use more than one physical interface at a time -- such that the node is simultaneously attached via different access technologies -- or just perform handovers across a variety of physical interfaces. Controlling the way the different access technologies are used (simultaneous, sequential attachment, etc.) is not trivial and requires additional intelligence and/or configuration within the logical- interface implementation. The configuration is typically handled via a connection manager, and it is based on a combination of user preferences on one hand and operator preferences such as those provisioned by the Access Network Discovery and Selection Function (ANDSF) [TS23402] on the other hand. The IETF Interfaces MIB specified in [RFC2863] and the YANG data model for interface management specified in [RFC7223] treat a logical interface just like any other type of network interface on the host. This essentially makes the logical interface a natural operating system construct.
RFC 5213. RFC 5213 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 the requirement of multi-access technology and supports both sequential and simultaneous access. RFC5072]. In this case, the PPP interface does not have any layer 2 (L2) addresses assigned. In some other
implementations, the wireless modem is presented to the IP layer as a virtual Ethernet interface. Figure 1. The logical interface allows heterogeneous attachment while making changes in the underlying media transparent to the IP stack. Simultaneous and sequential network attachment procedures are therefore 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 1: 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 that are essential for enabling inter-technology handover and flow- mobility features. Following are those properties: 1. 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. 2. The logical interface may be attached to multiple access technologies. 3. 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. 4. The logical interface maintains IP flow information for each of its sub-interfaces. A conceptual data structure is maintained for this purpose. The host may populate this information based on tracking each of the sub-interfaces for the active flows.
Figure 2 shows an example LIF table where logical interface LIF-1 has three sub-interfaces, ETH-0, WLAN-0, and LTE-0, and logical interface LIF-2 has two sub- interfaces, ETH-1 and WLAN-1. For each LIF entry, the table should store the associated link status and policy associated with that sub- interface (e.g., active or not active). The method by which the routing policies are configured on the host is out of scope for this document. +=======================+========================+==================+ | Logical_Interface | Sub_Interface | Status/Policy | +=======================+========================+==================+ | LIF-1 | ETH-0 | UP | +=======================+========================+==================+ | LIF-1 | WLAN-0 | DOWN | +=======================+========================+==================+ | LIF-1 | LTE-0 | UP | +=======================+========================+==================+ | LIF-2 | ETH-1 | UP | +=======================+========================+==================+ | LIF-2 | WLAN-1 | UP | +=======================+========================+==================+ Figure 2: Logical-Interface Table The logical interface also maintains the list of flows associated with a given sub-interface, and this conceptual data structure is called the Flow table. Figure 3 shows an example Flow table, where flows FID-1, FID-2, FID-3, FID-4, and FID-5 are associated with sub- interfaces ETH-0, WLAN-0, LTE-0, ETH-1, and WLAN-1, respectively.
+=======================+========================+ | Flow | Sub_Interface | +=======================+========================+ | FID-1 | ETH-0 | +=======================+========================+ | FID-2 | WLAN-0 | +=======================+========================+ | FID-3 | LTE-0 | +=======================+========================+ | FID-4 | ETH-1 | +=======================+========================+ | FID-5 | WLAN-1 | +=======================+========================+ Figure 3: Flow Table The Flow table allows the logical interface to properly route each IP flow over a specific sub-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 from the one locally stored, the logical interface should interpret the event as an explicit flow mobility trigger from the network, and it should update the corresponding entry 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.
Figure 4 shows a mobile node with multiple interfaces attached to a Proxy Mobile IPv6 domain. In this scenario, the mobile node is configured to use a logical interface over the physical interfaces through which it is attached. LMA Binding Table +========================+ +----+ | HNP MN-ID CoA ATT | |LMA | +========================+ +----+ | HNP-1 MN-1 PCoA-1 5 | //\\ | HNP-1 MN-1 PCoA-2 4 | +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA-1 // \\ PCoA-2 +----+ +----+ (WLAN) |MAG1| |MAG2| (3GPP) +----+ +----+ \ / \ / \ / \ / \ / +-------+ +-------+ | if_1 | | if_2 | |(WLAN) | |(3GPP) | +-------+-+-------+ | Logical | | Interface | | (HNP-1) | +-----------------| | MN | +-----------------+ Figure 4: Multihoming Support
Figure 5 shows a mobile node performing an inter-technology handoff between access networks. The protocol enables a mobile node to achieve address continuity during handoffs. If the host is configured to use a 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 | |LMA | +==========================+ +----+ | HNP-1 MN-1 PCoA-1 5 | //\\ (pCoA-2)(4) <--change +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA-1 // \\ PCoA-2 +----+ +----+ (WLAN) |MAG1| |MAG2| (3GPP) +----+ +----+ \ / \ Handoff / \ / \ / +-------+ +-------+ | if_1 | | if_2 | |(WLAN) | |(3GPP) | +-------+-+-------+ | Logical | | Interface | | (HNP-1) | +-----------------| | MN | +-----------------+ Figure 5: Inter-technology Handoff Support o When the mobile node performs a handoff between if_1 and if_2, the change will not be visible to the applications of the mobile node.
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. 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 the best MAG to 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. However, the specific details on how the LMA can formulate such flow policy is outside the scope of this document.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, DOI 10.17487/RFC5213, August 2008, <http://www.rfc-editor.org/info/rfc5213>. [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, <http://www.rfc-editor.org/info/rfc5844>. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, <http://www.rfc-editor.org/info/rfc2863>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, <http://www.rfc-editor.org/info/rfc5072>. [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>. [RFC7223] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, <http://www.rfc-editor.org/info/rfc7223>. [RFC7864] Bernardos, CJ., Ed., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", RFC 7864, DOI 10.17487/RFC7864, May 2016, <http://www.rfc-editor.org/info/rfc7864>. [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", TS 23.401, V13.6.0, March 2016.
[TS23402] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", TS 23.402, V13.5.0, March 2016.