INTERNET-DRAFT J. Mueller Intended Status: Informational AT&T Foundry Expires: August 07, 2017 T. Herbert Facebook February 07, 2017 Mobility Management Using Identifier Locator Addressing draft-mueller-ila-mobility-03 Abstract This specification describes a new mobile network architecture which improves mobility management using Identifier Locator Addressing ILA) in IPv6 for next generation mobile telecommunication networks such as 5G and Mobile Edge Clouds. Identifier-locator addressing differentiates between location and identity of a addressable network element, which can be a mobile device or a data center task. The approach presented in this draft enables mobility management on Layer 3, and provides a simplified, GTP-tunnel-free and more efficient architecture with less core network utilization compared to traditional architecture. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Mueller, Herbert Expires August 07. 2017 [Page 1]
INTERNET DRAFT <draft-mueller-ila-mobility> 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. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Related Work, Protocols and Concepts . . . . . . . . . . . . . 6 2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Proxy Mobile IPv6 (PMIPv6) . . . . . . . . . . . . . . . . 7 2.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 7 2.4. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . 7 2.5. Identifier-Locator Addressing (ILA) . . . . . . . . . . . . 8 2.6. Comparison of ILA to alternative approaches . . . . . . . . 8 2.6.1. Identifier Locator Network Protocol (ILNP) . . . . . . 8 2.6.2. Locator Identifier Separation Protocol . . . . . . . . 8 3. Mobility Management Architectures Using ILA . . . . . . . . . . 10 3.1. Address format for ILA mobile . . . . . . . . . . . . . . . 10 3.2. Architecture with Functional Elements and Reference Points . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Functional Elements . . . . . . . . . . . . . . . . . . . . 12 3.4. Signaling and Data Flows . . . . . . . . . . . . . . . . . 14 3.5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 14 3.5.2. Attachment . . . . . . . . . . . . . . . . . . . . . . 14 3.5.3. Communication Scenarios for End-to-End Data Transport Sessions . . . . . . . . . . . . . . . . . . . . . . . 15 3.5.4. Homogeneous Handover . . . . . . . . . . . . . . . . . 20 3.5.5. Heterogeneous Handover . . . . . . . . . . . . . . . . 21 3.5.6. Detachment . . . . . . . . . . . . . . . . . . . . . . 22 3.5.6. Idle-mode and paging . . . . . . . . . . . . . . . . . 22 4. Discussion, Evaluation and Summary . . . . . . . . . . . . . . 22 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Normative References . . . . . . . . . . . . . . . . . . . 23 5.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Mueller, Herbert Expires August 07. 2017 [Page 2]
INTERNET DRAFT <draft-mueller-ila-mobility> Mueller, Herbert Expires August 07. 2017 [Page 3]
INTERNET DRAFT <draft-mueller-ila-mobility> 1. Introduction and Problem Statement The Internet Protocol (IP) has been overloaded in its functionality in the sense that it has been used as service locator and service identifier at the same time. Since changes of the associated IP address during a connection-oriented TCP session causes service interruptions, mobility has become a challenge. Mobility has been a challenge for IP based network since the area of smart phones began and has been addressed with Layer 2 and Layer 3 tunneling solutions. More specifically, uplink and downlink data traffic is encapsulated with GPRS-Tunneling-Protocol (GTP) headers, which are routed through the core network between the service and the base stations. One big challenge of client mobility is to ensure seamless and transparent mobility (e.g. IP address preservation) for mobile devices among different geographical locations and in between several Radio Access Technologies. Due to the deployment of micro-service architectures, another dimension in the complexity of mobility occurs. Single IP addressable tasks might change their physical location within a (virtualized) data center architecture as well. Therefore, mobility on both ends of the End-to-End (E2E) connection can be observed. Hereby, mobility requires a large number of service registry (e.g. DNS) updates and the state synchronizations between registries perhaps located in different (geographical) locations. In regard to current research and development on next generation mobile broadband networks (such as Mobile Edge Cloud and 5G), key requirements such as high-availability, low-latency and ultra-high-bandwidth are required to ensure the reachability of the massive number of communicating instances including from cellular communications, high-definition multimedia streaming, Internet-of-Things (IoT), critical infrastructures, etc. This specification describes a new mobile network architecture which improves mobility management using Identifier Locator Addressing ILA) ([nvo3]) in IPv6 for next generation (virtualized) fixed and mobile telecommunication networks such as 5G and Mobile Edge Clouds. ILA shares many properties of the Identifier-Locator Network Protocol (ILNP) ([RFC6740], [RFC6741]) which is also a protocol that perform identifier locator split in IPv6 addresses. Identifier-locator addressing differentiates between location and identity of a addressable network element, which can be a mobile device or a data center task. A network architecture aligned on 3GPP is presented which evolves existing policy, charging and mobility concepts and substitutes GTP tunnels with ILA and therefore, improves mobility, latency, and service placement closer to the edge of the network. The key advantages of the presented ILA mobility solution are: 1) Backwards-compatibility within existing IPv6 network Mueller, Herbert Expires August 07. 2017 [Page 4]
INTERNET DRAFT <draft-mueller-ila-mobility> architectures such as the AT&T network, 2) Enablement of ultra-low-latency Mobile-Edge-Cloud (MEC) services by locating services closer at the network edge, 3) GTP-Tunnel-free and flatter architecture with less protocol overhead and less hops on the end-to-end path, 4) Reduce complexity by merging data plane gateways into a single gateway, 5) Proven applicability of ILA within the Facebook data centers and related networks at scale. 1.1. 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 RFC 2119 [RFC2119]. The following terminology will be referred to in the document. * SIR: As defined in ([nvo3ila]): "In order to maintain compatibility with existing networking stacks and applications, identifiers are encoded in IPv6 addresses using a standard identifier representation (SIR) address. A SIR address is a combination of a prefix which occupies what would be the locator portion of an ILA address, and the identifier in its usual location." * SIR: Standard Interface Representation. * SIR Prefix: A sixty-four bit network prefix used to identify a SIR address. * SIR Address: An IPv6 address composed of a SIR prefix (upper sixty- four bits) and an identifier (lower sixty-four bits). SIR addresses are visible to applications and provide a means to address nodes independent of their location. * ILA Identifier (ID): An identifier that identifies an addressable element in the network independent of its location and type. ILA identifiers are sixty-four bit values. An ID can be generated on a per session basis with the effect to secure the privacy of the end point. The International Mobile Subscriber Identity (IMSI) or the International Mobile Equipment Identity (IMEI) can be used for ID generation. The ID is comparable with the Globally Unique Temporary UE Identity (GUTI) in the mobile space. * ILA Locator (LOC): A network prefix that routes to a physical host. Locators provide the topological location of an addressed node. The locator is represented in the prefix of the SIR address. Mueller, Herbert Expires August 07. 2017 [Page 5]
INTERNET DRAFT <draft-mueller-ila-mobility> * ILA Host: An end host that is capable of performing ILA translations for both sending and receiving. An ILA host uses the ILA resolver protocol to get identifier to locator mappings for destinations in communication. * ILA Router: A network device that performs ILA translations and packet forwarding. ILA router participate in distribution protocol mapping. * ILA Node: A network node capable of performing ILA translations. This can be an ILA router or ILA host. * User Equipment (UE): A device with an identifier such as a mobile phone, IoT gateway or another SIM equipped mobile device. * Access Point (AP) and Base Station (BS): A edge network element such as evolved-NodeB (eNB) in 4G that bridges the radio network and fixed network. * Gateway (GW): A central network element such as Serving-Gateway (SWG) or Packet-Data-Network-Gateway (PGW) in 4G. * Application Function (AF): The AF refers to the 3GPP terminology and stands for any IP addressable endpoint such as service or task. * EXA: An Internet routable prefix, may be use as a SIR 2. Related Work, Protocols and Concepts This section provides an overview on the state-of-the-art on protocols and concepts for mobility management on mobile networks. In particular the 4th Generation (4G) of mobile telecommunication networks has been taken into account for this draft on functional and conceptual comparison. 2.1. Mobile IPv6 The IETF specified the Mobile IPv6 ([MIPv6]) protocol to ensure connectivity and reachability in case of client mobility within an IPv6 network. Mobility within a MIPv6 network is solved by assigning an additional IPv6 address - the Care-of-Address (CoA) - next to the current IPv6 address that as been assigned in the home network. Therefore a UE is equipped with a home address together with a primary CoA in case of foreign network attachment. IPv6 is classified as host-based mobility protocol, due to the fact that the UE is in charge of announcing its mobility to the network. In particular it is the client's responsibility for sending binding updates to the Home Agent (HA). In order to ensure reachability, the UE communicates its Mueller, Herbert Expires August 07. 2017 [Page 6]
INTERNET DRAFT <draft-mueller-ila-mobility> new assigned CoA(s) to the HA, which acts as a router and registrar for UEs. Connection requests are intercepted and re-routed in case CoA entries for a UE exists. A tunnel is established between the UE at the CoA and the HA for securely exchanging packets. By default, the first packet is routed from the correspondent UE towards the CoA of the UE via the HA. This route is not always the shortest path. All consecutive packets of the same data stream will follow on the same path, which might include a detour, but hides the new location of the UE for privacy reasons. The feature of route optimization allows the UE to directly contact the correspondent UE, therefore cuts out the HA from the communication path and forwards packets on a shorter route. Security of the Mobile IPv6 is enhanced through IPSec for binding updates to avoid spoofing of CoA for a UE. 2.2. Proxy Mobile IPv6 (PMIPv6) The IETF specified PMIPv6 ([PMIPv6]) provides network-based mobility management for UEs and extends the Mobile IPv6 in the way, that host- based mobility management functionalities in Mobile IPv6 are excluded from the client into the network. Hereby, the Local Mobility Anchor (LMA) acts as topological anchor point and manages the UE's binding state. The Mobile Access Gateway (MAG) manages mobility-related signaling on behalf of the UE at the access router. It is responsible for tracking the UE's movements to and from the access link for signaling the UE's local mobility anchor. 2.3. Host Identity Protocol (HIP) HIP ([hip]) is providing a secure solution for identifier/locator- split by adding a new host identity layer into the protocol stack. A cryptographic namespace build upon a host identity as public key allows scalability and multi-homing within the network. An extension of DNS supports rendezvous server functionality for secure host identity lookup. A secure channel is establishment over Diffie- Hellmann-key exchange between two communicating entities. The communication setup is considered as robust against DOS, due to a riddle solved at the requestor side. On the other side a high overhead for the secure communication establishment due to key exchange has to be taken into consideration. HIP requires an additional protocol layer between L2 and L3 for encapsulation. 2.4. Locator/ID Separation Protocol (LISP) LISP is a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). Tunnel router encapsulates and encapsulates packets. Mueller, Herbert Expires August 07. 2017 [Page 7]
INTERNET DRAFT <draft-mueller-ila-mobility> 2.5. Identifier-Locator Addressing (ILA) ILA is outlined in detail in ([nvo3]), ([nvo3ila]) as well as in this document. In a nutshell, the concept of ILA splits IPv6 addresses into a locator and an identifier, eliminates the need for tunneling and therefore reduces the header size. ILA routers create and maintain a mapping table of identifiers of locators. 2.6. Comparison of ILA to alternative approaches This section compares the ILA approach to some alternatives that have been discussed in 5gangip list. 2.6.1. Identifier Locator Network Protocol (ILNP) ILNP ([rfc6741]) is an experimental protocol that splits and IPv6 address into a locator and identifier. ILA is fundamentally based on ILNP. The key differences between ILA and ILNP are: * ILNP requires changes to the transport layer. This limits ILNP to be used only on hosts and every transport protocol implementation would need to be modified to use ILNP. Presumably to overcome the limitation above, some sort of ILNP proxy could be defined to perform ILNP in a middle-box. * ILA does not require changes to the transport layer. * Checksum neutral translation means that transport layer does not need to be parsed to perform ILA. This also ensures that existing device offloads (like checksum offload) work seamlessly. * ILNP employs IPv6 extension headers which are mostly considered non-deployable. ILA does not use these. * Core support for ILA is in upstream Linux, to date there is no publicly available source code for ILNP. * ILNP involves DNS to distribute mapping information, ILA assumes mapping information is not part of naming. 2.6.2. Locator Identifier Separation Protocol Locator Identifier Separation Protocol (LISP ([rfc6830)) is an IP encapsulation protocol where the destination address in the outer IP header is a locator and the destination address in the inner header Mueller, Herbert Expires August 07. 2017 [Page 8]
INTERNET DRAFT <draft-mueller-ila-mobility> is an identifier. The key differences between ILA and LISP are: * ILA is not encapsulation so there is no associated encapsulation overhead. For instance IPv6/IPv6 in LISP would have fifty-six bytes of overhead whereas ILA translation has zero. * LISP may not work with some network device offloads whereas ILA works with all stateless offloads (ILA is transparent to the network so that it would just see TCP/IP packets for instance). * ILA has been accepted into Linux, LISP has not been accepted. * ILA can run either on end hosts (ILA hosts) or in the network (ILA routers). ILA maintain a cache of identifier to locator mappings. * ILA defines locators and identifiers to be sixty-four bits whereas LISP allows them to be full 128 bit addresses increasing the memory needed in mapping table. * The process of ILA translation is much more efficient than performing LISP. The translation path is: 1) Parse IP header and extract the destination address 2) Lookup destination in a hash table (obviated with cached route for ILA hosts) 3) Write new destination address (16 byte copy) 4) Forward to new destination (or receive at final destination). 5) At the final destination, a reverse translation is performed to restore the originally sent address. LISP processing is more involved. To do encapsulation: 1) An outer IP header, UDP header and LISP header need to be inserted in the packet. Tunnel fragmentation and MTU need to be considered [RFCXXXX] (i.e. increasing the size of a packet may exceed tunnel MTU). 2) At the remote tunnel end point, the outer IP header must be validated and a lookup done on the destination address to see if it is a local address. A lookup must be done on the destination UDP port to find that it is a LISP port. If the Mueller, Herbert Expires August 07. 2017 [Page 9]
INTERNET DRAFT <draft-mueller-ila-mobility> UDP checksum is not zero that must also be validated. 3) The LISP header must is processed and validated. 4) Once the encapsulation is verified, the headers are removed and the inner packet is either forwarded or received. 3. Mobility Management Architectures Using ILA This section outlines the ILA protocol structure and architecture supporting ILA in mobile networks. The main functional blocks for connectivity, mobility support, security and charging are presented. Message flows for basic use cases executed by the mobile UE such as attachment, data transport with session handover and detachment are outlined. 3.1. Address format for ILA mobile The address format is derived out of the ILA draft in ([nvo3]) and is used without modifications in this draft. The IPv6 canonical address format is: +-----------------------------+-------------------------+ | 64 bits | 64 bits | +-----------------------------+-------------------------+ | IPv6 Unicast Routing Prefix | Interface Identifier | +-----------------------------+-------------------------+ The address format using ILA is: +--------------------------------------------------------+ | 64 bits |3 bits|1| 60 bits | +-----------------------------+--------------------------+ | Locator | Type |C| Identifier | +--------------------------------------------------------+ The C bit is used to indicate that checksum-neutral mapping has been performed ([nvo3]). 3.2. Architecture with Functional Elements and Reference Points The presented architecture in Fig 1 is aligned on the 3GPP Evolved Packet System (EPS) ([23401], [23402]) following the separation of control plane and data plane. Whereas 3GPP EPS addresses mobility through Layer 3 tunneling with GTP, this approach provides a Layer 3 mobility approach utilizing the ILA concepts for mobility without tunnels. Mueller, Herbert Expires August 07. 2017 [Page 10]
INTERNET DRAFT <draft-mueller-ila-mobility> +--------------------+ +--------------------+ | Access Network | | Policy Charging | +------+ Discovery and +-+ and Rules Function | | | Selection Function | | | | +------------+-------+ +---------+-----+----+ | | | | | | | | | +------+-----+ +---------+--+ | | | Mobility | | Home | | | | Management +---+ Subscriber | | | | Entity | | Server | | | +-----+------+ +------------+ | | | | | +--------------------------+--+ | | | | +-------+-------------+ | | | | | +-+--+ +--+-----------+ +----+----+ +-----+------+ | UE |====| Base Station |====| Gateway |====| IP Service | +----+ +--------------+ +---------+ +------------+ Fig 1: ILA-Based Architecture for Improved Mobility Similarities between this new mobile network architecture and the 3GPP EPS are: 1) Split control and data plane. 2) Policy Control and Charging Rules Function (PCRF) architecture and interfaces. 3) Network-based mobility management using Access Network Discovery and Selection Function (ANDSF). 4) Home Subscriber Service (HSS) for managing and control dynamic and static user profile information. Differences between this new mobile network architecture and the 3GPP EPS are: 1) Combined gateways and aggregated data plane functions within a single gateway. 2) Interfaces between the PCRF and ANDSF, HSS. 3) Enhanced mobility support as further outlined in 3.5.3. Communication Scenarios for End-to-End Data Transport Sessions. 4) Localized traffic handling within the Base Station to transport traffic among associated clients without core network involvement. 5) The associated network address is an ILA IPv6 address +--------+ +--------+ | Mobile +-+ +----| Mobile | Mueller, Herbert Expires August 07. 2017 [Page 11]
INTERNET DRAFT <draft-mueller-ila-mobility> | Node 1 | | (') | Node 3 | +--------+ | ................ ( ) +--------+ | +---+--+ . . +---+--+ (_) | | ILA |--. IPv6 .--| ILA | | +--|router| . Network . |router|---+ +---+--+ . . +---+--+ / . . / . Ipv6 Overlay . +--+-++--------+ +--------+ / . Network . | ILA|| Mobile | | Mobile +--+ . .- -|host|| Node 4 | | Node 2 | . . +--+-++--------+ +--------+ ................ Fig 2: Distributed ILA Network Architecture [nvo3ila] 3.3. Functional Elements This subsection summarizes the key functional elements of the ILA based mobility architecture. * The User Equipment (UE) is the SIM enabled mobile device (cellular, gateway, etc.) executing services such as apps on the device, binding apps to the ID as communication endpoints, handling the bindings of all associated LOC/ID's and performing mobility as described below. The UE performs security related functions via its (embedded) SIM handling at least one or multiple identifiers provisioned by one or multiple network operators. Security related functions include authentication of the UE towards the network (more specifically the BS) and certificate management for establishing secure transport connections. Either the UE supports IPv6 or ILA for handling locator and ID bindings and updates or the network is handling ILA functionality on behalf of the UE. Storage and management of multiple locators for multi-path and multi-homing is supported by the UE. * The Base Station (BS) or Access Point (AP) are the first point of contact from the UE when attaching over radio to the network. Its main purpose are routing, gating and forwarding data and control packets. The Radio Access Technology (RAT) is independent of the proposed concept and therefore out of scope of this document. 3G, 4G, 5G or WiFi are applicable RATs for the presented architecture. The BS is also capable of caching of content and state as close as possible to the user at the edge of the network. Another aspect of the cache is to support transparent handovers, during which buffering of packets at the target BS is required. Therefore, an X2-like connection between BSs is required. The BS supports a support a policy enforcement function (PEF) as well as a Event Reporting Function (ERF) aligned on the 3GPP defined Policy Control and Charging (PCC) functionality for the EPS in ([23203], [29212]). Mueller, Herbert Expires August 07. 2017 [Page 12]
INTERNET DRAFT <draft-mueller-ila-mobility> Uplink QoS management is handled by the BS, too. In order to differentiate between multiple types of data traffic, signaling, high-priority, real-time and non-real-time connections can be distinguished and the order of packet processing in the BS can be influenced for uplink. The same concept applies for downlink in the GW. Forward Error Correction (FEC), IP header compression, encryption of user data stream are supported by the BS, too. Traffic filtering, gating, legal interception on the BS, to include the case, in which traffic re-routed only by the BS and is not traversing the GW. * The Gateway (GW) encompasses data and control traffic related functions. Its main purpose is routing, gating and forwarding data and control packets. Therefore functionalities such as downlink QoS enforcement, APN management and charging is performed by each GW. * The Application Function (AF) or IP Service are an examples of any IP addressable service in network. Other than in the 3GPP defined architecture, the IP service does not need to reside in the SGi LAN reachable only after terminating the GTP tunnel in the PGW. Furthermore services can be reached directly after the RAN connection is terminated within the BS. * The Mobility Management Entity (MME) handles the initial authentication, authorization and mobility management of UE's over the control plane. The MME is responsible for tracking the UE's mobility and is in charge for updating the registries with near real- time status updates for LOC/ID mapping. ID and LOC assignment are performed by the MME. * The Home Subscriber Server (HSS) stores and manages user profile information. These include the static information such as the assigned ID, security credentials as well as dynamic information LOC and the current Tracking Area. * The Policy Charging and Rules Function (PCRF) controls data flows in the network architecture according to pre-defined rules. Such rules can be created by the network operator such as rate limiting or traffic shaping. Other rules differentiate between class of services for various traffic flow types identified on their Traffic Flow Template (TFT) characteristics such as source, destination, port and protocol information. The PCRF is handling charging for traffic flows using online (pre-paid) and offline (post-paid) charging. Both charging modes include a modes of operations with metrics such as service invocations, online time, data transferred, or no-charging. Out of credit events may influence the current connectivity for online charging, whereas offline charging is accumulating charging records which are usually processed in a monthly period. Mueller, Herbert Expires August 07. 2017 [Page 13]
INTERNET DRAFT <draft-mueller-ila-mobility> * The Access Network Discovery and Selection Function (ANDSF) is an operator controlled database used for mapping the user location with available (radio) access networks. With this information, the ANDSF is capable of signaling suggestions for handovers to UE's. A UE is therefore able to operate only on one interface at a time to save resources. In case of the availability of adjacent RAT and after reception of a handover suggestion from the ANDSF, the UE is able to enable the suggested interface, perform a scan and finally decide whether or not to attach to the new targeted RAT. The database can be filled using device monitoring/telemetry statistics signaled from the UE to the network or by active measurements of the environment. 3.4. Signaling and Data Flows 3.5.1. Provisioning A Subscriber Identity Module (SIM)-card is provisioned by the network operator with a unique and secure identifier that is comparable to the IMSI in 3GPP telco architectures (2G, 3G and 4G). This draft does not differentiate between a physical or an embedded SIM. In addition, security credentials and preferred network identifier are provisioned for authentication as well as network selection are provisioned. The matching information to the SIM card is stored in the HSS. 3.5.2. Attachment After powering on the device, a scan for available radio networks is performed on the device, which selects the initial network (e.g. with the strongest signal) and performs a network attachment procedure aligned on ([23401], [23401]) towards the BS using security parameters, ID, last MME associated with (GUMMEI) and last GUTI assigned by MME with ID GUMMEI - the Packet Temporary International Mobile Subscriber Identity (M-TSMI). A secure identifier on the SIM is used to generate a temporary ID (the ILA ID), which is only valid for one session, hides the privacy of the UE in the network and unambiguously identifies the UE within the global network. This ID is used for identification, authentication, authorization and charging purposes. For each network attachment, and due to privacy concerns for not revealing the identify of the UE towards the public, a new unique and temporary ID is generated. This ID is valid for a single session and is renewed afterwards. The BS derives the last MME association out of the network attachment request sent by the UE and queries the last or a new MME based on availability of information for UE authentication. The MME performs a lookup in the user database of the network operator, which is the Mueller, Herbert Expires August 07. 2017 [Page 14]
INTERNET DRAFT <draft-mueller-ila-mobility> Home Subscriber Server (HSS) and/or Home Location Register (HLR) and receives a profile in return. Hereby the MME is able to query the mapping database for existing mappings or to retrieve a unique ID for the UE. In the following, the MME selects and configures the BS and GW according to the profile received and signals the profile including the ID towards the BSs of a certain tracking area and GW. The BS allocates a LOC for the UE, binds the ID-LOC combination locally in a cache, publishes its binding in the MME/NVA and signals the ID-LOC towards the client. Quality of Service (QoS) and charging related policies are installed in the BS and GW. The BS handled uplink and the GW downlink related traffic shaping functions. Charging can be performed in both functional elements (BS or GW), whereas a centralized charging in case of multi-path streaming is preferred. After the successful attachment, a service can be invoked. 3.5.3. Communication Scenarios for End-to-End Data Transport Sessions After the successful attachment, applications can start communicating in the network using its assigned ILA by constructing IPv6 packets with the SIR source information (ID+LOC) and the mandatory target ID. The target LOC can be either set directly or can be defined as a broadcast message, in which the target LOC will be determined at the edge of the target. The following main high level use cases have been defined. The use cases can be distinguished into the following cases: 1) UE accessing a service in the AF, 2) UE is communicating with another UE attached to a different base station via a gateway, 3) UE is communicating with another UE attached to a different base station, 4) UE is communicating with another UE attached to the same base station, 5) Mobile Edge Cloud for localized traffic handling and low- latency communication, 6) Gateway mobility for enhanced mobility use cases The example use cases are outlined below in details and the differences compared to today's networks are discussed. Fig. 3 depicts the network elements and control and data flows related to those use cases. The communication form can be multicast, broadcast, anycast or unicast. Mueller, Herbert Expires August 07. 2017 [Page 15]
INTERNET DRAFT <draft-mueller-ila-mobility> +------------+ | UE 1 | | +--------+ +---+ | | Task 1 | | | +------------+ | +--------+ | | +------+ +----+ | Host H1 | +------------+ | | | | | | +--------+ | +---+ BS A +---+ GW +---+ | Task 0 | | +------------+ | | | | | | +--------+ | | UE 2 | | +------+ +-+--+ +------------+ | +--------+ +---+ | | | Task 2 | | | | +--------+ | | +------------+ | | +------------+ +------+ | | UE 3 | | | | | +--------+ +-------+ BS B +---+ | | Task 3 | | | | | +--------+ | +------+ +------------+ Fig 3: UE attachment over multiple base stations 1) E2E connection between the UE to AF (Task to Internet) Considering a communication scenario in which a UE (source) queries a web site (target) e.g. "http://about.att.com/innovation/foundry" in a browser represented by T1. SIR:T1,Iaddr -> // Transport endpoints at T1 L1:T1,Iaddr -> // On the wire in data center EXA:T1,Iaddr // In the Internet The request is forwarded to the BS, which performs ILA router functionality. In case a broadcast address has been selected as a target LOC, a cache lookup in a local lookup table is performed. Depending on finding an entry in the local cached lookup table, the routing is influenced and the packet is redirected. Otherwise the packet is routed on to the destination ILA SIR address (LOC/ID). 2) UE 1 to UE 3 are attached to distinct BSs via gateway Considering a communication scenario in which one task (T1) mobile device of UE 1 is contacting a second task (T3) on mobile device of UE 3. Both UEs are connected to different BSs. ILA routing is done in the BS. Mueller, Herbert Expires August 07. 2017 [Page 16]
INTERNET DRAFT <draft-mueller-ila-mobility> The transport endpoints for task to task between UE's communication are the SIR addresses for the tasks. When a packet is transported through the ILA network, the locators are set in source and destination addresses of the packet. On reception the source and destination addresses are converted back to SIR representations for processing at the transport layer. If task T1 on UE 1 is communicating with task T3 on UE 3, the ILA translation sequence would be: SIR:T1,SIR:T3 -> // Transport endpoints on T1 UE1:T1,UE3:T3 -> // ILA used on the wire SIR:T1,SIR:T3 // Received at T3 3) UE 1 to UE 2 are attached to distinct but interconnected BSs An extension of the scenario will happen, when If task T1 on UE1 is communicating with task T2 on UE 2 via interconnected BSs, the ILA translation sequence would be: SIR:T1,SIR:T2 -> // Transport endpoints on T1 UE1:T1,UE2:T2 -> // ILA used on the wire SIR:T1,SIR:T2 // Received at T2 4) UE 1 to UE 2 attached to the same BS Considering a communication scenario in which two communicating entities are attached to the same BS and therefore are in close proximity. The solution for routing traffic in today's network is the establishment of the data path from the UE over the access network (e.g. eNB) through the core network (e.g. EPC) into the AF (any IP addressable service or task) and backwards to the access network and finally terminated at the UE. Charging needs to be performed in the BS for this data flow. This communication pattern in today's networks creates a delay caused by the bearer concept of 3GPP network, which encapsulate and de-capsulate data in GTP-tunnels between the eNB and the PGW. A practical use case is the communication between autonomous vehicles (e.g. self-driving cars or self-organized and autonomous drone swarms) through a telecommunication infrastructure. A very low delay is required for the interaction and precise management. In order to reach such a low delay, the communication needs to stay local in order to result in a low delay. The presented solution on ILA mobility allows to keep traffic local for the case in which the communicating parties attached to the same BS. Mueller, Herbert Expires August 07. 2017 [Page 17]
INTERNET DRAFT <draft-mueller-ila-mobility> Due to a lower amount of hops between UE 1 and UE 2, a lower latency can be achieved which results in a lower delay. 5) Low-latency Mobile Edge Cloud (MEC) Service Considering a use case in which a UE is accessing a service with ultra-low latency requirements in the network such as image recognition, Augmented Reality (AR), Virtual Reality (VR) or other 5G low-latency and/or high throughput services. Other examples include vehicle control (drone or fleet management, traffic information, robot or power grid). In order to provide a high quality of experience for the user and customer, latency in the communication between the mobile device and the service has to be reduced in order to achieve a lower delay. Where multimedia streaming has an acceptable latency requirement of ~100ms, ultra-low latency services have strict requirements on the communication with under ~10ms or even close to 1ms. Classic cloud approaches that concentrate services centralized in the network are not applicable for ultra-low delay services due to the fact, that E2E latency is even too high. Violations of latency requirements result in motion sickness for VR users, outdated traffic information for autonomous self-driving cars, accidents with robotics in factories and the development of a new type of MEC services is hindered. Therefore, a request is created and addressed with the source LOC/ID and targeted towards the destination LOC/ID. +------------+ +------------+ +------------+ | UE 1 | | MEC | | Host H1 | | +--------+ | | +--------+ | | +--------+ | | | Task 1 | | +----+ | | Task 2 | | +----+ | | Task 0 | | | +--------+ | | BS | | +--------+ | | GW | | +--------+ | +------------+---+----+---+------------+---+----+---+------------+ Fig 4: Mobile Edge Computing architecture with ILA The innovative point in this use case depicted in Fig. 4 is the fact that the URL invocation may result in a redirect to a local service or content rather then a remote object. Hereby, the request may trigger a (third party) service or content deployment at the network edge instructed by the MEC_orchestrator and a policy decision. The policy decision is the outcome of the reasoning process within the MEC_orchestrator which takes context, user behavior, system load (throughput, latency, packet-loss, etc.), network topology map, distance between UE and service measured in hops, and other available metrics into account. Geographical load-balancing is therefore possible and enabled. Even when the first set packets of the connection are exchanged with a remote service over a longer Mueller, Herbert Expires August 07. 2017 [Page 18]
INTERNET DRAFT <draft-mueller-ila-mobility> geographical network distance, a context handover during the active session away from the remote and towards a closer service instance (out of the same type or load-balancing group) can be applied. In case service, task or content are available in MEC, ILA translation on the wire at the BS changes the locator to the closest point of presence. The following ILA steps are performed. SIR:T1,Iaddr_T0 -> // Transport endpoints at T1 invokes Task 0 (T0) L1:T1,Iaddr_T2 -> // Optional ILA translation from T0 to T2 EXA:T1,Iaddr // In mobile edge cloud data center Finally, the number of hops between UE and AF are reduced and a lower delay on the data path is achieved. Otherwise, in case the Edge Cloud capabilities cannot be utilized, basic routing is applied as outlined example 1) E2E connection between the UE to AF (Task to Internet) above. 6) Base Station or Gateway Mobility This use case covers situations in which the user stays connected to a BS but the core network is mobile and changes its location and connectivity to the service/Application Function. One example would be a BS that is attached to a vehicle (drone, car/bus, train, cargo ship, etc). The user facing side provides cellular service, backhaul is either WLAN, satellite, laser, MMWave or temporary a fixed connection. The AF facing side changes connection with each change of a transport connection such as WiFi, cellular or satellite. Gateway mobility requires the update of forwarding entries in related BS and AF to continuously forward the packets on the data path. The network setup is depicted in Fig.5 and Fig. 6 with both gateways (GW 1 and GW 2) both have connections to the same BS and AF. +------------+ +------+ +------+ | Host H1 | | | | | | +--------+ | +---+ BS A +---+ GW 1 |+---+ | Task 0 | | +------------+ | | | | | | +--------+ | | UE 1 | | +------+ +------+ +-----+------+ | +--------+ +---+ | | | Task 1 | | +------+ | | +--------+ | | | | +------------+ | GW 2 +----------+ | | +------+ Fig 5: Gateway mobility with attached UE via GW 1 Mueller, Herbert Expires August 07. 2017 [Page 19]
INTERNET DRAFT <draft-mueller-ila-mobility> The difference between Fig. 5 and Fig.6 is that BS A changes its association with the network by handing over its connectivity from GW 1 towards GW 2. Due to the use of ILA, and the related address-space translation capabilities, no GTP tunnels need to be updated and only the address translation between the gateway and the service space is updated. All attached UE's preserve their ILA IPv6 address and continue to be addressable in the network. +------------+ +------+ | Host H1 | | | | +--------+ | | GW 1 |+---+ | Task 0 | | +------------+ | | | +--------+ | | UE 1 | +------+ +-----+------+ | +--------+ +---+ | | | Task 1 | | | | | +--------+ | | +------+ +------+ | +------------+ | | | | | | +---+ BS A +---+ GW 2 +----------+ | | | | +------+ +------+ Fig 6: Gateway mobility with attached UE via GW 2 Service interruptions may occur during the time of detaching from GW 1 and attaching to GW 2 when using a single radio interface for wireless back hauling. The capabilities of the 3GPP MME are extended with the ability to select the target GW for the BS, management of the BS-GW handover by reserving resources on the target GW 2 and releasing resources on the source GW 1. GW 1 caches packets during handover and forwards them to GW 2 (in case a connection exist between them) until packets are transported on the new uplink and downlink paths. 3.5.4. Homogeneous Handover Client mobility in homogeneous networks is usually caused by physical location changes, changes in the received radio signal strength or network based handover due to network policies such as UE load balancing on the BSs. The status information (the list of signals received from adjacent BSs including their signal strength) signaled from the UE towards the BS enables positioning via triangulation as well as the selection of alternative BS's to which the UE may connect to alternatively. Reasons for handovers may be evacuation/preemption of resources on Mueller, Herbert Expires August 07. 2017 [Page 20]
INTERNET DRAFT <draft-mueller-ila-mobility> the BS due to emergency scenarios or higher priority calls, UE/BS/service load balancing or physical mobility of the UE among the network. Current resource utilization (e.g. data rates) of the UE or historical traffic pattern may influence the handover and the BS selection process. Mainly the MME selects a target BS (BS_target) as target for the handover of the UE away from the current BS (BS_source). The decision is signaled to related BS's and the UE. BS_source starts de- allocating resource blocked by the UE and BS_target blocks resources required by the UE. Since most UE's are considered to have only a single RAT of each type (one WLAN or one LTE interface) an interruption in the connection while handover is to be expected. In order to avoid packet loss at the UE, buffering at the BS_target as well as packet forwarding from BS_source to BS_target are supported. Only after UE successfully establishes connectivity at the BS_target, previously blocked resources at BS_source are freed up, which are used as handover role-back in case of failure. Finally the MME announces the new ILA ID (BS_target_LOC)/ID for the UE as an update at GW and in the ILa registry. New incoming connections are forwarded directly towards the UE over BS_target using the proclaimed ILA ID (LOC/ID). Homogenous handovers with one radio technology interface supported have interruptions during the handover. Nevertheless those interruptions are relatively small due to techniques such as improved handovers in WiFi (802.11x, 802.11k, 802.11r, and 802.11v) or context handover via X2 in 4G. 3.5.5. Heterogeneous Handover Client mobility may involve various Radio Access Technologies (RAT), in which the client is handed off from RAT_1 to RAT_2. The client is not required to move physically for heterogeneous mobility. Instead measurements on the UE or suggestion from the network (signaled over the ANDSF) may trigger handovers to alternative networks even when the UE is physically not moving. Such a handover can be done between WiFi, 4G and 5G. Heterogeneous handovers are motivated for optimizing connectivity between UE and AF/service to move a multimedia connection with high bandwidth requirements from cellular (4G/5G) towards WLAN, a security sensitive bank transaction from WLAN towards cellular or simply a better transport-cost-per-bit-ratio. Heterogeneous (compared to homogenous) handovers may be performed seamlessly with establishing a second alternative connection in Mueller, Herbert Expires August 07. 2017 [Page 21]
INTERNET DRAFT <draft-mueller-ila-mobility> parallel to the existing active connection and tearing down the old connection only, after successfully establishing the new connection. Usually this is possible, because more then one interface is available on the client, which can be used in parallel to establish connectivity in parallel. In order to provide higher bandwidth over multi-path, both connections may be kept open in parallel. In this regard, the MME adds another LOC'/ID as update to the existing entry LOC/ID in the registry on the gateways and DNS. 3.5.6. Detachment A detachment from the network can happen gracefully by shutting down the phone and de-registering it from the BS or suddenly due to a loss of connection. In both situations, a de-registration from the UE out of the list of active users attached to the BS is done directly or indirectly (after inactivity for a predefined time). Resource reservations are freed up again after detachment and opened up for other connections. 3.5.6. Idle-mode and paging Power saving methods are working transparent to the ILA mobility concept such as described in ([23401], [23402]). The device toggles from active to inactive mode in idle-mode in order to reduce the communication interval between device and antenna. Resource reservations in the network are kept alive in order to allow a fast weak-up and connection re-establishment caused by paging of the BS towards the device. 4. Discussion, Evaluation and Summary New low-delay services are appearing with AR/VR, drone communication, self-driving cars and robotic control that have new requirements on the network, which cannot be fulfilled by today's network and cloud architectures. New ultra-low latency is a key requirement on connectivity that is enabling a new services. One way of improving the End-to-End (E2E) connectivity is to substitute the underlying technology with a new generation and to improve the performance. Part of this improvement is described in Moore's-law, which highlights that the number of components per integrated circuit is doubling every 18 month. Another approach is to reduce the E2E latency by reducing the physical distance between device and service measured in number of hops and at the same time provide a backwards compatible solution for WiFi and 4G networks. This draft is addressing the above mentioned challenges and provides a solution in form of a new mobile network architecture based on Identifier-Location Addressing (ILA) mobility. ILA decouples the Mueller, Herbert Expires August 07. 2017 [Page 22]
INTERNET DRAFT <draft-mueller-ila-mobility> identity from locator within an IPv6 address. Therefore mobility can be achieved by preserving the same ID at the endpoint and only adapting the locator used routing in case of mobility. The implications are improved mobility with less control signaling and a more efficient tunnel-free core network architecture. ILA applied on mobile networks and the gained improved mobility enables multiple new and innovative use cases compared to legacy telecommunication networks. Summarizing, the above presented Communication Scenarios for data transport for an End-to-End session outlines ways to improve connectivity, optimize routing and enable a new type of service: Mobile Edge Cloud services. Firstly, the improved data path requires less hops to traverse between UE <-> AF enabled by Mobile Edge Computing or locally between UE_1 <-> UE_2 due to the flatter architecture. Secondly, less overhead is created due to the reduction of GTP tunnels between network elements. Thirdly, the presented approach of ILA mobility is backwards compatible with today's IPv6 based fixed and mobile telecommunication networks. 5. References 5.1. Normative References [rfc6741] Identifier-Locator Network Protocol (ILNP) Engineering Considerations, Jan 2013, https://tools.ietf.org/html/rfc6741 [nvo3ila] Identifier-locator addressing for network virtualization, draft-herbert-nvo3-ila-02, Tom Herbert, Mar 2016, https://tools.ietf.org/html/draft-herbert-nvo3-ila-02#page-17 5.2. Informative References [rfc6830] The Locator/ID Separation Protocol (LISP), D. Farinacci, Jan 2013 [MIPv6], Mobility Support in IPv6, C. Perkins, Ed. et al., Jul 2011, https://tools.ietf.org/html/rfc6275 [PMIPv6] S. Gundavelli, Ed. et al., Aug 2008, https://tools.ietf.org/html/rfc5213 [23401] 3GPP TS 23.401 V13.7.0 (2016-06), General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access (Release 13) [23402] 3GPP TS 23.402 V14.0.0 (2016-06), Architecture enhancements for non-3GPP accesses (Release 14) Mueller, Herbert Expires August 07. 2017 [Page 23]
INTERNET DRAFT <draft-mueller-ila-mobility> [23203] 3GPP TS 23.203 V14.0.0 (2016-06), Policy and charging control architecture (Release 14) [29212] 3GPP TS 29.212 V14.0.0 (2016-06), Policy and Charging Control (PCC); Reference points (Release 14) Authors' Addresses Dr.-Ing. Julius Mueller 260 Homer Ave Palo Alto, CA 94301 US EMail: jmu@att.com and Tom Herbert Facebook 1 Hacker Way Menlo Park, CA 94052 US Email: tom@herbertland.com Mueller, Herbert Expires August 07. 2017 [Page 24]