idnits 2.17.1 draft-vonhugo-5gangip-ip-issues-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 543, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-farinacci-lisp-predictive-rlocs-00 == Outdated reference: A later version (-04) exists of draft-herbert-nvo3-ila-03 == Outdated reference: A later version (-08) exists of draft-ietf-dmm-4283mnids-03 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-15 == Outdated reference: A later version (-03) exists of draft-mueller-ila-mobility-01 == Outdated reference: A later version (-03) exists of draft-padma-ideas-problem-statement-00 == Outdated reference: A later version (-02) exists of draft-portoles-lisp-eid-mobility-01 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. von Hugo 3 Internet-Draft Telekom Innovation Laboratories 4 Intended status: Informational B. Sarikaya 5 Expires: May 17, 2017 Huawei 6 November 13, 2016 8 Review on issues in discussion of next generation converged networks 9 (5G) from an IP point of view 10 draft-vonhugo-5gangip-ip-issues-01 12 Abstract 14 This document presents considerations related to open and upcoming 15 issues with upcoming new communication systems denoted as 5G aiming 16 to set a basis for documenting problem space, use-cases, and 17 potential solutions related to next-generation network 18 infrastructure. The draft reviews currently investigated topics, 19 including both inputs from IETF and from other SDOs as well as 20 research activities. Further the outcome of recent discussions at 21 side sessions during IETF meetings are recaptured to help identifying 22 a starting point for future thoughts. 24 Status of This Memo 26 This Internet-Draft is submitted 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). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on May 17, 2017. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Problem Space and Typical Use Cases . . . . . . . . . . . . . 4 60 2.1. Ubiquitous Broadband Access Use Case . . . . . . . . . . 4 61 2.2. Massive Deployment of Machines Use Case . . . . . . . . . 4 62 2.3. Critical Communications Use Case . . . . . . . . . . . . 4 63 3. Requirements to Future Communication Systems . . . . . . . . 4 64 4. Current Activities and Areas of Work within IETF/IRTF . . . . 5 65 5. Future Internet Architecture . . . . . . . . . . . . . . . . 6 66 6. Edge Network with no Tunneling . . . . . . . . . . . . . . . 8 67 7. Logical Network Isolation (Slicing) Concepts . . . . . . . . 9 68 8. Location Identification Separation and Naming . . . . . . . . 9 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 72 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 13.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 This document focuses on IP architecture and protocol aspects related 81 to upcoming new communication system infrastructure. This envisaged 82 5G system is foreseen to be available from 2020 onwards to provide a 83 converged Information and Communication Technology (ICT) ecosystem. 84 The offered broad spectrum of fixed and mobile services will be 85 characterised mainly by improved flexibility and efficient usage of 86 available resources to support services' demands with partially 87 contradicting requirements. A new highly re-configurable 88 architecture in both heterogeneous access and a converged core 89 network shall allow for key features as 91 o Stable selectable low latency 93 o Granted reliability and availability according to user and service 94 demands 96 o Potential (adaptive) mobility support (i.e. on demand): in case of 97 change in device or service location or as countermeasure to 98 partial failures /outage 100 o Low cost (i.e. affordable and related to service characteristics) 101 with respect to both investment and operational expenses: 102 efficiency in terms of resource consumption and effort 104 o Adaptive support of service quality in terms of (raw network) 105 performance and individual user experience (requiring end-to-end 106 monitoring and feedback) 108 o Selectable inbuilt security: different measures to be chosen from 109 a tool box 111 o Improved resource efficiency (e.g. in terms of energy consumption, 112 processing power, data storage, and radio spectrum usage) 114 o High flexibility for new services (and service features) 115 introduction and deployment 117 o Much better scalability in terms of amount of supported end 118 devices and transferred data rates and volume 120 o Higher bandwidth, data rate and throughput shall be achieved with 121 new radio technologies (multiple antennas) and usage of multiple 122 potentially heterogeneous technologies in concurrence 123 (multiaccess), bandwidth/ broadband access values exceeding 1Gbps. 125 A network to serve diverse demands ranging between very strict and 126 quite relaxed requirements asks for dynamic feature selection per 127 network functionality and thus will be much more software centric. 128 Only an architecture with modular control plane functions will enable 129 service tailored selection or adaptation of network characteristics 130 in terms of functionalities. 132 Also the expected high flexibility and resource efficiency demands 133 for exploitation of SDN and NFV together with computation and storage 134 space provision in central or distributed cloud environments. 136 In addition a new architecture with modular control plane functions 137 is required to enable service tailored selection or adaptation of 138 network characteristics in terms of functionalities. 140 Decoupling and abstraction of access and core domains to allow for 141 heterogeneity enabling higher flexibility and resource usage 142 efficiency is a request to 5G systems. 144 2. Problem Space and Typical Use Cases 146 The design of the new 5G system faces challenging requirements which 147 are derived from potential prospective services to be provisioned via 148 the 5G ecosystem. To illustrate the broad range of diverse demands 149 out of the plentitude of use cases as identified e.g. in [NGMN] a set 150 of three exemplary use case families is presented below following 151 [METIS]. 153 Generally all such services cannot and have not to be provided within 154 one specifically configured logical network. Flexibility to allow 155 different adaptations of the same physical infrastructure to fulfill 156 one tenants or verticals (service providers) requests is essential 157 for an appropriate 5G system concept. 159 2.1. Ubiquitous Broadband Access Use Case 161 These group of use cases covers fixed, portable, and mobile 162 applications between user equipment and servers in the network which 163 may be characterized by large bandwidth requirements, support of 164 moving devices, typical multimedia services between humans and 165 between humans and content in the network to only name a few. 167 2.2. Massive Deployment of Machines Use Case 169 The MTC or IoT use cases cover generally a large amount and dense 170 deployment of devices (sensors, metering) as smart grid or of 171 Industry 4.0 type, but also vehicular communication. 173 2.3. Critical Communications Use Case 175 Here a strict latency and reliability limit has to be considered 176 since services are time-critical or need high delivery probability. 178 3. Requirements to Future Communication Systems 180 Derived from the use case scenarios a list of requirements for 5G has 181 been established by several organisations as e.g. NGMN or 3GPP 182 denoting as key issues or key design principles or key drivers, for 183 details see e.g. 3GPP [TR23.799]. Also ITU has identified key 184 capabilities of IMT-2020, i.e. the International Mobile 185 Telecommunications (IMT) system for 2020 and beyond, which can be 186 found in [M.2083]. 188 Beside quantitatively measurable Expected enhancement of performance 189 parameters as 191 o User experienced data rate: 100 vs. 10 Mbit/s 192 o Spectrum efficiency 3 times that of IMT Advanced 194 o Mobility support for up to 500 km/h instead of 350 (only) 196 o Latency (of 1 vs. 10 ms), Latency down to 1ms could be foreseen 197 for 5G 199 o Connection density of 1 Million vs. 100000 devices/km ) 201 o Network energy efficiency of 100 times improved 203 o Area traffic capacity of 10 vs. 0.1 Mbit/s/m2 205 o Peak data rate of 20 instead of below 1 Gbit/s 207 Other key improvements which are not always direct quantitatively 208 measurable cover so-called soft features are also essential for 5G: 210 o Network scalability and flexibility 212 o Logical network separation (slicing) 214 o Consistent customer experience 216 o Service and network trust, reliability and security 218 o Operational efficiency 220 o Openness for innovation 222 4. Current Activities and Areas of Work within IETF/IRTF 224 Although a vertical topic as 5G is seen not as IETF topic ( providing 225 standardized building blocks for specific engineering challenges 226 "horizontals." IETF does not define or adapt "vertical" frameworks 227 like "Smart Cities," "Internet of Things," or "5G networks." It is 228 implicitly assumed that the participants will apply the building 229 blocks within the verticals 230 [I-D.arkko-ietf-trends-and-observations].), the topic creates issues 231 on multiple horizontal levels as is reflected within drafts and 232 discussions in WGs such as LISP (Locator/Identifier Separation 233 Protocol), NVO3 (Network Virtualization Overlays). Furthermore IRTF 234 RGs with focus on 5G topics are NFV(Network Function Virtualization), 235 SDN (Software Defined Networking), and ICN (Information Centric 236 Networking). 238 The current activities there contribute to one or more of the 239 following issues addressed in more detail during the preceding side 240 meetings of the 5GangIP mailing list archive. 242 5. Future Internet Architecture 244 Currently the efforts are in its beginning stages of defining, 245 designing or optimizing protocols for a more efficient internet to 246 provide mobility, scale, security and ease of deployment required for 247 a connected society beyond the year 2020. But the industry seems to 248 be divided by what should qualify as a true 5G. One approach to 5G 249 is: 251 5G radio + 4G Core (with improvements) 253 This approach takes 4G/LTE core, i.e. the current core network as 5G 254 core. However, what is in demand should be 256 5G radio + 5G Core 258 As a truly 5G, the real distinguisher lies in designing a new core to 259 meet the 5G requirements. The new core may also allow for connection 260 via enhanced 4G radio for reasons of operational continuity. 262 The current IP is connectivity-centric. Additional features such as 263 mobility and security are added as optional patches and fix-ups. 264 Moreover, protocols have been designed in a segmented way instead of 265 an architectural way. 267 Future Internet Architecture attempts to look at the current user/ 268 data plane protocol stack that is in use in both fixed and mobile 269 networks and redesign it. One issue the future internet architecture 270 addresses is the number of layers below the IP layer. 272 If we consider the current LTE radio protocol stack, we can easily 273 find that there are 6-plus layers, with PDCP, RLC, MAC and PHY being 274 the ones below IP layer. Each layer adds some bytes to the header, 275 some layers have their own checksums, i.e. more overhead. However, 276 in cellular Internet of Things, (IoT) a packet may have only 1 byte 277 payload. In this case, we would not call it efficient, the 278 efficiency rate is less than 1%, with the efficiency rate defined as 279 (payload length)/(packet size). 281 Future internet architecture deals with data plane protocol stack 282 reduction issues like: 284 Which layers could be reduced? 285 How can we deal with multiple checksums, since it is very expensive 286 to compute checksums, remembering we only have 1ms latency budget? 288 Should we design a new type of protocol that does not reuse the 289 existing ones to make the network more efficient? Such a clean slate 290 approach would expose a high degree of disruption. 292 What would happen if we take away GTP, LTE's tunneling protocol? For 293 more discussion on this see Section 6. 295 Future internet architecture proposes a unified layering for both 296 fixed and mobile networks. In the IP layer, we have Identifier 297 Oriented Networking or IP protocol. Below this, we have the next 298 generation medium access control protocol providing a unified medium 299 access to 5G radio, 802.11 or Wi-Fi and Ethernet type of fixed access 300 technologies. The lowest layer is the next generation physical layer 301 protocol unifying all physical accesses to 5G-era. 303 In the control plane, there are even much more we need to consider. 304 For example, the current internet is operated by routing protocols 305 and their extensions. These protocols are usually driven by Command 306 Line Interfaces (CLIs) on the first hand, e.g. for protocols like 307 OSPF [RFC5340] will work as instructed by the commands in CLI. 309 However, in 5G, there will be many moving things, perhaps with low- 310 power so that at one instant they are up and at the next instant they 311 are down. The traditional operation model won't work any more, since 312 we can't easily configure them and we don't want their mobility and 313 status change affecting the routing tables, Routing Information Base 314 (RIB) frequently. 316 In this case, mobility issue will arise. A cell phone moves, but its 317 identifier (ID) does not change. Can LISP-mobile [I-D.meyer-lisp-mn] 318 based on LISP [RFC6830] be used for this use case, i.e. also handle 319 e.g. session continuity in case of multi-connectivity? Which 320 further extensions and modifications might be needed to re-scope the 321 approach to apply for the required mobility? ID plays a central role 322 in mobility. Can we design a new protocol, say ID-Oriented 323 Networking Protocol? In future, more and more mobile things are 324 connected to the internet which may not yet have proper identifiers 325 available compared to cell phones (see e.g. 326 [I-D.ietf-dmm-4283mnids]): things like connected cars, connected 327 drones, etc. 329 For more discussion on this see Section 8. 331 6. Edge Network with no Tunneling 333 In fixed network, PPPoE protocol [RFC2516] is used between the 334 residential gateway and broadband network gateway to transport the 335 residential users IP packets to the fixed network gateway to the 336 Internet. PPPoE protocol requires 8 octets of header in every IP 337 packet, thereby reducing the MTU size by 8 octets to usually 1492 338 octets. PPPoE protocol is carried in Ethernet frames with 18 octet 339 headers where the destination address is the broadband network 340 gateway address. 342 Aiming at an IP protocol unaware/agnostic/overarching control plane 343 logic multiple protocol approches can be deployed depending on actual 344 service and slice demands, such as e.g. those based on low-overhead 345 translation mechanisms and encapsulation-based ones on the other 346 hand. If a client-based mapping between Identifier and Locator is 347 required (i.e. executed on a user terminal) translation would be the 348 recommended approach. For network-centric deployment a LISP-like 349 mapping function on gateways or the session terminating servers and 350 data centers can be deployed. How such a control plane could look 351 like on L2/L3 to support LISP has recently been described in 352 [I-D.portoles-lisp-eid-mobility]. 354 In mobile network, IP packets are tunneled using GTP data plane 355 protocol called GTP-U. First eNodeB or the base station tunnels UE's 356 IP packets to the Serving Gateway, in S1 GTP tunnel and then the 357 serving gateway tunnels to the Packet Gateway, called S5 tunnel. 358 Both of them are UDP tunnels which adds 8 octet header and GTP 359 protocol header is 12 octets, so a total of 20 octets are used. In 360 addition also an IPSec header should be accounted for between eNodeB 361 and SGW. 363 On the other hand in an end-to-end path between UEs or towards the 364 Application Function the network has either to keep a lot of status 365 information (meta data) for finding and maintaining the optimum path 366 - or apply encapsulation with specific headers between eNB and SGW/ 367 PGW - as tunneling. As exemplarily shown above, however, tunneling 368 adds a lot of overhead to the user IP packets and therefore 369 inefficiencies arise including reducing the MTU size. 371 If tunneling can be avoided, i.e. if edge networks can be designed 372 with no tunneling, a corrollary of this would be no gateways would be 373 needed, leading to edge networks with no tunneling or no gateway. 374 The means to avoid gateways and tunneling a direct end-to-end routing 375 has to be established in the edge network. 377 With routing support edge networks can direct the user traffic to the 378 correct destinations, rather than tunneling to the gateways. In 379 order to deal with user mobility, ID-oriented networking protocol 380 would be needed. So it needs to be evaluated if using ID-oriented 381 networking protocol with routing will lead to more efficient delivery 382 of user IP packets in the edge network compared with 4G edge network 383 techniques of tunneling with gateways. 385 As we deal with carrier-grade networks here also the aspects of AAA 386 and charging have to be considered. The main reason why tunneling is 387 used in 4G edge networks and broadband network is to direct the user 388 traffic so that the operator can charge the user properly. Edge 389 networks with no gateways should enable enough control to the 390 operators so that charging on the user traffic is properly conducted. 392 Optimum use of available resources may also require a common control 393 framework including e.g. user plane communication between devices 394 directly or via relays / access nodes only. How such an efficient, 395 scalable, and performant solution in case of mobility has to be 396 designed - preferably without much effort due to complex state 397 handling - is one of the challenging questions. 399 7. Logical Network Isolation (Slicing) Concepts 401 Within the framework of 5G a network slice is seen as an independent 402 logical end-to-end network, defined by a set of specific network 403 functions providing service-specific network characteristic 404 (performance). The basic Network Functions can be both physical and 405 virtual in nature, and comprise C-plane and D-plane tasks (maybe 406 supplemented by Management), and should be independently instantiated 407 and operated. Identified related work in IETF on aspects of single 408 virtualized network control cover the ACTN (Abstraction and Control 409 of Traffic Engineered Networks) activity in TEAS (Traffic Engineering 410 Architecture and Signaling) WG. 412 Corresponding discussion is also under way in IRTF NFVRG analysing 413 gaps of current approaches with respect to virtual network instances' 414 operation and inter-operation. 416 8. Location Identification Separation and Naming 418 With both physical and logical mobility of (an extremely high number 419 of) entities and virtualization of network functions the traditional 420 usage of IP addresses for denoting both IDentifier and Address or 421 logical entity and location as source or destination of data packets 422 becomes cumbersome. New approaches to solve the issues are proposed 423 in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also 424 ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge. 426 By separating a Routing LOCator (RLOC) from a unique Identity (EID) 427 LISP keeps a single address to each session endpoint even in multi- 428 homing but requires a dedicated mapping mechanism for compatibility 429 with the (LISP-unaware) Internet. ILNP (and ILNP-based ILA) avoid 430 encapsulation and require no changes in higher layers (except the 431 transport layer) re-using part of an (IPv6) Address as Identifier and 432 Locator. ILA does not require any changes in transport layer but it 433 is IPv6 only. 435 In LISP the EID/RLOC split can be collocated in the same entity: EID 436 mobile, RLOC static or dynamic. Predictive RLOCs 437 [I-D.farinacci-lisp-predictive-rlocs] can be used if LISP entity 438 knows where the user going so that the system can mitigate mobility 439 impacts. LISP can be used between the Serving and Packet data 440 Gateways. Best solution is to keep LISP close to the moving entity 441 with the functions as close to the edge as possible. 443 ILNP defines minimal changes on IPv4 and IPv6, it requires changes on 444 the domain name system and the transport layer [RFC6740]. Both ILNP 445 and ILNP-based ILA rely on the routing system or LTE core network to 446 route to the translated address. 448 LISP requires routing system changes, it is implemented on the 449 routers, possibly on the edge routers. That means LISP requires 450 changes on LTE core network. ILNP does not use encapsulation so it 451 is light weight. LISP is UDP encapsulated so in IPv6, LISP messages 452 incur 52 bytes of overhead. 454 ILNP nodes send Locator Update messages which are ICMPv4/v6 messages 455 to its correspondent nodes when its Locator value changes during an 456 active session. Correspondent node could be a fixed node such as 457 Google server which means ILNP has to be implemented by the fixed 458 nodes as well. 460 ILA is a major update to ILNP [I-D.herbert-nvo3-ila]. It is 461 originally designed for network virtualization to be used in cloud 462 networks. ILA can encode a virtual network identifier (VNID) and 463 virtual address as an ILNP identifier. ILA can be adopted for 464 mobility and it can be applied to LTE network, the result can be 465 called mobile-ILA. This effort is undergoing. These aspects of ILA 466 are described in [I-D.mueller-ila-mobility]. An open question here 467 is to use a proper mapping system which is more efficiently scalable 468 and responsive to frequent updates than DNS which originally was not 469 designed for mobility [I-D.padma-ideas-problem-statement] . 471 As already mentioned in Section 5 LISP aspects relevant for mobility 472 support are described in [I-D.meyer-lisp-mn]. 474 To summarize for IDentifier/Locator split three protocols are under 475 discussion which provide improved data/user plane routing as 476 candidates: 478 o ILA as a host-based solution that uses translation. 480 o ILNP as a host or router based solution that uses translation. 482 o LISP as a host or router based solution that uses encapsulation. 484 Also a combination of ILA and LISP to serve both host- and network- 485 based multi-homing across multiple domains can be thought of. 487 These protocols may also serve as the basis of an ID-oriented 488 networking protocol for 5G yet to be designed and standardized. 490 As none of the mentioned existing proposals fully covers the 5G 491 requirements consistently, in this document, the authors propose the 492 following steps for investigations on further enhancements that have 493 to be performed. 495 Problem statement on the need for ID-oriented networking protocol, 496 exploiting LISP, ILNP and ILA efforts. 498 Requirements on a new ID-oriented network protocol in view of 5G 499 requirements such as in Section 3, and issues such as in Section 6. 501 A document on possible solution space investigations. 503 9. IANA Considerations 505 None. 507 10. Security Considerations 509 Security considerations related to the 5G systems are discussed in 510 [NGMN]. Due to the request for intrinsic realization of security 511 such aspects have to be considered by design for architecture and 512 protocols. 514 11. Privacy Considerations 516 Support of full privacy of the users (customers and tenants / end 517 service providers) is a basic feature of the next generation trusted 518 and reliable communications offering system. Such a high degree of 519 ensured privacy shall be reflected in the proposed architecture and 520 protocol solutions (details have to be added). 522 Especially as Identifiers and mapping of locators to them are 523 addressed the discussion on identifier and privacy should consider 524 existing solutions such as 3GPP Globally Unique Temporary UE Identity 525 (GUTI) which is a temporary identity obfuscating the permanent 526 identity in the mobile network and specified in [TS23.003]. 528 12. Acknowledgements 530 This work has been partially performed in the framework of the 531 cooperation Config. Contributions of the project partners are 532 gratefully acknowledged. The project consortium is not liable for 533 any use that may be made of any of the information contained therein. 535 Comments and careful review by Dino Farinacci as well as 536 contributions by Tom Herbert, Julius Mueller, Robert Moskowitz and 537 others of the 5GangIP mailing list are gratefully acknowledged. 539 13. References 541 13.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 13.2. Informative References 550 [I-D.arkko-ietf-trends-and-observations] 551 Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O., 552 olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R. 553 White, "IETF Trends and Observations", draft-arkko-ietf- 554 trends-and-observations-00 (work in progress), February 555 2016. 557 [I-D.farinacci-lisp-predictive-rlocs] 558 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 559 RLOCs", draft-farinacci-lisp-predictive-rlocs-00 (work in 560 progress), May 2016. 562 [I-D.herbert-nvo3-ila] 563 Herbert, T., "Identifier-locator addressing for IPv6", 564 draft-herbert-nvo3-ila-03 (work in progress), October 565 2016. 567 [I-D.ietf-dmm-4283mnids] 568 Perkins, C. and (. (Unknown), "MN Identifier Types for RFC 569 4283 Mobile Node Identifier Option", draft-ietf-dmm- 570 4283mnids-03 (work in progress), November 2016. 572 [I-D.meyer-lisp-mn] 573 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 574 Mobile Node", draft-meyer-lisp-mn-15 (work in progress), 575 July 2016. 577 [I-D.mueller-ila-mobility] 578 Mueller, J. and T. Herbert, "Mobility Management for 5G 579 Network Architectures Using Identifier-locator 580 Addressing", draft-mueller-ila-mobility-01 (work in 581 progress), October 2016. 583 [I-D.padma-ideas-problem-statement] 584 Pillay-Esnault, P., Farinacci, D., Meyer, D., Lake, D., 585 Herbert, T., Menth, M., Raychadhuri, D., and J. Mueller, 586 "Problem Statement for Mapping Systems in Identity Enabled 587 Networks", draft-padma-ideas-problem-statement-00 (work in 588 progress), September 2016. 590 [I-D.portoles-lisp-eid-mobility] 591 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 592 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 593 Unified Control Plane", draft-portoles-lisp-eid- 594 mobility-01 (work in progress), October 2016. 596 [M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and 597 overall objectives of the future development of IMT for 598 2020 and beyond", September 2015. 600 [METIS] Elayoubi, S. and et al., "5G Service Requirements and 601 Operational Use Cases: Analysis and METIS II Vision", 602 Proc. euCNC, 2016. 604 [NGMN] NGMN Alliance, "NGMN White Paper", February 2015. 606 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 607 and R. Wheeler, "A Method for Transmitting PPP Over 608 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 609 February 1999, . 611 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 612 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 613 . 615 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 616 Protocol (ILNP) Architectural Description", RFC 6740, 617 DOI 10.17487/RFC6740, November 2012, 618 . 620 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 621 Locator/ID Separation Protocol (LISP)", RFC 6830, 622 DOI 10.17487/RFC6830, January 2013, 623 . 625 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 626 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 627 "Information-Centric Networking: Baseline Scenarios", 628 RFC 7476, DOI 10.17487/RFC7476, March 2015, 629 . 631 [TR23.799] 632 "3GPP TR23.799, Study on Architecture for Next Generation 633 System (Release 14)", October 2016. 635 [TS23.003] 636 "3GPP TS23.003, Numbering, addressing and identification 637 (Release 14)", September 2016. 639 Authors' Addresses 641 Dirk von Hugo 642 Telekom Innovation Laboratories 643 Deutsche-Telekom-Allee 7 644 D-64295 Darmstadt 645 Germany 647 Email: Dirk.von-Hugo@telekom.de 649 Behcet Sarikaya 650 Huawei 651 5340 Legacy Dr. 652 Plano, TX 75024 654 Email: sarikaya@ieee.org