idnits 2.17.00 (12 Aug 2021) /tmp/idnits7404/draft-clt-dmm-tn-aware-mobility-05.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 22 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 4, 2019) is 929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 8453' is mentioned on line 378, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 784, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-mobile-network' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-gue-extensions' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 864, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-chunduri-lsr-isis-preferred-path-routing-04 == Outdated reference: A later version (-04) exists of draft-chunduri-lsr-ospf-preferred-path-routing-03 == Outdated reference: A later version (-14) exists of draft-farinacci-lisp-mobile-network-06 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-02 == Outdated reference: A later version (-21) exists of draft-ietf-dmm-srv6-mobile-uplane-06 == Outdated reference: draft-ietf-spring-segment-routing has been published as RFC 8402 Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group U. Chunduri, Ed. 3 Internet-Draft R. Li 4 Intended status: Informational Futurewei 5 Expires: May 7, 2020 S. Bhaskaran 6 Altiostar 7 J. Kaippallimalil 8 Futurewei 9 J. Tantsura 10 Apstra, Inc. 11 L. Contreras 12 Telefonica 13 P. Muley 14 Nokia 15 November 4, 2019 17 Transport Network aware Mobility for 5G 18 draft-clt-dmm-tn-aware-mobility-05 20 Abstract 22 This document specifies a framework and a mapping function for 5G 23 mobile user plane with transport network slicing, integrated with 24 Mobile Radio Access and a Virtualized Core Network. The integrated 25 approach is specified in a way to fit into the 5G core network 26 architecture defined in [TS23.501]. 28 It focuses on an optimized mobile user plane functionality with 29 various transport services needed for some of the 5G traffic needing 30 low and deterministic latency, real-time, mission-critical services. 31 This document describes, how this objective is achieved agnostic to 32 the transport underlay used (IPv6, MPLS, IPv4) in various deployments 33 and with a new transport network underlay routing, called Preferred 34 Path Routing (PPR). 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC2119 [RFC2119]. 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 May 7, 2020. 59 Copyright Notice 61 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 78 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 79 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 6 81 2.1. XHaul Transport Network . . . . . . . . . . . . . . . . . 7 82 2.2. Mobile Transport Network Context (MTNC) and Scalability . 8 83 2.3. Transport Network Function (TNF) . . . . . . . . . . . . 9 84 2.4. TNF Interfaces . . . . . . . . . . . . . . . . . . . . . 9 85 2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 10 86 2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 11 87 2.7. Functionality for E2E Management . . . . . . . . . . . . 12 88 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 13 89 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 14 90 3.2. Path Steering Support to native IP user planes . . . . . 16 91 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 16 92 4. Other TE Technologies Applicability . . . . . . . . . . . . . 16 93 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 96 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 99 9.2. Informative References . . . . . . . . . . . . . . . . . 17 100 Appendix A. New Control Plane and User Planes . . . . . . . . . 20 101 A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 20 102 Appendix B. PPR with various 5G Mobility procedures . . . . . . 21 103 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 22 104 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 23 105 B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 108 1. Introduction 110 The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP], 111 [TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a 112 comprehensive set of functions for access mobility, session handling 113 and related functions for subscription management, authentication and 114 policy among others. These network functions (NF) are defined using 115 a service-based architecture (SBA) that allows NFs to expose their 116 functions via an API and common service framework. The architecture 117 also defines slicing aspects where the Network Slice Selection 118 Function (NSSF) assists the Access Mobility Manager (AMF) and Session 119 Management Function (SMF) to assist and select the right entities and 120 resources corresponding to the slice requested by the user equipment 121 (UE). The User Equipment (UE) indicates slice information in the 122 Network Slice Selection Assistance Information (NSSAI) field during 123 session establishment (Attach). The AMF selects the right SMF and 124 the SMF in turn selects the User Plane Functions (UPF) so that the 125 QoS and capabilities requested can be fulfilled. UPFs are the data 126 forwarding entities in the 5GC architecture. The architecture allows 127 the placement of Branching Point (BP) and Uplink Classifier (ULCL) 128 UPFs closer to the access network (5G-AN). The 5G-AN can be a radio 129 access network or any non-3GPP access network, for example, WLAN. 130 The IP address is anchored by a PDU session anchor UPF (PSA UPF). 132 5GS allows more than one UPF on the path for a PDU (Protocol Data 133 Unit) session that provides various functionality including session 134 anchoring, uplink classification and branching point for a multihomed 135 IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA 136 UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9 137 and N3 interface between the various UPF instances and the (R)AN. 138 3GPP has specified control and user plane aspects in [TS.23.501-3GPP] 139 to provide slice and QoS support. 3GPP has defined three broad slice 140 types to cover enhanced mobile broadband (eMBB) communications, 141 ultra-reliable low latency communications(URLLC) and massive internet 142 of things (mIoT). ATIS [ATIS075] has defined an additional slice 143 type for V2X services. There may be multiple instances of a slice 144 type to satisfy some characteristics like isolation. The slice 145 details in 3GPP, ATIS or NGMN do not specify how slice 146 characteristics for QoS, hard /soft isolation, protection and other 147 aspects should be satisfied in IP transport networks. This is 148 explored further in this document. 150 1.1. Problem Statement 152 [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one 153 of the core capability of 5GC with slice awareness from Radio and 5G 154 Core (5GC) network. The 5G System (5GS) as defined, does not 155 consider the resources and functionalities needed from transport 156 network for the selection of UPF. This is seen as independent 157 functionality and currently not part of 5GS. 159 However, the lack of underlying Transport Network (TN) awareness may 160 lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS 161 various procedures (e.g., session establishment, mobility). Meeting 162 the specific slice characteristics on the N3 and N9 interfaces 163 depends on the IP transport underlay providing these resources and 164 capabilities. This could also lead to the inability in meeting SLAs 165 for real-time, mission-critical or latency sensitive services. 5GS 166 procedures including but not limited to Service Request, PDU Session 167 Establishment, or UE mobility need same service level characteristics 168 from the TN for the Protocols Data Unit (PDU) session, similar to as 169 provided in Radio and 5GC for the various Slice Service Types (SST) 170 and 5QI's defined in [TS.23.501-3GPP]. 172 The 5GS provides slices to its clients (UEs). The UE's PDU session 173 spans the access network (radio) and N3 and N9 transport segments 174 which have an IP transport underlay. The 5G operator needs to obtain 175 slice capability from the IP transport provider. Several UE sessions 176 that match a slice may be mapped to an IP transport segment. Thus 177 there needs to be a mapping between the slice capability offered to 178 the UE (NSSAI) and what is provided by the IP transport. 180 1.2. Solution Approach 182 This document specifies an approach to fulfil the needs of 5GS to 183 transport user plane traffic from 5G-AN to UPF for all service 184 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 185 done by, keeping mobility procedures aware of underlying transport 186 network along with slicing requirements. 188 Section 2 describes in detail on how TN aware mobility can be built 189 irrespective of underlying TN technology used. Using Preferred Path 190 Routing (PPR), applicable to any transport network underlay (IPv6, 191 MPLS and IPv4) is detailed in Section 3. How other IETF TE 192 technologies applicable for this draft is specified in Section 4. At 193 the end, Appendix B further describes the applicability and 194 procedures of PPR with 5G SSC modes on N3 and N9 interfaces. 196 1.3. Acronyms 198 5QI - 5G QoS Indicator 200 5G-AN - 5G Access Network 202 AMF - Access and Mobility Management Function (5G) 204 BP - Branch Point (5G) 206 CSR - Cell Site Router 208 DN - Data Network (5G) 210 eMBB - enhanced Mobile Broadband (5G) 212 FRR - Fast ReRoute 214 gNB - 5G NodeB 216 GBR - Guaranteed Bit Rate (5G) 218 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 220 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 222 LFA - Loop Free Alternatives (IP FRR) 224 mIOT - Massive IOT (5G) 226 MPLS - Multi Protocol Label Switching 228 QFI - QoS Flow ID (5G) 230 PPR - Preferred Path Routing 232 PDU - Protocol Data Unit (5G) 234 PW - Pseudo Wire 236 RQI - Reflective QoS Indicator (5G) 238 SBI - Service Based Interface (5G) 240 SID - Segment Identifier 241 SMF - Session Management Function (5G) 243 SSC - Session and Service Continuity (5G) 245 SST - Slice and Service Types (5G) 247 SR - Segment Routing 249 TE - Traffic Engineering 251 ULCL - Uplink Classifier (5G) 253 UPF - User Plane Function (5G) 255 URLLC - Ultra reliable and low latency communications (5G) 257 2. Transport Network and Slice aware Mobility on N3/N9 259 Currently specified Control Plane (CP) functions - the AMF, the SMF 260 and the User plane (UP) components 5G-AN (e.g. gNB), UPF with N2, N3, 261 N4, N6 and N9 interfaces are relevant to this document. Other 262 Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, 263 NEF, and AF are not directly relevant for the discussion in this 264 document and one can see the functionalities of these in 265 [TS.23.501-3GPP]. 267 From encapsulation perspective, N3 interface is similar to S1U in 4G/ 268 LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to 269 transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). 270 Unlike S1U, N3 has some additional aspects as there is no bearer 271 concept and no per bearer GTP-U tunnels. Instead, QoS information is 272 carried in the PDU Session Container GTP-U extension header. 274 +------+ +-----+ +-------+ +-----+ 275 | NSSF | | NRF | | NWDAF | | PCF | 276 +---+--+ +--+--+ +---+---+ +--+--+ 277 | | | | 278 --+-----+--------+--+-----------+-----+-----+----- 279 | | Service Based Interfaces (SBI) 280 | +-----+--------+ | 281 +--+--+ | +-----+ NSSMF| +--+--+ 282 +-----+ AMF | | | TNF | | | SMF | 283 | +--+--+ | +--+--+ | +--+--+ 284 | +---+----------+ | 285 | |ACTN | 286 | +---+--+ | 287 N2 | +--------|SDN-C |-------+ | 288 | | +--+---+ | +----------+ 289 | |Ns _______ Nn| | N4 | 290 | | ___/ \______|_______|__________|___ 291 | | / | | | \ 292 +------+ +--+---+ IP +-++ +--+---+ +--+----+ +--+ 293 |(R)AN |====|CSR/PE| Backhaul |PE|+++|UP-NF2|+++|PE+UPF2|---|DN| 294 +------+ +------+ +--+ +------+ +-------+ +--+ 295 \___ _____________________________/ 296 Front/ \ / N3 N9 N6 297 Midhaul +-----+ 299 Figure 1: 5G Service Based Architecture with Transport Network 301 TN Aware Mobility with optimized transport network functionality is 302 explained below. How PPR fits in this framework in detail along with 303 other various TE technologies briefly are in Section 3 and Section 4 304 respectively. 306 2.1. XHaul Transport Network 308 Figure 1 depicts IP Xhaul network with SDN-C and CSR/PE (Provider 309 Edge) routers provide IP transport service to 5GS user plane entities 310 5G-AN (e.g. gNB) and UPF. 5GS architecture with key control and user 311 plane entities and its interaction with the IP transport plane is 312 shown here. When a UE initiates session establishment, it indicates 313 the desired slice type in the S-NSSAI (Specific Network Slice 314 Selection Assistance Information) field. The AMF uses the S-NSSAI, 315 other subscription information and configuration in the NSSF to 316 select the appropriate SMF and the SMF in turn selects UPFs (User 317 Plane Functions) that are able to provide the specified slice 318 resources and capabilities. Some of the slice capabilities along the 319 user plane path between the (R)AM and UPFs (N3, N9 segments) such as 320 a low latency path, jitter, protection and priority needs these to be 321 provided by the IP transport network. 323 Interface between (R)AN/5G-AN and CSR includes fronthaul and midhaul 324 part of the transport network. In some cases midhaul can also a 325 layer-2 network. In deployments where virtualized 5G-AN is used, F1U 326 interface with GTP encapsulation is considered between the 327 Distributed Unit (DU) and Centralized Unit (CU). 329 Slice capability required in IP transport networks is estimated and 330 provisioned by the functionality as specified in Section 2.3 (TNF) 331 with support from various other functions such as the Network Data 332 Analytics Function (NWDAF), Network Resource Function (NRF) and 333 Policy Control Function (PCF). Figure 1 depicts the PE router, where 334 transport paths are initiated/terminated can be deployed seperately 335 with UPF or both functionalities can be in the same node. The TNF 336 provisions this in the SDN-C of the IP XHaul network using ACTN 337 [RFC8453]. When a GTP encapsulated user packet from the (R)AN or UPF 338 with the slice information traverses the F1U/N3/N9 segment, the PE 339 router of the IP transport underlay can inspect the slice information 340 and provide the provisioned capabilities. This is elaborated further 341 in Section 2.5. 343 2.2. Mobile Transport Network Context (MTNC) and Scalability 345 The MTNC represents a slice, QoS configuration for a transport path 346 between two 3GPP user plane functions. The Mobile-Transport Network 347 Context Identifier (MTNC-ID) is generated by the TNF to be unique for 348 each path and per traffic class (including QoS and slice aspects). 349 Thus, there may be more than one MTNC-ID for the same QoS and path if 350 there is a need to provide isolation (slice) of the traffic. It 351 should be noted that MTNC are per class/path and not per user session 352 (nor is it per data path entity). The MTNC-IDs are configured by the 353 TNF to be unique within a provisioning domain. 355 Since the MTNC-IDs are not generated per user flow or session, there 356 is no need for unique MTNC-IDs per flow/session. In addition, since 357 the traffic estimation not performed at the time of session 358 establishment, there is no provisioning delay experienced during 359 session setup. The MTNC-ID space scales as a square of the number 360 sites between which 3GPP user plane functions require paths. If 361 there are T traffic classes across N sites, the number of MTNC-IDs in 362 a fully meshed network is (N*(N-1)/2) * T. For example, if there are 363 3 traffic classes between 25 sites, there would be at most 900 MTNC- 364 IDs required. Multiple slices for the same QoS class that need to be 365 fully isolated, will add to the MTNC provisioning. An MTNC-ID space 366 of 16 bits (65K+ identifiers) can be expected to be sufficient. 368 2.3. Transport Network Function (TNF) 370 Figure 1 shows a view of the functions and interfaces for 371 provisioning the MTNC-IDs. The focus is on provisioning between the 372 3GPP management plane (NSSMF), transport network (SDN-C) and carrying 373 the MTNC-IDs in PDU packets for the transport network to grant the 374 provisioned resources. 376 In Figure 1, the TNF (logical functionality within the NSSMF) 377 requests the SDN-C in the transport domain to program the TE path 378 using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE) 379 routers and internal routers according to the underlay transport 380 technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming 381 PDU data packets for the MTNC-ID, classifies and provides the VN 382 service provisioned across the transport network. 384 The detailed mechanisms by which the NSSMF provides the MTNC-IDs to 385 the control plane and user plane functions are for 3GPP to specify. 386 Two possible options are outlined below for completeness. The NSSMF 387 may provide the MTNC-IDs to the 3GPP control plane by either 388 providing it to the Session Management Function (SMF), and the SMF in 389 turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU 390 session setup. Alternatively, the user plane functions may request 391 the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case 392 where user plane entities request the TNF/NSSMF to translate the 393 Request and get the MTNC-ID (over interface Ns/Nn). 395 The TNF should be seen as a logical entity that can be part of NSSMF 396 in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use 397 network configuration, policies, history, heuristics or some 398 combination of these to derive traffic estimates that the TNF would 399 use. How these estimates are derived are not in the scope of this 400 document. The focus here is only in terms of how the TNF and SDN-C 401 are programmed given that slice and QoS characteristics across a 402 transport path can be represented by an MTNC-ID. The TNF requests 403 the SDN-C in the transport network to provision paths in the 404 transport domain based on the MTNC-ID. The TNF is capable of 405 providing the MTNC-ID provisioned to control and user plane functions 406 in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID 407 should be part of the 3GPP specifications. 409 2.4. TNF Interfaces 411 A south bound interface Ns is shown which interacts with the 5G 412 Access Network (e.g. CSR). 'Ns' can use one or more mechanism 413 available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF 414 [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay 415 paths from CSR to PE@UPF. Ns and Nn interfaces can be part of the 416 integrated 3GPP architecture, but the specification/ownership of 417 these interfaces SHOULD be left out of scope of 3GPP. 419 A north bound interface 'Nn' is shown from one or more of the 420 transport network nodes (or PE @ ULCL/BP UPF, Anchor Point UPF) to 421 TNF as shown in Figure 1. It would enable learning the TE 422 characteristics of all links and nodes of the network continuously 423 (through BGP-LS [RFC7752] or through a passive IGP adjacency and PCEP 424 [RFC5440]). 426 These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs 427 and UPFs concerned to allow mobility of UEs while associated with one 428 of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. 430 2.5. Transport Provisioning 432 Functionality of transport provisioning for an engineered IP 433 transport that supports 3GPP slicing and QoS requirements in 434 [TS.23.501-3GPP] is described in this section. 436 During a PDU session setup, the AMF using input from the NSSF selects 437 a network slice and SMF. The SMF with user policy from Policy 438 Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the 439 path of the PDU session. While QoS and slice selection for the PDU 440 session can be applied across the 3GPP control and user plane 441 functions as outlined in Section 2, the IP transport underlay across 442 N3 and N9 segments do not have enough information to apply the 443 resource constraints represented by the slicing and QoS 444 classification. Current guidelines for interconnection with 445 transport networks [IR.34-GSMA] provide an application mapping into 446 DSCP. However, these recommendations do not take into consideration 447 other aspects in slicing like isolation, protection and replication. 449 IP transport networks have their own slice and QoS configuration 450 based on domain policies and the underlying network capability. 451 Transport networks can enter into an agreement for virtual network 452 services (VNS) with client domains using the ACTN [RFC8453] 453 framework. An IP transport network may provide such slice instances 454 to mobile network operators, CDN providers or enterprises for 455 example. The 3GPP mobile network, on the other hand, defines a slice 456 instance for UEs as are the the mobile operator's 'clients'. The 457 Network Slice Selection Management Function (NSSMF) [TS 28.533] that 458 interacts with a TN controller like an SDN-C (that is out of scope of 459 3GPP). 461 The ACTN VN service can be used across the IP transport networks to 462 provision and map the slice instance and QoS of the 3GPP domain to 463 the IP transport domain. An abstraction that represents QoS and 464 slice instance in the mobile domain and mapped to ACTN VN service in 465 the transport domain is represented here as MTNC-IDs. Details of how 466 the MTNC-IDs are derived are upto functions that can estimate the 467 level of traffic demand. 469 The 3GPP network/5GS provides slices instances to its clients (UE) 470 that include resources for radio and mobile core segments. The UE's 471 PDU session spans the access network (radio) and N3 and N9 transport 472 segments which have an IP transport underlay. The 5G operator needs 473 to obtain slice capability from the IP transport provider since these 474 resources are not seen by the 5GS. Several UE sessions that match a 475 slice may be mapped to an IP transport segment. Thus, there needs to 476 be a mapping between the slice capability offered to the UE (NSSAI) 477 and what is provided by the IP transport. 479 When the 3GPP user plane function (5G-AN, UPF) does not terminate the 480 transport underlay protocol (e.g., MPLS), it needs to be carried in 481 the IP protocol header from end-to-end of the mobile transport 482 connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses 483 these scenarios in detail. 485 2.6. MTNC-ID in the Data Packet 487 When the 3GPP user plane function (5G-AN, UPF) and transport provider 488 edge is on different nodes, the PE router needs to have the means by 489 which to classify the PDU packet. The mapping information is 490 provisioned between the 5G provider and IP transport network and 491 corresponding information should be carried in each IP packet on the 492 N3, N9 interface. To allow the IP transport edge nodes to inspect 493 the transport context information efficiently, it should be carried 494 in an IP header field that is easy to inspect. It may be noted that 495 the N3 and N9 interfaces in 5GS are IP interfaces. Thus, Layer 2 496 alternatives such as VLAN will fail if there are multiple L2 networks 497 on the N3 or N9 path. Another alternative is to use L3 VPNs. 498 However, in the 5G architecture, there may be a large number of 499 smaller UPFs that are dynamically inserted on path. Adding this VPN 500 information for dynamic UPF insertion is configuration intensive and 501 error prone. GTP (N3, N9 encapsulation header) field extensions 502 offer a possibility, however these extensions are hard for a 503 transport edge router to parse efficiently on a per packet basis. 504 Other IP header fields like DSCP are not suitable as it only conveys 505 the QoS aspects (but not other aspects like isolation, protection, 506 etc.) 508 IPv6 extension headers like FaST, or SRv6 may be options to carry the 509 MTNC-ID when such mechanism is a viable (if complete transport 510 network is IPv6 based). To mininise the protocol changes are 511 required and make this underlay tranport independed (IPv4/IPv6/MPLS/ 512 L2), an option is to provision a mapping of MTNC-ID to a UDP port 513 range of the GTP encapsulated user packet. A simple mapping table 514 between the MTNC-ID and the source UDP port number can be configured 515 to ensure that ECMP /load balancing is not affected adversely by 516 encoding the UDP source port with an MTNC-ID mapping. This mapping 517 is configured in 3GPP user plane functions (5G-AN, UPF) and Provider 518 Edge (PE) Routers that process MTNC-IDs. PE routers can thus 519 provision a policy based on the source UDP port number (which 520 reflects the mapped MTNC-ID) to underlying transport path and then 521 deliver the QoS/slice resource provisioned in the transport network. 522 The source UDP port that is encoded is the outer IP (corresponding to 523 GTP header) while the inner IP packet (UE payload) is unaltered. 525 2.7. Functionality for E2E Management 527 With the TNF finctionality in 5GS Service Based Interface, the 528 following additional functionalities are required for end-2-end slice 529 management including the transport network: 531 o The Specific Network Slice Selection Assistance Information 532 (S-NSSAI) of PDU session SHOULD be mapped to the assigned 533 transport VPN and the TE path information for that slice. 535 o For transport slice assignment for various SSTs (eMBB, URLLC, 536 MIoT) corresponding underlay paths need to be created and 537 monitored from each transport end point (CSR and PE@UPF). 539 o During PDU session creation, apart from radio and 5GC resources, 540 transport network resources needed to be verified matching the 541 characteristics of the PDU session traffic type. 543 o The TNF MUST provide an API that takes as input the source and 544 destination 3GPP user plane element address, required bandwidth, 545 latency and jitter characteristics between those user plane 546 elements and returns as output a particular TE path's identifier, 547 that satisfies the requested requirements. 549 o Mapping of PDU session parameters to underlay SST paths need to be 550 done. One way to do this to let the SMF install a Forwarding 551 Action Rule (FAR) in the UPF via N4 with the FAR pointing to a 552 "Network Instance" in the UPF. A "Network Instance" is a logical 553 identifier for an underlying network. The "Network Instance" 554 pointed by the FAR can be mapped to a transport path (through L2/ 555 L3 VPN). FARs are associated with Packet Detection Rule (PDR). 556 PDRs are used to classify packets in the uplink (UL) and the 557 downlink (DL) direction. For UL procedures specified in 558 Section 2.5, Section 2.6 can be used for classifying a packet 559 belonging to a particular slice characteristics. For DL, at a PSA 560 UPF, the UE IP address is used to identify the PDU session, and 561 hence the slice a packet belongs to and the IP 5 tuple can be used 562 for identifying the flow and QoS characteristics to be applied on 563 the packet at UPF. If a PE is not co-located at the UPF then 564 mapping to the underlying TE paths at PE happens based on the 565 encapsulated GTP-US packet as specified in Section 2.6. 567 o If any other form of encapsulation (other than GTP-U) either on N3 568 or N9 corresponding QFI information MUST be there in the 569 encapsulation header. 571 o In some SSC modes Appendix B, if segmented path (CSR to 572 PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then 573 corresponding path characteristics MUST be used. This includes a 574 path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF 575 to eventual UPF access to DN. 577 o Continuous monitoring of the underlying transport path 578 characteristics should be enabled at the endpoints (technologies 579 for monitoring depends traffic engineering technique used as 580 described in Section 3 and Section 4). If path characteristics 581 are degraded, reassignment of the paths at the endpoints should be 582 performed. For all the affected PDU sessions, degraded transport 583 paths need to be updated dynamically with similar alternate paths. 585 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 586 based or N2 based), for target gNB selection, apart from radio 587 resources, transport resources MUST be factored. This enables 588 handling of all PDU sessions from the UE to target gNB and this 589 require co-ordination of gNB, AMF, SMF with the TNF module. 591 Integrating the TNF as part of the 5GS Service Based Interfaces, 592 provides the flexibility to control the allocation of required 593 characteristics from the TN during a 5GS signaling procedure (e.g. 594 PDU Session Establishment). If TNF is seen as part of management 595 plane, this real time flexibility is lost. Changes to detailed 596 signaling to integrate the above for various 5GS procedures as 597 defined in [TS.23.502-3GPP] is beyond the scope of this document. 599 3. Using PPR as TN Underlay 601 In a network implementing source routing, packets may be transported 602 through the use of Segment Identifiers (SIDs), where a SID uniquely 603 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 604 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 605 all SRv6 features along with a few concerns in Section 5.3.7 of the 606 same document. Those concerns as well as need for underlay agnostic 607 (L2/Ipv4/IPv6/MPLS) TE requirements are addressed by a new XHaul 608 routing mechanism called Preferred Path Routing (PPR), of which this 609 section provides an overview. 611 With PPR, the label/PPR-ID refer not to individual segments of which 612 the path is composed, but to the identifier of a path that is 613 deployed on network nodes. The fact that paths and path identifiers 614 can be computed and controlled by a controller, not a routing 615 protocol, allows the deployment of any path that network operators 616 prefer, not just shortest paths. As packets refer to a path towards 617 a given destination and nodes make their forwarding decision based on 618 the identifier of a path, not the identifier of a next segment node, 619 it is no longer necessary to carry a sequence of labels. This 620 results in multiple benefits including significant reduction in 621 network layer overhead, increased performance and hardware 622 compatibility for carrying both path and services along the path. 624 Details of the IGP extensions for PPR are provided here: 626 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 628 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 630 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 632 PPR does not remove GTP-U, unlike some other proposals laid out in 633 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 634 with the existing cellular user plane (GTP-U) for both N3 and any 635 approach selected for N9 (encapsulation or no-encapsulation). In 636 this scenario, PPR will only help providing TE benefits needed for 5G 637 slices from transport domain perspective. It does so for any 638 underlying data plane used in the transport network (L2/IPv4/IPv6/ 639 MPLS). This is achieved by: 641 o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in 642 the transport network. For Uplink traffic, the 5G-AN will choose 643 the right PPR-ID of the UPF based on the S-NSSAI the PDU Session 644 belongs to and/or the UDP Source port (corresponds to the MTNC-ID 645 Section 2.5) of the GTP-U encapsulation header. Similarly in the 646 Downlink direction matching PPR-ID of the 5G-AN is chosen based on 647 the S-NSSAI the PDU Session belongs to. The table below shows a 648 typical mapping: 650 +----------------+------------+------------------+-----------------+ 651 |GTP/UDP SRC PORT| SST | Transport Path | Transport Path | 652 | | in S-NSSAI | Info | Characteristics | 653 +----------------+------------+------------------+-----------------+ 654 | Range Xx - Xy | | | | 655 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 656 | values) | (massive | PPR-ID-A | Bit Rate) | 657 | | IOT) | | Bandwidth: Bx | 658 | | | | Delay: Dx | 659 | | | | Jitter: Jx | 660 +----------------+------------+------------------+-----------------+ 661 | Range Yx - Yy | | | | 662 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 663 | values) | (ultra-low | PPR-ID-B | Req. | 664 | | latency) | | Bandwidth: By | 665 | | | | Delay: Dy | 666 | | | | Jitter: Jy | 667 +----------------+------------+------------------+-----------------+ 668 | Range Zx - Zy | | | | 669 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 670 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 671 +----------------+------------+------------------+-----------------+ 673 Figure 2: Mapping of PPR-IDs on N3/N9 675 o It is possible to have a single PPR-ID for multiple input points 676 through a PPR tree structure separate in UL and DL direction. 678 o Same set of PPRs are created uniformly across all needed 5G-ANs 679 and UPFs to allow various mobility scenarios. 681 o Any modification of TE parameters of the path, replacement path 682 and deleted path needed to be updated from TNF to the relevant 683 ingress points. Same information can be pushed to the NSSF, and/ 684 or SMF as needed. 686 o PPR can be supported with any native IPv4 and IPv6 data/user 687 planes (Section 3.2) with optional TE features (Section 3.3) . As 688 this is an underlay mechanism it can work with any overlay 689 encapsulation approach including GTP-U as defined currently for N3 690 interface. 692 3.2. Path Steering Support to native IP user planes 694 PPR works in fully compatible way with SR defined user planes (SR- 695 MPLS and SRv6) by reducing the path overhead and other challenges as 696 listed in Section 5.3.7 of 697 [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the 698 source routing to user planes beyond SR-MPLS and SRv6 i.e., L2, 699 native IPv6 and IPv4 user planes. 701 This helps legacy transport networks to get the immediate path 702 steering benefits and helps in overall migration strategy of the 703 network to the desired user plane. Some of these benefits with PPR 704 can be realized with no hardware upgrade except control plane 705 software for native IPv6 and IPv4 user planes. 707 3.3. Service Level Guarantee in Underlay 709 PPR also optionally allows to allocate resources that are to be 710 reserved along the preferred path. These resources are required in 711 some cases (for some 5G SSTs with stringent GBR and latency 712 requirements) not only for providing committed bandwidth or 713 deterministic latency, but also for assuring overall service level 714 guarantee in the network. This approach does not require per-hop 715 provisioning and reduces the OPEX by minimizing the number of 716 protocols needed and allows dynamism with Fast-ReRoute (FRR) 717 capabilities. 719 4. Other TE Technologies Applicability 721 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 722 for MPLS user plane. However, it is perceived as less dynamic in 723 some cases and has some provisioning overhead across all the nodes in 724 N3 and N9 interface nodes. Also it has another drawback with 725 excessive state refresh overhead across adjacent nodes and this can 726 be mitigated with [RFC8370]. 728 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 729 bandwidth reservation or mechanism to guarantee latency on the nodes/ 730 links on SR path. But, SR allows path steering for any flow at the 731 ingress and particular path for a flow can be chosen. Some of the 732 issues around path overhead/tax, MTU issues are documented at 733 Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- 734 MPLS allows reduction of the control protocols to one IGP (with out 735 needing for LDP and RSVP-TE). 737 However, as specified above with PPR (Section 3), in the integrated 738 transport network function (TNF) a particular RSVP-TE path for MPLS 739 or SR path for MPLS and IPv6 with SRH user plane, can be supplied to 740 SMF for mapping a particular PDU session to the transport path. 742 5. Acknowledgements 744 Thanks to Young Lee for discussions on this document including ACTN 745 applicability for the proposed TNF. Thanks to Sri Gundavelli and 746 3GPP delegates who provided detailed feedback on this document. 748 6. IANA Considerations 750 This document has no requests for any IANA code point allocations. 752 7. Security Considerations 754 This document does not introduce any new security issues. 756 8. Contributing Authors 758 The following people contributed substantially to the content of this 759 document and should be considered co-authors. 761 Xavier De Foy 762 InterDigital Communications, LLC 763 1000 Sherbrooke West 764 Montreal 765 Canada 767 Email: Xavier.Defoy@InterDigital.com 769 9. References 771 9.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 9.2. Informative References 780 [ATIS075] Alliance for Telecommunications Industry Solutions (ATIS), 781 "IOT Categorization: Exploring the Need for Standardizing 782 Additional Network Slices ATIS-I-0000075", September 2019. 784 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 785 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 786 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 787 Camarillo, "Topology Independent Fast Reroute using 788 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 789 lfa-05 (work in progress), October 2018. 791 [I-D.bogineni-dmm-optimized-mobile-user-plane] 792 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 793 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 794 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 795 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 796 optimized-mobile-user-plane-01 (work in progress), June 797 2018. 799 [I-D.chunduri-lsr-isis-preferred-path-routing] 800 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 801 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 802 draft-chunduri-lsr-isis-preferred-path-routing-04 (work in 803 progress), July 2019. 805 [I-D.chunduri-lsr-ospf-preferred-path-routing] 806 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 807 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 808 chunduri-lsr-ospf-preferred-path-routing-03 (work in 809 progress), May 2019. 811 [I-D.farinacci-lisp-mobile-network] 812 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 813 for the Mobile Network", draft-farinacci-lisp-mobile- 814 network-06 (work in progress), September 2019. 816 [I-D.ietf-dmm-5g-uplane-analysis] 817 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 818 "User Plane Protocol and Architectural Analysis on 3GPP 5G 819 System", draft-ietf-dmm-5g-uplane-analysis-02 (work in 820 progress), July 2019. 822 [I-D.ietf-dmm-srv6-mobile-uplane] 823 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 824 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 825 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06 826 (work in progress), September 2019. 828 [I-D.ietf-intarea-gue-extensions] 829 Herbert, T., Yong, L., and F. Templin, "Extensions for 830 Generic UDP Encapsulation", draft-ietf-intarea-gue- 831 extensions-06 (work in progress), March 2019. 833 [I-D.ietf-spring-segment-routing] 834 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 835 Litkowski, S., and R. Shakir, "Segment Routing 836 Architecture", draft-ietf-spring-segment-routing-15 (work 837 in progress), January 2018. 839 [IR.34-GSMA] 840 GSM Association (GSMA), "Guidelines for IPX Provider 841 Networks (Previously Inter-Service Provider IP Backbone 842 Guidelines, Version 14.0", August 2018. 844 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 845 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 846 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 847 . 849 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 850 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 851 DOI 10.17487/RFC5440, March 2009, 852 . 854 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 855 and A. Bierman, Ed., "Network Configuration Protocol 856 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 857 . 859 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 860 Locator/ID Separation Protocol (LISP)", RFC 6830, 861 DOI 10.17487/RFC6830, January 2013, 862 . 864 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 865 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 866 RFC 7490, DOI 10.17487/RFC7490, April 2015, 867 . 869 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 870 S. Ray, "North-Bound Distribution of Link-State and 871 Traffic Engineering (TE) Information Using BGP", RFC 7752, 872 DOI 10.17487/RFC7752, March 2016, 873 . 875 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 876 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 877 . 879 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 880 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 881 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 882 . 884 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 885 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 886 DOI 10.17487/RFC8453, August 2018, 887 . 889 [TS.23.401-3GPP] 890 3rd Generation Partnership Project (3GPP), "Procedures for 891 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 893 [TS.23.501-3GPP] 894 3rd Generation Partnership Project (3GPP), "System 895 Architecture for 5G System; Stage 2, 3GPP TS 23.501 896 v2.0.1", December 2017. 898 [TS.23.502-3GPP] 899 3rd Generation Partnership Project (3GPP), "Procedures for 900 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 901 2017. 903 [TS.23.503-3GPP] 904 3rd Generation Partnership Project (3GPP), "Policy and 905 Charging Control System for 5G Framework; Stage 2, 3GPP TS 906 23.503 v1.0.0", December 2017. 908 [TS.28.533-3GPP] 909 3rd Generation Partnership Project (3GPP), "Management and 910 Orchestration Architecture Framework (Release 15)", June 911 2018. 913 [TS.29.281-3GPP] 914 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 915 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 916 December 2018. 918 Appendix A. New Control Plane and User Planes 920 A.1. Slice aware Mobility: Discrete Approach 922 In this approach transport network functionality from the 5G-AN to 923 UPF is discrete and 5GS is not aware of the underlying transport 924 network and the resources available. Deployment specific mapping 925 function is used to map the GTP-U encapsulated traffic at the 5G-AN 926 (e.g. gNB) in UL and UPF in DL direction to the appropriate transport 927 slice or transport Traffic Engineered (TE) paths. These TE paths can 928 be established using RSVP-TE [RFC3209] for MPLS underlay, SR 929 [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or 930 PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 931 with SRH, native IPv6 and native IPv4 underlays. 933 As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 934 user plane traffic forwarding rules in the UPF. The UPFs have a 935 concept of a "Network Instance" which logically abstracts the 936 underlying transport path. When the SMF creates the packet detection 937 rules (PDR) and forwarding action rules (FAR) for a PDU session at 938 the UPF, the SMF identifies the network instance through which the 939 packet matching the PDR has to be forwarded. A network instance can 940 be mapped to a TE path at the UPF. In this approach, TNF as shown in 941 Figure 1 need not be part of the 5G Service Based Interface (SBI). 942 Only management plane functionality is needed to create, monitor, 943 manage and delete (life cycle management) the transport TE paths/ 944 transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). 945 The management plane functionality also provides the mapping of such 946 TE paths to a network instance identifier to the SMF. The SMF uses 947 this mapping to install appropriate FARs in the UPF. This approach 948 provide partial integration of the transport network into 5GS with 949 some benefits. 951 One of the limitations of this approach is the inability of the 5GS 952 procedures to know, if underlying transport resources are available 953 for the traffic type being carried in PDU session before making 954 certain decisions in the 5G CP. One example scenario/decision could 955 be, a target 5G-AN selection during a N2 mobility event, without 956 knowing if the target 5G-AN is having a underlay transport slice 957 resource for the S-NSSAI and 5QI of the PDU session. The Integrated 958 approach specified below can mitigate this. 960 Appendix B. PPR with various 5G Mobility procedures 962 PPR fulfills the needs of 5GS to transport the user plane traffic 963 from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This 964 is done in keeping the backhaul network at par with 5G slicing 965 requirements that are applicable to Radio and virtualized core 966 network to create a truly end-to-end slice path for 5G traffic. When 967 UE moves across the 5G-AN (e.g. from one gNB to another gNB), there 968 is no transport network reconfiguration required with the approach 969 above. 971 SSC mode would be specified/defaulted by SMF. No change in the mode 972 once connection is initiated and this property is not altered here. 974 B.1. SSC Mode1 976 +--------------+ 977 +---+----+ |NSSMF +-----+ | +----------------+ 978 | AMF | | | TNF | | | SMF | 979 +---+--+-+ | +-+-+-+ | +-+--------------+ 980 N1 | +--------+-+---+ | 981 | | | | | 982 +--------+ N2 +----Ns---+ +-Nn-+ N4 983 | | | | | 984 + +---+---+ +--++ +-+--+---+ +----+ 985 UE1 |gNB|======|CSR|------N3---- | PE+UPF |-N6--| DN | 986 == +---+ +---+ +--------+ +----+ 988 Figure 3: SSC Mode1 with integrated Transport Slice Function 990 After UE1 moved to another gNB in the same UPF serving area 992 +--------------+ 993 +---+----+ |NSSMF +-----+ | +----------------+ 994 | AMF | | | TNF | | | SMF | 995 +---+--+-+ | +-+-+-+ | +-+--------------+ 996 | +--------+-+---+ | 997 | | | | 998 N2 +----Ns---+ +-Nn-+ N4 999 | | | | 1000 +----+--+ +-+-+ ++--+----+ +----+ 1001 |gNB1|======|CSR|------N3-----| PE+UPF |-N6--| DN | 1002 +----+ +---+ +---+----+ +----+ 1003 | 1004 | 1005 | 1006 | 1007 +----+ +--++ | 1008 UE1 |gNB2|======|CSR|------N3--------+ 1009 == +----+ +---+ 1011 Figure 4: SSC Mode1 with integrated Transport Slice Function 1013 In this mode, IP address at the UE is preserved during mobility 1014 events. This is similar to 4G/LTE mechanism and for respective 1015 slices, corresponding PPR-ID (TE Path) has to be assigned to the 1016 packet at UL and DL direction. During Xn mobility as shown above, 1017 source gNB has to additionally ensure transport path's resources from 1018 TNF are available at the target gNB apart from radio resources check 1019 (at decision and request phase of Xn/N2 mobility scenario). 1021 B.2. SSC Mode2 1023 In this case, if IP Address is changed during mobility (different UPF 1024 area), then corresponding PDU session is released. No session 1025 continuity from the network is provided and this is designed as an 1026 application offload and application manages the session continuity, 1027 if needed. For PDU Session, Service Request and Mobility cases 1028 mechanism to select the transport resource and the PPR-ID (TE Path) 1029 is similar to SSC Mode1. 1031 B.3. SSC Mode3 1033 In this mode, new IP address may be assigned because of UE moved to 1034 another UPF coverage area. Network ensures UE suffers no loss of 1035 'connectivity'. A connection through new PDU session anchor point is 1036 established before the connection is terminated for better service 1037 continuity. There are two ways in which this happens. 1039 o Change of SSC Mode 3 PDU Session Anchor with multiple PDU 1040 Sessions. 1042 o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU 1043 Session. 1045 In the first mode, from user plane perspective, the two PDU sessions 1046 are independent and the use of PPR-ID by gNB and UPFs is exactly 1047 similar to SSC Mode 1 described above. The following paragraphs 1048 describe the IPv6 multi-homed PDU session case for SSC Mode 3. 1050 +--------------+ 1051 +---+----+ |NSSMF +-----+ | +----------------+ 1052 | AMF | | | TNF | | | SMF | 1053 +---+--+-+ | +-+-+-+ | +-+-----------+--+ 1054 | | +--------+-+---+ | | 1055 N1 | | | | | 1056 to-UE+----+ N2 +------Ns---+ +-Nn-+ N4 N4| 1057 +---+ | | | | 1058 | | | | | 1059 +---+ +---++ +--+-------+--+ +---+---+ 1060 |gNB|===|CSR |---N3---| PE+BP UPF |-N9--| PE+UPF|-N6-> 1061 +---+ +----+ +----------+--+ +-------+ to DN 1062 | +----+ 1063 +-| DN | 1064 N6 +----+ 1066 Figure 5: SSC Mode3 and Service Continuity 1068 In the uplink direction for the traffic offloading from the Branching 1069 Point UPF, packet has to reach to the right exit UPF. In this case 1070 packet gets re-encapsulated by the BP UPF (with either GTP-U or the 1071 chosen encapsulation) after bit rate enforcement and LI, towards the 1072 anchor UPF. At this point packet has to be on the appropriate VPN/PW 1073 to the anchor UPF. This mapping is done based on the S-NSSAI the PDU 1074 session belongs to and/or with the UDP source port (corresponds to 1075 the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the 1076 PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR 1077 path) of the UPF. If it's a non-MPLS underlay, destination IP 1078 address of the encapsulation header would be the mapped PPR-ID (TE 1079 path). 1081 In the downlink direction for the incoming packet, UPF has to 1082 encapsulate the packet (with either GTP-U or the chosen 1083 encapsulation) to reach the BP UPF. Here mapping is done based on 1084 the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the 1085 BP UPF. If it's a non-MPLS underlay, destination IP address of the 1086 encapsulation header would be the mapped PPR-ID (TE path). In 1087 summary: 1089 o Respective PPR-ID on N3 and N9 has to be selected with correct 1090 transport characteristics from TNF. 1092 o For N2 based mobility SMF has to ensure transport resources are 1093 available for N3 Interface to new BP UPF and from there the 1094 original anchor point UPF. 1096 o For Service continuity with multi-homed PDU session same transport 1097 network characteristics of the original PDU session (both on N3 1098 and N9) need to be observed for the newly configured IPv6 1099 prefixes. 1101 Authors' Addresses 1103 Uma Chunduri (editor) 1104 Futurewei 1105 2330 Central Expressway 1106 Santa Clara, CA 95050 1107 USA 1109 Email: umac.ietf@gmail.com 1111 Richard Li 1112 Futurewei 1113 2330 Central Expressway 1114 Santa Clara, CA 95050 1115 USA 1117 Email: richard.li@futurewei.com 1119 Sridhar Bhaskaran 1120 Altiostar 1122 Email: sridharb@altiostar.com 1124 John Kaippallimalil 1125 Futurewei 1127 Email: john.kaippallimalil@futurewei.com 1129 Jeff Tantsura 1130 Apstra, Inc. 1132 Email: jefftant.ietf@gmail.com 1133 Luis M. Contreras 1134 Telefonica 1135 Sur-3 building, 3rd floor 1136 Madrid 28050 1137 Spain 1139 Email: luismiguel.contrerasmurillo@telefonica.com 1141 Praveen Muley 1142 Nokia 1143 440 North Bernardo Ave 1144 Mountain View, CA 94043 1145 USA 1147 Email: praveen.muley@nokia.com