idnits 2.17.1 draft-bogineni-dmm-optimized-mobile-user-plane-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([CP-173160-1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (June 29, 2018) is 2128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ILAGRPS' is defined on line 2799, but no explicit reference was found in the text == Unused Reference: 'WLDR' is defined on line 2877, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-00 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-00 == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-03 == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: A later version (-03) exists of draft-homma-dmm-5gs-id-loc-coexistence-01 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-13 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-01 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-mobility-02 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-mn-02 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-00 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-12 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-10 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-mapme-00 == Outdated reference: A later version (-08) exists of draft-irtf-icnrg-terminology-00 == Outdated reference: A later version (-08) exists of draft-kouvelas-lisp-map-server-reliable-transport-04 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-00 == Outdated reference: A later version (-04) exists of draft-rodrigueznatal-lisp-srv6-00 -- Duplicate reference: draft-herbert-ila-ilamp, mentioned in 'ILACONTROL', was also mentioned in 'I-D.herbert-ila-ilamp'. Summary: 5 errors (**), 0 flaws (~~), 23 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dmm K. Bogineni 3 Internet-Draft Verizon 4 Intended status: Informational A. Akhavain 5 Expires: December 31, 2018 Huawei Canada Research Centre 6 T. Herbert 7 Quantonium 8 D. Farinacci 9 lispers.net 10 A. Rodriguez-Natal 11 G. Carofiglio 12 J. Auge 13 L. Muscariello 14 P. Camarillo 15 Cisco Systems, Inc. 16 S. Homma 17 NTT 18 June 29, 2018 20 Optimized Mobile User Plane Solutions for 5G 21 draft-bogineni-dmm-optimized-mobile-user-plane-01 23 Abstract 25 3GPP CT4 has approved a study item to study different mobility 26 management protocols for potential replacement of GTP tunnels between 27 UPFs (N9 Interface) in the 3GPP 5G system architecture. 29 This document provides an overview of 5G system architecture in the 30 context of N9 Interface which is the scope of the 3GPP CT4 study item 31 [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP], 32 [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and 33 [TS.38.401-3GPP]. 35 Architecture requirements for evaluation of candidate protocols are 36 provided. Optimization of the user plane can be in different ways - 37 packet overhead, transport integration, etc. 39 Several IETF protocols are considered for comparison: SRv6, LISP, ILA 40 and several combinations of control plane and user plane protocols. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on December 31, 2018. 59 Copyright Notice 61 Copyright (c) 2018 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (https://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Scope of 3GPP Study Items . . . . . . . . . . . . . . . . 5 78 1.2. Relevance to IETF . . . . . . . . . . . . . . . . . . . . 6 79 1.3. Rationale for GTP replacement . . . . . . . . . . . . . . 6 80 1.4. Usage of GTP . . . . . . . . . . . . . . . . . . . . . . 7 81 1.5. Document Structure . . . . . . . . . . . . . . . . . . . 7 82 2. Conventions and terminology . . . . . . . . . . . . . . . . . 7 83 3. Overview of 3GPP Release 15 5G Architecture . . . . . . . . . 8 84 3.1. Non-Roaming Reference Architecture . . . . . . . . . . . 8 85 3.2. End-to-end Protocol Stack . . . . . . . . . . . . . . . . 10 86 3.3. Mobility Architecture with reference to N9 . . . . . . . 11 87 3.3.1. User Plane Function (UPF) Functionalities . . . . . . 12 88 3.3.2. N9 Interface . . . . . . . . . . . . . . . . . . . . 15 89 3.4. Roaming Architectures . . . . . . . . . . . . . . . . . . 16 90 3.4.1. Roaming and policy management . . . . . . . . . . . . 17 91 3.4.2. Local Break Out Model . . . . . . . . . . . . . . . . 18 92 3.4.3. Home Routed Model . . . . . . . . . . . . . . . . . . 18 93 3.5. Support for Multiple PDU Sessions . . . . . . . . . . . . 19 94 3.6. Service and Session Continuity Modes . . . . . . . . . . 21 95 4. Architectural requirements . . . . . . . . . . . . . . . . . 22 96 5. Data plane architecture models for N9 . . . . . . . . . . . . 23 97 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23 98 5.2. Forwarding and mobility paradigms . . . . . . . . . . . . 23 99 5.3. SRv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 25 101 5.3.2. SRv6 with Traffic Engineering . . . . . . . . . . . . 26 102 5.3.3. Service Programming with SRv6 . . . . . . . . . . . . 27 103 5.3.4. SRv6 and Entropy . . . . . . . . . . . . . . . . . . 28 104 5.3.5. SRv6 and transport slicing . . . . . . . . . . . . . 28 105 5.3.6. SRv6 and Alternative Approaches to Advanced Mobility 106 Support . . . . . . . . . . . . . . . . . . . . . . . 28 107 5.3.7. Areas of Concerns . . . . . . . . . . . . . . . . . . 29 108 5.4. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . 30 109 5.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . 30 110 5.4.2. LISP Encapsulation . . . . . . . . . . . . . . . . . 30 111 5.4.3. LISP Mapping Systems . . . . . . . . . . . . . . . . 30 112 5.4.4. LISP Mobility Features . . . . . . . . . . . . . . . 31 113 5.4.5. ILSR . . . . . . . . . . . . . . . . . . . . . . . . 31 114 5.5. ILA . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 5.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . 32 116 5.5.2. Protocol Layering . . . . . . . . . . . . . . . . . . 33 117 5.5.3. Control plane . . . . . . . . . . . . . . . . . . . . 33 118 5.5.4. IP addressing . . . . . . . . . . . . . . . . . . . . 34 119 5.5.5. Traffic engineering . . . . . . . . . . . . . . . . . 36 120 5.5.6. Locator Chaining with ILA . . . . . . . . . . . . . . 36 121 5.5.7. Security considerations . . . . . . . . . . . . . . . 36 122 5.6. Hybrid ICN (hICN) . . . . . . . . . . . . . . . . . . . . 37 123 5.6.1. Overview . . . . . . . . . . . . . . . . . . . . . . 37 124 5.6.2. Consumer and Producer mobility . . . . . . . . . . . 37 125 5.6.3. Anchorless mobility support . . . . . . . . . . . . . 38 126 5.6.4. Benefits . . . . . . . . . . . . . . . . . . . . . . 38 127 5.6.5. Deployment considerations . . . . . . . . . . . . . . 39 128 5.6.6. hICN with SRv6 . . . . . . . . . . . . . . . . . . . 40 129 5.6.7. Summary . . . . . . . . . . . . . . . . . . . . . . . 41 130 6. Integration into the 5G framework . . . . . . . . . . . . . . 41 131 6.1. Locator based - SRv6 . . . . . . . . . . . . . . . . . . 41 132 6.1.1. Insertion in N9 interface . . . . . . . . . . . . . . 41 133 6.1.2. Control Plane considerations . . . . . . . . . . . . 42 134 6.1.3. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 43 135 6.1.4. Coexistence with GTP-based architecture . . . . . . . 43 136 6.2. ID-LOC split . . . . . . . . . . . . . . . . . . . . . . 44 137 6.2.1. Insertion in N9 interface . . . . . . . . . . . . . . 44 138 6.2.2. LISP control plane . . . . . . . . . . . . . . . . . 46 139 6.2.3. ILA control plane . . . . . . . . . . . . . . . . . . 47 140 6.2.4. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 47 141 6.2.5. Coexistence with GTP-based architecture . . . . . . . 48 142 6.3. ID-based - hICN . . . . . . . . . . . . . . . . . . . . . 50 143 6.3.1. Insertion in N9 interface . . . . . . . . . . . . . . 50 144 6.3.2. Control plane considerations . . . . . . . . . . . . 51 145 6.3.3. Extensions to N3/F1-U/Xn-U interface . . . . . . . . 52 146 6.3.4. Coexistence with GTP-based architecture . . . . . . . 52 147 6.4. Coexistence of multiple protocols in network slices . . . 53 148 6.5. Interoperability/Roaming considerations . . . . . . . . . 54 149 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 150 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 55 151 9. Security Consideration . . . . . . . . . . . . . . . . . . . 56 152 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 153 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 56 154 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 155 12.1. Normative References . . . . . . . . . . . . . . . . . . 56 156 12.2. Informative References . . . . . . . . . . . . . . . . . 58 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 159 1. Introduction 161 Release 15 of the 3GPP specifications provide the 5G System 162 Architecture in [TS.23.501-3GPP], [TS.23.502-3GPP], and 163 [TS.23.503-3GPP]. They come with significant changes to the radio 164 and core architectures with respect to previous generations, with the 165 objective of enabling new use case requirements expected from 5G 166 networks. The user plane is however still based on GTP-U, and 167 tunnelling user-traffic to anchor points in the core network. User, 168 data and forwarding plane are used with the same meaning in this 169 context. 171 3GPP CT4 is in charge of specifying the user plane interface named 172 N9, and has approved a study item [CP-173160-1] to study possible 173 candidates for user plane protocol for the 5GC in Release 16. 175 This document comprehensively describes the various user plane 176 protocols and how they can be used in the 3GPP 5G architecture. 177 Specifically Segment Routing v6 (SRv6), Locator Identifier Separation 178 Protocol (LISP), Identifier Locator Addressing (ILA) and Hybrid 179 Information-Centric Networking (hICN) are introduced and their use as 180 replacement of GTP for N9 is further described. 182 Analysis work for clarifying the specifications of GTP-U as the 183 current mobile user plane protocol and the architectural requirements 184 of the 5G system is provided in [I-D.hmm-dmm-5g-uplane-analysis]. 185 That provides observations of GTP-U, the architectural requirements 186 for UP protocol, and some evaluation criteria based on the 187 requirements. 189 Optimization of the user plane can be in one more more of the 190 following: 192 o reduction/elimination of encapsulation; 193 o use of native routing mechanisms; 195 o efficient forwarding during, and in between mobility events; 197 o support of anchor-less mobility management and offloading of local 198 traffic; 200 o reduction of session state and signaling associated with mobility 201 management; 203 o convergence towards a flatter architecture, consistent with other 204 mobility proposals. 206 1.1. Scope of 3GPP Study Items 208 3GPP CT4 WG has approved a Release 16 study item [CP-173160-1] to 209 study user-plane protocol for N9 in 5GC architecture as specified in 210 [TS.23.501-3GPP] and [TS.23.502-3GPP]. This provides an opportunity 211 to investigate potential limits of the existing user plane solution 212 and potential benefits of alternative user plane solutions. 214 The following is extracted from the CT4 study item [CP-173160-1]. 216 The expected work in CT4 will include: 218 o Identify the possible candidate protocols for user-plane including 219 existing protocol; 221 o Define a list of evaluation criteria based on Rel-16 stage 2 222 requirements to evaluate the candidate protocols; 224 o Evaluate the candidate solutions against the list of requirements 225 and the potential benefits against the existing user plane 226 solution in 5GS. 228 CT4 will coordinate with RAN3 for selecting the user plane protocols 229 for N3 and F1-U interfaces in RAN. CT4 will also coordinate with CT3 230 Working Group for potential impacts to N6 interface and with SA2 for 231 potential impacts on stage 2 specifications. 233 Coordination will also be required with CT3 for potential impacts on 234 N6, and with SA2 if the work has possible impacts on the stage 2 235 specifications. 237 Extracted from [SP-180231-1], the work in SA2 Study item will study 238 the feasibility of extending the service concept from 5GC control 239 plane to the user plane function(s). Impact to User plane traffic 240 processing is not expected in this study. 242 1.2. Relevance to IETF 244 IETF has some protocols for potential consideration as candidates. 245 These protocols have the potential to simplify the architecture 246 through reduction/elimination of encapsulation; use of native routing 247 mechanisms; support of anchor-less mobility management; reduction of 248 session state and reduction of signaling associated with mobility 249 management. 251 This document provides an overview of the various protocols and how 252 they can be used in the 3GPP 5G architecture. Details of the 253 protocols will be provided as references in the respective sections, 254 then described in the context of the 3GPP 5G architecture. ILNP is 255 an end-to-end protocol and is not included in this document. The 256 scenario of replacing GTP on N9 as the focus of CT4 study is 257 discussed for each protocol. Additional scenarios are related to N3/ 258 F1-U; integration of mobility with transport; support for different 259 mobility protocols on different slices of the 5G system, etc. 261 1.3. Rationale for GTP replacement 263 Although being different in terms of architecture or implementations, 264 common objectives emerge from the different proposals and their 265 positioning with respect to the GTP-U tunnel-based architecture. We 266 succintly discuss those aspects here, that will be detailed in the 267 sections dedicated to each protocol, clarifying some terminology at 268 the same occasion. 270 _Simplification_ : simplify the management of networks, flat and 271 converge architecture with other mobility proposals. 273 _Efficiency_ : performance of the proposal for both packet 274 forwarding, and handling of traffic during mobility events. 276 _Overhead_ : remove encapsulation overhead due to tunneling. 278 _Data plane anchors_ : remove anchoring of all communications in a 279 central core location, and opt for distributed/decentralized/full 280 removal of anchors. 282 _Offloading of local communications_ : a direct consequence on the 283 distribution/removal of user plane anchors is the ability to offload 284 local traffic from the core. 286 _Control plane anchors_ : remove dependency on additional control 287 plane anchors, and interoperability with the SMF. 289 _Transport_ : Relieve transport and application layers from the 290 impact of mobility and related management protocols. 292 1.4. Usage of GTP 294 The main focus of the study is on the N9 interfaces that interconnect 295 UPFs and could span over the mobile backhaul. However, GTP is used 296 at multiple interfaces beyond N9. 298 N3 and N9 interfaces are tightly coupled and Section 6 discusses the 299 possibility to extend the deployment of new user planes to N3. The 300 impact on N3, F1-U, and Xn-U interfaces is still TBD. 302 1.5. Document Structure 304 Section 3 provides a high level overview of the 5G system 305 architecture and the relevant scenarios like roaming, support fo 306 multiple PDU sessions, etc. Section 4 provides a list of 307 architectural requirements that candidate solutions should address 308 are provided. Section 5 provides an overview of the various 309 protocols. Section 6 discusses how various approaches can be 310 integrated into the 5G framework. A summary is provided in 311 Section 7. 313 2. Conventions and terminology 315 In examples, "C:" and "S:" indicate lines sent by the client and 316 server respectively. 318 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 319 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 320 document are to be interpreted as described in RFC 2119 [RFC2119]. 322 In this document, these words will appear with that interpretation 323 only when in ALL CAPS. Lower case uses of these words are not to be 324 interpreted as carrying significance described in RFC 2119. 326 In this document, the characters ">>" preceding an indented line(s) 327 indicates a statement using the key words listed above. This 328 convention aids reviewers in quickly identifying or finding the 329 portions of this RFC covered by these keywords. 331 Acronyms 333 _AF_: Application Function 335 _AUSF_: Authentication Server Function 336 _AMF_: Access and Mobility Management Function 338 _DN_: Data Network, e.g. operator services, Internet access or 3rd 339 party services 341 _NEF_: Network Exposure Function 343 _NRF_: Network Repository Function 345 _NSSF_: Network Slice Selection Function 347 _PCF_: Policy Control Function 349 _RAN_: (Radio) Access Network 351 _SMF_: Session Management Function 353 _UDM_: Unified Data Management 355 _UDR_: Unified Data Repository 357 _UE_: User Equipment 359 _UPF_: User Plane Function 361 3. Overview of 3GPP Release 15 5G Architecture 363 This section briefly describes the 5G system architecture as 364 specified in [TS.23.501-3GPP]. The key relevant features for session 365 management and mobility management are: 367 o Separate the User Plane (UP) functions from the Control Plane (CP) 368 functions, allowing independent scalability, evolution and 369 flexible deployments e.g. centralized location or distributed 370 (remote) location. 372 o Support concurrent access to local and centralized services. To 373 support low latency services and access to local data networks, UP 374 functions can be deployed close to the Access Network. 376 o Support roaming with both Home routed traffic as well as Local 377 breakout traffic in the visited PLMN. 379 3.1. Non-Roaming Reference Architecture 381 This section briefly describes the 5G system architecture as 382 specified in 3GPP TS 23.501, and represented in Figure 1 and 383 Figure 2. 385 +------+ +------+ +------+ 386 | NSSF | | AUSF +-N13-+ UDM | 387 +------+ +------+ +------+ 388 \ | / \ 389 N22 N12 N8 N10 390 \ | / \ 391 +----+----+ +-------+ +------+ +------+ 392 +-----------+ AMF +- N11 -+ SMF +- N7 -+ PCF +- N5 -+ AF | 393 | +++-----+++ +---+---+ +--+---+ +------+ 394 | || || | | 395 | || |+------------|----- N15 ---+ 396 N1 N2|+-N14-+ N4 397 | | | 398 +--+--+ ++-------+ +---+---+ +------+ 399 | UE +-- NR --+ (R)AN +-- N3 --+ UPF +-- N6 --+ DN | 400 +-----+ +--------+ ++-----++ +------+ 401 | | 402 +--N9-+ 404 Figure 1: 5G System Architecture in Reference Point Representation 406 A short description of the network functions is provided below. 407 Details are in [TS.23.501-3GPP]. 409 Access and Mobility Management Function (AMF) interfaces with the 410 Radio access network and provides management of 411 registration/connection/reachability/mobility, access authentication 412 and authorization, etc. 414 Session Management function (SMF) handles session management, UE IP 415 address allocation & management, DHCP, ARP proxying, selection and 416 control of UP function, traffic steering, interface to PCF,charging 417 data collection, roaming, etc. 419 User Plane Function (UPF) is the anchor point mobility, packet 420 routing/forwarding/marking, packet inspection, policy rule 421 enforcement, lawful intercept, QoS handling,etc. 423 Policy Control Function (PCF) provides policy rules to Control Plane 424 function(s) to enforce them. 426 Network Exposure Function (NEF) supports exposure of capabilities and 427 events between network functions, to 3rd party, Application 428 Functions, Edge Computing, etc. 430 Network Repository Function (NRF) supports service discovery 431 function. 433 Unified Data Management (UDM) supports access authorization, 434 subscription management, etc. 436 Authentication Server Function (AUSF) supports authentication for 437 3GPP access and untrusted non-3GPP access. 439 Network Slice Selection Function (NSSF) selects the set of Network 440 Slice instances serving the UE, determines the allowed slices, etc. 442 Application Function (AF) 444 Service Based Interfaces 445 ----+-----+-----+----+----+---------+--------+-----+----+---- 446 | | | | | | | | | 447 +---+---+ | +--+--+ | +--+---+ +--+--+ +--+--+ | +----+ 448 | NSSF | | | NRF | | | AUSF | | UDM | | NEF | | | AF | 449 +-------+ | +-----+ | +------+ +-----+ +-----+ | +----+ 450 +---+----+ +--+--+ +-------------+--+ 451 | AMF | | PCF | | SMF | 452 +---+--+-+ +-----+ +-+-----------+--+ 453 N1 | | | 454 +-------+ | | N4 N4 455 | 5G UE |--+ | | | 456 +---+---+ N2 +-----+-+ +---+---+ +----+ 457 | | +----N3------+ UPF +-N9--+ UPF +--N6--+ DN | 458 | | | ++----+-+ +-------+ +----+ 459 | | | | | 460 | +---+------+-+ +-N9-+ 461 +-----| gNB | 462 +------------+ 464 Figure 2: 5G Service Based Architecture 466 3.2. End-to-end Protocol Stack 468 The protocol stack for the User Plane transport for a PDU session is 469 depicted below in Figure 3. 471 +-----+ | | | 472 | App +---------------------|-----------------------|----------| 473 +-----+ | | +------+ | 474 | PDU +---------------------|-----------------------|-+ PDU | | 475 +-----+ +---------------+ | +-----------------+ | +------+ | 476 | | |\ /| | |\ /| | | | | 477 | | | \ Relay / | | | \ Relay / | | | | | 478 | | | \ / | | | \ / | | |5G UP | | 479 | AN | | --+-- | | | ---+--- | | | Enc | | 480 | Pro | |AN Pro | GTP-U +--|--+ GTP-U |5GUP Enc+--|-+ | | 481 | Lyrs| | Lyrs +-------+ | +--------+--------+ | +------+ | 482 | +--+ |UDP/IP +--|--+ UDP/IP | UDP/IP +--|-+UDP/IP| | 483 | | | +-------+ | +--------+--------+ | +------+ | 484 | | | | L2 +--|--+ L2 | L2 +--|-+ L2 | | 485 | | | +-------+ | +--------+--------+ | +------+ | 486 | | | | L1 +--|--+ L1 | L1 +--|-+ L1 | | 487 +-----+ +-------+-------+ | +--------+--------+ | +------+ | 488 UE AN N3 UPF N9 N6 489 UPF 490 (PDU Session Anchor) 492 Legend: 493 o PDU layer: This layer corresponds to the PDU carried between the UE 494 and the DN over the PDU session. When the PDU session Type is 495 IPV6, it corresponds to IPv6 packets; When the PDU session Type 496 is Ethernet, it corresponds to Ethernet frames; etc. 497 o GPRS Tunnelling Protocol for the user plane (GTP U): This protocol 498 supports multiplexing traffic of different PDU sessions (possibly 499 corresponding to different PDU session Types) by tunnelling user 500 data over N3 (i.e. between the AN node and the UPF) in the 501 backbone network. GTP shall encapsulate all end user PDUs. It 502 provides encapsulation on a per PDU session level. This layer 503 carries also the marking associated with a QoS Flow. 504 o 5G Encapsulation: This layer supports multiplexing traffic of 505 different PDU sessions (possibly corresponding to different PDU 506 session Types) over N9 (i.e. between different UPF of the 5GC). 507 It provides encapsulation on a per PDU session level. This layer 508 carries also the marking associated with a QoS Flow. 510 Figure 3: Non-roaming 5G SA for multiple PDU Sessions 512 3.3. Mobility Architecture with reference to N9 514 This document focuses on the N9 interface which represents the user 515 user plane between UPFs in 5G architecture. Figure 4 shows the 516 relevant functions and interfaces. 518 +-----------------+ 519 | SMF | 520 +-+-------------+-+ 521 | | 522 N4 N4 523 | | 524 +-----------+ +------+-+ +-+------+ +----+ 525 | gNB/RAN |---N3---+ UPF |---N9----| UPF +---N6---| DN | 526 +-----------+ +--------+ +--------+ +----+ 528 Figure 4: N3, N4, N9, and N6 interfaces in 5G Service Based 529 Architecture 531 3.3.1. User Plane Function (UPF) Functionalities 533 The User plane function (UPF) is the function relevant to this 534 evaluation and the N9 interface between two UPFs. 536 The User Plane Function (UPF) handles the user plane path of PDU 537 sessions. The UPF transmits the PDUs of the PDU session in a single 538 tunnel between 5GC and (R)AN. The UPF includes the following 539 functionality. Some or all of the UPF functionalities may be 540 supported in a single instance of a UPF. Not all of the UPF 541 functionalities are required to be supported in an instance of user 542 plane function of a Network Slice. 544 The following provides a brief list of main UPF functionalities. 545 Please refer to section 6.2.3 of [TS.23.501-3GPP] for detailed 546 description of UPF and its functionalities. 548 o Anchor point for Intra-/Inter-RAT mobility (when applicable)" 550 o Sending and forwarding of one or more end marker to the source NG- 551 RAN node 553 o External PDU Session point of interconnect to Data Network. 555 o PDU session type: IPv4, IPv6, Ethernet, Unstructured (type of PDU 556 totally transparent to 5GS) 558 o Activation and release of the UP connection of an PDU session, 559 upon UE transition between the CM-IDLE and CM-CONNECTED 560 states(i.e. activation and release of N3 tunnelling towards the 561 access network) 563 o Data forwarding between the SMF and the UE or DN (e.g. IP address 564 allocation or DN authorization during the establishment of a PDU 565 session) 567 o Packet routing and forwarding (e.g. support of Uplink classifier 568 to route traffic flows to an instance of a data network, support 569 of Branching point to support IPv6 multi-homed PDU session> 571 o Branching Point to support routing of traffic flows of an IPv6 572 multi-homed PDU session to a data network, based on the source 573 Prefix of the PDU 575 o User Plane part of policy rule enforcement (e.g. Gating, 576 Redirection, Traffic steering) 578 o Uplink Classifier enforcement to support routing traffic flows to 579 a data network, e.g. based on the destination IP address/Prefix of 580 the UL PDU 582 o Lawful intercept (UP collection) 584 o Traffic usage reporting 586 o QoS handling for user plane including: 588 * packet filtering, gating, UL/DL rate enforcement, UL/DL 589 Session-AMBR enforcement (with the Session-AMBR computed by the 590 UPF over the Averaging window provisioned over N4, see 591 subclause 5.7.3 of 3GPP [TS.23.501-3GPP]), UL/DL Guaranteed 592 Flow Bit Rate (GFBR) enforcement, UL/DL Maximum Flow Bit Rate 593 (MFBR) enforcement, etc 595 * marking packets with the QoS Flow ID (QFI) in an encapsulation 596 header on N3 (the QoS flow is the finest granularity of QoS 597 differentiation in the PDU session) 599 * enabling/disabling reflective QoS activation via the User 600 Plane, i.e. marking DL packets with the Reflective QoS 601 Indication (RQI) in the encapsulation header on N3, for DL 602 packets matching a QoS Rule that contains an indication to 603 activate reflective QoS 605 o Uplink Traffic verification (SDF to QoS flow mapping, i.e. 606 checking that QFIs in the UL PDUs are aligned with the QoS Rules 607 provided to the UE or implicitly derived by the UE e.g. when using 608 reflective QoS) 610 o Transport level packet marking in the uplink and downlink, e.g. 611 based on 5QI and ARP of the associated QoS flow. 613 o Downlink packet buffering and downlink data notification 614 triggering: This includes the support and handling of the ARP 615 priority of QoS Flows over the N4 interface, to support priority 616 mechanism: 618 * "For a UE that is not configured for priority treatment, upon 619 receiving the "N7 PDU-CAN Session Modification" message from 620 the PCF with an ARP priority level that is entitled for 621 priority use, the SMF sends an "N4 Session Modification 622 Request" to update the ARP for the Signalling QoS Flows, and 623 sends an "N11 SM Request with PDU Session Modification Command" 624 message to the AMF, as specified in clause 4.3.3.2 of 625 [TS.23.502-3GPP]. 627 * "If an IP packet arrives at the UPF for a UE that is CM-IDLE 628 over a QoS Flow which has an ARP priority level value that is 629 entitled for priority use, delivery of priority indication 630 during the Paging procedure is provided by inclusion of the ARP 631 in the N4 interface "Downlink Data Notification" message, as 632 specified in clause 4.2.3.4 of [TS.23.502-3GPP]." 634 o ARP proxying as specified in [RFC1027] and / or IPv6 Neighbour 635 Solicitation Proxying as specified in [RFC4861] functionality for 636 the Ethernet PDUs. The UPF responds to the ARP and / or the IPv6 637 Neighbour Solicitation Request by providing the MAC address 638 corresponding to the IP address sent in the request. 640 o Packet inspection (e.g. Application detection based on service 641 data flow template and the optional PFDs received from the SMF in 642 addition) 644 o Traffic detection capabilities. 646 * For IP PDU session type, the UPF traffic detection capabilities 647 may detect traffic using traffic pattern based on at least any 648 combination of: 650 + PDU session 652 + QFI 654 + IP Packet Filter Set. Please refer to section 5.7.6.2 of 655 3GPP TS 23.501 for further details. 657 * For Ethernet PDU session type, the SMF may control UPF traffic 658 detection capabilities based on at least any combination of: 660 + PDU session 662 + QFI 663 + Ethernet Packet Filter Set. Please refer to section 5.7.6.3 664 of 3GPP TS 23.501 for further details. 666 o Network slicing Requirements for different MM mechanisms on 667 different slice. The selection mechanism for SMF to select UPF 668 based on the selected network slice instance, DNN and other 669 information e.g. UE subscription and local operator policies. 671 3.3.2. N9 Interface 673 The details of N9 interface are extracted from [TR.29.891-3GPP]. 675 The following information is sent in an encapsulation header over the 676 N3 interface. N9 needs to support that. 678 o QFI (QoS Flow Identifier), see subclause 5.7.1 of 679 [TS.23.501-3GPP]. 681 o RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of 682 [TS.23.501-3GPP]. 684 o Support of RAN initiated QoS Flow mobility, when using Dual 685 connectivity, also requires the QFI to be sent within End Marker 686 packets. See subclause 5.11.1 of [TS.23.501-3GPP] and subclause 687 4.14.1 of [TS.23.502-3GPP] respectively. 689 GTPv1-U as defined in [TS.29.281-3GPP] is used over the N3 and N9 690 interfaces in Release 15. Release 15 is still work-in-progress and 691 RAN3 will specify the contents of the 5GS Container. It is to be 692 decided whether CT4 needs to specify new GTP-U extension header(s) in 693 [TS.29.281-3GPP] for the 5GS Container. 695 A GTP-U tunnel is used per PDU session to encapsulate T-PDUs and 696 GTP-U signaling messages (e.g. End Marker, Echo Request, Error 697 Indication) between GTP-U peers. 699 A 5GS Container is defined as a new single GTP-U Extension Header 700 over the N3 and N9 interfaces and the elements are added to this 701 container as they appear with the forthcoming features and releases. 702 This approach would allow to design the 5GS information elements 703 independently from the tunneling protocol used within the 5GS, i.e. 704 it would achieve the separation of the Transport Network Layer (TNL) 705 and Radio Network Layer (RNL) as required in 3GPP TR 38.801 subclause 706 7.3.2. This would allow to not impact the RNL if in a future release 707 a new transport network layer (TNL) other than GTP-U/UDP/IP (e.g. 708 GRE/IP) was decided to be supported. 710 3.4. Roaming Architectures 712 3GPP specifies two roaming models in [TS.23.501-3GPP], namely the 713 Local Break Out (LBO) and the Home Routed (HR) model. 715 o Local Break Out Model: This model enables traffic to be offloaded 716 locally in the visited network. 718 o Home Routed Model: In this model, the traffic is always routed to 719 the home network. 721 A given UE can have multiple simultaneous PDU sessions with different 722 roaming models. In these scenarios, the HPLMN uses subscription data 723 per Data Network Name(DNN) and per Single Network Slice Selection 724 Assistance Information(S-NSSAI) to determine PDU sessions's roaming 725 model. 727 They are represented in Figure 5 and Figure 6 to the extent relevant 728 to N9. 730 VPLMN | HPLMN 731 +-----+ +-------+ | +-------+ 732 | AF |----N5---| V-PCF |-----------N24-------| H-PCF | 733 +-----+ +-------+ | +-------+ 734 | | 735 N7 | 736 | | 737 +--+--+ | 738 | SMF | | 739 +--+--+ | 740 | | 741 +-------+ N4 | 742 | 5G UE + | | 743 +---+---+ +-----+--+ | 744 | | | | 745 | +---+-+ +-+-+ +-+-+ +----+ | 746 +---| gNB |---|UPF|-N9-|UPF|--| DN | | 747 +-----+ +-+-+ +---+ +----+ | 749 Figure 5: Roaming 5G System Architecture - Local Breakout Scenario 750 VPLMN | HPLMN 751 -------------------- N32 ---------------------------- 752 | | | 753 | +-------+ | +-------+ | +-----+ 754 | | V-PCF |--- N24 ---| H-PCF |---N5---| AF | 755 | +-------+ | +-------+ | +-----+ 756 | | | | 757 | | N7 | 758 | | | | 759 | +--+--+ | +--+--+ | 760 +------|V-SMF| | |H-SMF|--+ 761 +--+--+ | +--+--+ 762 | | | 763 +-------+ | | | 764 | 5G UE | | | | 765 +---+---+ N4 | N4 766 | | | | 767 | +-+---+ +--+--+ | +--+--+ +----+ 768 +-----| gNB |-----| UPF |-----N9------| UPF |------| DN | 769 +-----+ +--+--+ | +-----+ +----+ 771 Figure 6: Roaming 5G System Architecture- Home Routed Scenario 773 3.4.1. Roaming and policy management 775 In general, the Policy Control Functions (PCF)s in Home PLMN (HPLMN) 776 and Visited PLMN (VPLMN) interact with their respective SMFs as well 777 as one another to support roaming. 779 The interface between the PCF and SMF allows the PCF to have dynamic 780 control over policy and charging decisions at SMF. More 781 specifically, the interface 783 o Enables the SMF to establish PDU session, 785 o Allows policy and charging control decisions to be requested from 786 the SMF to the PCF direction or to be provisioned from the 787 opposite direction. 789 o Provides a mean for SMF to deliver network events and PDU session 790 parameters to PCF. 792 o Provides for PDU session termination at either PCF or SMF end. 794 The N24 interface betweeen V-PCF and H-PCF provides a communication 795 path between these two entities. The interface enables H-PCF to 796 provision access and mobility management related policies to V-PCF, 797 and allows V-PCF to send Policy Association Establishmenent and 798 Termination requests to H-PCF during UE registration and 799 deregistration procedures. 801 3.4.2. Local Break Out Model 803 In the LBO model, visited operator routes user traffic locally 804 through UPFs that are local to the visited operator. In this model, 805 the SMF and all UPF(s) involved by the PDU Session are located and 806 are under the control of the VPLMN. 808 In this model, the V-PCF generates Policy and Charging Control (PCC) 809 rules from the local configuration data that are based on the roaming 810 agreement with the HPLMN. The V-PCF might also use information from 811 Application Function(AF) to generate PCC rules for VPLMN delivered 812 services. Here, the H-PCF uses the N24 interface to deliver UE 813 access selection, and PDU session selection policies to the V-PCF. 814 The V-PCF can either provide access and mobility policy information 815 on its own, or alternatively obtain the required information from the 816 H-PCF via the N24 interface. 818 3.4.3. Home Routed Model 820 In the HR model, user traffic is routed to the UPF in HPLMN via the 821 UPF in the visited network. In this scenario, the SMF in HPLMN 822 (H-SMF) selects the UPF(s) in the HPLMN and the SMF in VPLMN(V-SMF) 823 selects the UPF(s) in the VPLMN. In this model, the UE obtains 824 services from its home network. Here, the UPF acting as PGW resides 825 in home network, and can directly communicate with policy and billing 826 system. 828 In the HR roaming model: 830 o The NAS SM terminates at the V-SMF. 832 o The V-SMF forwards SM related informaton to the SMF in the HPLMN. 834 o The V-SMF sends UE's Subscription Permanent Identifier(SUPI) to 835 the H-SMF during the PDU session establishment procedure. 837 o The V-SMF sends the PDU Session Establishment Request message to 838 the H-SMF along with the S-NSSAI with the value from the HPLMN. 840 o The H-SMF obtains subscription data directly from the Unified Data 841 Management(UDM) and is responsible for checking the UE request 842 with regard to the user subscription, and may reject the request 843 in case of mismatch. 845 o The H-SMF may send QoS requirements associated with a PDU Session 846 to the V-SMF. This may happen at PDU Session establishment and 847 after the PDU Session is established. The interface between H-SMF 848 and V-SMF is also able to carry (N9) User Plane forwarding 849 information exchanged between H-SMF and V-SMF. The V-SMF may 850 check QoS requests from the H-SMF with respect to roaming 851 agreements.At the user plane, the ecapsulation header carries QoS 852 flow ID (QFI) over N3, and N9 without any changes to the end to 853 end packet header. 855 o The AMF selects a V-SMF and a H-SMF, and provides the identifier 856 of the selected H-SMF to the selected V-SMF. 858 o The H-SMF performs IP address management procedure based on the 859 selected PDU session type. 861 3.5. Support for Multiple PDU Sessions 863 Figure 7 depicts the non-roaming architecture for UEs concurrently 864 accessing two (e.g. local and central) data networks using multiple 865 PDU Sessions, using the reference point representation. This figure 866 shows the architecture for multiple PDU Sessions where two SMFs are 867 selected for the two different PDU Sessions. However, each SMF may 868 also have the capability to control both a local and a central UPF 869 within a PDU Session. 871 Service Based Interfaces 872 ---------+------------+------------------+---------------------- 873 | | 874 +--+--+ +--+--+ 875 | SMF | | SMF | 876 +--+--+ +--+--+ 877 | | 878 +-------+ N4 N4 879 | 5G UE | | | 880 +---+---+ +--+--+ +----+ +-----------+ 881 | +---| UPF |----| DN | | | 882 | | +-----+ +----+ | | 883 | +-+---+-+ +--+--+ +--+--+ +----+ 884 +-----| gNB |--------------------| UPF |--N9-| UPF |--| DN | 885 +-------+ +-----+ +-----+ +----+ 887 Figure 7: Non-roaming 5G System Architecture for multiple PDU 888 Sessions Service Based Interface 890 Figure 8 depicts the non-roaming architecture in case concurrent 891 access to two (e.g. local and central) data networks is provided 892 within a single PDU Session. 894 Service Based Interfaces 895 ---------+-----------------------+----------------------- 896 | 897 +--+--+ 898 | SMF | 899 +--+--+ 900 | 901 +-------+ +------+-------+ 902 | 5G UE | | | 903 +---+---+ N4 N4 904 | +-+---+ +--+--+ +--+--+ +----+ 905 +-----| gNB |-------| UPF |----N9--| UPF |----| DN | 906 +-----+ +--+--+ +-----+ +----+ 907 | 908 +--+--+ 909 | DN | 910 +-----+ 912 Figure 8: Non-roaming 5G System Architecture for Current Access to 913 Two (e.g. local and central) Data Networks (single PDU Session option 915 Figure 9 depicts overview of a network model where multiple UPFs are 916 distributed geographically. Such networks have two types of UPFs: 917 central UPF (cUPF) deployed for covering wide area, and local/ 918 distributed UPF (dUPF) deployed close to UEs' access points. UPFs 919 are connected via N9 interfaces over transport network. 921 +----------+ 922 | cDN/ | 923 | Internet | 924 +----------+ 925 |N6 926 +-----+-----+ 927 | cUPF | 928 +-----+-----+ 929 |N9 930 ,-----------------------+-----------------------. 931 / \ 932 | Transport Network | 933 \ / 934 `----+---------------------------+--------------' 935 |N9 |N9 936 +-----+-----+ +-----+-----+ 937 | dUPF#1 |N6 +-------+ | dUPF#2 |N6 +-------+ 938 | [UL/CL] +---| dDN#A | | [UL/CL] +---| dDN#B | 939 +-----------+ +-------+ +-----------+ +-------+ 940 |N3 |N3 941 +-----+ +-----+ 942 | gNB | | gNB | 943 +-----+ +-----+ 944 | | 945 +----+ +----+ 946 | UE | | UE | 947 +----+ +----+ 949 dUPF: Distributed UPF 950 cUPF: Central UPF 951 dDN: Distributed DN 952 cDN: Central DN 954 Figure 9: Overview of Network Model with Distributed UPFs 956 3.6. Service and Session Continuity Modes 958 The 5G System supports different session and service continuity (SSC) 959 modes. 961 _SSC mode 1_: the network preserves the connectivity service provided 962 to the UE. 964 _SSC mode 2_: the network may release the connectivity service 965 delivered to the UE and release the corresponding PDU Session. 967 _SSC mode 3_: changes to the user plane can be visible to the UE, 968 while the network ensures that the UE suffers no loss of 969 connectivity. A connection through new PDU Session Anchor point is 970 established before the previous connection is terminated in order to 971 allow for better service continuity. 973 4. Architectural requirements 975 [I-D.hmm-dmm-5g-uplane-analysis] provides a comprehensive summary of 976 GTP architecture, and architectural requirements related to user 977 plane collected from 3GPP specifications that we summarize here: 979 ARCH-Req-1: Supporting IPv4, IPv6, Ethernet and Unstructured PDU 981 The 5G system defines four types of PDU session as IPv4, IPv6, 982 Ethernet, and Unstractured, and UP protocol would be required to 983 support to convey all of these PDUs session type. 985 ARCH-Req-2: Supporting IP Connectivity over N3, N6, and N9 987 The 5G system provides IP connectivity over N3, N6, and N9 988 interfaces. 990 ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a 991 single PDU session 993 The 5G system allows to deploy multiple UPFs as anchors for a single 994 PDU session, and suupports multihoming of a single PDU session for 995 such anchor UPFs. 997 ARCH-Req-4: Supporting flexible UPF selection for PDU 999 The appropriate UPFs are selected for a PDU session based on 1000 parameters and information such as UPF's dynamic load or UE location 1001 information. 1003 ARCH-Req-5: No limitation for number of UPFs in a user plane path 1005 The number of UPF in the data path is not constrained by 3GPP 1006 specifications. 1008 ARCH-Req-6: Supporting aggregation of multiple QoS Flow indicated 1009 with QFI into a PDU Session 1011 In the 5G system, a single tunnel/data-path includes multiple QFIs 1012 contrast to just one QoS Flow (a bearer) to one tunnel/data-path 1013 User plane protocol needs to support fundamentally these 1014 requirements. In addition, [I-D.hmm-dmm-5g-uplane-analysis] provides 1015 evaluation aspects for user plane protocol that are mainly derived 1016 from the architectural requirements, such as Supporting PDU Session 1017 Type Variations, Nature of Data Path, Data Path Management, etc. The 1018 details are described in [I-D.hmm-dmm-5g-uplane-analysis]. 1020 For each protocol, we will attempt in the next section to discuss to 1021 what extent those architectural requirements are addressed. However, 1022 it is worth noticing that it is not mandatory that all those 1023 requirements are supported by the user plane protocol itself, as they 1024 might be realized through complementary mechanisms Section 6.6. 1026 5. Data plane architecture models for N9 1028 5.1. Overview 1030 The user plane architectures considered for UPF connectivity in 1031 mobile packet core fall into two categories: 1033 o Interworking model: 1035 * This model uses GWs. 1037 * UPFs and 3GPP control remain unchanged. 1039 * 3GPP user plane becomes an overlay on top of new user planes 1041 * GWs convert GTP traffic to underlying user plane format. 1043 o Integrated model: 1045 * In this model UPFs transmit/receive packets in accordance with 1046 the new user plane format. 1048 * UPFs and 3GPP control will be modified. 1050 * 3GPP and transport user plane are collapsed into one user 1051 plane. 1053 5.2. Forwarding and mobility paradigms 1055 Based on their use of identifiers and locators, mobility approaches 1056 can be broadly categorized in the three following classes: 1058 *Locator-based* 1059 IP communication relies solely on locators (host interfaces' 1060 addresses) that are also used as node/service identifiers at network 1061 layer. Such semantic overloading of IP addresses as both identifiers 1062 and locators does not allow to disentangle locators from location- 1063 independent traffic identifiers, thus complexifying mobility 1064 management. 1066 As a result, traffic anchors and tunnels have been introduced to 1067 handle mobility while preserving the identifier exposed to the 1068 transport layer. 1070 *Locator-ID separation* 1072 To overcome the limitations of purely locator-based architectures, 1073 "locator/identifier separation" (or Loc/ID split) schemes have been 1074 proposed, that use separate namespaces for so-called End-point 1075 Identifiers (EID) and Route Locators (RLOC), bound together through a 1076 mapping system. This service can be centralized, decentralized or 1077 distributed and offers control plane protocols for storage, update or 1078 retrieval of the correspondence between EIDs and RLOCs. 1080 Loc/ID split has been originally proposed by LISP to solve the 1081 scalability challenges of Internet routing, and further adapted as a 1082 mobility management solution. This category includes most of the 1083 approaches reviewed in this document, namely ILA, ILSR and a 1084 SRv6-based solution, which all share the requirement for a mapping 1085 system. 1087 *ID-based* 1089 A third class of approaches exists that redefines IP communication 1090 principles (i.e. network and transport layers) around location- 1091 independent identifiers [I-D.vonhugo-5gangip-ip-issues]. 1093 Information-Centric Networking (ICN) approaches fall into such class 1094 of approaches that we refer to as purely ID-based, or in that 1095 specific case, as name-based [I-D.irtf-icnrg-terminology]. Previous 1096 work has highlighted the interest of ICN for mobility management 1097 [RFC7476]. 1099 The rest of this section details the set of reviewed approaches, 1100 namely SRv6, LISP, ILSR, ILA and hICN, as summarized in Figure 10. 1101 Each proposal consists in an overview with pointers to reference 1102 material for a more in depth description. The focus is then given to 1103 a discussion on its integration at N9 interface, as well as the 1104 benefits with respect to GTP-U. Extensions to N3 interface as well 1105 as alternative deployments preserving GTP tunnels as discussed later 1106 in this document in Section 6. 1108 *Reviewed approaches* 1110 |_ Mobility Management 1111 |_ Locator-based 1112 |_ Tunnelling 1113 |_ 3GPP / GTP-U Sec. 4 1114 |_ Packet steering 1115 |_ SRv6 (backwards-compatible) Sec. 5.2.1 1116 |_ Loc/ID split 1117 |_ Packet steering 1118 |_ SRv6 Sec 5.2.2 1119 |_ Encapsulation 1120 |_ LISP, LISP-MN, ILSR Sec. 5.3 1121 |_ Address rewrite 1122 |_ Network-based translation 1123 |_ ILA Sec. 5.5 1124 |_ ID-based 1125 |_ Information-Centric Networking 1126 |_ ID-based mobility / IPv6 1127 |_ Hybrid ICN Sec. 5.6 1129 Figure 10: Overview of reviewed approaches 1131 5.3. SRv6 1133 5.3.1. Overview 1135 SRv6 [I-D.filsfils-spring-srv6-network-programming] is the IPv6 1136 dataplane instantiation of Segment Routing 1137 [I-D.ietf-spring-segment-routing]. Segment Routing is a network 1138 architecture based on source-routing (the headend inserts the nodes 1139 that a packet must traverse for TE, NFV and VPN purposes). Thus 1140 confining flow states to the ingress nodes in the SR domain. 1142 The SRv6 dataplane consists on leveraging the IPv6 extension headers, 1143 defined in RFC8200, to include in the IPv6 header a new "Segment 1144 Routing Header" [I-D.ietf-6man-segment-routing-header] (SRH). 1146 SRv6 encodes segments (SIDs) as IPv6 addresses in the Segment List of 1147 its header. The IPv6 Destination Address (DA) specifies the active 1148 segment in the Segment List, while the Segments Left (SL) field of 1149 the SRH points to the next active segment in the Segment List. SRv6 1150 routes over the shortest ECMP-aware path in the network up the the 1151 node instantiating the active segment. Once the packet has reached 1152 this node, the segment is executed. This implies running its 1153 associated function on the router, decrementing the SL value and 1154 updating the IPv6 DA to the next active segment. Notice that transit 1155 routers neither inspect the SRH nor process it. Thus they only need 1156 to be IPv6 capable. 1158 The main benefit of SRv6 overlays is the reduction of state in the 1159 network (there is no state in the forwarding fabric), with optimized 1160 MTU overhead, and its capability to integrate with the underlay (SLA; 1161 Traffic Engineering) and distributed NFVi. Hence there is no need 1162 NSH for NVF, RSVP for TE, or UDP for ECMP. SR also supports natively 1163 network slicing, which implies that SRv6 can offer end-to-end network 1164 slices that spans all those elements (overlay, underlay, NFV). 1166 The versatility and adaptability of SR combined with IPv6's ample and 1167 flexible address space positions SRv6 as a viable user plane for the 1168 next generation of mobile user-plane, in particular the 3GPP N3 and 1169 N9 interfaces. Notice that SRv6 applicability does not require a new 1170 mobility control-plane. SRv6 can be combined with other control- 1171 planes such as LISP, hICN described later in this document or others 1172 such as DHT, propietary CP, etc. 1174 The applicability of SRv6 to mobility is described in 1175 [I-D.ietf-dmm-srv6-mobile-uplane]. 1177 SRv6 counts with three open-source implementations (Linux Kernel, 1178 FD.io VPP, P4) and several propietary implementations (4xCisco, 1179 1xBarefoot Networks, 1xUTStarcom) which have publicly participated in 1180 interops and all execute at linecard rate. 1182 This section starts by summarising the use of SRv6 as a drop-in 1183 alternative for GTP-U over the N9 interface connecting different User 1184 Plane Functions (UPF). It then shows how SRv6 as a GTP-U replacement 1185 can then provide additional features such as TE, IP session 1186 aggregation, rate limiting, and distributed NFVi that are not 1187 natively available by GTP. 1189 It must be noted that the SRv6 models discussed in this document can 1190 follow either of the interworking or the integration model mentioned 1191 earlier depending on operator's requirements. 1193 SRv6 appears well placed as a mechanism to replace GTP-U with 1194 initially no control plane changes, but to then offer a progressive 1195 path towards many innovations in routing. 1197 5.3.2. SRv6 with Traffic Engineering 1199 SRv6 can be applied as a drop-in replacement for GTP without changes 1200 in the control-plane. This is a simple 1 to 1 replacement discussed 1201 in section 6.1. However, SRv6 offers much richer possibilities. 1203 Traffic engineering is a native feature of SR. The SRv6 variant of 1204 SR of course supports both strict and loose models of source routing. 1205 Here, the SID list in SRH can represent a loose or strict path to 1206 UPFs. Therefore, traffic engineering can easily be supported 1207 regardless of any of the aforementioned approaches. 1209 The main benefit of leveraging SRv6 for TE is the natural ability to 1210 create end-to-end network slices that spans both the UPFs and the 1211 underlaying transport network with TE optimization objectives (i.e. 1212 low-latency). 1214 It must be noted that the SRH could contain multiple sets of SIDs 1215 each representing a TE path between a pair of UPFs. Alternatively, 1216 the SRH can contain a fully resolved end to end TE path that covers 1217 every intermediate node and UPF along the user plane. 1219 SR considers segments to be instructions. Therefore each SID can 1220 represent a function that enforces a specific nodal or global packet 1221 treatment. Attributes such as jitter and delay requirement, rate 1222 limiting factors, etc. can be easily encoded in to SIDs in order to 1223 apply the desired treatment as packets traverse the network from UPF 1224 to UPF. [I-D.ietf-dmm-srv6-mobile-uplane] suggests a SID encoding 1225 mechanism for rate limiting purposes. 1227 Please refer to the followings for further details about SR traffic 1228 engineering capabilities, the network programming concept, and some 1229 of the main SRv6 functions. 1231 o [I-D.ietf-spring-segment-routing] 1233 o [I-D.ietf-spring-segment-routing-policy] 1235 o [I-D.filsfils-spring-srv6-network-programming] 1237 o [I-D.ietf-6man-segment-routing-header] 1239 5.3.3. Service Programming with SRv6 1241 Service programming -or distributed NFVi- is another intrinsic 1242 feature of SR. Leveraging this capability, operators can steer user 1243 traffic through a set of UPFs where each UPF performs a specific 1244 service on the traffic. 1246 Service programming is achieved through the use of SIDs in an 1247 identical manner to what was described in the previous section: the 1248 SRH is populated with a set of SIDs with each SID identifying a 1249 specific UPF in the network. Starting from the ingress SRv6 node, 1250 packets are then forwarded through the network visiting the set of 1251 UPFs listed as SIDs in the SRH. 1253 Please refer to [I-D.xuclad-spring-sr-service-chaining] for further 1254 detail. 1256 5.3.4. SRv6 and Entropy 1258 Ability to provide a good level of entropy is an important aspect of 1259 user plane protocols. If included in network node's hashing, the 1260 TEID field in GTP tunnels algorithms can result in good load 1261 balancing. Therefore, any new user plane proposal should be able to 1262 deal with entropy in an efficient manner. 1264 SRv6 natively supports entropy by using the IPv6 Flow Label. 1265 Additionally, SRv6 SIDs can easily accommodate entropy at a hop by 1266 hop level by reserving a set of bits in the SID construct itself. In 1267 this way, the hashing algorithm at different nodes distribute traffic 1268 flows based on the SID which has been copied to IPv6 DA field. 1270 5.3.5. SRv6 and transport slicing 1272 Slicing is one of the main features in 5G [TS.23.501-3GPP]. Several 1273 Slices with different requirements can coexist on top of the common 1274 network infrastructure. Diverse flows belonging to different 5G 1275 slices can be completely disjoint or can share different parts of the 1276 network infrastructure. SRv6 has native support for network slicing 1277 spanning the UPFs, underlay -transport network- and NFVi. Also, SRv6 1278 creates network slices without per-flow state in the fabric, hence 1279 simplifying the slicing paradigm. 1281 Please refer to [I-D.ietf-spring-segment-routing-policy] for further 1282 detail. 1284 5.3.6. SRv6 and Alternative Approaches to Advanced Mobility Support 1286 SRv6 flexibility enables it to support different methods of providing 1287 mobility in the network. ID-LOC for mobility support is one such 1288 option. 1290 The previous sections discussed how SRv6 could be employed as a 1291 replacement for GTP tunnels while leaving the existing control plane 1292 intact. This section describes the use of SRv6 as a vehicle to 1293 implement Locator/ID Separation model for UPF user plane 1294 connectivity. It must be ntoed that SRv6 implementation of the ID- 1295 LOC architecture can employ a variety of different control planes 1296 including LISP, , different variety of DHT, proprietary, etc. 1298 5.3.6.1. UPF connectivity via SRv6 with Loc-ID separation (Interworking 1299 model) 1301 SRv6 can easily implement ID-LOC Separation model for UPF 1302 connectivity. The SIDs are once again the main vehicle here. In 1303 this model, UPFs are considered to be the IDs while the nodes where 1304 the UPFs attach to take on the role of the Locators. 1306 In this approach, UPFs connect to SRv6 capable Locators. UPFs use 1307 IPv4/IPv6 transport either in conjunction with GTP or without any GTP 1308 tunnel and send the packets to their associated Locator at the near 1309 end (Ingress SRv6 Locator). 1311 It must be noted that use of GTP at UPFs allows us to leave the 3GPP 1312 control plane intact and hence provides a smooth migration path 1313 toward SRv6 with ID-Locator model. 1315 5.3.6.2. SRv6 Capable UPFs and RLOCs (Integration model) 1317 In this model, the head-end UPF (Ingress UPF) is the ingress node and 1318 the entity that constructs the SRH in the SRv6 domain. 1320 The 3GPP control plane is responsible for distributing UPF's endpoint 1321 information. But it requires some modifications to be able to convey 1322 endpoint information to interested parties. 1324 The SMF can provide a fully resolved SID list by communicating with a 1325 centralised or distributed ID-LOC mapping system containing all the 1326 relevant data regarding the UPF-Locator relationship. 1328 5.3.6.3. Advanced Features in ID-Locator Architecture 1330 SRv6's native features such as Traffic Engineering, QoS support, UPF 1331 Chaining, network slicing, etc. can be easily added to ID-Locator 1332 support. As it was noted earlier, these features are not readily 1333 available by GTP. 1335 5.3.7. Areas of Concerns 1337 Support for IPv6 is a precondition for SRv6. Although SRv6 can 1338 support hybrid IPv4/IPv6 mobile user plane through an interworking 1339 node, support of UPFs with IPv4 address is rather complex. 1341 Due to IPv6 128-bit address space, large SRH size can have a negative 1342 impact on MTU. Large SRH size can also exert undesirable header tax 1343 especially in the case of small payload size. 1345 ID-LOC architecture relies on high performance mapping systems. The 1346 SRv6 support of ID-LOC as described earlier can employ different 1347 control planes. Distributed mapping systems using some form 1348 Distributed Hash Table(DHT) however, exhibit very promising results. 1349 But further investigation is needed to ensure comformance with 1350 performance metrics required by the mobile networks, specially for 1351 slice types supporting high speed mobility. 1353 5.4. LISP 1355 5.4.1. Overview 1357 The Locator/Identifier Separation Protocol (LISP), which provides a 1358 set of functions for routers to exchange information used to map from 1359 Endpoint Identifiers (EIDs) that are not globally routable to 1360 routable Routing Locators (RLOCs). It also defines a mechanism for 1361 these LISP routers to encapsulate IP packets addressed with EIDs for 1362 transmission across a network infrastructure that uses RLOCs for 1363 routing and forwarding. 1365 An introduction to LISP can be found in [I-D.ietf-lisp-introduction]. 1367 A complete RFC-set of specifications can be found in [RFC6830], 1368 [RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061], 1369 [RFC8111]. They describe support and mechanisms for all combinations 1370 of inner and outer IPv4 and IPv6 packet headers for unicast and 1371 multicast packet flows that also interwork with non-LISP sites as 1372 well as two designs to realize a scalable mapping system. 1374 A standards-track based set of drafts [I-D.ietf-lisp-rfc6830bis] 1375 [I-D.ietf-lisp-rfc6833bis] are products and work in progress of the 1376 LISP Working Group. 1378 5.4.2. LISP Encapsulation 1380 LISP uses dynamic tunnel encapsulation as its fundadmental mechanism 1381 for the data-plane. Fixed headers are used between the outer and 1382 inner IP headers which are 16 bytes in length. Details can be found 1383 in [RFC6830]. 1385 5.4.3. LISP Mapping Systems 1387 Many years of research dating back to 2007 have gone into LISP 1388 scalable mapping systems. They can be found at [LISP-WG] and 1389 [IRTF-RRG]. The two that show promise and have deployment experience 1390 are LISP-DDT [RFC8111] and LISP-ALT [RFC6836]. 1392 The control-plane API which LISP xTRs are the clients of is 1393 documented in [RFC6833]. Various mapping system and control-plane 1394 tools are available [RFC6835] [RFC8112] and are in operational use. 1396 5.4.4. LISP Mobility Features 1398 LISP supports multi-homed shortest-path session survivable mobility. 1399 An EID can remain fixed for a node that roams while its dynamic 1400 binding changes to the RLOCs it uses when it reconnect to the new 1401 network location. 1403 When the roaming node supports LISP, its EIDs and RLOCs are local to 1404 the node. This form of mobility is call LISP Mobile-Node. Details 1405 can be found in [I-D.ietf-lisp-mn]. 1407 When the roaming node does not support LISP, but LISP runs in the 1408 network the node roams to, the EIDs and RLOCs are not co-located in 1409 the same device. In this case, EIDs are assigned to the roaming node 1410 and RLOCs are assigned to LISP xTRs. So when the roaming node 1411 attaches to the network, its EIDs are mapped to the RLOCs of the LISP 1412 xTRs in the network. This form of mobility is called LISP EID- 1413 Mobility. Details can be found in [I-D.ietf-lisp-eid-mobility]. 1415 For a 3GGP mobile network, the LISP EID-Mobility form of mobility is 1416 recommended and is specified in the use-case document 1417 [I-D.farinacci-lisp-mobile-network]. 1419 5.4.5. ILSR 1421 ILSR is a specific recommendation for using LISP in the 3GPP 5G 1422 mobile network architecture. A detailed whitepaper can be found at 1423 [ILSR-WP]. The recommendation is to use the mechanisms in 1424 [I-D.farinacci-lisp-mobile-network]. 1426 5.5. ILA 1428 Identifier-Locator Addressing [I-D.herbert-intarea-ila] is a protocol 1429 to implement transparent network overlays without encapsulation. It 1430 addresses the need for network overlays in virtualization and 1431 mobility that are efficient, lightweight, performant, scalable, 1432 secure, provide seamless mobility, leverage and encourage use of 1433 IPv6, provide strong privacy, are interoperable with existing 1434 infrastructure, applicable to a variety of use cases, and have 1435 simplified control and management. 1437 5.5.1. Overview 1439 ILA is a form of identifier/locator split where IPv6 addresses are 1440 transformed from application-visible, non-topological "identifier" 1441 addresses to topological "locator" addresses. Locator addresses 1442 allow packets to be forwarded to the network location where a logical 1443 or mobile node currently resides or is attached. Before delivery to 1444 the ultimate destination, locator addresses are reverse transformed 1445 back to the original application visible addresses. ILA does address 1446 "transformation" as opposed to "translation" since address 1447 modifications are always undone. ILA is conceptually similar to ILNP 1448 and 8+8, however ILA is contained in the network layer. It is not 1449 limited to end node deployment, does not require any changes to 1450 transport layer protocols, and does not use extension headers. 1452 ILA includes both a user plane and control plane. The user plane 1453 defines the address structure and mechanisms for transforming 1454 application visible identifier addresses to locator addresses. The 1455 control plane's primary focus is a mapping system that includes a 1456 database of identifier to locator mappings. This mapping database 1457 drives ILA transformations. Control plane protocols disseminate 1458 identifier to locator mappings amongst ILA nodes. 1460 The use cases of ILA include mobile networks, datacenter 1461 virtualization, and network virtualization. A recent trend in the 1462 industry is to build converged networks containing all three of these 1463 to provide low latency and high availability. A single network 1464 overlay solution that works across multiple use cases is appealing. 1466 Benefits of ILA include: 1468 o Facilitates node mobility and virtualization 1470 o Multiple use cases (mobile, datacenter, cloud) 1472 o Super efficient and performant user plane 1474 o Allows strong privacy in addressing 1476 o Promotes anchorless mobility 1478 o No typical tunneling issues (e.g. MTU) or management related to 1479 encapsulation 1481 o Flexible control plane that splits data and control 1483 o Modern "SDN" control protocols (e.g. RPC/TCP) 1484 o Scale number of nodes to billions for 5G, DC virtualization 1486 o Upstream Linux kernel data path and open source ctrl plane 1487 [ILACONTROL]. 1489 The ILA user plane protocol is described in 1490 [I-D.herbert-intarea-ila], motivation and problems areas are 1491 described in [ILAMOTIVE], ILA in the mobile user-plane is described 1492 in detail in [I-D.herbert-ila-mobile]. 1494 5.5.2. Protocol Layering 1496 Figure 11 illustrates the protocol layers of packets packets sent 1497 over various user plane interfaces in the downlink direction of data 1498 network to a mobile node. Note that this assumes the topology shown 1499 in Figure 2 where GTP-U is used over N3 and ILA is used on N9. 1501 - - - 1502 DN to ILA-R ILA-R to ILA-N ILA-N to gNB gNB to UE 1503 +------------+ +------------+ +------------+ +------------+ 1504 | Application| | Application| | Application| | Application| 1505 +------------+ +------------+ +------------+ +------------+ 1506 | L4 | | L4 | | L4 | | L4 | 1507 +------------+ +------------+ +------------+ +------------+ 1508 | IPv6 | | IPv6 (ILA) | | IPv6 | | PDU Layer | 1509 +------------+ | +------------+ | +------------+ +------------+ 1510 | L2 | | | L2 | | | GTP-U | | AN Protocol| 1511 +------------+ | +------------+ | +------------+ | Layers | 1512 | | | UDP/IP | | | 1513 N6 <--N9 N3 +------------+ +------------+ 1514 | L2 | 1515 +------------+ 1517 Figure 11: ILA and protocol layer in 5G 1519 5.5.3. Control plane 1521 ILA-M provides the interface between the 5G services architecture and 1522 the common ILA control plane. 1524 5.5.3.1. ILA-M services interface 1526 The control interface into ILA is via an ILA-M that interacts with 5G 1527 network services. ILA-M uses RESTful APIs to make requests to 1528 network services. An ILA-M receives notifications when devices enter 1529 the network, leave it, or move within the network. The ILA-M writes 1530 the ILA mapping entries accordingly. 1532 ILA is a consumer of several 5G network services. The service 1533 operations of interest to ILA are: 1535 o Nudm (Unified Data Management): Provides subscriber information. 1537 o Nsmf (Service Managment Function): Provides information about PDU 1538 sessions. 1540 o Namf (Core Access and Mobility Function): Provides notifications 1541 of mobility events. 1543 5.5.3.2. ILA control plane 1545 The ILA control plane is composed of mapping protocols that manage 1546 and disseminate information about the mapping database. There are 1547 two levels of mapping protocols: one used by ILA routers that require 1548 the full set of ILA mappings for a domain, and one used by ILA nodes 1549 that maintain a caches of mappings. 1551 The ILA mapping system is effectively a key/value datastore that maps 1552 identifiers to locators. The protocol for sharing mapping 1553 information amongst ILA routers can thus be implemented by a 1554 distributed database [I-D.herbert-ila-ilamp]. ILA separates the 1555 control plane from the user plane, so alternative control plane 1556 protocols may be used with a common user plane 1557 [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp]. 1559 The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA 1560 forwarding nodes and ILA mapping routers. The purpose of the 1561 protocol is to populate and maintain the ILA mapping cache in 1562 forwarding nodes. ILAMP defines redirects, a request/response 1563 protocol, and a push mechanism to populate the mapping table. Unlike 1564 traditional routing protocols that run over UDP, this protocol is 1565 intended to be run over TCP and may be RPC oriented. TCP provides 1566 reliability, statefulness implied by established connections, 1567 ordering, and security in the form of TLS. Secure redirects are 1568 facilitated by the use of TCP. RPC facilities such REST, Thrift, or 1569 GRPC leverage widely deployed models that are popular in SDN. 1571 5.5.4. IP addressing 1573 ILA supports single address assignments as well as prefix 1574 assignments. ILA will also support strong privacy in addressing. 1576 5.5.4.1. Singleton address assignment 1578 Singleton addresses can use a canonical 64/64 locator/identifier 1579 split. Singleton addresses can be assigned by DHCPv6. 1581 5.5.4.2. Network prefix assignment 1583 Prefix assignment can be done via SLAAC or DHCPv6-PD. 1585 To support /64 prefix assignment with ILA, the ILA identifier can be 1586 encoded in the upper sixty-four bits of an address. A level of 1587 indirection is used so that ILA transforms the upper sixty four bits 1588 to contain both a locator and an index into a locator (ILA-N) 1589 specific table. The entry in the table provides the original sixty- 1590 four bit prefix so that locator to identifier address transformation 1591 can be done. 1593 As an example of this scheme, suppose network has a /24 prefix. The 1594 identifier address format for /64 assignment might be: 1596 +-------------+---------------------|------------------------------+ 1597 | 24 bits | 40 bits | 64 bits | 1598 +-------------+---------------------|------------------------------+ 1599 | Network | Identifier | IID | 1600 +-------------+---------------------+------------------------------+ 1602 The IID part is arbitrarily assigned by the device, so that is 1603 ignored by ILA. All routing, lookups, and transformations (excepting 1604 checksum neutral mapping) are based on the upper sixty-four bits. 1606 For identifier to locator address transformation, a lookup is done on 1607 the upper sixty-four bits. That returns a value that contains a 1608 locator and a locator table index. The resulting packet format may 1609 be something like: 1611 +-------------+---------------------|------------------------------+ 1612 | 24 bits | 20 bits | 20 bits | 64 bits | 1613 +-------------+---------------------|------------------------------+ 1614 | Network | Locator | Loc index | IID | 1615 +-------------+---------+-----------+------------------------------+ 1617 The packet is forwarded and routed to the ILA-N addressed by locator 1618 (/44 route in this case). At the ILA forwarding node, the locator 1619 index is used as a key to an ILA-N specific table that returns a 40 1620 bit Identifier. This value is then written in the packet do ILA to 1621 identifier address transformation thereby restoring the original 1622 destination address. 1624 The locator index is not globally unique, it is specific to each ILA- 1625 N. When a node attaches to an ILA-N, an index is chosen so that the 1626 table is populated at the ILA-N and the ILA mapping includes the 1627 locator and index. When a node detaches from on ILA, it's entry in 1628 the table is removed and the index can be reused after a hold-down 1629 period to allow stale mappings to be purged. 1631 5.5.4.3. Strong privacy addresses 1633 Note that when a /64 is assigned to UEs, the assigned prefix may 1634 become a persistent identifier for a device. This is a potential 1635 privacy issue. 1637 5.5.5. Traffic engineering 1639 ILA is primarily a mechanism for mobility and network virtualization. 1640 Transport mechanisms for traffic engineering such as MPLS, network 1641 slices, encapsulation, routing based on flow hash(flow label) can be 1642 applied independently of ILA. This separation allows any discussion 1643 related to transport to be left to operator deployment. 1645 5.5.6. Locator Chaining with ILA 1647 ILA transformations can be performed on a hop-by-hop bases. In this 1648 manner a packet can be source routed through a sequence of nodes. At 1649 each hop a determination is made as to the next hop the packet should 1650 visit. The locator for the target is then written into the 1651 destination. Eventually, the packet will be forwarded to an ILA 1652 forwarding node that will restore the original address before 1653 delivery to the final destination. 1655 5.5.7. Security considerations 1657 A mobile public infrastructure has many considerations in security as 1658 well as privacy. Fundamentally, a system must protect against 1659 misdirection for the purposes of hijacking traffic, spoofing, 1660 revealing user identities, exposing accurate geo-location, and Denial 1661 of Service attacks on the infrastructure. 1663 The ILA mapping system contains personally identifiable information 1664 (PII) including user identities and geo-location. The information 1665 must be safeguarded. An ILA domain is confined to one administrative 1666 domain, only trusted parties entities in the domain participate in 1667 ILA. There is no concept of a global, public mapping system and UEs 1668 in public networks generally do not participate in ILA protocols 1669 since they are untrusted. ILA control protocols, include ILA 1670 redirects, use TCP. TLS or other protocols can be applied for strong 1671 security. 1673 Privacy in addressing is a consideration. ILA endeavors to provide a 1674 mechanism of address assignment that prevents inference of user 1675 identity or location. 1677 5.6. Hybrid ICN (hICN) 1679 5.6.1. Overview 1681 hICN Anchorless Mobility Management (hICN-AMM) refers to a novel 1682 mobility management approach, introduced in 1683 [I-D.auge-dmm-hicn-mobility], that leverages routable location- 1684 independent identifiers (IDs) and an Information-Centric Networking 1685 (ICN) communication model integrated in IPv6, (also referred to as 1686 Hybrid ICN, or hICN) [I-D.muscariello-intarea-hicn]. 1688 Such approach belongs to the category of pure ID-based mobility 1689 management schemes whose objective is (i) to overcome the limitations 1690 of traditional locator-based solutions like Mobile IP (conf)using 1691 locators as identifiers, (ii) to remove the need for a global mapping 1692 system as the one required by locator-identifier separation 1693 solutions. 1695 5.6.2. Consumer and Producer mobility 1697 In ICN and hICN endpoints can act as consumers and/or producers. 1698 Consumers when they emit requests for named data packets (so called 1699 Interests), producers when they send data packets in response to 1700 consumers request (pull-based transport model). Clearly a node can 1701 be a consumer and a producer at the same time (e.g. in a voice 1702 conversation). 1704 Consumer and producer mobility are handled in a different way due to 1705 the pull-based request model. More specifically, consumer mobility 1706 is natively supported: consumers pull traffic by sending Interest 1707 packets towards named content (wherever produced/stored, the source 1708 is a priori unknown by the consumer). Interests are named-based 1709 forwarded using the information found in traversed routers' FIBs. 1711 In case of consumer mobility, i.e. mobility of the endpoint issuing 1712 the requests, selection of a new available output interface and 1713 retransmission of not-yet-satisfied Interests is sufficient for data 1714 delivery to continue, independently from the underlying change of 1715 locators. Consumer mobility is fully anchorless with hICN, and does 1716 not incur any signalization nor tunneling overhead. 1718 Producer mobility is not natively supported by ICN architecture, 1719 rather handled in different ways according to the selected producer 1720 mobility management scheme. 1722 5.6.3. Anchorless mobility support 1724 The selected mobility management scheme for hICN is MAP-Me, an 1725 anchorless producer mobility management solution originally proposed 1726 for ICN [I-D.irtf-icnrg-mapme] [MAPME] and further extended to hICN 1727 in [I-D.auge-dmm-hicn-mobility]. 1729 MAP-Me belongs to the class of anchorless approaches that relies on 1730 scope-limited forwarding updates triggered by producer mobility 1731 events to keep locally up-to-date FIB information for a low-latency 1732 guaranteed reroute of consumer Interests towards changing location of 1733 the producer. Forwarding and mobility management operations in hICN 1734 are based only location-independent identifiers, preserving 1735 coexistence with IP locators whose existence may be required by non- 1736 hICN services and by control/management plane operations specific to 1737 the considered network architecture. 1739 Signaling of mobility is only required upon producer movements and 1740 limited in scope to current-to-previous network hops. Unlike routing 1741 updates, it is not necessary to update all routers' FIBs after a node 1742 has moved, but only those located on the path between the new and a 1743 former position of the producer. Scalability of producer mobility is 1744 guaranteed by an efficient and secure FIB update process with minimal 1745 and bounded path stretch. 1747 The difference w.r.t. to other classes of approaches is that it does 1748 not require an anchor neither in forwarding plane (no tunnel, traffic 1749 does not need to pass through a specific network node), nor in the 1750 control plane (no rendez-vous point, no mapping system). 1752 5.6.4. Benefits 1754 The appeal of purely ID-based architectures is that they move Loc/ID 1755 split one step further by embedding ID-awareness in the network and 1756 transport layer by default and as such completely decoupling data 1757 delivery from underlying network connectivity. The resulting 1758 mobility management solution is fully anchorless for both consumer 1759 and producer mobility. Forwarding is performed directly based on 1760 identifiers stored in routers' FIBs and no mapping of ID into 1761 locators is required. In this way, purely ID-based architectures 1762 remove the need to maintain a global mapping system at scale, and its 1763 intrinsic management complexity. 1765 Additional benefits brought specifically by ICN principles motivate 1766 the consideration of ICN solutions for next generation mobility 1767 architectures, like for instance: 1769 o the flexibility of multi-source/multi-path connectionless pull- 1770 based transport. An example is the native support for consumer 1771 mobility, i.e. the transparent emission of data requests over 1772 multiple and varying available network interfaces during node 1773 mobility; 1775 o the opportunity to define fine-grained per-application forwarding 1776 and security policies (in the network, and in-between UPFs); 1778 o low-latency and multicast capabilities by means of in-path edge 1779 caching; 1781 o network-assisted transport. 1783 An in depth analysis of benefits originating from the coupling 1784 between a purely identifier-based approach and from specific hICN 1785 properties can be found in 1786 [I-D.auge-dmm-hicn-mobility-deployment-options] along with some 1787 illustrative examples. 1789 5.6.5. Deployment considerations 1791 *Partial insertion* 1793 The benefits previously described can be obtained by an upgrade of 1794 only a few selected routers at the network edge. The design of hICN 1795 allows the rest of the infrastructure to remain unmodified, and to 1796 leverage existing management and monitoring tools. There exists thus 1797 a tradeoff between incremental deployment and benefits which are 1798 proportionally related to the degree of hICN penetration. 1800 *End-to-end deployment* 1802 The deployment of an hICN stack in endpoints is the preferred option 1803 and offers the full range of benefits. Both the hICN forwarder and 1804 the transport stack are available as reference implementations based 1805 on the CICN project [CICN]. They are both designed to facilitate 1806 insertion on routers and end-user devices thanks to implementation in 1807 user space, one targetting high-performance, the other aiming at wide 1808 support from major vendors including iOS, Android, Linux, MacOSX and 1809 Windows. 1811 *Network-contained deployment* 1813 It is not always possible nor desirable to affect endpoints, and a 1814 deployment fully contained in the network is possible through the 1815 deployment of proxies. An example would be the deployment of HTTP 1816 proxies at the ingress and egress (resp. first and last UPFs), in 1817 order to benefit from content awareness in the network. Such 1818 configuration however reduces the flexibility and dynamic forwarding 1819 capabilities in endpoints. In particular, existing transport 1820 protocols have limited support for dynamically changing paths or 1821 network conditions. 1823 Traffic that is not handled though hICN mechanisms can still benefit 1824 from the lower overhead and anchorless mobility capabilities coming 1825 from the removal of GTP tunnels, as well as dynamic forwarding 1826 capabilities that are inherent to the forwarding pipeline. This 1827 results from the ability to assign location-independent identifiers 1828 to endpoints. It preserves the advantage of removing the mapping 1829 system, and of a lightweight FIB update process. No encapsulation is 1830 required and packet headers are not modified, which allows the 1831 network to have visibility in the source and/or destination 1832 identifiers. 1834 *hICN in a slice* 1836 The use of hICN does not impose any specific slicing of the network. 1837 Rather, it can assist a transition of services towards hICN, and/or 1838 the coexistence of different hICN deployment options. 1840 As an example of use of hICN in a slice, a service provider might for 1841 instance decide to use an hICN-enabled slice dedicated to video 1842 delivery, with appropriate mobility management, and dedicated hICN 1843 nodes with appropriate caching/forwarding strategies at places 1844 aggregating considerable number of user requests. 1846 5.6.6. hICN with SRv6 1848 The association of hICN with other user planes technologies, such as 1849 SRv6, is investigated as a possibility to overcome the above- 1850 mentioned tradeoff yielding to a selective, yet fully beneficial 1851 insertion of hICN in IP networks. This would inherit all SRv6 1852 advantages for underlay (TE, FRR) and service programming (NFV), but 1853 also extend the reach of hICN on regular IP routers with SRv6 1854 functionality. 1856 One realization consists in creating SRv6 domains in between hICN 1857 nodes. The hICN router (through forwarding strategies) would then 1858 act as a control plane for SRv6 by specifying the list of SIDs to 1859 insert in the packet. 1861 5.6.7. Summary 1863 hICN proposes a general purpose network architecture that combines 1864 the benefits of a pure-ID architecture with those of ICN. While a 1865 full deployment is recommended to make efficient use of available 1866 network resources, it is still possible to opt for a partial or 1867 phased deployment, with the associated tradeoffs that we have 1868 reviewed here. 1870 An hICN enabled network offers native offloading capabilities thanks 1871 to the anchorless properties resulting from the pure-ID communication 1872 scheme. It does so without the need for a third party mapping 1873 system, and further requires no change in the 5G architecture nor in 1874 its control plane. The architecture will further leverage the 1875 incremental insertion of information centric functionalities through 1876 proxies or direct insertion in user devices as the technology gets 1877 adopted and deployed. 1879 6. Integration into the 5G framework 1881 6.1. Locator based - SRv6 1883 6.1.1. Insertion in N9 interface 1885 Existing mobile backhaul employs GTP tunnels to carry user traffic 1886 flows in the network. These tunnels are unidirectional, are 1887 established via the control plane for a particular QoS level, and run 1888 on links between access and the different anchor nodes all the way to 1889 DN gateways. 1891 The Tunnel Endpoint Id (TEID) field in the GTP tunnel plays a crucial 1892 role in stitching the data path between the above mentioned network 1893 nodes for a particular user flow. In other words, TEIDs are used to 1894 coordinate traffic hand off between different UPFs. 1896 In its most basic form, SRv6 can be used as a simple drop-in 1897 alternative for GTP tunnels. The control plane in this approach 1898 remains the same, and still attempts to establish GTP-U tunnels and 1899 communicate TEIDs between the tunnel end points. However, at the 1900 next level, SRv6 capable nodes use SIDs to direct user traffic 1901 between the UPFs. 1903 The simplest option here is to encapsulate the entire GTP frame as a 1904 payload within SRv6. This scheme still carries the GTP header as the 1905 payload and as such doesn't offer any significant advantage. 1907 A much more promising and efficient option however is to use SIDs to 1908 carry tunnel related information. This is commonly known as the 1909 Traditional Mode for SRv6 support for mobility. Here, TEIDs and 1910 other relevant data can be encoded into SRv6 SIDs which can be mapped 1911 back to TEID's at the intermediate UPFs thus requiring no changes 1912 except at the encapsulation and de-encapsulation points in the UPF 1913 chains. 1915 Note that this is a direct replacement of GTP by SRv6. It's also 1916 worth noting that in this case the MTU overhead in the N9 interface 1917 is reduced. 1919 [I-D.ietf-dmm-srv6-mobile-uplane] discusses the details of leveraging 1920 the existing control plane for distributing GTP tunnel information 1921 between the end nodes and employing SRv6 in user plane for UPF 1922 connectivity. The document defines a SID structure for conveying 1923 TEID, DA, and SA of GTP tunnels, shows how hybrid IPV4/IPV6 networks 1924 are supported by this model and in doing so, it paves a migration 1925 path toward a full SRv6 user plane. 1927 Another alternative that can provide for a smooth migration toward 1928 SRv6 data plane between UPFs is via the use of "Tag", and optional 1929 TLV fields in SRH. Similar to the previously described method, this 1930 approach takes advantage of the existing control plane to deliver GTP 1931 tunnel information to the UPF endpoints. "Tag" and optional TLV 1932 fields in SRH are then used to encode tunnel information in the SRv6 1933 user plane where the UPFs can determine the TEID etc. by inverting 1934 the mapping. 1936 In yet another option, GTP tunnel information can be encoded as a 1937 separate SID either within the same SRH after the SID that identifies 1938 the UPF itself (SRH-UPF) or inside a separate SRH (SRH-GTP). This 1939 option resembles the MPLS label stacking mechanism which is widely 1940 used in different VPN scenarios. Here, we use one SID to carry 1941 traffic to the target UPF and use the other to encode and decode GTP 1942 related information. 1944 It must be noted that in any of the above mentioned approaches, the 1945 ingress UPF in SRv6 domain can insert a SRH containing the list of 1946 SIDs that corresponds to all UPFs along the path. Alternatively, 1947 UPFs can stack a new SRH on top of the one inserted by the previous 1948 one as packets traverse network paths between different pairs of UPFs 1949 in the network. 1951 6.1.2. Control Plane considerations 1953 SRv6, when applied in Tradditional Mode follows the inteworking model 1954 and as such does not require control-plane changes. It still attemps 1955 to establish GTP-U tunnels and communicate TEIDs between the tunnel 1956 endpoints. AT the next level of user plane however, SRv6 capable 1957 nodes use SIDs to direct user traffic between the UPFs. 1959 6.1.3. Extensions to N3/F1-U/Xn-U interface 1961 Although not strictly the object of study by 3GPP, previous solutions 1962 can (and would gain to) be extended beyond N9 to cover N3 interface 1963 too. 1965 The immediate benefit is the complete removal of all GTP tunnels, 1966 along with associated mangement complexity and traffic overhead. In 1967 particular, this removes the need for internetworking between N3 and 1968 N9 technologies, and offers a uniform user plane as recommended in 1969 the specification. 1971 Potential gains can result for an early handling of traffic right 1972 from the RAN and thus possibly closer to the UE. The result is a 1973 simpler and lighter architecture, allowing convergence with other 1974 non-3GPP accesses. 1976 The mobile network would benefit of the application of SRv6 to both, 1977 N3 and N9 interfaces. The intrinsic ability of SRv6 to integrate, in 1978 a single protocol, the control of the overlay, underlay and NFV 1979 implies that if applied to the N3 interface the end-to-end SRv6-based 1980 network slice can start on the NodeB itself. 1982 In addition, SRv6 could be applied to the F1-U interface for cloud- 1983 RAN and TE purposes. 1985 6.1.4. Coexistence with GTP-based architecture 1987 An alternative vision, although not recommended, would be to preserve 1988 the current architecture as is, and deploy alternative user planes on 1989 top. 1991 As explained in section 5.3.1, SRv6 can co-exist with the current 1992 GTP-based control plane. Additionally, the current control plane can 1993 be extended to suport TE as defined in 5.3.2. 1995 From a dataplane perspective, SRv6 can coexist on the N9 interface 1996 together with GTP-U traffic. 1998 This is important towards a slow migration from a GTP-based 1999 architecture into different architectures. 2001 6.2. ID-LOC split 2003 6.2.1. Insertion in N9 interface 2005 An ID-LOC network architecture is able to decouple the identity of 2006 endpoints (ID) from their location in the network (LOC). Common ID- 2007 LOC architectures are based on two main components, ID-LOC data-plane 2008 nodes and an ID-LOC mapping system. 2010 ID-LOC data-plane nodes act upon received data traffic and perform 2011 ID-LOC data-plane operation. The specific operation that these ID- 2012 LOC data-plane nodes perform is based on the particular ID-LOC data- 2013 plane protocol that they implement. ID-LOC data-plane protocols are 2014 usually divided in two categories, (1) those that encapsulate ID- 2015 based data-plane packets into LOC-based data-plane packets and (2) 2016 those that transform the addresses on the data-plane packets from ID- 2017 based addresses to LOC-based addresses. SRv6 and LISP-DP protocols 2018 are examples of the former while the ILA protocol is an example of 2019 the latter. 2021 The ID-LOC mapping system is a database that provides mappings of 2022 Identity to Location for ID-LOC data-plane nodes to use. Usually, 2023 ID-LOC architectures use an ID-LOC control plane protocol to make 2024 available at the data-plane nodes the ID-LOC mappings that they need 2025 to operate. Examples of such ID-LOC control plane protocols are 2026 LISP-CP and ILAMP, which are discussed later in this section. 2028 When integrating ID-LOC architecture into the 5G framework there are 2029 several aspects to take into account. One is that the ID-LOC data- 2030 plane function needs to be performed in the data-plane path as the 2031 packets enter and leave the ID-LOC domain. On option for this is to 2032 deploy ID-LOC data-plane nodes adjacent to UPFs to perform the ID-LOC 2033 operation on the traffic as it leaves or enters the UPFs (as shown in 2034 Fig. Figure 12). In this case the ID-LOC data-plane protocol will be 2035 part of the N9 interface along with current GTP. 2037 +----+----+ 2038 +-------------N4--------+ SMF +--------N4-----------+ 2039 | +----+----+ | 2040 | | | 2041 | +----+----+ | 2042 | | ID-LOC | | 2043 | | Mapping | ID-LOC | 2044 | +------>| System |<--control-plane | 2045 | | +----+----+ | | 2046 | V V | 2047 +---+---+ +----+----+ +----+----+ +---+---+ 2048 --N3-+ UPF-A +--N9--+ID-L Node+<--ID-LOC--->+ID-L Node+--N9--+ UPF-B +-N6-- 2049 +-------+ GTP +----+----+ data-plane +----+----+ GTP +-------+ 2051 Figure 12: 5G Integration with ID-LOC (Interworking model) 2053 Another option is to implement the ID-LOC data-plane function 2054 directly in the UPFs (as shown in Fig. Figure 13). In this case, 2055 these ID-LOC enabled UPFs will directly generate packets encapsulated 2056 or transformed and will be able to directly process packets 2057 encapsulated or transformed. In this case the ID-LOC protocol will 2058 completely replace GTP in the N9 interface. 2060 +----+----+ 2061 +-------------N4--------+ SMF +--------N4-----------+ 2062 | +----+----+ | 2063 | | | 2064 | +----+----+ | 2065 | | ID-LOC | | 2066 | | Mapping | ID-LOC | 2067 | +------------------->| System |<--control-plane--+ | 2068 | | +----+----+ | | 2069 | V V | 2070 +---+---+ +---+---+ 2071 --N3-+ UPF-A +<---------- N9 - ID-LOC data-plane ----------->+ UPF-B +-N6-- 2072 +-------+ +-------+ 2074 Figure 13: 5G Integration with ID-LOC (Integrated model) 2076 Finally, another aspect to consider when integrating the ID-LOC 2077 architecture into the 5G framework is that the Mapping System needs 2078 to contain the appropriate ID-LOC mappings in coordination with the 2079 SMF. In order to do so, the mappings in the Mapping System are 2080 populated either by the SMF directly or by the LOC-nodes that should 2081 be in synch with the SMF. In the former case, an interface from the 2082 SMF to the Mapping System is needed (as shown in Figs. Figure 12 and 2083 Figure 13). 2085 6.2.2. LISP control plane 2087 The current LISP control-plane (LISP-CP) specification 2088 [I-D.ietf-lisp-rfc6833bis] is data-plane agnostic and can serve as 2089 control plane for different data-plane protocols (beyond the LISP 2090 data-plane). LISP-CP offers different mechanisms to register, 2091 request, notify and update ID-Loc mappings between ID-LOC data-plane 2092 elements and the ID-LOC Mapping System. In the sections below we 2093 describe how LISP-CP can serve to enable the operation of the ILA 2094 data-plane and the SRv6 data-plane. 2096 It should be noted that the LISP-CP can run over TCP or UDP. The 2097 same signaling and logic applies independently of the transport. 2098 Additionally, when running over TCP, the optimizations specified in 2099 [I-D.kouvelas-lisp-map-server-reliable-transport] can be applied. 2101 6.2.2.1. LISP-CP for ILA 2103 The LISP-CP can serve to resolve the Identifier-to-Locator mappings 2104 required for the operation of an ILA data-plane. The required ILA 2105 control plane operations of "request/response" and "push" are 2106 implemented via the LISP mechanisms defined in 2107 [I-D.ietf-lisp-rfc6833bis] and [I-D.ietf-lisp-pubsub] respectively. 2108 In addition, the ILA "redirect" operation is implemented via the 2109 mapping notifications described in [I-D.ietf-lisp-pubsub] triggered 2110 as response to data-plane events. 2112 Furthermore, the LISP-CP can also be used to obtain the ILA 2113 Identifier when it is not possible to locally derivate it from the 2114 endpoint address. These two mapping operations, Endpoint-to- 2115 Identifier and Identifier-to-Locator, can be combined into one 2116 mapping operation to obtain the ILA Identifier and associated 2117 Locators in a single round of signaling. 2119 The complete specification of how to use the LISP-CP in conjunction 2120 with an ILA data-plane can be found in [I-D.rodrigueznatal-ila-lisp]. 2122 6.2.2.2. LISP-CP for SRv6 2124 The LISP-CP can be used by an ingress SRv6 node to obtain the egress 2125 node SRv6 VPN SID and its corresponding SLA associated with such 2126 endpoint. Alternatively, an ingress SRv6 node can use the LISP-CP to 2127 obtain not only the egress SRv6 VPN segment for a particular endpoint 2128 but also the SRv6 SID list to steer the traffic to that egress SRv6 2129 node. 2131 The complete specification of how to use the LISP-CP in conjunction 2132 with an SRv6 data-plane can be found in 2133 [I-D.rodrigueznatal-lisp-srv6]. 2135 6.2.3. ILA control plane 2137 The ILA control plane is composed of mapping protocols that manage 2138 and disseminate information about the mapping database. There are 2139 two levels of mapping protocols: one used by ILA routers that require 2140 the full set of ILA mappings for a domain, and one used by ILA nodes 2141 that maintain a caches of mappings. 2143 The ILA mapping system is effectively a key/value datastore that maps 2144 identifiers to locators. The protocol for sharing mapping 2145 information amongst ILA routers can thus be implemented by a 2146 distributed database [I-D.herbert-ila-ilamp]. ILA separates the 2147 control plane from the user plane, so alternative control plane 2148 protocols may be used with a common user plane 2149 [I-D.lapukhov-bgp-ila-afi], [I-D.rodrigueznatal-ila-lisp]. 2151 The ILA Mapping Protocol [I-D.herbert-ila-ilamp] is used between ILA 2152 forwarding nodes and ILA mapping routers. The purpose of the 2153 protocol is to populate and maintain the ILA mapping cache in 2154 forwarding nodes. ILAMP defines redirects, a request/response 2155 protocol, and a push mechanism to populate the mapping table. Unlike 2156 traditional routing protocols that run over UDP, this protocol is 2157 intended to be run over TCP and may be RPC oriented. TCP provides 2158 reliability, statefulness implied by established connections, 2159 ordering, and security in the form of TLS. Secure redirects are 2160 facilitated by the use of TCP. RPC facilities such REST, Thrift, or 2161 GRPC leverage widely deployed models that are popular in SDN. 2163 6.2.4. Extensions to N3/F1-U/Xn-U interface 2165 While not the main focus of this document, it is worth noting that it 2166 is also possible to enable an ID-LOC data-plane over the N3 interface 2167 and to instantiate the ID-LOC overlay directly at the NodeB. In this 2168 case, the NodeB will implement the functionality of an ID-LOC node, 2169 i.e. it will retrieve ID-LOC mappings using an ID-LOC control 2170 protocol and will encapsulate/transform ID packets into LOC packets. 2171 Bringing the ID-LOC data-plane to the NodeB (closer to the UE) has 2172 several advantages: (1) complete removal of GTP tunnels, (2) unified 2173 management of the ID-LOC data-plane across the network, (3) improved 2174 data-plane latency due to traffic being forwarded to the destination 2175 ID-LOC node directly from the NodeB, and (4) lower handover time 2176 since the ID-LOC mobility event can start at the NodeB itself. 2178 6.2.5. Coexistence with GTP-based architecture 2180 ID-Locator separation architecture can be implemented by control 2181 plane of a dedicated protocol such as LISP, ILA, etc., however, it 2182 may cause major impact to the specifications of 3GPP 5GS. The 2183 approach, described in [I-D.homma-dmm-5gs-id-loc-coexistence], 2184 enables to introduce such ID-Locator separation protocols into 5GS 2185 with no or low impacts. It would also support a migration path 2186 toward a network which an ID-Locator separation protocol is 2187 completely incorporated. 2189 This approach establishes an individual domain/slice in which an ID- 2190 Locator 2192 separation protocol works as packet forwarding mechanism, and divert 2193 the appropriate packets (e.g., packets for UE-to-UE communication) to 2194 the domain at local/distributed UPFs by using Up-Link Classifier 2195 (ULCL). ULCL is a fundamental function of UPF, and it diverts uplink 2196 traffic based on filter rules indicated by SMF. The other packets to 2197 a central UPF (e.g., packets for Internet access) are forwarded with 2198 GTP-U via N9 interface. 2200 The architecture is shown in Figure 14. 2202 +-----------------------------+ 2203 | SMF +<-------------+ 2204 +--+----------------------+---+ | 2205 N4 N4 | 2206 | | | 2207 +--+---+ +--+---+ +-----+ | 2208 ---- N3 ---+ dUPF +---N9(GTP-U)---+ cUPF +-N6-+ cDN | | 2209 |[ULCL]| | | | | | 2210 +--+---+ +------+ +-----+ | 2211 | Sync 2212 N6 | 2213 . . | . . . . . . . . . . . . . . . | 2214 +-----+ . +--+---+ +---------+ . | 2215 | dDN +-N6-+ ID-L +--ID-LOC CP---+ ID-LOC | . | 2216 | | . | Node | | Mapping |<-----------+ 2217 +-----+ . | +--ID-LOC UP | System | . 2218 . +------+ | +---+-----+ . 2219 . | | . 2220 . +------+ | | . 2221 -N6-+ ID-L +---------+ | . 2222 . | Node | | . 2223 . | +--ID-LOC CP-------+ . 2224 . +--+---+ . 2225 . . N6 . . . . . . . . . . . . . . 2226 | ID-LOC Domain 2228 Figure 14: Architecture of 5GS and ID-LOC Coexistence 2230 Coexistence approach allows to use GTP-U or any other forwarding 2231 protocol described in this document as user plane mechanism. 2232 However, each LOC-Node must be connected to the all other LOC-Nodes, 2233 and thus it may cause complexity of path management if you use a 2234 protocol which needs session establishment. 2236 Regarding to control plane of this approach, every dedicated ID- 2237 Locator separation protocol described in this document can be used. 2238 For management of mobility of UEs in ID-Locator separation domain, 2239 some cooperation between SMF and mapping system is needed. In this 2240 approach, a UE is attached to a LOC-Node only when it communicates to 2241 another UE or an NF in a dDN. In 5GS, SMF manages sessions, and thus 2242 SMF may be required to update mapping database when an UE moves to 2243 under another UPF or an NF is moved to another dDN. The impact 2244 caused by such cooperation can be reduced by using Naf interface 2245 which is defined in 5GS specifications. 2247 This approach provides a mechanism for introducing ID-Locator 2248 separation architecture into 5GS with no or nominal impact, and 2249 achieves optimization of forwarding path and session continuity. 2251 Moreover, this can keep scalability on forwarding on down link from 2252 cDN/Internet because it can use the current GTP-based mechanism. 2254 Meanwhile, this approach causes an extra hop when diverting packets 2255 to ID-Locator separation domain, and it may leads to increase of 2256 latency. 2258 6.3. ID-based - hICN 2260 By operating directly on routers' FIBs for mobility updates, dynamic 2261 hop-by-hop forwarding strategies etc., hICN inherits the simplicity 2262 of IP forwarding and reuses IP routing protocols for ID prefixes 2263 advertisement and routing. In this way it removes the challenges of 2264 managing a distributed mapping service at scale (cache update/ 2265 refresh, etc.). In addition it remains compatible with the exiting 2266 control plane architecture as proposed in the 3GPP standard, with no 2267 change required to N1, N2 or N4. 2269 MAP-Me anchorless producer mobility management does not imply SMF 2270 interaction, but does not exclude neither to use SMF signaling to 2271 trigger MAP-Me updates or to handle FIB updates, at the condition to 2272 follow the same procedure described for MAP-Me. However, the absence 2273 of SMF interaction might be beneficial in case of dense deployments 2274 or failure of the central control entities (infrastructure-less 2275 communication scenarios) to empower distributed control of local 2276 mobility within an area. 2278 6.3.1. Insertion in N9 interface 2280 Insertion of hICN in 5G IP infrastructure is facilitated by its 2281 design allowing a selective insertion of hICN capabilities in a few 2282 network nodes at the edge (no need for pervasive fully hICN network 2283 enablement), and to guarantee a transparent interconnection with 2284 hICN-unaware IP nodes, without using overlays. 2286 The deployment of hICN routers allow to avoid the reliance on GTP 2287 tunnels, and to provide an agile transport and native anchorless 2288 mobility natively. The resulting protocol stack is showin in 2289 Figure 15. We remark that in the protocol layer, hICN is associated 2290 to IPv6 PDU layer, transported in N9 directly over L2. 2292 UE 5G-AN N3 UPF N9 UPF N6 2293 | | | 2294 +--------+ | | | 2295 | App. |--------------------------------------------------------| 2296 +--------+ | | +--------+ | 2297 | IP PDU | | | | IP PDU | | 2298 | (hICN) |---------------------------------------------| (hICN) | | 2299 +--------+ +-----------------+ | +-----------------+ | | | | 2300 | | |\ relay /| | |\ decap / | | | | 2301 | | | \_____________/ |-|-| \_____________/ | | | | 2302 | | | | GTP-U | | | GTP-U | | | | | 2303 | | | +--------+ | +--------+ | | | | 2304 | 5G | | 5G | UDP |-|-| UDP | | | | | 2305 | AN |-| AN +--------+ | +--------+ | | | | 2306 |protocol| |protocol| IP |-|-| IP | | | | | 2307 | layers | | layers +--------+ | +--------+--------+ | +--------+ | 2308 | | | | L2 |-|-| L2 | L2 |-|-| L2 | | 2309 | | | +--------+ | +--------+--------+ | +--------+ | 2310 | | | | L1 |-|-| L1 | L1 |-|-| L1 | | 2311 +--------+ +-----------------+ | +-----------------+ | +--------+ | 2312 | | | 2314 Figure 15: Replacement of N9 interface - Protocol layers 2316 6.3.2. Control plane considerations 2318 By operating directly on routersa€™ FIBs for mobility 2319 updates, dynamic hop-by-hop forwarding strategies etc., hICN inherits 2320 the simplicity of IP forwarding and reuses IP routing protocols for 2321 ID prefixes advertisement and routing. In this way it removes the 2322 challenges of managing a distributed mapping service at scale (cache 2323 update/refresh, etc.). In addition it remains compatible with the 2324 exiting control plane architecture as proposed in the 3GPP standard, 2325 with no change required to N1, N2 or N4. 2327 MAP-Me anchorless producer mobility management does not imply SMF 2328 interaction, but does not exclude neither to use SMF signaling to 2329 trigger MAP-Me updates or to handle FIB updates, at the condition to 2330 follow the same procedure described for MAP-Me. However, the absence 2331 of SMF interaction might be beneficial in case of dense deployments 2332 or failure of the central control entities (infrastructure-less 2333 communication scenarios) to empower distributed control of local 2334 mobility within an area. 2336 6.3.3. Extensions to N3/F1-U/Xn-U interface 2338 This option ensures that forwarding beyond the radio access is 2339 directly managed through hICN. As a consequence, no additional state 2340 nor signaling is required for static and mobile consumers, nor for 2341 static producers. The impact of producer mobility is low because of 2342 the small number of impacted routers. 2344 Dynamic forwarding capabilities are extended in this configuration to 2345 the selection of the first UPF, with the potential of additional 2346 performance improvement and higher traffic offload because of the 2347 deployment of hICN functionalities closer to the UE. A significant 2348 advantage arises in dense deployments scenarios where it becomes 2349 possible to isolate the core network from the locally-management 2350 mobility (a design objective of the mobile architecture), while 2351 allowing distributed selection of ingress UPFs, and dynamic per- 2352 packet load balancing of traffic across them. 2354 6.3.4. Coexistence with GTP-based architecture 2356 This section discusses the insertion of hICN-AMM in an unmodified 2357 3GPP 5G reference architecture, where GTP tunnels are preserved. As 2358 previously stated, maintaining GTP tunnels does not allow to overcome 2359 limitations of anchor-based approaches. However, a transparent 2360 integration of hICN-AMM limits to the minimum deployment costs and 2361 already brings advantages over the baseline architecture presented 2362 earlier. 2364 The first option shares some similarities with the previous situation 2365 and proposes to deploy hICN-AMM within Mobile Edge Computing (MEC) 2366 platforms. It relies on the local breakout capability introduced in 2367 5G through the UL/CL. This function is used to realize the hICN 2368 punting function described in [I-D.muscariello-intarea-hicn], i.e. to 2369 identify hICN traffic (Interest and Data packets) and forward it to 2370 the local MEC hICN instance. Although it preserves tunnels and 2371 anchor points, this option permits an early termination of tunnels 2372 and the distribution of hICN capabilities close to the edge like in 2373 path caching and rate/loss/congestion control which may be leveraged 2374 for efficient low-latency content distribution especially in presence 2375 of consumer mobility. 2377 The second option consists in the deployment of hICN-AMM as User 2378 Plane Function (UPF) inside mobile user plane. It has the advantage 2379 of preserving hICN benefits in terms of consumer mobility and 2380 flexible transport. 2382 A more in depth presentation of those alternative deployments can be 2383 found in [I-D.auge-dmm-hicn-mobility-deployment-options]. 2385 6.4. Coexistence of multiple protocols in network slices 2387 Slicing is one of the main features in 5G. Several Slices with 2388 different requirements can coexist on top of the common network 2389 infrastructure. Diverse flows belonging to different 5G slices can 2390 be completely disjoint or can share different parts of the network 2391 infrastructure. 2393 All proposals reviewed in this draft lend themselves well to 5G 2394 slicing paradigm, that can assist a transition of services towards 2395 these new user plane protocols, or allow the coexistence of different 2396 deployment options. 2398 Figure 16 illustrates the use of network slices with the different 2399 proposals. All categories of approach can coexist in separate 2400 slices, so as different deployments of the same approach. We refer 2401 to previous sections for more details about the possible 2402 configurations for ID-LOC, and limit our discussion here to the 2403 possibility for different slices to deploy their own mapping system, 2404 or share it as illustrated here. 2406 Locator-based ID-LOC split ID-based 2407 (GTP, SRv6-T) (LISP, ILSR, ILA, SRv6-E) (hICN) 2408 ----+-------------------------------+-----------------------+---------- 2409 | | | 2410 +---------------------+ +-----------------------+ +--------------------+ 2411 | +-------+ Slice #1 | | +----------+ Slice #2 | | +-------+ Slice #4 | 2412 | | SMF |---+ GTP | | | Mapping +---+ | | | SMF |---+ hICN | 2413 | +--+----+ | | | +---+-----++ | | | +--+----+ | AMM | 2414 | N4 | | N4 | | | | | | | N4 | | N4 | 2415 | +--+--+ +--+----+ | | +---+---+ | +--+----+ | | +--+--+ +--+----+ | 2416 | | UPF | | UPF | | | | LOC-A | | | LOC-B | | | | UPF | | UPF | | 2417 | +-----+ +-------+ | | +-------+ | +-------+ | | +-----+ +-------+ | 2418 +----------- ---------+ +-----------|-----------+ +--------------------+ 2419 | | | | | 2420 +--+-+ | +--+-+ +--+--+ +--+-+ 2421 | DN | | | DN | | MEC | | DN | 2422 +----+ | +----+ +-----+ +----+ 2423 +------------|------------+ 2424 | | Slice #3 | 2425 | +------+---+ | 2426 | | | | 2427 | +---+---+ +-+-----+ | +----+ 2428 +-----+ | | LOC-A | | LOC-B | |---| DN | 2429 | MEC |--| +-------+ +-------+ | +----+ 2430 +-----+ +-------------------------+ 2432 Figure 16: Network slices in 5G 2434 *Locator-based* 2436 Slice #1 illustrates legacy use of UPFs with GTP in a slice. New 2437 approaches can be deployed incrementally or in parts of the network. 2438 As demonstrated, the use of network slices can provide domain 2439 isolation for this. 2441 *ID-LOC split* 2443 Slice #2 and #3 support ID-LOC. We illustrate in slice #2 a typical 2444 deployment with ILA. Mapping then corresponds to ILA-M, LOC-A to 2445 ILA-N and LOC-B to ILA-R. 2447 Some number of ILA-Ns and ILA-Rs are deployed. ILA transformations 2448 are performed over the N9 interface. ILA-Rs would be deployed at the 2449 N6 interface to perform transformations on packets received from a 2450 data network. ILA-Ns will be deployed deeper in the network at one 2451 side of the N3 interface. ILA-Ns may be supplemented by ILA-Rs that 2452 are deployed in the network. ILA-M manages the ILA nodes and mapping 2453 database within the slice. 2455 Slice #3 shows another slice that supports ILA. In this scenario, 2456 the slice is for Mobile Edge Computing. The slice contains ILA-Rs 2457 and ILA-Ns, and as illustrated, it may also contain ILA_Hs that run 2458 directly on edge computing servers. Note in this example, one ILA-M, 2459 and hence one ILA domain, is shared between slice #2 and slice #3. 2460 Alternatively, the two slices could each have their own ILA-M and 2461 define separate ILA domains. 2463 *ID-based* 2465 Finally, in slice #4, a slice using hICN-AMM is shown, that does not 2466 require any mapping system nor changes in N4. 2468 6.5. Interoperability/Roaming considerations 2470 Different situations including roaming scenarios might require the 2471 coexistence of different mobility protocols for the same user plane. 2472 In Figure 17 and Figure 18, we illustrate two possible deployments 2473 for the Home-Routed Roaming Scenario, respectively using a UPF 2474 supporting several protocols, and relying on an exchange service 2475 point for interconnection. 2477 VPLMN | HPLMN 2478 -----+----- N32 --------+-------- 2479 | | | 2480 +--+--+ | +--+--+ 2481 | SMF | | | SMF | 2482 +--+--+ | +--+--+ 2483 | | | 2484 +-------+ | | | 2485 | 5G UE | | | | 2486 +---+---+ N4 | N4 2487 | | | 2488 | +-----+ +--+--+ +--+--+ +----+ 2489 +-----| gNB |-----| UPF |-----N9------| UPF |------| DN | 2490 +-----+ +-----+ +-----+ +----+ 2492 Figure 17: Direct Connectivity between operators with UPFs supporting 2493 more than one mobility protocols 2495 VPLMN | HPLMN 2496 -----+----- N32 --------+-------- 2497 | | | 2498 +--+--+ | +--+--+ 2499 | SMF | | | SMF | 2500 +--+--+ | +--+--+ 2501 | | | 2502 +-------+ | | | 2503 | 5G UE | | | | 2504 +---+---+ N4 | N4 2505 | | | 2506 | +-----+ +--+--+ +-----+ +--+--+ +----+ 2507 +-----| gNB |-----| UPF |---| Exc |----| UPF |------| DN | 2508 +-----+ +-----+ +-----+ +-----+ +----+ 2510 Figure 18: Connectivity between operators using an Exchange that 2511 supports multiple mobility protocols 2513 7. Summary 2515 This document summarizes the various IETF protocol options for GTP 2516 replacement on N9 interface of 3GPP 5G architecture. The document 2517 also proposes optional raplacemets of GTP in N3 interface. 2519 8. Formal Syntax 2521 The following syntax specification uses the augmented Backus-Naur 2522 Form (BNF) as described in [RFC2234]. 2524 9. Security Consideration 2526 All 3GPP security aspects apply to all the protocols discussed in 2527 this document. 2529 10. IANA Considerations 2531 There are no IANA considerations in this specification. 2533 11. Acknowledgement 2535 The authors would like to thank Farooq Bari, Devaki Chandramouli, 2536 Ravi Guntupalli, Sri Gundavelli, Peter Ashwood Smith, Satoru 2537 Matsushima, Michael Mayer, Vina Ermagan, Fabio Maino, Albert 2538 Cabellos, Cameron Byrne for reviewing various iterations of the 2539 document and for providing content into various sections. 2541 12. References 2543 12.1. Normative References 2545 [RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to 2546 implement transparent subnet gateways", RFC 1027, 2547 DOI 10.17487/RFC1027, October 1987, 2548 . 2550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2551 Requirement Levels", BCP 14, RFC 2119, 2552 DOI 10.17487/RFC2119, March 1997, 2553 . 2555 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2556 Specifications: ABNF", RFC 2234, DOI 10.17487/RFC2234, 2557 November 1997, . 2559 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2560 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2561 DOI 10.17487/RFC4861, September 2007, 2562 . 2564 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2565 Locator/ID Separation Protocol (LISP)", RFC 6830, 2566 DOI 10.17487/RFC6830, January 2013, 2567 . 2569 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 2570 Locator/ID Separation Protocol (LISP) for Multicast 2571 Environments", RFC 6831, DOI 10.17487/RFC6831, January 2572 2013, . 2574 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2575 "Interworking between Locator/ID Separation Protocol 2576 (LISP) and Non-LISP Sites", RFC 6832, 2577 DOI 10.17487/RFC6832, January 2013, 2578 . 2580 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 2581 Protocol (LISP) Map-Server Interface", RFC 6833, 2582 DOI 10.17487/RFC6833, January 2013, 2583 . 2585 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 2586 Protocol Internet Groper (LIG)", RFC 6835, 2587 DOI 10.17487/RFC6835, January 2013, 2588 . 2590 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 2591 "Locator/ID Separation Protocol Alternative Logical 2592 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 2593 January 2013, . 2595 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 2596 Pascual, J., and D. Lewis, "Locator/Identifier Separation 2597 Protocol (LISP) Network Element Deployment 2598 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2599 2014, . 2601 [RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., 2602 Tyson, G., Davies, E., Molinaro, A., and S. Eum, 2603 "Information-Centric Networking: Baseline Scenarios", 2604 RFC 7476, DOI 10.17487/RFC7476, March 2015, 2605 . 2607 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 2608 (LISP) Data-Plane Confidentiality", RFC 8061, 2609 DOI 10.17487/RFC8061, February 2017, 2610 . 2612 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 2613 Smirnov, "Locator/ID Separation Protocol Delegated 2614 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 2615 May 2017, . 2617 [RFC8112] Farinacci, D., Jain, A., Kouvelas, I., and D. Lewis, 2618 "Locator/ID Separation Protocol Delegated Database Tree 2619 (LISP-DDT) Referral Internet Groper (RIG)", RFC 8112, 2620 DOI 10.17487/RFC8112, May 2017, 2621 . 2623 12.2. Informative References 2625 [CICN] Linux Foundation fd.io, "CICN project", 2018. 2627 [CP-173160-1] 2628 3rd Generation Partnership Project (3GPP), "New Study Item 2629 on User Plane Protocol in 5GC", December 2017. 2631 [I-D.auge-dmm-hicn-mobility] 2632 Auge, J., Carofiglio, G., Muscariello, L., and M. 2633 Papalini, "Anchorless mobility through hICN", draft-auge- 2634 dmm-hicn-mobility-00 (work in progress), June 2018. 2636 [I-D.auge-dmm-hicn-mobility-deployment-options] 2637 Auge, J., Carofiglio, G., Muscariello, L., and M. 2638 Papalini, "Anchorless mobility management through hICN 2639 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 2640 mobility-deployment-options-00 (work in progress), June 2641 2018. 2643 [I-D.farinacci-lisp-mobile-network] 2644 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 2645 for the Mobile Network", draft-farinacci-lisp-mobile- 2646 network-03 (work in progress), March 2018. 2648 [I-D.filsfils-spring-srv6-network-programming] 2649 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 2650 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 2651 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 2652 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 2653 M. Sharif, "SRv6 Network Programming", draft-filsfils- 2654 spring-srv6-network-programming-04 (work in progress), 2655 March 2018. 2657 [I-D.herbert-ila-ilamp] 2658 Herbert, T., "Identifier Locator Addressing Mapping 2659 Protocol", draft-herbert-ila-ilamp-00 (work in progress), 2660 December 2017. 2662 [I-D.herbert-ila-mobile] 2663 Herbert, T. and K. Bogineni, "Identifier Locator 2664 Addressing for Mobile User-Plane", draft-herbert-ila- 2665 mobile-01 (work in progress), March 2018. 2667 [I-D.herbert-intarea-ila] 2668 Herbert, T. and P. Lapukhov, "Identifier-locator 2669 addressing for IPv6", draft-herbert-intarea-ila-01 (work 2670 in progress), March 2018. 2672 [I-D.hmm-dmm-5g-uplane-analysis] 2673 Homma, S., Miyasaka, T., and S. Matsushima, "User Plane 2674 Protocol and Architectural Analysis on 3GPP 5G System", 2675 2018. 2677 [I-D.homma-dmm-5gs-id-loc-coexistence] 2678 Homma, S., Kawakami, K., and A. Akhavain, "Co-existence of 2679 3GPP 5GS and Identifier Locator Separation Architecture", 2680 draft-homma-dmm-5gs-id-loc-coexistence-01 (work in 2681 progress), May 2018. 2683 [I-D.ietf-6man-segment-routing-header] 2684 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 2685 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 2686 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 2687 progress), May 2018. 2689 [I-D.ietf-dmm-srv6-mobile-uplane] 2690 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 2691 daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing 2692 IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- 2693 uplane-01 (work in progress), March 2018. 2695 [I-D.ietf-lisp-eid-mobility] 2696 Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino, 2697 F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a 2698 Unified Control Plane", draft-ietf-lisp-eid-mobility-02 2699 (work in progress), May 2018. 2701 [I-D.ietf-lisp-introduction] 2702 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 2703 Introduction to the Locator/ID Separation Protocol 2704 (LISP)", draft-ietf-lisp-introduction-13 (work in 2705 progress), April 2015. 2707 [I-D.ietf-lisp-mn] 2708 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 2709 Mobile Node", draft-ietf-lisp-mn-02 (work in progress), 2710 April 2018. 2712 [I-D.ietf-lisp-pubsub] 2713 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 2714 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 2715 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 2716 Subscribe Functionality for LISP", draft-ietf-lisp- 2717 pubsub-00 (work in progress), April 2018. 2719 [I-D.ietf-lisp-rfc6830bis] 2720 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 2721 Cabellos-Aparicio, "The Locator/ID Separation Protocol 2722 (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), 2723 March 2018. 2725 [I-D.ietf-lisp-rfc6833bis] 2726 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 2727 "Locator/ID Separation Protocol (LISP) Control-Plane", 2728 draft-ietf-lisp-rfc6833bis-10 (work in progress), March 2729 2018. 2731 [I-D.ietf-spring-segment-routing] 2732 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 2733 Litkowski, S., and R. Shakir, "Segment Routing 2734 Architecture", draft-ietf-spring-segment-routing-15 (work 2735 in progress), January 2018. 2737 [I-D.ietf-spring-segment-routing-policy] 2738 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 2739 bogdanov@google.com, b., and P. Mattes, "Segment Routing 2740 Policy Architecture", draft-ietf-spring-segment-routing- 2741 policy-01 (work in progress), June 2018. 2743 [I-D.irtf-icnrg-mapme] 2744 Auge, J., Carofiglio, G., Muscariello, L., and M. 2745 Papalini, "MAP-Me : Managing Anchorless Mobility in 2746 Content Centric Networking", draft-irtf-icnrg-mapme-00 2747 (work in progress), March 2018. 2749 [I-D.irtf-icnrg-terminology] 2750 Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran, 2751 D., and C. Tschudin, "Information-Centric Networking 2752 (ICN): CCN and NDN Terminology", draft-irtf-icnrg- 2753 terminology-00 (work in progress), December 2017. 2755 [I-D.kouvelas-lisp-map-server-reliable-transport] 2756 Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. 2757 Arango, "LISP Map Server Reliable Transport", draft- 2758 kouvelas-lisp-map-server-reliable-transport-04 (work in 2759 progress), September 2017. 2761 [I-D.lapukhov-bgp-ila-afi] 2762 Lapukhov, P., "Use of BGP for dissemination of ILA mapping 2763 information", draft-lapukhov-bgp-ila-afi-02 (work in 2764 progress), October 2016. 2766 [I-D.muscariello-intarea-hicn] 2767 Muscariello, L., Carofiglio, G., Auge, J., and M. 2768 Papalini, "Hybrid Information-Centric Networking", draft- 2769 muscariello-intarea-hicn-00 (work in progress), June 2018. 2771 [I-D.rodrigueznatal-ila-lisp] 2772 Rodriguez-Natal, A., Ermagan, V., Maino, F., and A. 2773 Cabellos-Aparicio, "LISP control-plane for Identifier 2774 Locator Addressing (ILA)", draft-rodrigueznatal-ila- 2775 lisp-01 (work in progress), April 2018. 2777 [I-D.rodrigueznatal-lisp-srv6] 2778 Rodriguez-Natal, A., et al., "LISP Control Plane for SRv6 2779 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00 2780 (work in progress) , June 2018. 2782 [I-D.vonhugo-5gangip-ip-issues] 2783 Hugo, D. and B. Sarikaya, "Review on issues in discussion 2784 of next generation converged networks (5G) from an IP 2785 point of view", draft-vonhugo-5gangip-ip-issues-03 (work 2786 in progress), March 2017. 2788 [I-D.xuclad-spring-sr-service-chaining] 2789 Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca, 2790 d., Li, C., Decraene, B., Ma, S., Yadlapalli, C., 2791 Henderickx, W., and S. Salsano, "Segment Routing for 2792 Service Chaining", draft-xuclad-spring-sr-service- 2793 chaining-01 (work in progress), March 2018. 2795 [ILACONTROL] 2796 Herbert, T., "Identifier Locator Addressing Mapping 2797 Protocol draft-herbert-ila-ilamp-00", December 2017. 2799 [ILAGRPS] Herbert, T., "Identifier Groups draft-herbert-idgroups- 2800 00", February 2018. 2802 [ILAMOTIVE] 2803 Herbert, T., "Identifier Locator Addressing: Problem 2804 Areas, Motivation, and Use Cases draft-herbert-ila- 2805 motivation-00", January 2018. 2807 [ILSR-WP] Kurebayashi, R., Ashwood-Smith, P., and D. Farinacci, 2808 "Evolving 5G Routing", December 2017. 2810 [IRTF-RRG] 2811 Li, T., "IRTF Routing Research Group (rrg)", November 2812 2012. 2814 [LISP-WG] Halrpen, J. and L. Iannone, "IETF Locator/ID Separation 2815 Protocol (lisp) Working Group", June 2018. 2817 [MAPME] Auge, J., Carofiglio, G., Grassi, G., Muscariello, L., 2818 Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less 2819 Producer Mobility in Content-Centric Networks", IEEE 2820 Transactions on Network and Service Management Vol. 15, 2821 pp. 596-610, DOI 10.1109/tnsm.2018.2796720, June 2018. 2823 [SP-180231-1] 2824 3rd Generation Partnership Project (3GPP), "New Study on 2825 Enhancements to the Service-Based 5G System Architecture", 2826 March 2018. 2828 [TR.29.891-3GPP] 2829 3rd Generation Partnership Project (3GPP), "5G System ? 2830 Phase 1, CT WG4 Aspects, 3GPP TR 29.891 v15.0.0", December 2831 2017. 2833 [TS.23.203-3GPP] 2834 3rd Generation Partnership Project (3GPP), "Policy and 2835 Charging Control Architecture, 3GPP TS 23.203 v2.0.1", 2836 December 2017. 2838 [TS.23.501-3GPP] 2839 3rd Generation Partnership Project (3GPP), "System 2840 ARchitecture for the 5G System; Stage 2, 3GPP TS 23.501, 2841 v15.2.0", June 2018. 2843 [TS.23.502-3GPP] 2844 3rd Generation Partnership Project (3GPP), "Procedures for 2845 5G System; Stage 2, 3GPP TS 23.502, v15.2.0", June 2018. 2847 [TS.23.503-3GPP] 2848 3rd Generation Partnership Project (3GPP), "Policy and 2849 Charging Control System for 5G Framework; Stage 2, 3GPP TS 2850 23.503 v15.2.0", June 2018. 2852 [TS.29.244-3GPP] 2853 3rd Generation Partnership Project (3GPP), "Interface 2854 between the Control Plane and the User Plane Nodes; Stage 2855 3, 3GPP TS 29.244 v15.2.0", June 2018. 2857 [TS.29.281-3GPP] 2858 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 2859 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.3.0", 2860 June 2018. 2862 [TS.38.300-3GPP] 2863 3rd Generation Partnership Project (3GPP), "NR and NG-RAN 2864 Overall Description: Stage 2, 3GPP TS 38.300 v15.2.0", 2865 June 2018. 2867 [TS.38.401-3GPP] 2868 3rd Generation Partnership Project (3GPP), "NG-RAN: 2869 Architecture Description, 3GPP TS 38.401 v15.2.0", June 2870 2018. 2872 [TS.38.801-3GPP] 2873 3rd Generation Partnership Project (3GPP), "Study on new 2874 radio access technology: Radio access architecture and 2875 interfaces", March 2017. 2877 [WLDR] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 2878 N., and X. Zeng, "Leveraging ICN In-network Control for 2879 Loss Detection and Recovery in Wireless Mobile networks", 2880 Proceedings of the 2016 conference on 3rd ACM Conference 2881 on Information-Centric Networking - ACM-ICN '16, 2882 DOI 10.1145/2984356.2984361, 2016. 2884 Authors' Addresses 2886 Kalyani Bogineni 2887 Verizon 2889 Email: kalyani.bogineni@verizon.com 2890 Arashmid Akhavain 2891 Huawei Canada Research Centre 2893 Email: arashmid.akhavain@huawei.com 2895 Tom Herbert 2896 Quantonium 2898 Email: tom@quantonium.net 2900 Dino Farinacci 2901 lispers.net 2903 Email: farinacci@gmail.com 2905 Alberto Rodriguez-Natal 2906 Cisco Systems, Inc. 2908 Email: natal@cisco.com 2910 Giovanna Carofiglio 2911 Cisco Systems, Inc. 2913 Email: gcarofig@cisco.com 2915 Jordan Auge 2916 Cisco Systems, Inc. 2918 Email: jordan.auge@cisco.com 2920 Luca Muscariello 2921 Cisco Systems, Inc. 2923 Email: lumuscar@cisco.com 2925 Pablo Camarillo Garvia 2926 Cisco Systems, Inc. 2928 Email: pcamaril@cisco.com 2929 Shunsuke Homma 2930 NTT 2932 Email: homma.shunsuke@lab.ntt.co.jp