idnits 2.17.1 draft-mueller-ila-mobility-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2016) is 2737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6740' is mentioned on line 128, but not defined == Missing Reference: 'RFC6741' is mentioned on line 128, but not defined == Missing Reference: 'RFC2119' is mentioned on line 155, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 373, but not defined Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT J. Mueller 3 Intended Status: Informational AT&T Foundry 4 Expires: April 30, 2017 T. Herbert 5 Facebook 6 October 27, 2016 8 Mobility Management Using Identifier Locator Addressing 9 draft-mueller-ila-mobility-02 11 Abstract 13 This specification describes a new mobile network architecture which 14 improves mobility management using Identifier Locator Addressing ILA) 15 in IPv6 for next generation mobile telecommunication networks such as 16 5G and Mobile Edge Clouds. Identifier-locator addressing 17 differentiates between location and identity of a addressable network 18 element, which can be a mobile device or a data center task. The 19 approach presented in this draft enables mobility management on Layer 20 3, and provides a simplified, GTP-tunnel-free and more efficient 21 architecture with less core network utilization compared to 22 traditional architecture. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Related Work, Protocols and Concepts . . . . . . . . . . . . . 6 64 2.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2. Proxy Mobile IPv6 (PMIPv6) . . . . . . . . . . . . . . . . 7 66 2.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 7 67 2.4. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . 7 68 2.5. Identifier-Locator Addressing (ILA) . . . . . . . . . . . . 8 69 2.6. Comparison of ILA to alternative approaches . . . . . . . . 8 70 2.6.1. Identifier Locator Network Protocol (ILNP) . . . . . . 8 71 2.6.2. Locator Identifier Separation Protocol . . . . . . . . 8 72 3. Mobility Management Architectures Using ILA . . . . . . . . . . 10 73 3.1. Address format for ILA mobile . . . . . . . . . . . . . . . 10 74 3.2. Architecture with Functional Elements and Reference 75 Points . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 3.3. Functional Elements . . . . . . . . . . . . . . . . . . . . 12 77 3.4. Signaling and Data Flows . . . . . . . . . . . . . . . . . 14 78 3.5.1. Provisioning . . . . . . . . . . . . . . . . . . . . . 14 79 3.5.2. Attachment . . . . . . . . . . . . . . . . . . . . . . 14 80 3.5.3. Communication Scenarios for End-to-End Data Transport 81 Sessions . . . . . . . . . . . . . . . . . . . . . . . 15 82 3.5.4. Homogeneous Handover . . . . . . . . . . . . . . . . . 20 83 3.5.5. Heterogeneous Handover . . . . . . . . . . . . . . . . 21 84 3.5.6. Detachment . . . . . . . . . . . . . . . . . . . . . . 22 85 3.5.6. Idle-mode and paging . . . . . . . . . . . . . . . . . 22 86 4. Discussion, Evaluation and Summary . . . . . . . . . . . . . . 22 87 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 5.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 5.2. Informative References . . . . . . . . . . . . . . . . . . 23 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction and Problem Statement 94 The Internet Protocol (IP) has been overloaded in its functionality 95 in the sense that it has been used as service locator and service 96 identifier at the same time. Since changes of the associated IP 97 address during a connection-oriented TCP session causes service 98 interruptions, mobility has become a challenge. Mobility has been a 99 challenge for IP based network since the area of smart phones began 100 and has been addressed with Layer 2 and Layer 3 tunneling solutions. 101 More specifically, uplink and downlink data traffic is encapsulated 102 with GPRS-Tunneling-Protocol (GTP) headers, which are routed through 103 the core network between the service and the base stations. One big 104 challenge of client mobility is to ensure seamless and transparent 105 mobility (e.g. IP address preservation) for mobile devices among 106 different geographical locations and in between several Radio Access 107 Technologies. Due to the deployment of micro-service architectures, 108 another dimension in the complexity of mobility occurs. Single IP 109 addressable tasks might change their physical location within a 110 (virtualized) data center architecture as well. Therefore, mobility 111 on both ends of the End-to-End (E2E) connection can be observed. 112 Hereby, mobility requires a large number of service registry (e.g. 113 DNS) updates and the state synchronizations between registries 114 perhaps located in different (geographical) locations. In regard to 115 current research and development on next generation mobile broadband 116 networks (such as Mobile Edge Cloud and 5G), key requirements such as 117 high-availability, low-latency and ultra-high-bandwidth are required 118 to ensure the reachability of the massive number of communicating 119 instances including from cellular communications, high-definition 120 multimedia streaming, Internet-of-Things (IoT), critical 121 infrastructures, etc. 123 This specification describes a new mobile network architecture which 124 improves mobility management using Identifier Locator Addressing ILA) 125 ([nvo3]) in IPv6 for next generation (virtualized) fixed and mobile 126 telecommunication networks such as 5G and Mobile Edge Clouds. ILA 127 shares many properties of the Identifier-Locator Network Protocol 128 (ILNP) ([RFC6740], [RFC6741]) which is also a protocol that perform 129 identifier locator split in IPv6 addresses. Identifier-locator 130 addressing differentiates between location and identity of a 131 addressable network element, which can be a mobile device or a data 132 center task. A network architecture aligned on 3GPP is presented 133 which evolves existing policy, charging and mobility concepts and 134 substitutes GTP tunnels with ILA and therefore, improves mobility, 135 latency, and service placement closer to the edge of the network. 137 The key advantages of the presented ILA mobility solution are: 139 1) Backwards-compatibility within existing IPv6 network 140 architectures such as the AT&T network, 141 2) Enablement of ultra-low-latency Mobile-Edge-Cloud (MEC) 142 services by locating services closer at the network edge, 143 3) GTP-Tunnel-free and flatter architecture with less protocol 144 overhead and less hops on the end-to-end path, 145 4) Reduce complexity by merging data plane gateways into a single 146 gateway, 147 5) Proven applicability of ILA within the Facebook data centers 148 and related networks at scale. 150 1.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 The following terminology will be referred to in the document. 158 * SIR: As defined in ([nvo3ila]): "In order to maintain compatibility 159 with existing networking stacks and applications, identifiers are 160 encoded in IPv6 addresses using a standard identifier 161 representation (SIR) address. A SIR address is a combination of a 162 prefix which occupies what would be the locator portion of an ILA 163 address, and the identifier in its usual location." 165 * SIR: Standard Interface Representation. 167 * SIR Prefix: A sixty-four bit network prefix used to identify a SIR 168 address. 170 * SIR Address: An IPv6 address composed of a SIR prefix (upper sixty- 171 four bits) and an identifier (lower sixty-four bits). SIR addresses 172 are visible to applications and provide a means to address nodes 173 independent of their location. 175 * ILA Identifier (ID): An identifier that identifies an addressable 176 element in the network independent of its location and type. ILA 177 identifiers are sixty-four bit values. An ID can be generated on a 178 per session basis with the effect to secure the privacy of the end 179 point. The International Mobile Subscriber Identity (IMSI) or the 180 International Mobile Equipment Identity (IMEI) can be used for ID 181 generation. The ID is comparable with the Globally Unique Temporary 182 UE Identity (GUTI) in the mobile space. 184 * ILA Locator (LOC): A network prefix that routes to a physical host. 185 Locators provide the topological location of an addressed node. The 186 locator is represented in the prefix of the SIR address. 188 * ILA Host: An end host that is capable of performing ILA 189 translations for both sending and receiving. An ILA host uses the 190 ILA resolver protocol to get identifier to locator mappings for 191 destinations in communication. 193 * ILA Router: A network device that performs ILA translations and 194 packet forwarding. ILA router participate in distribution protocol 195 mapping. 197 * ILA Node: A network node capable of performing ILA translations. 198 This can be an ILA router or ILA host. 200 * User Equipment (UE): A device with an identifier such as a mobile 201 phone, IoT gateway or another SIM equipped mobile device. 203 * Access Point (AP) and Base Station (BS): A edge network element 204 such as evolved-NodeB (eNB) in 4G that bridges the radio network 205 and fixed network. 207 * Gateway (GW): A central network element such as Serving-Gateway 208 (SWG) or Packet-Data-Network-Gateway (PGW) in 4G. 210 * Application Function (AF): The AF refers to the 3GPP terminology 211 and stands for any IP addressable endpoint such as service or task. 213 * EXA: An Internet routable prefix, may be use as a SIR 215 2. Related Work, Protocols and Concepts 217 This section provides an overview on the state-of-the-art on 218 protocols and concepts for mobility management on mobile networks. In 219 particular the 4th Generation (4G) of mobile telecommunication 220 networks has been taken into account for this draft on functional and 221 conceptual comparison. 223 2.1. Mobile IPv6 225 The IETF specified the Mobile IPv6 ([MIPv6]) protocol to ensure 226 connectivity and reachability in case of client mobility within an 227 IPv6 network. Mobility within a MIPv6 network is solved by assigning 228 an additional IPv6 address - the Care-of-Address (CoA) - next to the 229 current IPv6 address that as been assigned in the home network. 230 Therefore a UE is equipped with a home address together with a 231 primary CoA in case of foreign network attachment. IPv6 is classified 232 as host-based mobility protocol, due to the fact that the UE is in 233 charge of announcing its mobility to the network. In particular it is 234 the client's responsibility for sending binding updates to the Home 235 Agent (HA). In order to ensure reachability, the UE communicates its 236 new assigned CoA(s) to the HA, which acts as a router and registrar 237 for UEs. Connection requests are intercepted and re-routed in case 238 CoA entries for a UE exists. A tunnel is established between the UE 239 at the CoA and the HA for securely exchanging packets. By default, 240 the first packet is routed from the correspondent UE towards the CoA 241 of the UE via the HA. This route is not always the shortest path. All 242 consecutive packets of the same data stream will follow on the same 243 path, which might include a detour, but hides the new location of the 244 UE for privacy reasons. The feature of route optimization allows the 245 UE to directly contact the correspondent UE, therefore cuts out the 246 HA from the communication path and forwards packets on a shorter 247 route. Security of the Mobile IPv6 is enhanced through IPSec for 248 binding updates to avoid spoofing of CoA for a UE. 250 2.2. Proxy Mobile IPv6 (PMIPv6) 252 The IETF specified PMIPv6 ([PMIPv6]) provides network-based mobility 253 management for UEs and extends the Mobile IPv6 in the way, that host- 254 based mobility management functionalities in Mobile IPv6 are excluded 255 from the client into the network. Hereby, the Local Mobility Anchor 256 (LMA) acts as topological anchor point and manages the UE's binding 257 state. The Mobile Access Gateway (MAG) manages mobility-related 258 signaling on behalf of the UE at the access router. It is responsible 259 for tracking the UE's movements to and from the access link for 260 signaling the UE's local mobility anchor. 262 2.3. Host Identity Protocol (HIP) 264 HIP ([hip]) is providing a secure solution for identifier/locator- 265 split by adding a new host identity layer into the protocol stack. A 266 cryptographic namespace build upon a host identity as public key 267 allows scalability and multi-homing within the network. An extension 268 of DNS supports rendezvous server functionality for secure host 269 identity lookup. A secure channel is establishment over Diffie- 270 Hellmann-key exchange between two communicating entities. The 271 communication setup is considered as robust against DOS, due to a 272 riddle solved at the requestor side. On the other side a high 273 overhead for the secure communication establishment due to key 274 exchange has to be taken into consideration. HIP requires an 275 additional protocol layer between L2 and L3 for encapsulation. 277 2.4. Locator/ID Separation Protocol (LISP) 279 LISP is a network-layer-based protocol that enables separation of IP 280 addresses into two new numbering spaces: Endpoint Identifiers (EIDs) 281 and Routing Locators (RLOCs). Tunnel router encapsulates and 282 encapsulates packets. 284 2.5. Identifier-Locator Addressing (ILA) 286 ILA is outlined in detail in ([nvo3]), ([nvo3ila]) as well as in this 287 document. In a nutshell, the concept of ILA splits IPv6 addresses 288 into a locator and an identifier, eliminates the need for tunneling 289 and therefore reduces the header size. ILA routers create and 290 maintain a mapping table of identifiers of locators. 292 2.6. Comparison of ILA to alternative approaches 294 This section compares the ILA approach to some alternatives that have 295 been discussed in 5gangip list. 297 2.6.1. Identifier Locator Network Protocol (ILNP) 299 ILNP ([rfc6741]) is an experimental protocol that splits and IPv6 300 address into a locator and identifier. ILA is fundamentally based on 301 ILNP. 303 The key differences between ILA and ILNP are: 305 * ILNP requires changes to the transport layer. This limits ILNP 306 to be used only on hosts and every transport protocol 307 implementation would need to be modified to use ILNP. Presumably 308 to overcome the limitation above, some sort of ILNP proxy could 309 be defined to perform ILNP in a middle-box. 311 * ILA does not require changes to the transport layer. 313 * Checksum neutral translation means that transport layer does not 314 need to be parsed to perform ILA. This also ensures that 315 existing device offloads (like checksum offload) work 316 seamlessly. 318 * ILNP employs IPv6 extension headers which are mostly considered 319 non-deployable. ILA does not use these. 321 * Core support for ILA is in upstream Linux, to date there is no 322 publicly available source code for ILNP. 324 * ILNP involves DNS to distribute mapping information, ILA assumes 325 mapping information is not part of naming. 327 2.6.2. Locator Identifier Separation Protocol 329 Locator Identifier Separation Protocol (LISP ([rfc6830)) is an IP 330 encapsulation protocol where the destination address in the outer IP 331 header is a locator and the destination address in the inner header 332 is an identifier. 334 The key differences between ILA and LISP are: 336 * ILA is not encapsulation so there is no associated encapsulation 337 overhead. For instance IPv6/IPv6 in LISP would have fifty-six 338 bytes of overhead whereas ILA translation has zero. 340 * LISP may not work with some network device offloads whereas ILA 341 works with all stateless offloads (ILA is transparent to the 342 network so that it would just see TCP/IP packets for instance). 344 * ILA has been accepted into Linux, LISP has not been accepted. 346 * ILA can run either on end hosts (ILA hosts) or in the network 347 (ILA routers). ILA maintain a cache of identifier to locator 348 mappings. 350 * ILA defines locators and identifiers to be sixty-four bits 351 whereas LISP allows them to be full 128 bit addresses increasing 352 the memory needed in mapping table. 354 * The process of ILA translation is much more efficient than 355 performing LISP. The translation path is: 357 1) Parse IP header and extract the destination address 359 2) Lookup destination in a hash table (obviated with cached 360 route for ILA hosts) 362 3) Write new destination address (16 byte copy) 364 4) Forward to new destination (or receive at final destination). 366 5) At the final destination, a reverse translation is performed 367 to restore the originally sent address. 369 LISP processing is more involved. To do encapsulation: 371 1) An outer IP header, UDP header and LISP header need to be 372 inserted in the packet. Tunnel fragmentation and MTU need to 373 be considered [RFCXXXX] (i.e. increasing the size of a packet 374 may exceed tunnel MTU). 376 2) At the remote tunnel end point, the outer IP header must be 377 validated and a lookup done on the destination address to see 378 if it is a local address. A lookup must be done on the 379 destination UDP port to find that it is a LISP port. If the 380 UDP checksum is not zero that must also be validated. 382 3) The LISP header must is processed and validated. 384 4) Once the encapsulation is verified, the headers are removed 385 and the inner packet is either forwarded or received. 387 3. Mobility Management Architectures Using ILA 389 This section outlines the ILA protocol structure and architecture 390 supporting ILA in mobile networks. The main functional blocks for 391 connectivity, mobility support, security and charging are presented. 392 Message flows for basic use cases executed by the mobile UE such as 393 attachment, data transport with session handover and detachment are 394 outlined. 396 3.1. Address format for ILA mobile 398 The address format is derived out of the ILA draft in ([nvo3]) and is 399 used without modifications in this draft. 401 The IPv6 canonical address format is: 403 +-----------------------------+-------------------------+ 404 | 64 bits | 64 bits | 405 +-----------------------------+-------------------------+ 406 | IPv6 Unicast Routing Prefix | Interface Identifier | 407 +-----------------------------+-------------------------+ 409 The address format using ILA is: 411 +--------------------------------------------------------+ 412 | 64 bits |3 bits|1| 60 bits | 413 +-----------------------------+--------------------------+ 414 | Locator | Type |C| Identifier | 415 +--------------------------------------------------------+ 417 The C bit is used to indicate that checksum-neutral mapping has been 418 performed ([nvo3]). 420 3.2. Architecture with Functional Elements and Reference Points 422 The presented architecture in Fig 1 is aligned on the 3GPP Evolved 423 Packet System (EPS) ([23401], [23402]) following the separation of 424 control plane and data plane. Whereas 3GPP EPS addresses mobility 425 through Layer 3 tunneling with GTP, this approach provides a Layer 3 426 mobility approach utilizing the ILA concepts for mobility without 427 tunnels. 429 +--------------------+ +--------------------+ 430 | Access Network | | Policy Charging | 431 +------+ Discovery and +-+ and Rules Function | 432 | | Selection Function | | | 433 | +------------+-------+ +---------+-----+----+ 434 | | | | 435 | | | | 436 | +------+-----+ +---------+--+ | 437 | | Mobility | | Home | | 438 | | Management +---+ Subscriber | | 439 | | Entity | | Server | | 440 | +-----+------+ +------------+ | 441 | | | 442 | +--------------------------+--+ 443 | | | 444 | +-------+-------------+ | 445 | | | | 446 +-+--+ +--+-----------+ +----+----+ +-----+------+ 447 | UE |====| Base Station |====| Gateway |====| IP Service | 448 +----+ +--------------+ +---------+ +------------+ 450 Fig 1: ILA-Based Architecture for Improved Mobility 452 Similarities between this new mobile network architecture and the 453 3GPP EPS are: 454 1) Split control and data plane. 455 2) Policy Control and Charging Rules Function (PCRF) architecture 456 and interfaces. 457 3) Network-based mobility management using Access Network 458 Discovery and Selection Function (ANDSF). 459 4) Home Subscriber Service (HSS) for managing and control dynamic 460 and static user profile information. 462 Differences between this new mobile network architecture and the 3GPP 463 EPS are: 464 1) Combined gateways and aggregated data plane functions within a 465 single gateway. 466 2) Interfaces between the PCRF and ANDSF, HSS. 467 3) Enhanced mobility support as further outlined in 3.5.3. 468 Communication Scenarios for End-to-End Data Transport Sessions. 469 4) Localized traffic handling within the Base Station to transport 470 traffic among associated clients without core network 471 involvement. 472 5) The associated network address is an ILA IPv6 address 474 +--------+ +--------+ 475 | Mobile +-+ +----| Mobile | 476 | Node 1 | | (') | Node 3 | 477 +--------+ | ................ ( ) +--------+ 478 | +---+--+ . . +---+--+ (_) 479 | | ILA |--. IPv6 .--| ILA | | 480 +--|router| . Network . |router|---+ 481 +---+--+ . . +---+--+ 482 / . . 483 / . Ipv6 Overlay . +--+-++--------+ 484 +--------+ / . Network . | ILA|| Mobile | 485 | Mobile +--+ . .- -|host|| Node 4 | 486 | Node 2 | . . +--+-++--------+ 487 +--------+ ................ 489 Fig 2: Distributed ILA Network Architecture [nvo3ila] 491 3.3. Functional Elements 493 This subsection summarizes the key functional elements of the ILA 494 based mobility architecture. 496 * The User Equipment (UE) is the SIM enabled mobile device (cellular, 497 gateway, etc.) executing services such as apps on the device, binding 498 apps to the ID as communication endpoints, handling the bindings of 499 all associated LOC/ID's and performing mobility as described below. 500 The UE performs security related functions via its (embedded) SIM 501 handling at least one or multiple identifiers provisioned by one or 502 multiple network operators. Security related functions include 503 authentication of the UE towards the network (more specifically the 504 BS) and certificate management for establishing secure transport 505 connections. Either the UE supports IPv6 or ILA for handling locator 506 and ID bindings and updates or the network is handling ILA 507 functionality on behalf of the UE. Storage and management of multiple 508 locators for multi-path and multi-homing is supported by the UE. 510 * The Base Station (BS) or Access Point (AP) are the first point of 511 contact from the UE when attaching over radio to the network. Its 512 main purpose are routing, gating and forwarding data and control 513 packets. The Radio Access Technology (RAT) is independent of the 514 proposed concept and therefore out of scope of this document. 3G, 4G, 515 5G or WiFi are applicable RATs for the presented architecture. The BS 516 is also capable of caching of content and state as close as possible 517 to the user at the edge of the network. Another aspect of the cache 518 is to support transparent handovers, during which buffering of 519 packets at the target BS is required. Therefore, an X2-like 520 connection between BSs is required. The BS supports a support a 521 policy enforcement function (PEF) as well as a Event Reporting 522 Function (ERF) aligned on the 3GPP defined Policy Control and 523 Charging (PCC) functionality for the EPS in ([23203], [29212]). 525 Uplink QoS management is handled by the BS, too. In order to 526 differentiate between multiple types of data traffic, signaling, 527 high-priority, real-time and non-real-time connections can be 528 distinguished and the order of packet processing in the BS can be 529 influenced for uplink. The same concept applies for downlink in the 530 GW. Forward Error Correction (FEC), IP header compression, encryption 531 of user data stream are supported by the BS, too. Traffic filtering, 532 gating, legal interception on the BS, to include the case, in which 533 traffic re-routed only by the BS and is not traversing the GW. 535 * The Gateway (GW) encompasses data and control traffic related 536 functions. Its main purpose is routing, gating and forwarding data 537 and control packets. Therefore functionalities such as downlink QoS 538 enforcement, APN management and charging is performed by each GW. 540 * The Application Function (AF) or IP Service are an examples of any 541 IP addressable service in network. Other than in the 3GPP defined 542 architecture, the IP service does not need to reside in the SGi LAN 543 reachable only after terminating the GTP tunnel in the PGW. 544 Furthermore services can be reached directly after the RAN connection 545 is terminated within the BS. 547 * The Mobility Management Entity (MME) handles the initial 548 authentication, authorization and mobility management of UE's over 549 the control plane. The MME is responsible for tracking the UE's 550 mobility and is in charge for updating the registries with near real- 551 time status updates for LOC/ID mapping. ID and LOC assignment are 552 performed by the MME. 554 * The Home Subscriber Server (HSS) stores and manages user profile 555 information. These include the static information such as the 556 assigned ID, security credentials as well as dynamic information LOC 557 and the current Tracking Area. 559 * The Policy Charging and Rules Function (PCRF) controls data flows 560 in the network architecture according to pre-defined rules. Such 561 rules can be created by the network operator such as rate limiting or 562 traffic shaping. Other rules differentiate between class of services 563 for various traffic flow types identified on their Traffic Flow 564 Template (TFT) characteristics such as source, destination, port and 565 protocol information. The PCRF is handling charging for traffic flows 566 using online (pre-paid) and offline (post-paid) charging. Both 567 charging modes include a modes of operations with metrics such as 568 service invocations, online time, data transferred, or no-charging. 569 Out of credit events may influence the current connectivity for 570 online charging, whereas offline charging is accumulating charging 571 records which are usually processed in a monthly period. 573 * The Access Network Discovery and Selection Function (ANDSF) is an 574 operator controlled database used for mapping the user location with 575 available (radio) access networks. With this information, the ANDSF 576 is capable of signaling suggestions for handovers to UE's. A UE is 577 therefore able to operate only on one interface at a time to save 578 resources. In case of the availability of adjacent RAT and after 579 reception of a handover suggestion from the ANDSF, the UE is able to 580 enable the suggested interface, perform a scan and finally decide 581 whether or not to attach to the new targeted RAT. The database can be 582 filled using device monitoring/telemetry statistics signaled from the 583 UE to the network or by active measurements of the environment. 585 3.4. Signaling and Data Flows 587 3.5.1. Provisioning 589 A Subscriber Identity Module (SIM)-card is provisioned by the network 590 operator with a unique and secure identifier that is comparable to 591 the IMSI in 3GPP telco architectures (2G, 3G and 4G). This draft does 592 not differentiate between a physical or an embedded SIM. In addition, 593 security credentials and preferred network identifier are provisioned 594 for authentication as well as network selection are provisioned. The 595 matching information to the SIM card is stored in the HSS. 597 3.5.2. Attachment 599 After powering on the device, a scan for available radio networks is 600 performed on the device, which selects the initial network (e.g. with 601 the strongest signal) and performs a network attachment procedure 602 aligned on ([23401], [23401]) towards the BS using security 603 parameters, ID, last MME associated with (GUMMEI) and last GUTI 604 assigned by MME with ID GUMMEI - the Packet Temporary International 605 Mobile Subscriber Identity (M-TSMI). A secure identifier on the SIM 606 is used to generate a temporary ID (the ILA ID), which is only valid 607 for one session, hides the privacy of the UE in the network and 608 unambiguously identifies the UE within the global network. This ID is 609 used for identification, authentication, authorization and charging 610 purposes. 612 For each network attachment, and due to privacy concerns for not 613 revealing the identify of the UE towards the public, a new unique and 614 temporary ID is generated. This ID is valid for a single session and 615 is renewed afterwards. 617 The BS derives the last MME association out of the network attachment 618 request sent by the UE and queries the last or a new MME based on 619 availability of information for UE authentication. The MME performs a 620 lookup in the user database of the network operator, which is the 621 Home Subscriber Server (HSS) and/or Home Location Register (HLR) and 622 receives a profile in return. Hereby the MME is able to query the 623 mapping database for existing mappings or to retrieve a unique ID for 624 the UE. 626 In the following, the MME selects and configures the BS and GW 627 according to the profile received and signals the profile including 628 the ID towards the BSs of a certain tracking area and GW. 630 The BS allocates a LOC for the UE, binds the ID-LOC combination 631 locally in a cache, publishes its binding in the MME/NVA and signals 632 the ID-LOC towards the client. 634 Quality of Service (QoS) and charging related policies are installed 635 in the BS and GW. The BS handled uplink and the GW downlink related 636 traffic shaping functions. Charging can be performed in both 637 functional elements (BS or GW), whereas a centralized charging in 638 case of multi-path streaming is preferred. 640 After the successful attachment, a service can be invoked. 642 3.5.3. Communication Scenarios for End-to-End Data Transport Sessions 644 After the successful attachment, applications can start communicating 645 in the network using its assigned ILA by constructing IPv6 packets 646 with the SIR source information (ID+LOC) and the mandatory target ID. 647 The target LOC can be either set directly or can be defined as a 648 broadcast message, in which the target LOC will be determined at the 649 edge of the target. 651 The following main high level use cases have been defined. The use 652 cases can be distinguished into the following cases: 653 1) UE accessing a service in the AF, 654 2) UE is communicating with another UE attached to a different 655 base station via a gateway, 656 3) UE is communicating with another UE attached to a different 657 base station, 658 4) UE is communicating with another UE attached to the same base 659 station, 660 5) Mobile Edge Cloud for localized traffic handling and low- 661 latency communication, 662 6) Gateway mobility for enhanced mobility use cases 664 The example use cases are outlined below in details and the 665 differences compared to today's networks are discussed. Fig. 3 666 depicts the network elements and control and data flows related to 667 those use cases. The communication form can be multicast, broadcast, 668 anycast or unicast. 670 +------------+ 671 | UE 1 | 672 | +--------+ +---+ 673 | | Task 1 | | | +------------+ 674 | +--------+ | | +------+ +----+ | Host H1 | 675 +------------+ | | | | | | +--------+ | 676 +---+ BS A +---+ GW +---+ | Task 0 | | 677 +------------+ | | | | | | +--------+ | 678 | UE 2 | | +------+ +-+--+ +------------+ 679 | +--------+ +---+ | 680 | | Task 2 | | | 681 | +--------+ | | 682 +------------+ | 683 | 684 +------------+ +------+ | 685 | UE 3 | | | | 686 | +--------+ +-------+ BS B +---+ 687 | | Task 3 | | | | 688 | +--------+ | +------+ 689 +------------+ 691 Fig 3: UE attachment over multiple base stations 693 1) E2E connection between the UE to AF (Task to Internet) 695 Considering a communication scenario in which a UE (source) queries a 696 web site (target) e.g. "http://about.att.com/innovation/foundry" in a 697 browser represented by T1. 699 SIR:T1,Iaddr -> // Transport endpoints at T1 700 L1:T1,Iaddr -> // On the wire in data center 701 EXA:T1,Iaddr // In the Internet 703 The request is forwarded to the BS, which performs ILA router 704 functionality. In case a broadcast address has been selected as a 705 target LOC, a cache lookup in a local lookup table is performed. 706 Depending on finding an entry in the local cached lookup table, the 707 routing is influenced and the packet is redirected. Otherwise the 708 packet is routed on to the destination ILA SIR address (LOC/ID). 710 2) UE 1 to UE 3 are attached to distinct BSs via gateway 712 Considering a communication scenario in which one task (T1) mobile 713 device of UE 1 is contacting a second task (T3) on mobile device of 714 UE 3. Both UEs are connected to different BSs. ILA routing is done in 715 the BS. 717 The transport endpoints for task to task between UE's communication 718 are the SIR addresses for the tasks. When a packet is transported 719 through the ILA network, the locators are set in source and 720 destination addresses of the packet. On reception the source and 721 destination addresses are converted back to SIR representations for 722 processing at the transport layer. 724 If task T1 on UE 1 is communicating with task T3 on UE 3, the ILA 725 translation sequence would be: 727 SIR:T1,SIR:T3 -> // Transport endpoints on T1 728 UE1:T1,UE3:T3 -> // ILA used on the wire 729 SIR:T1,SIR:T3 // Received at T3 731 3) UE 1 to UE 2 are attached to distinct but interconnected BSs An 732 extension of the scenario will happen, when If task T1 on UE1 is 733 communicating with task T2 on UE 2 via interconnected BSs, the ILA 734 translation sequence would be: 736 SIR:T1,SIR:T2 -> // Transport endpoints on T1 737 UE1:T1,UE2:T2 -> // ILA used on the wire 738 SIR:T1,SIR:T2 // Received at T2 740 4) UE 1 to UE 2 attached to the same BS 742 Considering a communication scenario in which two communicating 743 entities are attached to the same BS and therefore are in close 744 proximity. The solution for routing traffic in today's network is the 745 establishment of the data path from the UE over the access network 746 (e.g. eNB) through the core network (e.g. EPC) into the AF (any IP 747 addressable service or task) and backwards to the access network and 748 finally terminated at the UE. Charging needs to be performed in the 749 BS for this data flow. This communication pattern in today's networks 750 creates a delay caused by the bearer concept of 3GPP network, which 751 encapsulate and de-capsulate data in GTP-tunnels between the eNB and 752 the PGW. 754 A practical use case is the communication between autonomous vehicles 755 (e.g. self-driving cars or self-organized and autonomous drone 756 swarms) through a telecommunication infrastructure. A very low delay 757 is required for the interaction and precise management. In order to 758 reach such a low delay, the communication needs to stay local in 759 order to result in a low delay. 761 The presented solution on ILA mobility allows to keep traffic local 762 for the case in which the communicating parties attached to the same 763 BS. 765 Due to a lower amount of hops between UE 1 and UE 2, a lower latency 766 can be achieved which results in a lower delay. 768 5) Low-latency Mobile Edge Cloud (MEC) Service 770 Considering a use case in which a UE is accessing a service with 771 ultra-low latency requirements in the network such as image 772 recognition, Augmented Reality (AR), Virtual Reality (VR) or other 5G 773 low-latency and/or high throughput services. Other examples include 774 vehicle control (drone or fleet management, traffic information, 775 robot or power grid). In order to provide a high quality of 776 experience for the user and customer, latency in the communication 777 between the mobile device and the service has to be reduced in order 778 to achieve a lower delay. Where multimedia streaming has an 779 acceptable latency requirement of ~100ms, ultra-low latency services 780 have strict requirements on the communication with under ~10ms or 781 even close to 1ms. Classic cloud approaches that concentrate services 782 centralized in the network are not applicable for ultra-low delay 783 services due to the fact, that E2E latency is even too high. 784 Violations of latency requirements result in motion sickness for VR 785 users, outdated traffic information for autonomous self-driving cars, 786 accidents with robotics in factories and the development of a new 787 type of MEC services is hindered. 789 Therefore, a request is created and addressed with the source LOC/ID 790 and targeted towards the destination LOC/ID. 792 +------------+ +------------+ +------------+ 793 | UE 1 | | MEC | | Host H1 | 794 | +--------+ | | +--------+ | | +--------+ | 795 | | Task 1 | | +----+ | | Task 2 | | +----+ | | Task 0 | | 796 | +--------+ | | BS | | +--------+ | | GW | | +--------+ | 797 +------------+---+----+---+------------+---+----+---+------------+ 799 Fig 4: Mobile Edge Computing architecture with ILA 801 The innovative point in this use case depicted in Fig. 4 is the fact 802 that the URL invocation may result in a redirect to a local service 803 or content rather then a remote object. Hereby, the request may 804 trigger a (third party) service or content deployment at the network 805 edge instructed by the MEC_orchestrator and a policy decision. The 806 policy decision is the outcome of the reasoning process within the 807 MEC_orchestrator which takes context, user behavior, system load 808 (throughput, latency, packet-loss, etc.), network topology map, 809 distance between UE and service measured in hops, and other available 810 metrics into account. Geographical load-balancing is therefore 811 possible and enabled. Even when the first set packets of the 812 connection are exchanged with a remote service over a longer 813 geographical network distance, a context handover during the active 814 session away from the remote and towards a closer service instance 815 (out of the same type or load-balancing group) can be applied. 817 In case service, task or content are available in MEC, ILA 818 translation on the wire at the BS changes the locator to the closest 819 point of presence. The following ILA steps are performed. 821 SIR:T1,Iaddr_T0 -> // Transport endpoints at T1 invokes Task 0 (T0) 822 L1:T1,Iaddr_T2 -> // Optional ILA translation from T0 to T2 823 EXA:T1,Iaddr // In mobile edge cloud data center 825 Finally, the number of hops between UE and AF are reduced and a lower 826 delay on the data path is achieved. Otherwise, in case the Edge Cloud 827 capabilities cannot be utilized, basic routing is applied as outlined 828 example 1) E2E connection between the UE to AF (Task to Internet) 829 above. 831 6) Base Station or Gateway Mobility This use case covers situations 832 in which the user stays connected to a BS but the core network is 833 mobile and changes its location and connectivity to the 834 service/Application Function. One example would be a BS that is 835 attached to a vehicle (drone, car/bus, train, cargo ship, etc). The 836 user facing side provides cellular service, backhaul is either WLAN, 837 satellite, laser, MMWave or temporary a fixed connection. The AF 838 facing side changes connection with each change of a transport 839 connection such as WiFi, cellular or satellite. 841 Gateway mobility requires the update of forwarding entries in related 842 BS and AF to continuously forward the packets on the data path. 844 The network setup is depicted in Fig.5 and Fig. 6 with both gateways 845 (GW 1 and GW 2) both have connections to the same BS and AF. 847 +------------+ 848 +------+ +------+ | Host H1 | 849 | | | | | +--------+ | 850 +---+ BS A +---+ GW 1 |+---+ | Task 0 | | 851 +------------+ | | | | | | +--------+ | 852 | UE 1 | | +------+ +------+ +-----+------+ 853 | +--------+ +---+ | 854 | | Task 1 | | +------+ | 855 | +--------+ | | | | 856 +------------+ | GW 2 +----------+ 857 | | 858 +------+ 860 Fig 5: Gateway mobility with attached UE via GW 1 861 The difference between Fig. 5 and Fig.6 is that BS A changes its 862 association with the network by handing over its connectivity from GW 863 1 towards GW 2. Due to the use of ILA, and the related address-space 864 translation capabilities, no GTP tunnels need to be updated and only 865 the address translation between the gateway and the service space is 866 updated. All attached UE's preserve their ILA IPv6 address and 867 continue to be addressable in the network. 869 +------------+ 870 +------+ | Host H1 | 871 | | | +--------+ | 872 | GW 1 |+---+ | Task 0 | | 873 +------------+ | | | +--------+ | 874 | UE 1 | +------+ +-----+------+ 875 | +--------+ +---+ | 876 | | Task 1 | | | | 877 | +--------+ | | +------+ +------+ | 878 +------------+ | | | | | | 879 +---+ BS A +---+ GW 2 +----------+ 880 | | | | 881 +------+ +------+ 883 Fig 6: Gateway mobility with attached UE via GW 2 885 Service interruptions may occur during the time of detaching from GW 886 1 and attaching to GW 2 when using a single radio interface for 887 wireless back hauling. The capabilities of the 3GPP MME are extended 888 with the ability to select the target GW for the BS, management of 889 the BS-GW handover by reserving resources on the target GW 2 and 890 releasing resources on the source GW 1. GW 1 caches packets during 891 handover and forwards them to GW 2 (in case a connection exist 892 between them) until packets are transported on the new uplink and 893 downlink paths. 895 3.5.4. Homogeneous Handover 897 Client mobility in homogeneous networks is usually caused by physical 898 location changes, changes in the received radio signal strength or 899 network based handover due to network policies such as UE load 900 balancing on the BSs. 902 The status information (the list of signals received from adjacent 903 BSs including their signal strength) signaled from the UE towards the 904 BS enables positioning via triangulation as well as the selection of 905 alternative BS's to which the UE may connect to alternatively. 907 Reasons for handovers may be evacuation/preemption of resources on 908 the BS due to emergency scenarios or higher priority calls, 909 UE/BS/service load balancing or physical mobility of the UE among the 910 network. Current resource utilization (e.g. data rates) of the UE or 911 historical traffic pattern may influence the handover and the BS 912 selection process. 914 Mainly the MME selects a target BS (BS_target) as target for the 915 handover of the UE away from the current BS (BS_source). The decision 916 is signaled to related BS's and the UE. BS_source starts de- 917 allocating resource blocked by the UE and BS_target blocks resources 918 required by the UE. Since most UE's are considered to have only a 919 single RAT of each type (one WLAN or one LTE interface) an 920 interruption in the connection while handover is to be expected. In 921 order to avoid packet loss at the UE, buffering at the BS_target as 922 well as packet forwarding from BS_source to BS_target are supported. 923 Only after UE successfully establishes connectivity at the BS_target, 924 previously blocked resources at BS_source are freed up, which are 925 used as handover role-back in case of failure. Finally the MME 926 announces the new ILA ID (BS_target_LOC)/ID for the UE as an update 927 at GW and in the ILa registry. 929 New incoming connections are forwarded directly towards the UE over 930 BS_target using the proclaimed ILA ID (LOC/ID). 932 Homogenous handovers with one radio technology interface supported 933 have interruptions during the handover. Nevertheless those 934 interruptions are relatively small due to techniques such as improved 935 handovers in WiFi (802.11x, 802.11k, 802.11r, and 802.11v) or context 936 handover via X2 in 4G. 938 3.5.5. Heterogeneous Handover 940 Client mobility may involve various Radio Access Technologies (RAT), 941 in which the client is handed off from RAT_1 to RAT_2. The client is 942 not required to move physically for heterogeneous mobility. Instead 943 measurements on the UE or suggestion from the network (signaled over 944 the ANDSF) may trigger handovers to alternative networks even when 945 the UE is physically not moving. Such a handover can be done between 946 WiFi, 4G and 5G. 948 Heterogeneous handovers are motivated for optimizing connectivity 949 between UE and AF/service to move a multimedia connection with high 950 bandwidth requirements from cellular (4G/5G) towards WLAN, a security 951 sensitive bank transaction from WLAN towards cellular or simply a 952 better transport-cost-per-bit-ratio. 954 Heterogeneous (compared to homogenous) handovers may be performed 955 seamlessly with establishing a second alternative connection in 956 parallel to the existing active connection and tearing down the old 957 connection only, after successfully establishing the new connection. 958 Usually this is possible, because more then one interface is 959 available on the client, which can be used in parallel to establish 960 connectivity in parallel. In order to provide higher bandwidth over 961 multi-path, both connections may be kept open in parallel. In this 962 regard, the MME adds another LOC'/ID as update to the existing entry 963 LOC/ID in the registry on the gateways and DNS. 965 3.5.6. Detachment 967 A detachment from the network can happen gracefully by shutting down 968 the phone and de-registering it from the BS or suddenly due to a loss 969 of connection. In both situations, a de-registration from the UE out 970 of the list of active users attached to the BS is done directly or 971 indirectly (after inactivity for a predefined time). Resource 972 reservations are freed up again after detachment and opened up for 973 other connections. 975 3.5.6. Idle-mode and paging 977 Power saving methods are working transparent to the ILA mobility 978 concept such as described in ([23401], [23402]). The device toggles 979 from active to inactive mode in idle-mode in order to reduce the 980 communication interval between device and antenna. Resource 981 reservations in the network are kept alive in order to allow a fast 982 weak-up and connection re-establishment caused by paging of the BS 983 towards the device. 985 4. Discussion, Evaluation and Summary 987 New low-delay services are appearing with AR/VR, drone communication, 988 self-driving cars and robotic control that have new requirements on 989 the network, which cannot be fulfilled by today's network and cloud 990 architectures. New ultra-low latency is a key requirement on 991 connectivity that is enabling a new services. One way of improving 992 the End-to-End (E2E) connectivity is to substitute the underlying 993 technology with a new generation and to improve the performance. Part 994 of this improvement is described in Moore's-law, which highlights 995 that the number of components per integrated circuit is doubling 996 every 18 month. Another approach is to reduce the E2E latency by 997 reducing the physical distance between device and service measured in 998 number of hops and at the same time provide a backwards compatible 999 solution for WiFi and 4G networks. 1001 This draft is addressing the above mentioned challenges and provides 1002 a solution in form of a new mobile network architecture based on 1003 Identifier-Location Addressing (ILA) mobility. ILA decouples the 1004 identity from locator within an IPv6 address. Therefore mobility can 1005 be achieved by preserving the same ID at the endpoint and only 1006 adapting the locator used routing in case of mobility. The 1007 implications are improved mobility with less control signaling and a 1008 more efficient tunnel-free core network architecture. 1010 ILA applied on mobile networks and the gained improved mobility 1011 enables multiple new and innovative use cases compared to legacy 1012 telecommunication networks. Summarizing, the above presented 1013 Communication Scenarios for data transport for an End-to-End session 1014 outlines ways to improve connectivity, optimize routing and enable a 1015 new type of service: Mobile Edge Cloud services. Firstly, the 1016 improved data path requires less hops to traverse between UE <-> AF 1017 enabled by Mobile Edge Computing or locally between UE_1 <-> UE_2 due 1018 to the flatter architecture. Secondly, less overhead is created due 1019 to the reduction of GTP tunnels between network elements. Thirdly, 1020 the presented approach of ILA mobility is backwards compatible with 1021 today's IPv6 based fixed and mobile telecommunication networks. 1023 5. References 1025 5.1. Normative References 1027 [rfc6741] Identifier-Locator Network Protocol (ILNP) Engineering 1028 Considerations, Jan 2013, https://tools.ietf.org/html/rfc6741 1030 [nvo3ila] Identifier-locator addressing for network virtualization, 1031 draft-herbert-nvo3-ila-02, Tom Herbert, Mar 2016, 1032 https://tools.ietf.org/html/draft-herbert-nvo3-ila-02#page-17 1034 5.2. Informative References 1036 [rfc6830] The Locator/ID Separation Protocol (LISP), D. Farinacci, 1037 Jan 2013 1039 [MIPv6], Mobility Support in IPv6, C. Perkins, Ed. et al., Jul 2011, 1040 https://tools.ietf.org/html/rfc6275 1042 [PMIPv6] S. Gundavelli, Ed. et al., Aug 2008, 1043 https://tools.ietf.org/html/rfc5213 1045 [23401] 3GPP TS 23.401 V13.7.0 (2016-06), General Packet Radio 1046 Service (GPRS) enhancements for Evolved Universal Terrestrial Radio 1047 Access Network (E-UTRAN) access (Release 13) 1049 [23402] 3GPP TS 23.402 V14.0.0 (2016-06), Architecture enhancements 1050 for non-3GPP accesses (Release 14) 1052 [23203] 3GPP TS 23.203 V14.0.0 (2016-06), Policy and charging control 1053 architecture (Release 14) 1055 [29212] 3GPP TS 29.212 V14.0.0 (2016-06), Policy and Charging Control 1056 (PCC); Reference points (Release 14) 1058 Authors' Addresses 1060 Dr.-Ing. Julius Mueller 1061 260 Homer Ave 1062 Palo Alto, CA 94301 1063 US 1065 EMail: jmu@att.com 1066 and 1067 Tom Herbert 1068 Facebook 1069 1 Hacker Way 1070 Menlo Park, CA 94052 1071 US 1073 Email: tom@herbertland.com