NETEXT Working Group CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Informational UC3M Expires: September 9, 2010 JC. Zuniga InterDigital Communications, LLC T. Melia Alcatel-Lucent Bell Labs March 8, 2010 Applicability Statement on Link Layer implementation/Logical Interface over Multiple Physical Interfaces draft-bernardos-netext-ll-statement-01 Abstract The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6) as [RFC5213]. PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi-homing support to multi-mode mobile devices. Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. Link layer implementations can hide the actually used physical interfaces from the IP stack. These techniques can be used to achieve inter-access technology handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). This document provides an informational applicability statement that analyzes the issues involved with this approach (i.e. hiding access technology changes from host IP layer) and characterizes the contexts in which such use is or is not appropriate to achieve inter-access handovers or flow mobility. 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 Bernardos, et al. Expires September 9, 2010 [Page 1] Internet-Draft Link Layer Applicability Statement March 2010 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 September 9, 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. Bernardos, et al. Expires September 9, 2010 [Page 2] Internet-Draft Link Layer Applicability Statement March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Hiding access technology changes . . . . . . . . . . . . . . . 4 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 7 3.1. Link Layer Support . . . . . . . . . . . . . . . . . . . . 7 3.2. Logical Interface . . . . . . . . . . . . . . . . . . . . . 8 3.3. Layer 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Bernardos, et al. Expires September 9, 2010 [Page 3] Internet-Draft Link Layer Applicability Statement March 2010 1. Introduction Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the first layer three hop detecting Mobile Node's (MN) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all traffic from/to the MN. Proxy mobility is based on the assumption that changes in host IP stacks are undesirable. Link layer implementations can hide the actually used physical interfaces from the IP stack. These techniques can be used to achieve inter-access technology handovers or flow mobility, i.e., the movement of selected flows from one access technology to another. It is assumed that an IP layer interface can simultaneously and/or sequentially attach to multiple MAGs (possibly over multiple media). This document provides an informational applicability statement that analyzes the issues involved with this approach and characterizes the contexts in which such use is or is not appropriate. 2. Hiding access technology changes 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. 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. Bernardos, et al. Expires September 9, 2010 [Page 4] Internet-Draft Link Layer Applicability Statement March 2010 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 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 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 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 Bernardos, et al. Expires September 9, 2010 [Page 5] Internet-Draft Link Layer Applicability Statement March 2010 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 virtual 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 | | | | | | +------+------+ +------+ Figure 3: Logical interface architecture o Layer 2.5: another potential solution is to add a layer 2.5 (e.g., shim-layer) on top of multiple L2 media. In this case, the so- called layer 2.5 takes care of making inter-media support transparent to upper layers (i.e. IP). The layer 2.5 functionality can reside only in the mobile node or it can also have a layer 2.5 counterpart in the network (see Figure 4). Communication between the layer 2.5 functionality in the mobile node and in the network can either take place over L2 or L3 signaling, as described in RFC5164 [RFC5164] and RFC5677 [RFC5677]. Bernardos, et al. Expires September 9, 2010 [Page 6] Internet-Draft Link Layer Applicability Statement March 2010 Mobile Node +-----------------------+ | TCP/UDP | AR1 AR2 +-----------------------+ +------+ +------+ | IP | | IP | | IP | +-----------------------+ +------+ +------+ | Layer 2.5 | | L2.5 | | L2.5 | +-----------------------+ +------+ +------+ | L2a | L2b | L2c | L2d | | L2d | | L2b | +-----+-----+-----+-----+ +------+ +------+ | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | +-----+-----+-----+-----+ +------+ +------+ ^ ^ |___________________________________________| Figure 4: Layer 2.5 support solution architecture 3. Applicability Statement This section analyzes the issues involved with the approaches described in Section 2 and characterizes the contexts in which their use is or is not appropriate. 3.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 Bernardos, et al. Expires September 9, 2010 [Page 7] Internet-Draft Link Layer Applicability Statement March 2010 network domains. 3.2. Logical Interface The use of a logical interface allows the mobile node to provide a single interface view to the layers above IP. 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, since the IP stack at the mobile does only "see" one interface, special mechanisms are required to enable addressing a particular interface from the network. Unmodified standard Neighbor Discovery cannot be used to detect MN attachment, since all physical interfaces are bound to the same logical IP interface. Extensions to PMIPv6 would be required in order to enable the network (i.e., the MAG and LMA) 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. 3.3. Layer 2.5 The layer 2.5 mobility support applies to cases similar to the ones described in Section 3.1, although in this case heterogeneous networks can be considered (i.e. 802.11 WLAN and 802.16 WiMAX networks), as well as networks of the same access technology that expand over multiple network domains. Hints from the layer 2.5 can help both the network and the mobile node perform inter-access technology handovers while ensuring the mobile node keeps using the same IP address. 4. IANA Considerations This document makes no request of IANA. 5. Security Considerations TBD Bernardos, et al. Expires September 9, 2010 [Page 8] Internet-Draft Link Layer Applicability Statement March 2010 6. Acknowledgments The research of Carlos J. Bernardos and Antonio de la Oliva leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN project). The work of Carlos J. Bernardos has also received funding from the Ministry of Science and Innovation of Spain, under the QUARTET project (TIN2009-13992-C02-01 7. References 7.1. Normative References [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 7.2. Informative References [I-D.yokota-netlmm-pmipv6-mn-itho-support] Yokota, H., Gundavelli, S., Trung, T., Hong, Y., and K. Leung, "Virtual Interface Support for IP Hosts", draft-yokota-netlmm-pmipv6-mn-itho-support-03 (work in progress), March 2010. [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 Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Bernardos, et al. Expires September 9, 2010 [Page 9] Internet-Draft Link Layer Applicability Statement March 2010 Antonio de la Oliva Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8803 Email: aoliva@it.uc3m.es URI: http://www.it.uc3m.es/aoliva/ Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Telemaco Melia Alcatel-Lucent Bell Labs Email: Telemaco.Melia@alcatel-lucent.com Bernardos, et al. Expires September 9, 2010 [Page 10]