idnits 2.17.1 draft-mueller-ila-mobility-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 12 characters in excess of 72. ** There are 6 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 == Line 126 has weird spacing: '... for ident...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 6, 2016) is 2822 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6740' is mentioned on line 125, but not defined == Missing Reference: 'RFC6741' is mentioned on line 125, but not defined == Missing Reference: 'RFC2119' is mentioned on line 133, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 328, but not defined == Unused Reference: 'KEYWORDS' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'EVILBIT' is defined on line 745, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 749, but no explicit reference was found in the text == Unused Reference: 'RFC5514' is defined on line 753, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). 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: January 7, 2017 T. Herbert 5 Facebook 6 July 6, 2016 8 Mobility Management for 5G Network Architectures Using Identifier-locator Addressing 9 draft-mueller-ila-mobility-00 11 Abstract 13 This specification describes Mobility Management Architecture for 5G 14 Networks Using Identifier-Locator Addressing in IPv6 for virtualized 15 mobile telecommunication networks. Identifier-locator addressing 16 differentiates between location and identity of a network node. The 17 approach presented in this draft enables mobility management on Layer 18 3, and provides a simplified and more efficient architecture with 19 less core network utilization compared to traditional architecture. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/1id-abstracts.html 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 Copyright and License Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1 Introduction and Problem Statement . . . . . . . . . . . . . . 4 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3 Related Work, Protocols and Concepts . . . . . . . . . . . . . 5 63 3.1 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2 Proxy MobileIPv6 . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3 Host Identity Protocol (HIP) . . . . . . . . . . . . . . . . 6 66 3.4 Locator/ID Separation Protocol (LISP) . . . . . . . . . . . 7 67 3.5 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.6 Identifier-Locator Addressing (ILA) . . . . . . . . . . . . 7 69 3.7 Comparison of ILA to alternative approaches . . . . . . . . 7 70 3.7.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.7.2 LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.8 Taxonomy & Summary . . . . . . . . . . . . . . . . . . . . . 9 73 4 Mobility Management Architectures for 5G Network Using ILA . . . 9 74 4.1 Address format for ILA mobile . . . . . . . . . . . . . . . 9 75 4.2 Architecture with functional elements and reference 76 points . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3 Functional Elements . . . . . . . . . . . . . . . . . . . . 10 78 4.4 Signaling and data flow . . . . . . . . . . . . . . . . . . 12 79 4.5.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . 12 80 4.5.2 Attachment . . . . . . . . . . . . . . . . . . . . . . . 12 81 4.5.3 Communication scenarios for data transport for an 82 End-to-End session . . . . . . . . . . . . . . . . . . . 13 83 4.5.4 Homogeneous Handover . . . . . . . . . . . . . . . . . . 15 84 4.5.5 Heterogeneous Handover . . . . . . . . . . . . . . . . . 16 85 4.5.6 Detachment . . . . . . . . . . . . . . . . . . . . . . . 16 86 4.6 TODO: Other cases . . . . . . . . . . . . . . . . . . . . . 16 87 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 18 89 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 90 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.1 Normative References . . . . . . . . . . . . . . . . . . . 18 92 5.2 Informative References . . . . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1 Introduction and Problem Statement 98 Mobility has been a challenge for IP based network since the area of 99 smartphones began. One challenge is to ensure seamless and 100 transparent mobility for mobile devices among different locations and 101 in between several Radio Access Technologies. More complexity has 102 been added through Cloud computing and virtualization in which 103 services might change their physical location within a virtualized 104 architecture, too. In regards of current research and develpment on 105 Mobile Edge Cloud and 5G, high availability, low delay and ultra high 106 bandwidth requirements are required for a massive amount of 107 communuicating instances ranging from cellulars, high-definition 108 multimedia streaming, Internet-of-Things (IoT), critical 109 infrastructures among others. 111 IP has been overloaded and used at teh same time for locator and 112 identifier. requirements: efficient routing, scalability, mobility, 113 security lead changesin the design principles on decoupling Locator- 114 Identifier wihtin IP. 116 This specification describes Mobility Management Architecture for 5G 117 Networks Using Identifier-Locator Addressing (ILA) ([nvo3]) in IPv6 118 for virtualized mobile telecommunication networks. Identifier-locator 119 ([nvo3]) addressing differentiates between location and identity of a 120 network node. The approach presented in this draft enables mobility 121 management on Layer 3, provides a simplified and more efficient 122 architecture, less core network utilization. 124 The concept of ILA extends the Identifier-Locator Network Protocol 125 (ILNP) ([RFC6740], [RFC6741]) defines a protocol and operations model 126 for identifier-locator addressing in IPv6. 128 1.1 Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 The following terminology will be referred to in the document. 136 * ILA ID or only ID: unique identifier in ILA terms - not used public 137 and only used for GUTI creation for each new attachment. The 138 International Mobile Subscriber Identity (IMSI) can be used for ID 139 generation. 141 * ILA host: An end host that is capable of performing ILA 142 translations for both sending and receiving. An ILA host uses the 143 ILA resolver protocol to get identifier to locator mappings for 144 destinations in communication. 145 * ILA router: A network device that performs ILA translations. ILA 146 routers participate in a mapping distribution protocol. 148 * Globally Unique Temporary UE Identity (GUTI): temporary address 149 considered as a temporary ILA ID. 151 * ILA Locator (LOC): either International Mobile Equipment Identity 152 (IMEI) or an IP address that has been assigned to a single UE. 154 * User Equipment (UE): device with identifier such as a mobile phone 155 or IoT gateway. 157 * Access Point (AP): Base station, evolved-NodeB (eNB) in 4G. 159 * Gateway (GW): Gateway, e.g. Serving-Gateway (SWG) or Packet-Data- 160 Network-Gateway (PGW) in 4G. 162 * Application Function (AF): refers to the 3GPP terminology and 163 stands for any IP service. 165 2 Motivation There is increasing demand for improved connectivity for a 166 growing number of devices including IoT, mobile phones, cars, etc. 5G 167 networking is intended to address access and core bottlenecks to 168 provide for lower lower latency, higher throughput, and greater 169 number of connected devices. There are several challenges in 170 applying Mobile-Edge-Computing (MEC) concepts due to Layer 2 171 tunneling and signaling overhead. The following architecture is 172 based on a layer 3 design that obviates the need for layer 2 173 tunneling and signaling overhead. The design decisions and call flow 174 outline an approach using ILA for mobility management in 5G networks 175 that overcomes challenges of legacy networks. A flatter network 176 architecture as well as optimizations in the data and control path 177 are presented, which result in a shorter communication path and 178 therefore lower delay. 180 3 Related Work, Protocols and Concepts This section provides an 181 overview on of the state-of-the-art on related Work, protocols and 182 concepts for mobility management on mobile networks. In particular 183 the 4th Generation (4G) of mobile telecommunication networks has been 184 taken into comparison for this draft. 186 3.1 Mobile IPv6 The IETF specified Mobile IPv6 to ensure connectivity 187 and reachability in case of client mobilty within an IPv6 network. 189 Mobility is solved by assigning an additional IPv6 address - the 190 Care-of-Address (CoA) - next to the current IPv6 address that as been 191 assigned in the home network. Therefore a UE is equipped with a home 192 address, plus primary CoA in case of foreign network attachment. IPv6 193 is classified as host-based mobility protocol, due to the fact, that 194 the UE is in charge of announcing its mobility to the network. In 195 particular it is the clientresponsibility for signalling binding 196 update signaling to HA. In order to ensure reachability, the UE 197 communicates its new assigned CoA to the Home Agent, which acts as a 198 router and registrar for UEs. Connection requests are intercepted and 199 re-routed in case CoA entries for a UE exists. A tunnel is 200 established between the UE at the CoA and the HA for securely 201 exchanging packets. Per default, the first packet is routed from the 202 correspondent UE towards CoA of the UE via the HA. All consecutive 203 packets will follow on the same path, which might include a detour, 204 but hides the new location of the UE for privacy reasons. The feature 205 of route optimization allows the UE to directly contact the 206 correspondent UE, therefore cuts out the HA from the communication 207 path and forwards packets on a shorter route. Security of the Mobile 208 IPv6 is enhanced through IPSec for binding updates to avoid spoofing 209 of CoA for a UE. 211 3.2 Proxy MobileIPv6 The IETF specified Proxy Mobile IPv6 provides 212 network-based mobility management for UE and extends the Mobile IPv6 213 in the way, that host-based mobility management functionalities in 214 Mobile IPv6 are excluded from the client into the network in Proxy 215 Mobile IPv6. The Local Mobility Anchor (LMA) acts as topological 216 anchor point and manages the UE's binding state. The Mobile Access 217 Gateway (MAG) manages the mobility-related signaling on behalf of a 218 UE at the access router. It is responsible for tracking the UE's 219 movements to and from the access link for signaling the UE's local 220 mobility anchor. 222 3.3 Host Identity Protocol (HIP) HIP ([hip]) is provising a secure 223 solution for identifier/locator-split by adding a new host identity 224 layer into protocol stack. A cryptographic namespace build upon a 225 host identity as public key allows scalability and multi-homing 226 within the network. An extensions of DNS supports rendezvous server 227 functioanlity for secure host identity lookup. A secure channel is 228 establishment over Diffie-Hellmann-key exchange between two 229 communicating entities. The communication setup is considered as 230 robust against DOS, due to a riddle solved at the requestor side. On 231 the other side a high overheaed for the secure communication 232 establishment due to key exchange has to be taken into 233 consideration. 235 3.4 Locator/ID Separation Protocol (LISP) 236 https://tools.ietf.org/html/rfc6830 network-layer-based protocol that 237 enables separation of IP addresses into two new numbering spaces: 238 Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) tunnel 239 router encapsulates and decapsulates packets 241 3.5 ILNP 243 3.6 Identifier-Locator Addressing (ILA) * reduced header size * MN - 244 Network Virtualization Edge * NVE creates and maintains local state 245 about each Virtual Network for which it is providing service on 246 behalf of a Tenant System. 248 3.7 Comparison of ILA to alternative approaches 250 This section compares the ILA approach to some alternatives that have 251 been discussed in 5gangip list. 253 3.7.1 ILNP 255 Identifier Locator Network Protocol (ILNP [RFCXXXX]) is an 256 experimental protocol that splits and IPv6 address into a locator and 257 identfier. ILA is fundamentally based on ILNP. 259 The key differences between ILA and ILNP are: 261 * ILNP requires changes to the transport layer. This limits ILNP 262 to be used only on hosts and every transport protocol 263 implementation would need to be modified to use ILNP. Presumably 264 to overcome the limitation above, some sort of ILNP proxy could 265 be defined to perform ILNP in a middlebox. 267 * ILA does not require changes to the transport layer. 269 * Checksum neutral translation means that transport layer does not 270 need to be parsed to perform ILA. This also ensures that 271 existing device offloads (like checksum offload) work 272 seamlessly. 274 * ILNP employs IPv6 extension headers which are mostly considered 275 non-deployable. ILA does not use these. 277 * Core support for ILA is in upstream Linux, to date there is no 278 publically available source code for ILNP. 280 * ILNP involves DNS to distribute mapping information, ILA assumes 281 mapping information is not part of naming. 283 3.7.2 LISP 285 Locator Identifier Separation Protocol (LISP [RFCXXXX) is an IP 286 encapsulation protocol where the destination address in the outer IP 287 header is a locator and the destination address in the inner header 288 is an idnetifier. 290 The key differences between ILA and LISP are: 292 * ILA is not encpasulation so there is not associate encapsulaiton 293 overhead. For instance IPv6/IPv6 in LISP would have 52 bytes of 294 overhead whereas ILA translation has zero. 296 * LISP may not work with some network device offloads whereas ILA 297 works with all stateless offloads (ILA is transparent to the 298 network so that it would just see TCP/IP packets for instance). 300 * ILA has been accpeted into Linux, LISP has not been accepted. 302 * ILA can run either on end hosts (ILA hosts) or in the network 303 (ILA routers). In ILA hosts the mapping database is a cache to 304 optimize communications. 306 * ILA defines locators and identifiers to be 64 bits whereas LISP 307 allows them to be full 128 bit address making for for memory 308 needed in mapping table. 310 * ILA is not encpasulation so there is not associate encapsulaiton 311 overhead. For instance IPv6/IPv6 in LISP would have fifty-six 312 bytes of overhead whereas ILA translation has zero. 314 * The process of ILA translation is much more efficient than 315 performing LISP. The translation path is: 317 1) Parse IP header and extract the destination address 319 2) Lookup destination in a hash table (obviated with cached 320 route for ILA hosts) 322 3) Write new destination address (16 byte copy) 324 4) Forward to new destination (or receive at final destination). 326 LISP processing is more involved. To do encapsulation an outer 327 IP header, UDP header and LISP header need to be inserted. 328 Tunnel fragmentation and MTU need to be considered [RFCXXXX] 329 (i.e. increasing the size of a packet may exceed tunnel MTU). At 330 the remote tunnel end point, the outer IP header must be 331 validated and aa lookup done on the destination address to see 332 if it is a local address . A lookup must be done on the 333 destination UDP port to find that it is a LISP port. If the UDP 334 checksum is not zero that must also be validated. The LISP 335 header must also be processed. Once the encapsulation is 336 verfied, the headers are removed and the inner packet is either 337 forwarded or received. 339 3.8 Taxonomy & Summary Comparing solutions above in a taxonomy and 340 compare them using the following parameters: 342 * multi-homing? * multi-path? * IP-session continuity: all three 343 * seamless handover or transparent handover? Attached with same 344 or different interface * state - number and positions * overhead 345 through tunneling or header extension * client mobility support 346 and efficient update of location information in the network * 347 number of functional elements in the architecture 349 4 Mobility Management Architectures for 5G Network Using ILA This 350 section outlines the architecture supporting ILA in mobile 351 networks. The main functional blocks for connectivity, mobility 352 support, security and charging are presented. Message flows for 353 basic use cases executed by the mobile UE such as attachment, 354 data transport with session handover and detachment are 355 outlined. 357 4.1 Address format for ILA mobile 359 The address format is derived out of the ILA draft in ([nvo3]). 361 /* IPv6 canonical address format */ | 64 362 bits | 64 bits | +------- 363 -------------------------+-------------------------------+ 364 | IPv6 Unicast Routing Prefix | Interface Identifier 365 | +--------------------------------+----------------------- 366 --------+ 368 /* ILA for IPv6 */ | 64 bits 369 |3 bits| 61 bits | +------------------------ 370 --------+-------------------------------+ | 371 Locator | Type | Identifier | +----- 372 -----------------------------------------------------------+ 374 4.2 Architecture with functional elements and reference points 375 The presented architecture is aligned on the 3GPP Evolved Packet 376 System ([23.401], [23.402]) following the separation of control 377 plane and data plane. Whereas 3GPP EPS addresses mobility 378 through Layer 2 tunneling with GTP, this approach provides a 379 Layer 3 mobility approach utilizing the ILA concepts for 380 mobility. 382 TODO: architecture bootstrapping: which entity assigns ILA 383 address space for LOC and ID? 385 4.3 Functional Elements 387 * The User Equipment (UE) is the mobile device (cellular or 388 laptop) executing services such as apps on the device, binding 389 apps to the ID as communication endpoints, handling the bindings 390 of all associated LOC/ID's and performing mobility as described 391 below. The UE performs security related functions via its 392 (Embedded) SIM handing at least one or multiple identifiers 393 provisioned by one or multiple network operators. Security 394 related functions include authentication of the UE towards the 395 network (more specifically the AP) and certificate management 396 for establishing secure transport connections. Either the UE 397 supports IPv6 or ILA for handling locator and ID bindings and 398 updates or the etwork is handling ILA functionality on behalf of 399 the UE. Storage and management of multiple locators for multi- 400 path and multi-homing is supported by the UE support. 402 * The Access Point (AP) is the first point of contact from the 403 UE when attaching over radio to the network. Its main purpose is 404 routing, gating and forwarding data and control packets. The 405 Radio Access Technology (RAT) is independent of the proposed 406 concept and therefore out of scope of this document. 3G, 4G, 5G 407 or WiFi are applicable RATs. The AP is also capable of caching 408 for Content-Centric-Networks (CCN) TODO:LINK like apps, in order 409 to store content or host service instances close to the user at 410 the edge of the network. Another aspect of the cache is to 411 support transparent handovers, during which buffering of packets 412 at the target AP is required. Therefore a X2-like connection 413 between APs is required. The AP supports a support a policy 414 enforcement function (PEF) as well as a Event Reporting Function 415 (ERF) aligned on the 3GPP defined Policy Control and Charging 416 (PCC) functionality for the EPS in ([23.203], [29.212]). Uplink 417 QoS management is handled by the AP, too. In order to 418 differentiate between multiple types of data traffic, signaling, 419 high-priority, real-time and non-real-time connections can be 420 distinguished and the order of packet processing in the AP can 421 be influenced for uplink. The same concept applies for downlink 422 in the GW. Forward Error Correction (FEC), IP header 423 compression, encryption of user data stream are supported by the 424 AP, too. 426 * The Gateway (GW) encompasses management and policy enforcement 427 functions as well. Its main purpose is routing, gating and 428 forwarding data and control packets. Therefore functionalities 429 such as downlink QoS enforcement, APN management and charging is 430 performed by each GW. 432 * The Mobility Management Entity (MME) handles the initial 433 authentication, authorization and mobility management of UE's 434 over the control plane. The MME is responsible for tracking the 435 UE's mobility and is in charge for updating the registries with 436 near real-time status updates for LOC/ID mapping. ID and LOC 437 assignment are performed by the MME. 439 * The Home Subscriber Server (HSS) stores and manages user 440 profile information. These include the static information such 441 as the assigned ID, security credentials as well as dynamic 442 information LOC and the current Tracking Area. 444 * The Policy Charging Rules Function (PCRF) controls data flows 445 in the network architecture according to pre-defined rules. Such 446 rules can be created by the network operator such as an upper 447 limited for the data rate or total bytes transferred given a 448 time interval (e.g. 2GB per month data plane with unlimited 449 speed and a reduction of bandwidth after reaching the limit of 450 2G). Other rules differentiate between class of services for 451 various traffic flow types identified on their Traffic Flow 452 Template (TFT) characteristics such as source, destination, port 453 and protocol information. The PCRF is handling charging for 454 traffic flows using online (pre-paid) and offline (post-paid) 455 charging. Both charging modes include a charging based on 456 metrics such as service invocations, online time, data 457 transferred, or no-charging. Out of credit events may influence 458 the current connectivity for online charging, whereas offline 459 charging is accumulating charging records which are usually 460 processed in a monthly period. 462 * The Access Network Discovery and Selection Function (ANDSF) is 463 a database used for mapping the user location with available 464 access networks. With this information, the ANDSF is capable of 465 signaling suggestions for handovers to UE's. A UE is therefore 466 able to operate only on one interface at a time to save 467 resources. In case of the availability of adjacent RAT and after 468 reception of a handover suggestion from the ANDSF, the UE is 469 able to enable the suggested interface, perform a scan and 470 finally decide whether or not to attach to the new targeted RAT. 471 The database can be filled using device monitoring/telemetry 472 statistics signaled from the UE to the network or by active 473 measurements of the environment. 475 TODO: OPEN - assignment to Functional Elements needed * 476 filtering * gating * legal interception on the AP, to include 477 the case, in which traffic re-routed only by the AP and is not 478 traversing the GW. 480 4.4 Signaling and data flow 482 4.5.1 Provisioning A Subscriber Identity Module (SIM)-card is 483 provisioned by the network operator with a unique ID, that is 484 comparable to the IMSI in 3GPP telco architectures (2G, 3G and 485 4G). This draft is no differentiating between a physical or an 486 embedded SIM. The ID unambiguous identifies the UE within the 487 global network, is used for identification, authentication, 488 authorization and charging purposes. In addition, security 489 credentials and preferred network identifier are provisioned for 490 authentication as well as network selection are provisioned. The 491 matching information to the SIM card is stored in the HSS. 493 4.5.2 Attachment After powering on the device, a scan for available 494 networks is performed on the device, which selects the network 495 with the strongest signal and performs a network attachment 496 procedure aligned with ([23.401], [23.401]) towards the Access 497 Point (AP) using security parameters, ID, last MME associated 498 with (GUMMEI) and last GUTI assigned by MME with ID GUMMEI - the 499 Packet Temporary International Mobile Subscriber Identity (M- 500 TSMI). 502 For each network attachment and due to privacy concerns for not 503 revealing the identify of the UE towards the public, a creation 504 of a Globally Unique Temporary UE Identity (GUTI) is performed. 506 The AP derives the last MME association out of the network 507 attachment request sent by the UE and queries the last or a new 508 MME based on availability of information for UE authentication. 509 The MME performs a lookup in the user database of the network 510 operator, which is the Home Subscriber Server (HSS) and/or Home 511 Location Register (HLR) and receives a profile in return. 513 In the following, the MME selects and configures the AP and GW 514 according to the profile received and signals the profile 515 including the GUTI towards the AP and GW. 517 The AP allocates a LOC for the UE, binds the GUTI-LOC 518 combination locally in a cache, publishes its binding in the MME 519 and signals the GUTI-LOC towards the client. 521 Quality of Service (QoS) and charging related policies are 522 installed in the AP and GW. The AP handled uplink and the GW 523 downlink related traffic shaping functions. Charging can be 524 performed in both functional elements (AP or GW), whereas a 525 centralized charging in case of multi-path streaming is 526 preferred. 528 4.5.3 Communication scenarios for data transport for an End-to-End 529 session After the successful attachment, a service can be 530 invoked. There are three main data path to be considered, to 531 address all use cases. The use cases can be distinguished 532 between a UE accessing a service in the AF. A UE is 533 communicating with another UE. The example use cases below 534 outline the details and point out the differences compared to 535 today's networks. 537 TODO: Include schema as in nvo3 - 5.3 Reference network for 538 scenarios 540 1) UE to AF through the complete network 542 Considering a communication scenario in which a UE queries a 543 website ("http://about.att.com/innovation/foundry") in a 544 browser. An ID is retrieved in return from the DNS. 546 UE[Task UE_T1] -> DNS // request ID for URL DNS -> UE[Task 547 UE_T1] // ID for URI 549 The sequence for traversing the network looks as follows. 551 UE(GUTI/LOC):[Task UE_T1] <-> AP <-> GW <-> AF[Task AF_T1] 552 The request is forwards to the AP, which performs ILA router 553 functionality and a lookup in a local lookup table. Depending on 554 finding an entry in the local lookup table, the routing is 555 influenced and the packet is redirected. Otherwise routing on 556 the initial destination LOC/ID is fulfilled. 558 2) UE_1 to UE_2 attached to distinct APs 560 UE1[Task UE1_T1] <-> AP_1 <-> GW <-> AP_2 <-> UE2[Task UE2_T1] 562 Considering a communication scenario in which one mobile device 563 (UE1) is contacting a second mobile device (UE2). ILA routing is 564 done in the AP. TODO: Classic signaling and data flow similar to 565 legacy networks. 567 3) UE_1 to UE_2 attached to the same AP 569 UE_1[Task UE1_Tx] <-> AP <-> UE_2[Task UE2_Ty] 571 Considering a communication scenario in which two communicating 572 entities are attached to the same AP and therefore are in close 573 proximity. The solution for routing traffic in todays network is 574 the establishment of the datapath from the UE over the access 575 network (e.g. eNB) into the core network (e.g. EPC) and back to 576 the access network and finally to the UE. Charging needs to be 577 performed in the AP for this data flow. This communication 578 pattern creates a delay caused by the bearer concept of 3GPP 579 network, which encapsulate and de-apsulate data in Layer 2 580 tunnels between the eNB and the PGW. 582 4) UE to Mobile Edge Cloud (MEC) UE[Task UE_T1] <-> DNS 583 Considering a communication scenario in which a Virtual Reality 584 (VR) application on a smartphone is accessing a low-delay 585 service in the network e.g. an image recognition service. In 586 order to provide a high quality of experience for the user, the 587 delay between the mobile device and the service should be 588 reduced. 590 Firstly, a DNS lookup resolves the URL into a ID to identify the 591 closest service instance. The lookup process may be resolve to a 592 service co-located at the AP or trigger the deployment of that 593 service instance within a datacenter co-located or attached to 594 the AP. 596 A request is created and addressed with the source LOC/ID and 597 targeted towards the destination LOC/ID. 599 The sequence for traversing the network looks as follows. 601 UE[Task UE_T1] <-> AP <-> AF[Task AF_T1] 603 5) Summarizing, the use of ILA for mobile reduces allows 604 multiple improvements compared to legacy telecommunication 605 networks. Firstly, the improved datapath has less hops to 606 traverse between UE and AF or UE_1 and UE_2 due to the flatter 607 architecture. Secondly, the less overhead is created due to the 608 reduction of GTP tunnels between network elements. Thirdly, the 609 more efficient routing reduces the core network traffic by 610 routing traffic particularly locally and avoiding re-routing and 611 traffic forwarding through the complete core network, even in 612 scenarios, in which the communication partner are in close 613 proximity and attached to the same AP. lower delay, which is one 614 critical requirement for 5G networks. 616 4.5.4 Homogeneous Handover Client mobility using the same access network 617 technology due to location changes is referred to as homogeneous 618 handover. Triggers for homogeneous handover may be changes in 619 signal strength at the UE or network based handover due to 620 network policies such as load balancing. 622 The status information (the list of signals received from 623 adjacent APs including their signal strength) signaled from the 624 UE towards the AP indicates its position via triangulation as 625 well as the alternative AP's to which the UE may connect to. 627 Reasons for handovers may be evacuation/preemption of resources 628 on the AP due to emergency scenarios or higher priority calls, 629 UE/AP/service load balancing or physical mobility of the UE 630 among the network. The current resource utilization (e.g. data 631 rates) of the UE or historical traffic pattern may influence the 632 handover and the AP selection process. 634 The MME selects a new AP (AP_new) as target for the handover of 635 the UE away from the current AP (AP_current). The decision is 636 signaled to related AP's and the UE. AP_current starts de- 637 allocating resource blocked by the UE and AP_new blocks 638 resources required by the UE. Since most UE's are considered to 639 have only a single RAT of each type (one WLAN or one LTE 640 interface) an interruption in the connection while handover is 641 to be expected. In order to avoid packet loss at the UE, 642 buffering at the AP_new as well as packet forwarding from 643 AP_current to AP_new are supported. Only after UE successfully 644 establishes connectivity at the AP_new, previously blocked 645 resources at AP_current are freed up, which are used as handover 646 role-back in case of failure. Finally the MME announces the new 647 LOC(AP_new)/ID for the UE as an update at GW and in the DNS. 649 New incoming connections are forwards directly towards the UE 650 over AP_new using the proclaimed LOC/ID. 652 4.5.5 Heterogeneous Handover Client mobility may involve various Radio 653 Access Technologies (RAT), in which the client is handed off 654 from RAT_1 to RAT_2. The client is not required to move 655 physically for heterogeneous mobility. Instead measurements on 656 the UE or suggestion from the network over the ANDSF may trigger 657 handovers even when the UE is physically not moving. 659 Heterogeneous handover may be motivated for optimizing 660 connectivity between UE and a service to move a multimedia 661 connection with high bandwidth requirements from cellular 662 towards WLAN or a security sensitive bank transaction from WLAN 663 towards cellular. 665 Heterogeneous (compared to homogenous) handovers may be 666 performed seamless with establishing a second alternative 667 connection in parallel to the existing and tearing down the old 668 connection, after successfully establishing the new connection. 669 In order to provide higher bandwidth over multi-path, both 670 connections may be kept open in parallel. In this regard, the 671 MME adds another LOC'/ID as update to the existing entry LOC/ID 672 in the registry on the gateways and DNS. 674 4.5.6 Detachment A detachment from the network can happen gracefully by 675 shutting down the phone and de-registering it from the AP or 676 suddenly due to a loss of connection. In both situations, a de- 677 registration from the UE out of the list of active users 678 attached to the AP is done directly or indirectly (after 679 inactivity for a predefined timeframe). Resource reservations 680 are freed up again after detachment. 682 4.6 TODO: Other cases idle mode, paging 684 Emergency call support 686 Connectivity between UE and AF 688 Connectivity between UE and other UE 689 Similar AP or TA 691 Distinct AP or TA 693 5. Discussion Backwards compatibility 695 IP address allocation split into locator and identifier part 697 loc at attachment via MME/GW 699 id at attachment via AP/MME 701 703 Definitions and code { 704 line 1 705 line 2 706 } 708 Special characters examples: 710 The characters , , , 711 However, the characters \0, \&, \%, \" are displayed. 713 .ti 0 is displayed in text instead of used as a directive. 714 .\" is displayed in document instead of being treated as a comment 716 C:\dir\subdir\file.ext Shows inclusion of backslash "\". 718 3 Security Considerations 720 722 4 IANA Considerations 724 726 5 References 728 5.1 Normative References 730 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, DOI 732 10.17487/RFC2119, March 1997, . 735 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 736 10.17487/RFC1776, April 1 1995, . 739 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 740 10.17487/RFC1925, April 1 1996, . 743 5.2 Informative References 745 [EVILBIT] Bellovin, S., "The Security Flag in the IPv4 Header", 746 RFC 3514, DOI 10.17487/RFC3514, April 1 2003, 747 . 749 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 750 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 751 . 753 [RFC5514] Vyncke, E., "IPv6 over Social Networks", RFC 5514, DOI 754 10.17487/RFC5514, April 1 2009, . 757 Authors' Addresses 759 Dr.-Ing. Julius Mueller 760 260 Homer Ave 761 Palo Alto, CA 94301 762 US 764 EMail: jmu@att.com 765 and 766 Tom Herbert 767 Facebook 768 1 Hacker Way 769 Menlo Park, CA 94052 770 US 772 Email: tom@herbertland.com