idnits 2.17.1 draft-xyx-5gip-ps-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 1 character in excess of 72. 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 (May 2, 2017) is 2549 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arkko-ietf-trends-and-observations' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-predictive-rlocs' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-4283mnids' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'I-D.portoles-lisp-eid-mobility' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'METIS' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC2516' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC7476' is defined on line 573, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-farinacci-lisp-predictive-rlocs-01 == Outdated reference: A later version (-08) exists of draft-ietf-dmm-4283mnids-04 == Outdated reference: A later version (-05) exists of draft-kanugovi-intarea-mams-protocol-04 == Outdated reference: A later version (-02) exists of draft-zhu-intarea-mams-control-protocol-01 == Outdated reference: A later version (-09) exists of draft-zhu-intarea-mams-user-protocol-01 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 16 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 Deutsche Telekom - Technology Innovation 4 Intended status: Informational B. Sarikaya 5 Expires: November 3, 2017 Huawei 6 T. Herbert 7 Quantonium 8 K. Satish 9 Nokia 10 R. Schott 11 Deutsche Telekom 12 May 2, 2017 14 5G IP Access Mobility and Session Management Protocols 15 draft-xyx-5gip-ps-00 17 Abstract 19 This document builds upon 5G IP issues work and - based on a 20 simplified 5G system architecture - attempts to make the case for a 21 possible set of new protocols that need to be developed to be used 22 among various virtualized functions in a 5G network. 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 November 3, 2017. 41 Copyright Notice 43 Copyright (c) 2017 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3 61 4. Access Management Protocols . . . . . . . . . . . . . . . . 6 62 5. Mobility Management Protocols . . . . . . . . . . . . . . . . 8 63 6. Session Management Protocols . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 11.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Current networking infrastructure is moving towards a converged 76 common core network serving wireline and wireless access networks to 77 which the end users are connected. Such a network if realized in 78 terms of 5G project being undertaken worldwide is expected to meet 79 the stringent requirements discussed in 80 [I-D.vonhugo-5gangip-ip-issues]. 82 In this document we elaborate upon 5G system architecture which is 83 composed of modularised adaptable network functions of control plane 84 and data plane and their interconnections. Much of this 85 functionality is expected to be implemented as virtualized functions 86 running in central and/or distributed computation environment (cloud) 87 as well as traditional physical entities in parallel. 89 We discuss IP level protocols that need to be developed. The 90 discussion is based on and builds upon our existing documents on 91 mobility management and access management. Identifier Locator 92 Addressing (ILA) protocol is designed as a data plane protocol for 93 task communication and migration in L3 based data center networks 94 [I-D.herbert-nvo3-ila]. ILA can also be used in user mobility. This 95 aspect of ILA is investigated in [I-D.mueller-ila-mobility] by 96 attempting to apply it directly to 4G 3GPP Evolved Packet System 97 (EPS). 99 Regarding access management, a framework allowing clients and 100 networks in a multi-network scenario to negotiate combination of 101 uplink and downlink paths taking into account client's application 102 needs and network conditions has been developed in 103 [I-D.kanugovi-intarea-mams-protocol]. A control plane protocol for 104 configuring the user plane in a multi access management framework 105 that can be used to flexibly select the combination of uplink and 106 downlink access and core network paths is described in 107 [I-D.zhu-intarea-mams-control-protocol]. A data plane protocol for 108 multiplexing end to end connections is described in 109 [I-D.zhu-intarea-mams-user-protocol] using trailer approach. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Converged Access-Agnostic Core Network 119 Key principles and concepts in 5G system architecture include 120 separation of User Plane (UP) functions from the Control Plane (CP) 121 functions, allowing independent scalability, evolution, and a 122 flexible deployment at e.g. centralised location or distributed 123 (remote) locations; the concept relies on a new definition of the 124 network functions, e.g. to enable flexible and efficient provision of 125 logically separated network slices. Network slicing with slice 126 instantiations that may include components served by fixed networks 127 is another innovation in 3GPP 5G system architecture as well as the 128 definition of a common core network which is access agnostic. 129 Wherever applicable, procedures (i.e. the set of interactions between 130 network functions) are defined as services, so that their re-use is 131 possible. Each Network Function can interact with the other NF 132 directly if required. The architecture does not preclude the use of 133 an intermediate function to help route control plane messages. On 134 the other hand, the architecture shall be flexible enough to allow 135 for hassle-free introduction of newly specified network services if 136 required by a specific network slice for a prospective new use case. 138 Currently network infrastructure is being transformed into two-layer 139 data center or cloud as Core Network (CN) and the Access Network (AN) 140 which mainly accommodates 5G radio access network on the wireless 141 side and central office on the wireline network closer to the user. 142 This new architecture enables us to flexibly deploy 5G Virtual 143 Network Functions (VNFs) based on the service scenarios. The 144 division of work in this case is to deploy 5G control plane VNFs and 145 5G data plane VNFs with related applications in both the central core 146 cloud and distributed local edge clouds. 148 Especially for new ultra low latency services offering vehicular 149 communications a placement of both user data plane functions (e.g. 150 caches or anchors) and corresponding control plane tasks (e.g. 151 activating and monitoring them) near the points of attachment (e.g. 152 road side radio antennas) may be required. 154 These Network Function names as defined in current version of draft 155 3GPP specifications are given here exemplarily and shall serve for 156 illustrative purposes. The final version of the architecture is 157 still under discussion. 159 5G system architecture is based on a complete system operation 160 including policy control, authentication, quality of service (QoS), 161 subscriber profiles and charging which are not of interest to us in 162 this document. Based on this abstraction we can simplify the 163 architecture with the elimination of the corresponding network 164 functions and their interconnections. The resulting simplified 165 system architecture is shown in Figure 1. The rectangles are the 166 network functions and the lines are their interconnections. Network 167 Function names are given on the right hand side. 169 +---+ +---+ 170 ________|AMF|-----|SMF| 171 / +---+ +---+ 172 / / / 173 / / / Access and Mobility 174 / / / Function (AMF) 175 / / / Session Management 176 / / / Function (SMF) 177 / / / Data Network, e.g. 178 / / / Internet (DN) 179 +--+ +-----+ +---+ /---\ User Equipment(UE) 180 |UE|-----|(R)AN|--------|UPF|------ | DN | (Radio)Access Network ((R)AN) 181 +--+ +-----+ +---+ \---/ User Plane Function (UPF) 183 Figure 1: Simplified 5G System Architecture 185 Access and Mobility Management Function (AMF) is in charge of 186 registration management, connection management, reachability 187 management, mobility management. It does access authentication and 188 access authorization. 190 Session Management Function (SMF) is in charge of session 191 establishment, modify and release, including tunnel maintenance 192 between UPF and the access network (AN) node (if applicable). UE IP 193 address allocation and management (incl. optional authorization), 194 selection and control of the user plane (UP), i.e. data plane 195 function. SMF configures traffic steering at UPF to route traffic to 196 proper destination (i.e. the corresponding Data Network, DN); 197 initiator of AN specific SM information, sent via AMF to AN; support 198 for interaction with external DN for transport of signalling for PDU 199 session authorization/authentication by external DN. 201 User Plane Function (UPF) is anchor point for mobility; external PDU 202 session point of interconnect to Data Network; Packet routing and 203 forwarding; Packet inspection and User plane part of Policy rule 204 enforcement; uplink classifier to support routing traffic flows to a 205 data network; branching point to support multi-homed PDU session; 206 transport level packet marking in the uplink and downlink; downlink 207 packet buffering and downlink data notification triggering. 209 The reference points in the original 5G system architecture 210 [TR23.501], [TR23.502] usually carry a specific protocol such as GTP 211 (GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g. 212 over N3) or Non-Access Stratum (NAS) of 3GPP. Access and Mobility 213 Management Function (AMF) is the Network Function (NF) that 214 terminates N1 and N2. User Plane Function (UPF) is the NF that 215 terminates N3. N1 which is the reference point between UE and AMF 216 represents interactions going over (R)AN but these interactions are 217 transparently relayed by (R)AN. That is the difference between N1 218 and N2 which is the reference point between (R)AN and AMF. 220 According to 5G architecture, 5G UE is expected to use Non-Access 221 Stratum (as opposed to Access-Stratum (AS) which is used between 222 access network and UE) signaling for establishment of communication 223 sessions and for maintaining continuous communications with the user 224 equipment as it moves in 5G core network even when UE is connected to 225 5G core network via a non-3GPP access network, e.g. over Wi-Fi, 226 oftentimes simultaneously to the wireless radio access network (RAN). 227 Some of the procedures for the 5G system being defined in [TR23.502] 228 are to be used in establishing an IP link, like Non-Access Stratum 229 signaling. Such link layer aspects of 5G System Architecture are out 230 of scope. 232 In the simplified 5G system architecture, our interest in this 233 document is to use IETF protocols in the interconnection points shown 234 in Figure 1. The goals of the work will involve: 236 o Align with the identifier usage, e.g. 64-bit identifier for UE, 237 e.g. International Mobile Subscriber Identity (IMSI) 239 o Adopt the same network functions, e.g. Access and mobility 240 Management Function, Session Management Function (SMF), User Plane 241 Function (UPF) 243 o Address multiple access issue in the access management and also 244 session management 246 o Adopt the identifier locator addressing protocol which does not 247 involve tunneling for mobility management 249 o Define address allocation function of the session management as 250 part of the mobility management protocol 252 o Define session and service continuity as part of the session 253 management 255 One of the challenges in 5G FMC is how to provide seamless mobility 256 when 5G UE while in a 5G radio access network later moves to an area 257 of served by a Wi-Fi access point connected to a central office 258 within the fixed network while both access networks are served by a 259 converged common core. Another challenge is to enable flexible and 260 seamless management of the user sessions while accessing the network 261 sometimes simultaneously over UE's multiple interfaces, e.g. 5G and 262 Wi-Fi. 264 In the next sections, we discuss access (Section 4) and mobility 265 (Section 5) and session (Section 6) management protocols that need to 266 be developed in order to satisfy the key features and requirements of 267 the upcoming 5G networks described in 268 [I-D.vonhugo-5gangip-ip-issues]. These protocols will be defined to 269 be potentially used in the interconnections of the virtualized 270 network functions shown in Figure 1. 272 4. Access Management Protocols 274 An investigation of multiple access management for a UE that 275 simultaneously connects to multiple data networks is presented in 276 [I-D.kanugovi-intarea-mams-protocol]. 278 [I-D.kanugovi-intarea-mams-protocol] sets forward the requirements 279 such as enabling connectivity using different access networks. The 280 network path selection and user data distribution should work 281 transparently. Access path selection should be independent for 282 Uplink and Downlink. A common core network independent of the access 283 networks should be accessed by the UE. Network path selection should 284 be adaptive to the link quality. Distribution and aggregation of 285 user data across multiple network paths at the IP layer should be 286 supported. Heterogeneous access networks, which may have different 287 MTU sizes should be supported using concatenation and fragmentation. 289 Based on these requirements, control and data plane functions for 290 connection management can be determined. Network Connection Manager 291 (NCM) is the control plane function. There is a data plane component 292 for user data traffic forwarding called Network Multi-Access Data 293 Proxy (MADP) which is part of the User Plane Function (UPF) in 294 Figure 1. It can be argued that we also need corresponding client 295 side counter part of NCM, called CCM and MADP hosted on the UE. 296 Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the 297 core network handles the user data traffic forwarding across multiple 298 network paths, as well as other user-plane functionalities, e.g. 299 encapsulation, fragmentation, concatenation, reordering, 300 retransmission, etc. N-MADP is the distribution node for uplink and 301 downlink data with visibility of packets at the IP layer. 303 Network Connection Manager (NCM) in the core network configures 304 identification and distribution rules for different user data traffic 305 type at the N-MADP. The NCM configures the routing in the MADP based 306 on signaling exchanged with the CCM in UE. In the uplink, NCM 307 specifies the core network path to be used by MADP to route uplink 308 user data at the MADP. In the downlink, NCM specifies the access 309 links to be used for delivery of data to the client at the MADP. 311 At the UE, MADP handles encapsulation, fragmentation, concatenation, 312 reordering, retransmissions, etc. C-MADP is configured by CCM based 313 on signaling exchange with NCM and local policies at the UE. 315 At the UE, CCM manages the multiple network connections. CCM is 316 responsible for exchange of MAMS signaling messages with the NCM for 317 supporting functions like configuring uplink and downlink user 318 network paths for transporting user data packets, link sounding and 319 reporting to support adaptive network path selection by NCM. In the 320 downlink, for the user data received by UE, it configures IP layer 321 forwarding for application data packets received over any of the 322 accesses to reach the appropriate application module on the client. 323 In the uplink, for the data transmitted by UE, it configures the 324 routing table to determine the best access to be used for uplink data 325 based on a combination of local policy and network policy delivered 326 by the NCM. 328 IP level protocols need to be developed supporting connection 329 management in a 5G IP network. An example is the trailer based 330 approach integrating multiple connections into a single end to end IP 331 connection. A multiplexing trailer is added to the end of IP payload 332 to flexibly support concatenation and fragmentation. 334 [I-D.zhu-intarea-mams-user-protocol] gives an earlier 4G approach, 335 there could possibly be other similar approaches. 337 5. Mobility Management Protocols 339 Next, we discuss mobility management. Anchor-less mobility in a 5G 340 fixed mobile convergence network with a converged core network 341 possibly based on identifier and locator separation should be the 342 preferred approach as opposed to tunneling approaches with fixed 343 anchors, e.g. or with distributed anchors. 345 The prospective approach is to overcome tunneling and encapsulation 346 overhead explained in detail in [I-D.vonhugo-5gangip-ip-issues] by 347 simplified routing in the edge network according to identifiers not 348 bound to locations and thus allowing for relocation within underlying 349 infrastructure. Such an approach should also incorporate session 350 management in support of session and service continuity in the 5G 351 architecture with a common core enabling mobility in multiple access 352 networks. 354 Anchor points perform important duties such as policy, accounting 355 etc. as well as mapping that cannot be ignored. In anchor-less 356 mobility, without anchor points, UE is the only common device in the 357 path to perform these functions. When anchors are removed then it 358 becomes a challenge to provide functions like security and trust. 359 One option is to use the UE as the only remaining single anchor point 360 to perform its own accounting and policy and other functions. 362 There are secure execution environments/processors in UE's these 363 days, where all the finger print recognition, password encryption 364 etc. is done and perhaps it is possible to extend these to run secure 365 network functions on behalf of the slices. However, a trusted 366 federation between any UE and the corresponding/accessible network 367 entities cannot be assumed without doubt in any case. In view of 368 this, virtualizing and distributing anchor point functions, e.g. 369 mapping identifiers to the most recent locators, security 370 associations (SA), etc. so they can run in the network at the points 371 of attachment close to the UE will need to be investigated. 373 Transport protocol level independence is a strong requirement in 374 identifier locator separation based mobility protocols. This means 375 that UE can have a locator or address but it should not be used as 376 connection end point. The identifier which may not be routable 377 should be used as the connection end point. This enables no 378 modifications at the transport layer in the host stack. 380 Based on the requirements, Identifier Locator Addressing (ILA) 381 protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base 382 protocol. IPv6 operation in the current ILA need to be improved in 383 order to be used by the end nodes such as the UEs. Mobility 384 procedures in the control plane need to be defined. ILA design is 385 influenced by UE prefix/address allocation and management which is 386 part of Session Management function. Therefore the two functions 387 need to be designed in an integrated fashion. 389 Multihoming, UEs with more than one network interfaces should be 390 supported including simultaneous usage of the interfaces to connect 391 to multiple access networks. ILNP [RFC6740] supports multihoming. 392 ILA support could be similarly designed. 394 6. Session Management Protocols 396 Session management responsible for the setup of the connectivity for 397 the UE as well as managing the user plane for that connectivity is 398 identified as one of the key issues in 5G system architecture in 399 [TR23.799]. Session management design issues include managing 400 multiple access, multiple connectivity, multiple transport paths, 401 e.g. to RAN and to non-3GPP access network (AN), sometimes 402 simultaneously and how to efficiently transmit and receive infrequent 403 small amounts of data and short data bursts, e.g. for Narrow Band 404 Internet of Things (NB-IoT). 406 The challenges of this kind of session management design include if 407 such a design can be simplified so that NB-IoT type of very simple 408 sessions can also be handled. Regarding SMF and AMF, identifying the 409 correlation between session management and mobility management, 410 identifying the interactions between session management and the 411 mobility framework required to enable the various mobility scenarios 412 while minimizing any negative impact on the user experience 413 investigating solutions to coordinate the relocation of user-plane 414 flows with the relocation of applications (hosted close to the point 415 of attachment of the UE) due to the mobility of users can be 416 considered as the challenges of 5G architecture. 418 Network layer or IP session normally has two components: source IP 419 address and destination IP address. In case identifier locator 420 separation protocol is used IP session has four components source 421 locator, source identifier, destination locator and destination 422 identifier. With transport layer independence IP session should be 423 composed of source identifier and destination identifier only. 425 Session management deals with IP address management. SMF performs IP 426 address allocation. Both IPv4 and IPv6 should be supported. In an 427 identifier locator separation system, IPv4 can be supported 428 transparently by keeping the communication in IPv6 and converting the 429 addresses at the end points. 431 Session continuity in the case of UE mobility should be provided. In 432 an anchorless system, UE mobility incurs changes to the locators. 433 Session management should maintain the established sessions when the 434 UE moves. This also involves informing the destinations of the 435 locator change. This is done in the control plane of the mobility 436 management. 438 7. IANA Considerations 440 None. 442 8. Security Considerations 444 Security considerations related to the 5G systems are discussed in 445 [NGMN]. Due to the request for intrinsic realization of security 446 such aspects have to be considered by design for architecture and 447 protocols. 449 Especially as a joint usage of resources and network functions by 450 different separate logical network slices (e.g. in terms of virtual 451 network functions) seems to be inevitable in the framework of 5G the 452 need for strong security measures in such an environment is a major 453 challenge. 455 9. Privacy Considerations 457 Support of full privacy of the users (customers and tenants / end 458 service providers) is a basic feature of the next generation trusted 459 and reliable communications offering system. Such a high degree of 460 ensured privacy shall be reflected in the proposed architecture and 461 protocol solutions (details have to be added). 463 Especially as Identifiers and mapping of locators to them are 464 addressed the discussion on identifier and privacy should consider 465 existing solutions such as 3GPP Globally Unique Temporary UE Identity 466 (GUTI) which is a temporary identity obfuscating the permanent 467 identity in the mobile network and specified in [TS23.003]. 469 10. Acknowledgements 471 This work has been partially performed in the framework of the 472 cooperation Config. Contributions of the project partners are 473 gratefully acknowledged. The project consortium is not liable for 474 any use that may be made of any of the information contained therein. 476 11. References 478 11.1. Normative References 480 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 481 Requirement Levels", BCP 14, RFC 2119, 482 DOI 10.17487/RFC2119, March 1997, 483 . 485 11.2. Informative References 487 [I-D.arkko-ietf-trends-and-observations] 488 Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O., 489 olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R. 490 White, "IETF Trends and Observations", draft-arkko-ietf- 491 trends-and-observations-00 (work in progress), February 492 2016. 494 [I-D.farinacci-lisp-predictive-rlocs] 495 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 496 RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in 497 progress), November 2016. 499 [I-D.herbert-nvo3-ila] 500 Herbert, T. and P. Lapukhov, "Identifier-locator 501 addressing for IPv6", draft-herbert-nvo3-ila-04 (work in 502 progress), March 2017. 504 [I-D.ietf-dmm-4283mnids] 505 Perkins, C. and V. Devarapalli, "MN Identifier Types for 506 RFC 4283 Mobile Node Identifier Option", draft-ietf-dmm- 507 4283mnids-04 (work in progress), January 2017. 509 [I-D.kanugovi-intarea-mams-protocol] 510 Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng, 511 S., Mueller, J., and S. Seo, "Multiple Access Management 512 Services", draft-kanugovi-intarea-mams-protocol-04 (work 513 in progress), March 2017. 515 [I-D.mueller-ila-mobility] 516 Mueller, J. and T. Herbert, "Mobility Management Using 517 Identifier Locator Addressing", draft-mueller-ila- 518 mobility-03 (work in progress), February 2017. 520 [I-D.portoles-lisp-eid-mobility] 521 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 522 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 523 Unified Control Plane", draft-portoles-lisp-eid- 524 mobility-02 (work in progress), April 2017. 526 [I-D.vonhugo-5gangip-ip-issues] 527 Hugo, D. and B. Sarikaya, "Review on issues in discussion 528 of next generation converged networks (5G) from an IP 529 point of view", draft-vonhugo-5gangip-ip-issues-03 (work 530 in progress), March 2017. 532 [I-D.zhu-intarea-mams-control-protocol] 533 Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng, 534 S., and S. Seo, "Control Plane Protocols and Procedures 535 for Multiple Access Management Services", draft-zhu- 536 intarea-mams-control-protocol-01 (work in progress), March 537 2017. 539 [I-D.zhu-intarea-mams-user-protocol] 540 Zhu, J. and S. Seo, "User-Plane Protocols for Multiple 541 Access Management Service", draft-zhu-intarea-mams-user- 542 protocol-01 (work in progress), March 2017. 544 [M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and 545 overall objectives of the future development of IMT for 546 2020 and beyond", September 2015. 548 [METIS] Elayoubi, S. and et al., "5G Service Requirements and 549 Operational Use Cases: Analysis and METIS II Vision", 550 Proc. euCNC, 2016. 552 [NGMN] NGMN Alliance, "NGMN White Paper", February 2015. 554 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 555 and R. Wheeler, "A Method for Transmitting PPP Over 556 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 557 February 1999, . 559 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 560 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 561 . 563 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 564 Protocol (ILNP) Architectural Description", RFC 6740, 565 DOI 10.17487/RFC6740, November 2012, 566 . 568 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 569 Locator/ID Separation Protocol (LISP)", RFC 6830, 570 DOI 10.17487/RFC6830, January 2013, 571 . 573 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 574 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 575 "Information-Centric Networking: Baseline Scenarios", 576 RFC 7476, DOI 10.17487/RFC7476, March 2015, 577 . 579 [TR23.501] 580 "3GPP TR23.501, System Architecture for the 5G System 581 (Release 15)", December 2017. 583 [TR23.502] 584 "3GPP TR23.502, Procedures for the 5G System (Release 585 15)", December 2017. 587 [TR23.799] 588 "3GPP TR23.799, Study on Architecture for Next Generation 589 System (Release 14)", December 2016. 591 [TS23.003] 592 "3GPP TS23.003, Numbering, addressing and identification 593 (Release 14)", September 2016. 595 Authors' Addresses 597 Dirk von Hugo 598 Deutsche Telekom - Technology Innovation 599 Deutsche-Telekom-Allee 7 600 D-64295 Darmstadt 601 Germany 603 Email: Dirk.von-Hugo@telekom.de 605 Behcet Sarikaya 606 Huawei 607 5340 Legacy Dr. 608 Plano, TX 75024 610 Email: sarikaya@ieee.org 611 Tom Herbert 612 Quantonium 614 Email: tom@herbertland.com 616 K Satish 617 Nokia 619 Email: satish.k@nokia.com 621 Roland Schott 622 Deutsche Telekom 624 Email: roland.schott@telekom.de