idnits 2.17.1 draft-vonhugo-5gangip-ip-issues-03.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 (March 13, 2017) is 2601 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 768, 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 (-04) exists of draft-herbert-nvo3-ila-03 == 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-03 == 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 (~~), 7 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: September 14, 2017 Huawei 6 March 13, 2017 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-03 12 Abstract 14 This document presents considerations related to open issues with 15 upcoming new communication systems denoted as 5G aiming to set a 16 basis for documenting problem space, use-cases, and potential 17 solutions related to next-generation network infrastructure. The 18 draft reviews currently investigated topics, including both inputs 19 from IETF and from other SDOs as well as research activities. 20 Further the outcome of recent discussions at side sessions during 21 IETF meetings are recaptured to help identifying a starting point for 22 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 September 14, 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. 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. Towards Converged Access-Agnostic Core Network . . . . . . . 10 69 9. Session Management Architecture . . . . . . . . . . . . . . . 12 70 10. Investigations in 5G IP Protocols . . . . . . . . . . . . . . 14 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 74 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 75 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 15.1. Normative References . . . . . . . . . . . . . . . . . . 17 77 15.2. Informative References . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 80 1. Introduction 82 This document focuses on IP architecture and protocol aspects related 83 to upcoming new communication system infrastructure. This envisaged 84 5G system is foreseen to be available from 2020 onwards to provide a 85 converged Information and Communication Technology (ICT) ecosystem. 86 The offered broad spectrum of fixed and mobile services will be 87 characterised mainly by improved flexibility and efficient usage of 88 available resources to support services' demands with partially 89 contradicting requirements. A new highly re-configurable 90 architecture in both heterogeneous access and a converged core 91 network shall allow for key features as 93 o Stable selectable low latency 95 o Granted reliability and availability according to user and service 96 demands 98 o Potential (adaptive) mobility support (i.e. on demand): in case of 99 change in device or service location or as countermeasure to 100 partial failures /outage 102 o Low cost (i.e. affordable and related to service characteristics) 103 with respect to both investment and operational expenses: 104 efficiency in terms of resource consumption and effort 106 o Adaptive support of service quality in terms of (raw network) 107 performance (Quality of Service, QoS) and individual user 108 experience (Quality of Experience, QoE) requiring end-to-end 109 monitoring and feedback 111 o Selectable inbuilt security: different measures to be chosen from 112 a tool box 114 o Improved resource efficiency (e.g. in terms of energy consumption, 115 processing power, data storage, and radio spectrum usage) 117 o High flexibility for new services (and service features) 118 introduction and deployment 120 o Much better scalability in terms of amount of supported end 121 devices and transferred data rates and volume 123 o Higher bandwidth, data rate and throughput shall be achieved with 124 new radio technologies (multiple antennas) 126 o multiple heterogeneous technologies in concurrence (multiaccess) 128 o Bandwidth/ broadband access values exceeding 1Gbps. 130 A network to serve diverse demands ranging between very strict and 131 quite relaxed requirements asks for dynamic feature selection per 132 network functionality and thus will be much more software centric. 133 Only an architecture with modular control plane functions will enable 134 service tailored selection or adaptation of network characteristics 135 in terms of functionalities. 137 Also the expected high flexibility and resource efficiency demands 138 for exploitation of SDN and NFV together with computation and storage 139 space provision in central or distributed cloud environments. 141 In addition a new architecture with modular control plane functions 142 is required to enable service tailored selection or adaptation of 143 network characteristics in terms of functionalities. 145 Decoupling and abstraction of access and core domains to allow for 146 heterogeneity enabling higher flexibility and resource usage 147 efficiency is a request to 5G systems. 149 2. Problem Space and Typical Use Cases 151 The design of the new 5G system faces challenging requirements which 152 are derived from potential prospective services to be provisioned via 153 the 5G ecosystem. To illustrate the broad range of diverse demands 154 out of the plentitude of use cases as identified e.g. in [NGMN] a set 155 of three exemplary use case families is presented below following 156 [METIS]. 158 Generally all such services cannot and have not to be provided within 159 one specifically configured logical network. Flexibility to allow 160 different adaptations of the same physical infrastructure to fulfill 161 one tenants or verticals (service providers) requests is essential 162 for an appropriate 5G system concept. 164 2.1. Ubiquitous Broadband Access Use Case 166 This group of use cases covers fixed, portable, and mobile 167 applications between user equipment and servers in the network which 168 may be characterized by large bandwidth requirements, support of 169 mobile devices, typical multimedia services between humans and 170 between humans and content in the network to only name a few. 172 2.2. Massive Deployment of Machines Use Case 174 The Machine Type Communication (MTC) or Internet of Things (IoT) use 175 cases cover generally a large amount and dense deployment of devices 176 (sensors, metering) as smart grid or of Industry 4.0 type, but also 177 vehicular communication. 179 2.3. Critical Communications Use Case 181 Here a strict latency and reliability limit has to be considered 182 since services are time-critical or need high delivery probability. 184 3. Requirements to Future Communication Systems 186 Derived from the use case scenarios a list of requirements for 5G has 187 been established by several organisations as e.g. NGMN or 3GPP 188 denoting as key issues or key design principles or key drivers, for 189 details see e.g. 3GPP [TR23.799]. Also ITU has identified key 190 capabilities of IMT-2020, i.e. the International Mobile 191 Telecommunications (IMT) system for 2020 and beyond, which can be 192 found in [M.2083]. 194 Beside quantitatively measurable expected enhancement of performance 195 parameters as 197 o User experienced data rate: 100 vs. 10 Mbit/s 199 o Spectrum efficiency 3 times that of IMT Advanced 201 o Mobility support for up to 500 km/h instead of 350 km/h (only) 203 o Latency (of 1 vs. 10 ms), Latency down to 1ms could be foreseen 204 for 5G 206 o Connection density of 1 Million vs. 100000 devices/km 208 o Network energy efficiency of 100 times improved 210 o Area traffic capacity of 10 vs. 0.1 Mbit/s/m2 212 o Peak data rate of 20 instead of below 1 Gbit/s 214 Other key improvements which are not always direct quantitatively 215 measurable cover so-called soft features are also essential for 5G: 217 o Network scalability and flexibility 219 o Logical network separation (slicing) 221 o Consistent customer experience 223 o Service and network trust, reliability and security 225 o Operational efficiency 227 o Openness for innovation 229 4. Current Activities and Areas of Work within IETF/IRTF 231 Although a vertical topic as 5G is seen not as IETF topic ( providing 232 standardized building blocks for specific engineering challenges 233 "horizontals." IETF does not define or adapt "vertical" frameworks 234 like "Smart Cities," "Internet of Things," or "5G networks." It is 235 implicitly assumed that the participants will apply the building 236 blocks within the verticals 237 [I-D.arkko-ietf-trends-and-observations].), the topic creates issues 238 on multiple horizontal levels as is reflected within drafts and 239 discussions in WGs such as LISP (Locator/Identifier Separation 240 Protocol), NVO3 (Network Virtualization Overlays). Furthermore IRTF 241 RGs with focus on 5G topics are NFV(Network Function Virtualization), 242 SDN (Software Defined Networking), and ICN (Information Centric 243 Networking). 245 There is also a rich set of Mobile IP based mobility approaches which 246 also can be viewed as identifier locator separation protocol with 247 home address as the identifier and care-of address as the locator. 248 Original Mobile IP used tunneling and a fixed anchor called Home 249 Agent (HA) or Local Mobility Anchor (LMA). However more recently 250 extensions for distributed anchoring were designed. 252 The current activities there contribute to one or more of the 253 following issues addressed in more detail during the preceding side 254 meetings of the 5GangIP mailing list archive. 256 5. Future Internet Architecture 258 Currently, the efforts towards the Next Generation System have 259 defined architectural requirements as outlined in [TR23.799] and 260 design of specific network entities as network functions (NFs or 261 VNFs) and interfaces between them, protocols and procedures both for 262 5G Access Network for various different accesses and a common core 263 network is ongoing. Aim is specifying and optimizing protocols for a 264 more efficient internet to provide mobility, scale, security and ease 265 of deployment required for a connected society beyond the year 2020. 266 But the industry seems to be divided by what should qualify as a true 267 5G. One approach to 5G is: 269 5G radio / enhanced LTE + 5G core 271 This new core shall both meet the 5G requirements and allow for 272 connection via enhanced 4G radio for reasons of operational 273 continuity. 275 The current IP is connectivity-centric. Additional features such as 276 mobility and security are added as optional patches and fix-ups. 277 Moreover, protocols have been designed in a segmented way instead of 278 an architectural way. 280 Future Internet Architecture attempts to look at the current user/ 281 data plane protocol stack that is in use in both fixed and mobile 282 networks and redesign it. One issue the future internet architecture 283 addresses is the number of layers below the IP layer. 285 If we consider the current LTE radio protocol stack, we can easily 286 find that there are 6-plus layers, with PDCP, RLC, MAC and PHY being 287 the ones below IP layer. Each layer adds some bytes to the header, 288 some layers have their own checksums, i.e. more overhead. However, 289 in cellular Internet of Things, (IoT) a packet may have only 1 byte 290 payload. In this case, we would not call it efficient, the 291 efficiency rate is less than 1%, with the efficiency rate defined as 292 (payload length)/(packet size). 294 Future internet architecture deals with data plane protocol stack 295 reduction issues like: 297 o Which layers could be reduced? 299 o How can we deal with multiple checksums, since it is very 300 expensive to compute checksums, remembering we aim at 1ms latency 301 budget? 303 o Should we design a new type of protocol that does not reuse the 304 existing ones to make the network more efficient? Such a clean 305 slate approach would expose a high degree of disruption. 307 o What would happen if we take away GTP, LTE's tunneling protocol? 308 For more discussion on this see Section 6. 310 Future internet architecture proposes a unified layering for both 311 fixed and mobile networks. In the IP layer, we have Identifier 312 Oriented Networking or IP protocol. Below this, we have the next 313 generation medium access control protocol providing a unified medium 314 access to 5G radio, 802.11 or Wi-Fi and Ethernet type of fixed access 315 technologies. The lowest layer is the next generation physical layer 316 protocol unifying all physical accesses to 5G-era. 318 In the control plane, more need to be considered. For example, the 319 current internet is operated by routing protocols and their 320 extensions. These protocols are usually driven by Command Line 321 Interfaces (CLIs) on the first hand, e.g. for protocols like OSPF 322 [RFC5340] will work as instructed by the commands in CLI. 324 However, in 5G, there will be many mobile nodes, perhaps with low- 325 power so that at one instant they are up and at the next instant they 326 are down. The traditional operation model won't work any more, since 327 we can't easily configure them and we don't want their mobility and 328 status change affecting the routing tables, Routing Information Base 329 (RIB) frequently. 331 In this case, mobility issue will arise. A cell phone moves, but its 332 identifier (ID) does not change. Can 5G network mobility protocols 333 (see Section 10) be used for this use case, i.e. also handle e.g. 334 session continuity in case of multi-connectivity? Which further 335 extensions and modifications might be needed to re-scope the approach 336 to apply for the required mobility? ID plays a central role in 337 mobility. Can we design a new protocol, say ID-Oriented Networking 338 Protocol? In future, more and more mobile things are connected to 339 the internet which may not yet have proper identifiers available 340 compared to cell phones (see e.g. [I-D.ietf-dmm-4283mnids]): things 341 like connected cars, connected drones, etc. 343 For more discussion on this see Section 10. 345 6. Edge Network with no Tunneling 347 In fixed network, PPPoE protocol [RFC2516] is used between the 348 residential gateway and broadband network gateway to transport the 349 residential users IP packets to the fixed network gateway to the 350 Internet. PPPoE protocol requires 8 octets of header in every IP 351 packet, thereby reducing the MTU size by 8 octets to usually 1492 352 octets. PPPoE protocol is carried in Ethernet frames with 18 octet 353 headers where the destination address is the broadband network 354 gateway address. 356 Aiming at an IP protocol unaware/agnostic/overarching control plane 357 logic multiple protocol approches can be deployed depending on actual 358 service and slice demands, such as e.g. those based on low-overhead 359 translation mechanisms and encapsulation-based ones on the other 360 hand. If a client-based mapping between Identifier and Locator is 361 required (i.e. executed on a user terminal) translation would be the 362 recommended approach. For network-centric deployment a LISP-like 363 mapping function on gateways or the session terminating servers and 364 data centers can be deployed. How such a control plane could look 365 like on L2/L3 to support LISP has recently been described in 366 [I-D.portoles-lisp-eid-mobility]. 368 In mobile network, IP packets are tunneled using GTP data plane 369 protocol called GTP-U. First eNodeB or the base station tunnels UE's 370 IP packets to the Serving Gateway, in S1 GTP tunnel and then the 371 serving gateway tunnels to the Packet Gateway, called S5 tunnel. 372 Both of them are UDP tunnels which adds 8 octet header and GTP 373 protocol header is 12 octets, so a total of 20 octets are used. In 374 addition also an IPSec header should be accounted for between eNodeB 375 and SGW. 377 On the other hand in an end-to-end path between UEs or towards the 378 Application Function the network has either to keep a lot of status 379 information (meta data) for finding and maintaining the optimum path 380 - or apply encapsulation with specific headers between eNB and SGW/ 381 PGW - as tunneling. As exemplarily shown above, however, tunneling 382 adds a lot of overhead to the user IP packets and therefore 383 inefficiencies arise including reducing the MTU size. 385 If tunneling can be avoided, i.e. if edge networks can be designed 386 with no tunneling, a corollary of this would be no gateways would be 387 needed, leading to edge networks with no tunneling or no gateway. 388 The means to avoid gateways and tunneling a direct end-to-end routing 389 has to be established in the edge network. 391 With routing support edge networks can direct the user traffic to the 392 correct destinations, rather than tunneling to the gateways. In 393 order to deal with user mobility, ID-oriented networking protocol 394 would be needed. So it needs to be evaluated if using ID-oriented 395 networking protocol with routing will lead to more efficient delivery 396 of user IP packets in the edge network compared with 4G edge network 397 techniques of tunneling with gateways. 399 As we deal with carrier-grade networks here also the aspects of AAA 400 and charging have to be considered. The main reason why tunneling is 401 used in 4G edge networks and broadband network is to direct the user 402 traffic so that the operator can identify and handle the traffic 403 according to underlying service class specific demands. Another 404 issue is charging and accounting the user properly and both requires 405 the traffic to be routed via specific gateway nodes using the tunnel 406 endpoint identifiers (TEID) carried in GTP header. Edge networks 407 with no gateways should enable enough control to the operators so 408 that charging and other functions on the user traffic is properly 409 conducted. 411 Optimum use of available resources may also require a common control 412 framework including e.g. user plane communication between devices 413 directly or via relays / access nodes only. How such an efficient, 414 scalable, and performant solution in case of mobility has to be 415 designed - preferably without much effort due to complex state 416 handling - is one of the challenging questions. 418 7. Logical Network Isolation (Slicing) Concepts 420 Within the framework of 5G a network slice is seen as an independent 421 logical end-to-end network, defined by a set of specific network 422 functions providing service-specific network characteristic 423 (performance). The basic Network Functions can be both physical and 424 virtual in nature, and comprise C-plane and D-plane tasks (maybe 425 supplemented by Management), and should be independently instantiated 426 and operated. Network functions are adapted and configured according 427 to service demands which includes as well parameter settings as their 428 logical and spatial location within the network topology (e.g. at 429 central or remote processing clouds, i.e. data centers, to achieve 430 e.g. a low transmission delay towards the end user). 432 A major issue in isolation between different network slices beside 433 the security and reliability is a minimum interference in between 434 them in terms of trade-off with respect to joint usage of shared 435 resources (e.g. radio spectrum for wireless access or processing 436 capacity for network function execution). Here again, the more 437 limited the resources are, the more important it is to achieve a 438 highly effient usage creating the need for proper mechanisms (e.g., 439 algorithms and protocols) to orchestrate and coordinate resource 440 assignment (and to monitor the actual network slice performance). 442 8. Towards Converged Access-Agnostic Core Network 444 Currently network infrastructure is being transformed into two-layer 445 data center or cloud as Core Network (CN) and the Access Network 446 which mainly accommodates 5G radio access network on the wireless 447 side and central office on the wireline network closer to the user. 448 This new architecture enables us to flexibly deploy 5G Virtual 449 Network Functions (VNFs) based on the service scenarios. The 450 division of work in this case is to deploy 5G control plane VNFs in 451 the core cloud and 5G user/data plane VNFs and related applications 452 in the edge cloud. 454 The new architecture also leads us to a converged access independent 455 core network with a common access network - core network interface 456 which integrates 5G network with the fixed network leading us to 5G 457 Fixed Mobile Convergence (FMC). 5G architecture minimizes 458 dependencies between Access Network (AN) and Core Network (CN), the 459 architecture is defined with a converged access-agnostic core network 460 with a common AN - CN interface which integrates different 3GPP and 461 non-3GPP access types. 463 Proposed 5G architecture is shown in Figure 1. The rectangles are 464 the network functions and the lines are their interconnections or 465 reference points from N1 to N15. Network Function names are given on 466 the right hand side. 468 The reference points usually carry a specific protocol such as GTP 469 (GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g. 470 over N3) or Non-Access Stratum (NAS) of 3GPP. Access and Mobility 471 Management Function (AMF) is the Network Function (NF) that 472 terminates N1 and N2. User Plane Function (UPF) is the NF that 473 terminates N3. We explain a few important network functions here. 475 Access and Mobility Management Function (AMF) is in charge of 476 registration management, connection management, reachability 477 management, mobility Management, it is transparent proxy for routing 478 session management messages. It does access authentication and 479 access authorization. 481 Session Management Function (SMF) is in charge of session 482 establishment, modify and release, including tunnel maintainance 483 between UPF and the access network (AN) node. UE IP address 484 allocation and management (incl. optional Authorization), selection 485 and control of the user plane (UP), i.e. data plane function. SMF 486 configures traffic steering at UPF to route traffic to proper 487 destination (i.e the corresponding Data Network, DN); termination of 488 interfaces towards policy control functions (PCF); control part of 489 policy enforcement and QoS termination of session management (SM) 490 parts of non-access stratum (NAS) messages, downlink Data 491 Notification; initiator of AN specific SM information, sent via AMF 492 over N2 to AN; support for interaction with external DN for transport 493 of signalling for PDU session authorization/authentication by 494 external DN. 496 User Plane Function (UPF) is anchor point for mobility (when 497 applicable); external PDU session point of interconnect to Data 498 Network; packet routing and forwarding Packet inspection and User 499 plane part of Policy rule enforcement; uplink classifier to support 500 routing traffic flows to a data network; branching point to support 501 multi-homed PDU session; transport level packet marking in the uplink 502 and downlink; downlink packet buffering and downlink data 503 notification triggering. 505 According to 5G architecture, 5G UE is expected to use Non-Access 506 Stratum (as opposed to Access-Stratum (AS) which is used between 507 radio network and UE) signaling for establishment of communication 508 sessions and for maintaining continuous communications with the user 509 equipment as it moves with 5G core network even when UE is connected 510 to 5G core network via a non-3GPP access network, e.g. over Wi-Fi, 511 oftentimes simultaneously to the wireless radio access network (RAN). 513 Key principles and concepts in 5G architecture include separation of 514 User Plane (UP) functions from the Control Plane (CP) functions, 515 allowing independent scalability, evolution and a flexible deployment 516 e.g. centralised location or distributed (remote) location; 517 definition of the the network functions, e.g. to enable flexible and 518 efficient network slicing. Network slicing (see Section 7) with 519 slices that may include components served by fixed networks is 520 another innovation in 3GPP 5G architecture work as well as the 521 definition of a common core network which is access agnostic. 522 Wherever applicable, procedures (i.e. the set of interactions between 523 network functions) are defined as services, so that their re-use is 524 possible. Each Network Function can interact with the other NF 525 directly if required. The architecture does not preclude the use of 526 an intermediate function to help route control plane messages. 528 +----+ +---+ Authentication 529 |AUSF|---N13---|UDM| Server Function 530 +----+ +---+ (AUSF) 531 \ /\ Core Access and 532 \ / \ Mobility Management 533 N12 N8 N10 Function (AMF) 534 \ / \ Data network (DN) 535 +---+ +---+ +---+ +--+ 536 ________|AMF|-N11-|SMF|-N7-|PCF|--N5-|AF| 537 / +---+ +---+ +---+ +--+ 538 / / N14|_______/__N15_____| 539 / / / Policy Control 540 N1 N2 / Function (PCF) 541 / / N4 Session Management 542 / / / Function (SMF) 543 / / / Unified Data 544 / / / Management (UDM) 545 +--+ +---+ +---+ /---\ User Equipment(UE) 546 |UE|-------|RAN|---N3---|UPF|---N6- -|DN | (Radio)Access Network ((R)AN) 547 +--+ +---+ +---+ \---/ User Plane Function (UPF) 548 |-N9-| 550 Figure 1: 5G Architecture 552 One of the challenges in 5G FMC is how to provide seamless mobility 553 when 5G UE while in a 5G radio access network later moves to an area 554 of Wi-Fi access point connected to a central office while both access 555 networks are served by a converged common core. Another challenge is 556 to enable flexible and seamless management of the user sessions while 557 accessing sometimes simultaneously over UE's multiple interfaces, 558 e.g. 5G and Wi-Fi. 560 9. Session Management Architecture 562 Session management responsible for the setup of the connectivity for 563 the UE as well as managing the user plane for that connectivity is 564 identified as one of the key issues in 5G system architecture in 565 [TR23.799]. It is one of the network functions, the Session 566 Management Function (SMF) in 5G Architecture described in Section 8. 567 Session management design issues include managing multiple access, 568 multiple connectivity, multiple transport paths, e.g. to RAN and to 569 non-3GPP access network (AN), sometimes simultaneously and how to 570 efficiently transmit and receive infrequent small amounts of data and 571 short data bursts, e.g. for Narrow Band Internet of Things (NB-IoT). 572 In this section, we take a look at how SMF can be structured. 574 Using control plane data plane separation principle, SMF is a control 575 plane function as such it corresponds to Network Connection Manager 576 (NCM). There is a data plane component for user data traffic 577 forwarding called Network Multi-Access Data Proxy (MADP) which is 578 part of the User Plane Function (UPF) in Figure 1. It can be argued 579 that we also need corresponding client side NCM, called CCM and MADP 580 hosted on the UE [I-D.kanugovi-intarea-mams-protocol]. 582 Network Multi-Access Data Proxy (MADP) in the core network handles 583 the user data traffic forwarding across multiple network paths, as 584 well as other user-plane functionalities, e.g. encapsulation, 585 fragmentation, concatenation, reordering, retransmission, etc. 586 N-MADP is the distribution node for uplink and downlink data with 587 visibility of packets at the IP layer. 589 Network Connection Manager (NCM) in the core network configures 590 identification and distribution rules for different user data traffic 591 type at the N-MADP. The NCM configures the routing in the MADP based 592 on signaling exchanged with the CCM in UE. In the uplink, NCM 593 specifies the core network path to be used by MADP to route uplink 594 user data at the MADP. In the downlink, NCM specifies the access 595 links to be used for delivery of data to the client at the MADP. 597 At the UE, MADP handles encapsulation, fragmentation, concatenation, 598 reordering, retransmissions, etc. C-MADP is configured by CCM based 599 on signaling exchange with NCM and local policies at the UE. 601 At the UE, CCM manages the multiple network connections. CCM is 602 responsible for exchange of MAMS signaling messages with the NCM for 603 supporting functions like configuring uplink and downlink user 604 network paths for transporting user data packets, link sounding and 605 reporting to support adaptive network path selection by NCM. In the 606 downlink, for the user data received by UE, it configures IP layer 607 forwarding for application data packets received over any of the 608 accesses to reach the appropriate application module on the client. 609 In the uplink, for the data transmitted by UE, it configures the 610 routing table to determine the best access to be used for uplink data 611 based on a combination of local policy and network policy delivered 612 by the NCM. 614 The challenges of this kind of session management design include if 615 such a design can be simplified so that NB-IoT type of very simple 616 sessions can also be handled. Regarding SMF and AMF, identifying the 617 correlation between session management and mobility management, 618 identifying the interactions between session management and the 619 mobility framework required to enable the various mobility scenarios 620 while minimizing any negative impact on the user experience 621 investigating solutions to coordinate the relocation of user-plane 622 flows with the relocation of applications (hosted close to the point 623 of attachment of the UE) due to the mobility of users can be 624 considered as the challenges of 5G architecture. 626 10. Investigations in 5G IP Protocols 628 With both physical and logical mobility of (an extremely high number 629 of) entities and virtualization of network functions the traditional 630 usage of IP addresses for denoting both IDentifier and Address or 631 logical entity and location as source or destination of data packets 632 becomes cumbersome. New approaches to solve the issues are proposed 633 in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also 634 ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge. 636 By separating a Routing LOCator (RLOC) from a unique Identity (EID) 637 LISP keeps a single address to each session endpoint even in multi- 638 homing but requires a dedicated mapping mechanism for compatibility 639 with the (LISP-unaware) Internet. ILNP (and ILNP-based ILA) avoid 640 encapsulation and require no changes in higher layers (except the 641 transport layer) re-using part of an (IPv6) Address as Identifier and 642 Locator. ILA does not require any changes in transport layer but it 643 is IPv6 only. 645 In LISP the EID/RLOC split can be collocated in the same entity: EID 646 mobile, RLOC static or dynamic. Predictive RLOCs 647 [I-D.farinacci-lisp-predictive-rlocs] can be used if LISP entity 648 knows where the user going so that the system can mitigate mobility 649 impacts. LISP can be used between the Serving and Packet data 650 Gateways. Best solution is to keep LISP close to the moving entity 651 with the functions as close to the edge as possible. 653 ILNP defines minimal changes on IPv4 and IPv6, it requires changes on 654 the domain name system and the transport layer [RFC6740]. Both ILNP 655 and ILNP-based ILA rely on the routing system or LTE core network to 656 route to the translated address. 658 LISP requires routing system changes, it is implemented on the 659 routers, possibly on the edge routers. That means LISP requires 660 changes on LTE core network. ILNP does not use encapsulation so it 661 is light weight. LISP is UDP encapsulated so in IPv6, LISP messages 662 incur 52 bytes of overhead. 664 ILNP nodes send Locator Update messages which are ICMPv4/v6 messages 665 to its correspondent nodes when its Locator value changes during an 666 active session. Correspondent node could be a fixed node such as 667 Google server which means ILNP has to be implemented by the fixed 668 nodes as well. 670 ILA is a major update to ILNP [I-D.herbert-nvo3-ila]. It is 671 originally designed for network virtualization to be used in cloud 672 networks. ILA can encode a virtual network identifier (VNID) and 673 virtual address as an ILNP identifier. ILA adaptation for 3G network 674 mobility is investigated in [I-D.mueller-ila-mobility]. 676 Further investigations are needed for anchor-less mobility in a 5G 677 fixed mobile convergence network with a converged core network. The 678 prospective approach is to overcome tunneling and encapsulation 679 overhead by simplified routing according to identifiers not bound to 680 locations and thus allowing for relocation within underlying 681 infrastructure. Such an approach should also incorporate session 682 management in support of session and service continuity in the 5G 683 architecture with a common core enabling mobility in multiple access 684 networks. 686 Anchor points perform important duties such as policy, accounting 687 etc. as well as mapping that cannot be ignored. In anchor-less 688 mobility, the absolute best place to perform these functions (if it 689 is not at an anchor point in the network) is actually in the 690 terminal/UE itself. When anchors are removed then it becomes a 691 challenge to provide functions like security and trust and use the UE 692 as the only remaining single anchor point to perform its own 693 accounting and policy and other functions. 695 There are secure execution environments/processors in UE's these 696 days, where all the finger print recognition, password encryption 697 etc. is done and perhaps it is possible to extend these to run secure 698 network functions on behalf of the slices. This way, the NFV cloud 699 extends into the terminal's secure execution engine. 701 As none of the mentioned existing proposals fully covers the 5G 702 requirements consistently, in this document, the authors propose the 703 following steps for investigations on further enhancements that have 704 to be performed. 706 Problem statement on the need for a next generation or 5G mobility 707 protocol with session management, exploiting previous standardization 708 efforts. 710 Requirements on a new 5G FMC network mobility protocol in view of 5G 711 execution environments such as in Section 8, and issues such as in 712 Section 6. 714 An architecture document that uses all the relevant Network Functions 715 identified in 5G architecture and possibly their subdivisions or 716 components when deploying 5G FMC network mobility and session 717 management protocol and their interconnections. 719 A document on possible solution space investigations including 720 adaptations into specific architectures such as 5G architecture. 722 11. IANA Considerations 724 None. 726 12. Security Considerations 728 Security considerations related to the 5G systems are discussed in 729 [NGMN]. Due to the request for intrinsic realization of security 730 such aspects have to be considered by design for architecture and 731 protocols. 733 Especially as a joint usage of resources and network functions by 734 different separate logical network slices (e.g. in terms of virtual 735 network functions) seems to be inevitable in the framework of 5G the 736 need for strong security measures in such an environment is a major 737 challenge. 739 13. Privacy Considerations 741 Support of full privacy of the users (customers and tenants / end 742 service providers) is a basic feature of the next generation trusted 743 and reliable communications offering system. Such a high degree of 744 ensured privacy shall be reflected in the proposed architecture and 745 protocol solutions (details have to be added). 747 Especially as Identifiers and mapping of locators to them are 748 addressed the discussion on identifier and privacy should consider 749 existing solutions such as 3GPP Globally Unique Temporary UE Identity 750 (GUTI) which is a temporary identity obfuscating the permanent 751 identity in the mobile network and specified in [TS23.003]. 753 14. Acknowledgements 755 This work has been partially performed in the framework of the 756 cooperation Config. Contributions of the project partners are 757 gratefully acknowledged. The project consortium is not liable for 758 any use that may be made of any of the information contained therein. 760 Comments and careful review by the 5GangIP mailing list (Dino 761 Farinacci, Tom Herbert, Julius Mueller, Robert Moskowitz, Peter 762 Ashwood, to name just a few) are gratefully acknowledged. 764 15. References 766 15.1. Normative References 768 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 769 Requirement Levels", BCP 14, RFC 2119, 770 DOI 10.17487/RFC2119, March 1997, 771 . 773 15.2. Informative References 775 [I-D.arkko-ietf-trends-and-observations] 776 Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O., 777 olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R. 778 White, "IETF Trends and Observations", draft-arkko-ietf- 779 trends-and-observations-00 (work in progress), February 780 2016. 782 [I-D.farinacci-lisp-predictive-rlocs] 783 Farinacci, D. and P. Pillay-Esnault, "LISP Predictive 784 RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in 785 progress), November 2016. 787 [I-D.herbert-nvo3-ila] 788 Herbert, T., "Identifier-locator addressing for IPv6", 789 draft-herbert-nvo3-ila-03 (work in progress), October 790 2016. 792 [I-D.ietf-dmm-4283mnids] 793 Perkins, C. and V. Devarapalli, "MN Identifier Types for 794 RFC 4283 Mobile Node Identifier Option", draft-ietf-dmm- 795 4283mnids-04 (work in progress), January 2017. 797 [I-D.kanugovi-intarea-mams-protocol] 798 Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng, 799 S., and J. Mueller, "Multiple Access Management Services", 800 draft-kanugovi-intarea-mams-protocol-03 (work in 801 progress), March 2017. 803 [I-D.mueller-ila-mobility] 804 Mueller, J. and T. Herbert, "Mobility Management Using 805 Identifier Locator Addressing", draft-mueller-ila- 806 mobility-03 (work in progress), February 2017. 808 [I-D.portoles-lisp-eid-mobility] 809 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 810 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 811 Unified Control Plane", draft-portoles-lisp-eid- 812 mobility-01 (work in progress), October 2016. 814 [M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and 815 overall objectives of the future development of IMT for 816 2020 and beyond", September 2015. 818 [METIS] Elayoubi, S. and et al., "5G Service Requirements and 819 Operational Use Cases: Analysis and METIS II Vision", 820 Proc. euCNC, 2016. 822 [NGMN] NGMN Alliance, "NGMN White Paper", February 2015. 824 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 825 and R. Wheeler, "A Method for Transmitting PPP Over 826 Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516, 827 February 1999, . 829 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 830 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 831 . 833 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network 834 Protocol (ILNP) Architectural Description", RFC 6740, 835 DOI 10.17487/RFC6740, November 2012, 836 . 838 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 839 Locator/ID Separation Protocol (LISP)", RFC 6830, 840 DOI 10.17487/RFC6830, January 2013, 841 . 843 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 844 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 845 "Information-Centric Networking: Baseline Scenarios", 846 RFC 7476, DOI 10.17487/RFC7476, March 2015, 847 . 849 [TR23.799] 850 "3GPP TR23.799, Study on Architecture for Next Generation 851 System (Release 14)", December 2016. 853 [TS23.003] 854 "3GPP TS23.003, Numbering, addressing and identification 855 (Release 14)", September 2016. 857 Authors' Addresses 859 Dirk von Hugo 860 Telekom Innovation Laboratories 861 Deutsche-Telekom-Allee 7 862 D-64295 Darmstadt 863 Germany 865 Email: Dirk.von-Hugo@telekom.de 867 Behcet Sarikaya 868 Huawei 869 5340 Legacy Dr. 870 Plano, TX 75024 872 Email: sarikaya@ieee.org