idnits 2.17.1 draft-clt-dmm-tn-aware-mobility-06.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 35 instances of too long lines in the document, the longest one being 6 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 (March 9, 2020) is 1510 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 8453' is mentioned on line 441, but not defined == Unused Reference: 'I-D.bashandy-rtgwg-segment-routing-ti-lfa' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'I-D.farinacci-lisp-mobile-network' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dmm-srv6-mobile-uplane' is defined on line 905, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-intarea-gue-extensions' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 937, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 942, but no explicit reference was found in the text == Unused Reference: 'RFC6830' is defined on line 947, but no explicit reference was found in the text == Unused Reference: 'RFC7490' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC7752' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'RFC8040' is defined on line 963, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-chunduri-lsr-isis-preferred-path-routing-05 == Outdated reference: A later version (-18) exists of draft-farinacci-lisp-mobile-network-06 == Outdated reference: A later version (-04) exists of draft-ietf-dmm-5g-uplane-analysis-03 == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-07 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). 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: September 10, 2020 S. Bhaskaran 6 Altiostar 7 J. Kaippallimalil, Ed. 8 Futurewei 9 J. Tantsura 10 Apstra, Inc. 11 L. Contreras 12 Telefonica 13 P. Muley 14 Nokia 15 March 9, 2020 17 Transport Network aware Mobility for 5G 18 draft-clt-dmm-tn-aware-mobility-06 20 Abstract 22 This document specifies a framework and mapping from slices in 5G 23 mobile systems to transport slices in IP and Layer 2 transport 24 networks. Slices in 5G systems are characterized by latency bounds, 25 reservation guarantees, jitter, data rates, availability, mobility 26 speed, usage density, criticality and priority should be mapped to 27 transport slice characteristics that include bandwidth, latency and 28 criteria such as isolation, directionality and disjoint routes. 29 Mobile slice criteria need to be mapped to the appropriate transport 30 slice and capabilities offered in backhaul, midhaul and fronthaul 31 connectivity segments between radio side network functions and user 32 plane function (gateway). 34 This document describes how mobile network functions map its slice 35 criteria to identifiers in IP packets that transport segments use to 36 grant transport layer services. This is based on mapping between 37 mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment 38 Routing). Applicability of this framework and a new transport 39 network underlay routing mechanism, Preferred Path Routing (PPR), 40 which brings slice properties and works with any underlying transport 41 (L2, IPv4, SR and MPLS) is also discussed. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC2119 [RFC2119]. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on September 10, 2020. 66 Copyright Notice 68 Copyright (c) 2020 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 85 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 86 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 87 2. Transport and Slice aware Mobility in 5G Networks . . . . . . 6 88 2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 7 89 2.2. Front Haul Transport Network . . . . . . . . . . . . . . 9 90 2.3. Mobile Transport Network Context (MTNC) and Scalability . 9 91 2.4. Transport Network Function (TNF) . . . . . . . . . . . . 10 92 2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 11 93 2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 12 94 2.7. Functionality for E2E Management . . . . . . . . . . . . 13 95 3. Transport Network Underlays . . . . . . . . . . . . . . . . . 15 96 3.1. Using PPR as TN Underlay . . . . . . . . . . . . . . . . 15 97 3.1.1. PPR on F1-U/N3/N9 Interfaces . . . . . . . . . . . . 16 98 3.1.2. Path Steering Support to native IP user planes . . . 17 99 3.1.3. Service Level Guarantee in Underlay . . . . . . . . . 17 100 3.2. Other TE Technologies Applicability . . . . . . . . . . . 18 101 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 102 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 104 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 107 8.2. Informative References . . . . . . . . . . . . . . . . . 19 108 Appendix A. New Control Plane and User Planes . . . . . . . . . 22 109 A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 22 110 A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 23 111 Appendix B. PPR with various 5G Mobility procedures . . . . . . 24 112 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 24 113 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 25 114 B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 26 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 117 1. Introduction 119 The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP], 120 [TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a 121 comprehensive set of functions for access mobility, session handling 122 and related functions for subscription management, authentication and 123 policy among others. These network functions (NF) are defined using 124 a service-based architecture (SBA) that allows NFs to expose their 125 functions via an API and common service framework. 127 UPFs are the data forwarding entities in the 5GC architecture. The 128 architecture allows the placement of Branching Point (BP) and Uplink 129 Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- 130 AN can be a radio access network or any non-3GPP access network, for 131 example, WLAN. The IP address is anchored by a PDU session anchor 132 UPF (PSA UPF). 3GPP slicing and RAN aspects are further described in 133 (Appendix A.1). 135 5GS allows more than one UPF on the path for a PDU (Protocol Data 136 Unit) session that provides various functionality including session 137 anchoring, uplink classification and branching point for a multihomed 138 IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA 139 UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9 140 and N3 interface between the various UPF instances and the (R)AN and 141 also for the F1-U interface between the DU and the CU in the RAN. 142 3GPP has specified control and user plane aspects in [TS.23.501-3GPP] 143 to provide slice and QoS support. 3GPP has defined three broad slice 144 types to cover enhanced mobile broadband (eMBB) communications, 145 ultra-reliable low latency communications(URLLC) and massive internet 146 of things (mIoT). ATIS [ATIS075] has defined an additional slice 147 type for V2X services. There may be multiple instances of a slice 148 type to satisfy some characteristics like isolation. The slice 149 details in 3GPP, ATIS or NGMN do not specify how slice 150 characteristics for QoS, hard /soft isolation, protection and other 151 aspects should be satisfied in IP transport networks. This is 152 explored further in this document. 154 1.1. Problem Statement 156 [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one 157 of the core capability of 5GC with slice awareness from Radio and 5G 158 Core (5GC) network. The 5G System (5GS) as defined, does not 159 consider the resources and functionalities needed from transport 160 network for the selection of UPF. This is seen as independent 161 functionality and currently not part of 5GS. 163 However, the lack of underlying Transport Network (TN) awareness may 164 lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS 165 various procedures (e.g., session establishment, mobility). Meeting 166 the specific slice characteristics on the F1-U, N3, N9 interfaces 167 depends on the IP transport underlay providing these resources and 168 capabilities. This could also lead to the inability in meeting SLAs 169 for real-time, mission-critical or latency sensitive services. 5GS 170 procedures including but not limited to Service Request, PDU Session 171 Establishment, or UE mobility need same service level characteristics 172 from the Transport Network (TN) for the Protocols Data Unit (PDU) 173 session, similar to as provided in Radio and 5GC for the various 174 Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP]. 176 The 5GS provides slices to its clients (UEs). The UE's PDU session 177 spans the access network (radio network including the F1-U) and N3 178 and N9 transport segments which have an IP transport underlay. The 179 5G operator needs to obtain slice capability from the IP transport 180 provider. Several UE sessions that match a slice may be mapped to an 181 IP transport segment. Thus there needs to be a mapping between the 182 slice capability offered to the UE (S-NSSAI) and what is provided by 183 the IP transport. 185 1.2. Solution Approach 187 This document specifies an approach to fulfil the needs of 5GS to 188 transport user plane traffic from 5G-AN to UPF for all service 189 continuity modes [TS.23.501-3GPP] in an optimized fashion. This is 190 done by, keeping establishment and mobility procedures aware of 191 underlying transport network along with slicing requirements. 193 (Section 2) describes in detail on how TN aware mobility can be built 194 irrespective of underlying TN technology used. Using Preferred Path 195 Routing (PPR), applicable to any transport network underlay (IPv6, 196 MPLS and IPv4) is detailed in (Section 3.1). How other IETF TE 197 technologies applicable for this draft is specified in (Section 3.2). 198 At the end, (Appendix B) further describes the applicability and 199 procedures of PPR with 5G SSC modes on F1-U, N3 and N9 interfaces. 201 1.3. Acronyms 203 5QI - 5G QoS Indicator 205 5G-AN - 5G Access Network 207 AMF - Access and Mobility Management Function (5G) 209 BP - Branch Point (5G) 211 CSR - Cell Site Router 213 CP - Control Plane (5G) 215 CU - Centralized Unit (5G, gNB) 217 DN - Data Network (5G) 219 DU - Distributed Unit (5G, gNB) 221 eMBB - enhanced Mobile Broadband (5G) 223 FRR - Fast ReRoute 225 gNB - 5G NodeB 227 GBR - Guaranteed Bit Rate (5G) 229 GTP-U - GPRS Tunneling Protocol - Userplane (3GPP) 231 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 233 LFA - Loop Free Alternatives (IP FRR) 235 mIOT - Massive IOT (5G) 237 MPLS - Multi Protocol Label Switching 239 NSSMF - Network Slice Selection Management Function 240 QFI - QoS Flow ID (5G) 242 PPR - Preferred Path Routing 244 PDU - Protocol Data Unit (5G) 246 PW - Pseudo Wire 248 RAN - Radio Access Network 250 RQI - Reflective QoS Indicator (5G) 252 SBI - Service Based Interface (5G) 254 SID - Segment Identifier 256 SMF - Session Management Function (5G) 258 SSC - Session and Service Continuity (5G) 260 SST - Slice and Service Types (5G) 262 SR - Segment Routing 264 TE - Traffic Engineering 266 ULCL - Uplink Classifier (5G) 268 UP - User Plane(5G) 270 UPF - User Plane Function (5G) 272 URLLC - Ultra reliable and low latency communications (5G) 274 2. Transport and Slice aware Mobility in 5G Networks 276 3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing 277 in 5GS. However, the application of 5GS slices in transport network 278 for backhaul, mid-haul and front haul are not explicitly covered. To 279 support specific characteristics in backhaul (N3, N9), mid-haul (F1) 280 and front haul, it is necessary to map and provision corresponding 281 resources in the transport domain. This section describes how to 282 provision the mapping information in transport network and apply it 283 so that user plane packets can be provided the transport resources 284 (QoS, isolation, protection, etc.) expected by the 5GS slices. 286 TN Aware Mobility with optimized transport network functionality is 287 explained below. How an underlay agnostic routing technology fits in 288 this framework in detail along with other various TE technologies 289 briefly are in (Section 3.1) and (Section 3.2) respectively. 291 5G Control and Management Planes 292 +------------------------------------------------------------------------+ 293 | +--------------------------------------------------------------------+ | 294 | | (TNF) 5G Management Plane (TNF) | | 295 | +----+-----------------+-------------+---------------+-----------+---+ | 296 | | | | | | | 297 | +----+-----+ | F1-C +----+-----+ | N2 +----+---+ | 298 | | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | | 299 | | | | +----+-----+ | +----+---+ | 300 +-| |-----------|-------------|---------------|-----------|-----+ 301 | | | | | | 302 | | | | | | 303 | | | ACTN | | ACTN | 304 | | +---+---+ | +---+---+ | 305 | | | | | | | | 306 | gNB-DU | | SDN-C | E1 | SDN-C | | 307 | | | | | | | | 308 | | +---+---+ | +---+---+ | 309 | | | | | | 310 | | | | | | 311 | | __ +__ | ___+__ | 312 | | __/ \__ +--+---+ __/ \__ +-+-+ 313 | | / IP \ | gNB | / IP \ | | 314 UE---| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN 315 +----------| \__ __/ +------+ \__ __/ +---+ 316 \______/ \______/ 318 |------ F1-U -------| |------ N3 OR N9 ------| 320 Figure 1: Backhaul and Mid-haul Transport Network for 5G 322 2.1. Backhaul and Mid-Haul Transport Network 324 Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge) 325 routers provide IP transport service to 5GS user plane entities 5G-AN 326 (e.g. gNB) and UPF. 5GS architecture with high level management, 327 control and user plane entities and its interaction with the IP 328 transport plane is shown here. The slice capability required in IP 329 transport networks is estimated and provisioned by the functionality 330 as specified in Section 2.4 (TNF) with support from various other 331 control plane functions such as the Network Data Analytics Function 332 (NWDAF), Network Function Repository Function (NRF) and Policy 333 Control Function (PCF). The TNF is only a logical function that 334 maybe realized in a 3GPP management function such as Network Slice 335 Selection Management Function (NSSMF) defined in [TS.28.533-3GPP]. 336 The TNF requests the SDN-C to provision the IP XHaul network using 337 ACTN [RFC8453]. 339 The 5G management plane in Figure 1 interacts with the 5G control 340 plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and 341 gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS) 342 signaling from the UE for session management, mobility is handled by 343 the 5GC. When a UE initiates session establishment, it indicates the 344 desired slice type in the S-NSSAI (Specific Network Slice Selection 345 Assistance Information) field. The AMF uses the S-NSSAI, other 346 subscription information and configuration in the NSSF to select the 347 appropriate SMF and the SMF in turn selects UPFs (User Plane 348 Functions) that are able to provide the specified slice resources and 349 capabilities. 351 The AMF, SMF, NSSF, PCF, NRF, NWDAF and other control functions in 352 5GC are described in [TS.23.501-3GPP] Some of the slice capabilities 353 along the user plane path between the (R)AN and UPFs (F1-U, N3, N9 354 segments) such as a low latency path, jitter, protection and priority 355 needs these to be provided by the IP transport network. 357 The 5G user plane from UE to DN (Data Network) includes a mid-haul 358 segment (F1-U between gNB DU(UP), gNB CU(UP)) and backhaul (N3 359 between gNB - UPF; N9 between UPFs). If the RAN uses lower layer 360 split architecture as specified by O-RAN alliance, then the user 361 plane path from UE to DN also includes the fronthaul interface. The 362 fronthaul interface carries the radio frames in the form of In-phase 363 (I) and Quadrature (Q) samples using eCPRI encapsulation over 364 Ethernet or UDP over IP. 366 The N3, N9 and F1 user planes use GTP-U [TS.29.281-3GPP] to transport 367 UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). For the 368 front haul described further in Section 2.2, an Ethernet transport 369 with VLANs can be expected to be the case in many deployments. 371 Figure 1 also depicts the PE router, where transport paths are 372 initiated/terminated can be deployed separately with UPF or both 373 functionalities can be in the same node. The TNF provisions this in 374 the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP 375 encapsulated user packet from the (R)AN (gNB) or UPF with the slice 376 information traverses the F1U/N3/N9 segment, the PE router of the IP 377 transport underlay can inspect the slice information and provide the 378 provisioned capabilities. This is elaborated further in 379 (Section 2.5). 381 2.2. Front Haul Transport Network 383 The O-RAN Alliance has specified the fronthaul interface between the 384 O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer 385 information, in the form of In-phase (I) and Quadrature (Q) samples 386 are transported using Enhanced Common Public Radio Interface (eCPRI) 387 framing over Ethernet or UDP. On the Ethernet based fronthaul 388 interface, the slice information is carried in the Ethernet header 389 through the VLAN tags. The Ethernet switches in the fronthaul 390 transport network can inspect the slice information (VLAN tag) in the 391 Ethernet header and provide the provisioned capabilities. The 392 mapping of I and Q samples of different radio resources (radio 393 resource blocks or carriers etc.,.) to different slices and to their 394 respective VLAN tags on the fronthaul interface is controlled by the 395 O-RAN fronthaul C-Plane and M-Plane interfaces. On UDP based 396 fronthaul interface, the slice information is carried in the IP or 397 UDP header. The PE routers of the fronthaul transport network can 398 inspect the slice information in the IP or UDP header and provide the 399 provisioned capabilities. The fronthaul transport network is latency 400 and jitter sensitive. The provisioned slice capabilities in the 401 fronthaul transport network MUST take care of the latency and jitter 402 budgets of the specific slice for the fronthaul interface. The 403 provisioning of the fronthaul transport network is handled by the 404 SDN-C pertaining to the fronthaul transport. 406 2.3. Mobile Transport Network Context (MTNC) and Scalability 408 The MTNC represents a slice, QoS configuration for a transport path 409 between two 3GPP user plane functions. The Mobile-Transport Network 410 Context Identifier (MTNC-ID) is generated by the TNF to be unique for 411 each path and per traffic class (including QoS and slice aspects). 412 Thus, there may be more than one MTNC-ID for the same QoS and path if 413 there is a need to provide isolation (slice) of the traffic. It 414 should be noted that MTNC are per class/path and not per user session 415 (nor is it per data path entity). The MTNC-IDs are configured by the 416 TNF to be unique within a provisioning domain. 418 Since the MTNC-IDs are not generated per user flow or session, there 419 is no need for unique MTNC-IDs per flow/session. In addition, since 420 the traffic estimation not performed at the time of session 421 establishment, there is no provisioning delay experienced during 422 session setup. The MTNC-ID space scales as a square of the number 423 sites between which 3GPP user plane functions require paths. If 424 there are T traffic classes across N sites, the number of MTNC-IDs in 425 a fully meshed network is (N*(N-1)/2) * T. For example, if there are 426 3 traffic classes between 25 sites, there would be at most 900 MTNC- 427 IDs required. Multiple slices for the same QoS class that need to be 428 fully isolated, will add to the MTNC provisioning. An MTNC-ID space 429 of 16 bits (65K+ identifiers) can be expected to be sufficient. 431 2.4. Transport Network Function (TNF) 433 Figure 1 shows a view of the functions and interfaces for 434 provisioning the MTNC-IDs. The focus is on provisioning between the 435 3GPP management plane (NSSMF), transport network (SDN-C) and carrying 436 the MTNC-IDs in PDU packets for the transport network to grant the 437 provisioned resources. 439 In Figure 1, the TNF (logical functionality within the NSSMF) 440 requests the SDN-C in the transport domain to program the TE path 441 using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE) 442 routers and internal routers according to the underlay transport 443 technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming 444 PDU data packets for the MTNC-ID, classifies and provides the VN 445 service provisioned across the transport network. 447 The detailed mechanisms by which the NSSMF provides the MTNC-IDs to 448 the control plane and user plane functions are for 3GPP to specify. 449 Two possible options are outlined below for completeness. The NSSMF 450 may provide the MTNC-IDs to the 3GPP control plane by either 451 providing it to the Session Management Function (SMF), and the SMF in 452 turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU 453 session setup. Alternatively, the user plane functions may request 454 the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case 455 where user plane entities request the TNF/NSSMF to translate the 456 Request and get the MTNC-ID. Another alternative is for the TNF to 457 provide a mapping of the 3GPP Network Instance Identifier, described 458 in (Section 2.7) and the MTNC-ID to the user plane entities via 459 configuration. 461 The TNF should be seen as a logical entity that can be part of NSSMF 462 in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use 463 network configuration, policies, history, heuristics or some 464 combination of these to derive traffic estimates that the TNF would 465 use. How these estimates are derived are not in the scope of this 466 document. The focus here is only in terms of how the TNF and SDN-C 467 are programmed given that slice and QoS characteristics across a 468 transport path can be represented by an MTNC-ID. The TNF requests 469 the SDN-C in the transport network to provision paths in the 470 transport domain based on the MTNC-ID. The TNF is capable of 471 providing the MTNC-ID provisioned to control and user plane functions 472 in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID 473 should be part of the 3GPP specifications. 475 2.5. Transport Provisioning 477 Functionality of transport provisioning for an engineered IP 478 transport that supports 3GPP slicing and QoS requirements in 479 [TS.23.501-3GPP] is described in this section. 481 During a PDU session setup, the AMF using input from the NSSF selects 482 a network slice and SMF. The SMF with user policy from Policy 483 Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the 484 path of the PDU session. While QoS and slice selection for the PDU 485 session can be applied across the 3GPP control and user plane 486 functions as outlined in (Section 2), the IP transport underlay 487 across F1-U, N3 and N9 segments do not have enough information to 488 apply the resource constraints represented by the slicing and QoS 489 classification. Current guidelines for interconnection with 490 transport networks [IR.34-GSMA] provide an application mapping into 491 DSCP. However, these recommendations do not take into consideration 492 other aspects in slicing like isolation, protection and replication. 494 IP transport networks have their own slice and QoS configuration 495 based on domain policies and the underlying network capability. 496 Transport networks can enter into an agreement for virtual network 497 services (VNS) with client domains using the ACTN [RFC8453] 498 framework. An IP transport network may provide such slice instances 499 to mobile network operators, CDN providers or enterprises for 500 example. The 3GPP mobile network, on the other hand, defines a slice 501 instance for UEs as are the mobile operator's 'clients'. The Network 502 Slice Selection Management Function (NSSMF) [TS 28.533] that 503 interacts with a TN controller like an SDN-C (that is out of scope of 504 3GPP). 506 The ACTN VN service can be used across the IP transport networks to 507 provision and map the slice instance and QoS of the 3GPP domain to 508 the IP transport domain. An abstraction that represents QoS and 509 slice instance in the mobile domain and mapped to ACTN VN service in 510 the transport domain is represented here as MTNC-IDs. Details of how 511 the MTNC-IDs are derived are up to functions that can estimate the 512 level of traffic demand. 514 The 3GPP network/5GS provides slices instances to its clients (UE) 515 that include resources for radio and mobile core segments. The UE's 516 PDU session spans the access network (radio) and F1-U/N3/N9 transport 517 segments which have an IP transport underlay. The 5G operator needs 518 to obtain slice capability from the IP transport provider since these 519 resources are not seen by the 5GS. Several UE sessions that match a 520 slice may be mapped to an IP transport segment. Thus, there needs to 521 be a mapping between the slice capability offered to the UE (NSSAI) 522 and what is provided by the IP transport. 524 When the 3GPP user plane function (5G-AN, UPF) does not terminate the 525 transport underlay protocol (e.g., MPLS), it needs to be carried in 526 the IP protocol header from end-to-end of the mobile transport 527 connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses 528 these scenarios in detail. 530 2.6. MTNC-ID in the Data Packet 532 When the 3GPP user plane function (5G-AN, UPF) and transport provider 533 edge is on different nodes, the PE router needs to have the means by 534 which to classify the PDU packet. The mapping information is 535 provisioned between the 5G provider and IP transport network and 536 corresponding information should be carried in each IP packet on the 537 F1-U, N3, N9 interface. To allow the IP transport edge nodes to 538 inspect the transport context information efficiently, it should be 539 carried in an IP header field that is easy to inspect. It may be 540 noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces. 541 Thus, Layer 2 alternatives such as VLAN will fail if there are 542 multiple L2 networks on the F1-U or N3 or N9 path. GTP (F1-U, N3, N9 543 encapsulation header) field extensions offer a possibility, however 544 these extensions are hard for a transport edge router to parse 545 efficiently on a per packet basis. Other IP header fields like DSCP 546 are not suitable as it only conveys the QoS aspects (but not other 547 aspects like isolation, protection, etc.) 549 IPv6 extension headers like SRv6 may be options to carry the MTNC-ID 550 when such mechanism is a viable (if complete transport network is 551 IPv6 based). To mininise the protocol changes are required and make 552 this underlay tranport independent (IPv4/IPv6/MPLS/L2), an option is 553 to provision a mapping of MTNC-ID to a UDP port range of the GTP 554 encapsulated user packet. A simple mapping table between the MTNC-ID 555 and the source UDP port number can be configured to ensure that ECMP 556 /load balancing is not affected adversely by encoding the UDP source 557 port with an MTNC-ID mapping. This mapping is configured in 3GPP 558 user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that 559 process MTNC-IDs. 561 PE routers can thus provision a policy based on the source UDP port 562 number (which reflects the mapped MTNC-ID) to underlying transport 563 path and then deliver the QoS/slice resource provisioned in the 564 transport network. The source UDP port that is encoded is the outer 565 IP (corresponding to GTP header) while the inner IP packet (UE 566 payload) is unaltered. The source UDP port is encoded by the node 567 that creates the GTP-U encapsulation and therefore, this mechanism 568 has no impact to UDP checksum calculations. 570 3GPP network operators may use IPSec gateways (SEG) to secure packets 571 between two sites - for example over an F1-U, N3 or N9 segment. The 572 MTNC identifier in the GTP-U packet should be in the outer IP source 573 port even after IPSec encryption for PE transport routers to inspect 574 and provide the level of service provisioned. Tunnel mode - which is 575 the case for SEG/IPSec gateways - adds an outer IP header in both AH 576 (Authenticated Header) and ESP (Encapsulated Security Payload) modes. 577 The GTP-U / UDP source port with encoded MTNC identifier should be 578 copied to the IPSec tunnel ESP header. One option is to use 16 bits 579 from the SPI field of the ESP header to encode the MTNC identifier 580 and use the remaining 16 bits in SPI field to identify an SA. Load 581 balancing entropy for ECMP will not be affected as the MTNC encoding 582 mechanism already accounts for this. 584 If the RAN uses O-RAN lower layer split architecture, then a 585 fronthaul network is involved. On an Ethernet based fronthaul 586 transport network, VLAN tag may be an option to carry the MTNC-ID. 587 The VLAN ID provides a 12 bit space and is sufficient to support up 588 to 4096 slices on the fronthaul transport network. The mapping of 589 fronthaul traffic to corresponding network slice is based on the 590 radio resource for which the fronthaul carries the I and Q samples. 591 The mapping of fronthaul traffic to the VLAN tag corresponding to the 592 network slice is specified in Section 2.2. On UDP based fronthaul 593 transport network, the UDP source port can be used to carry the MTNC- 594 ID. 596 2.7. Functionality for E2E Management 598 With the TNF functionality in 5GS Service Based Interface, the 599 following additional functionalities are required for end-2-end slice 600 management including the transport network: 602 o The Specific Network Slice Selection Assistance Information 603 (S-NSSAI) of PDU session SHOULD be mapped to the assigned 604 transport VPN and the TE path information for that slice. 606 o For transport slice assignment for various SSTs (eMBB, URLLC, 607 MIoT) corresponding underlay paths need to be created and 608 monitored from each transport end point (CSR and PE@UPF). 610 o During PDU session creation, apart from radio and 5GC resources, 611 transport network resources needed to be verified matching the 612 characteristics of the PDU session traffic type. 614 o The TNF MUST provide an API that takes as input the source and 615 destination 3GPP user plane element address, required bandwidth, 616 latency and jitter characteristics between those user plane 617 elements and returns as output a particular TE path's identifier, 618 that satisfies the requested requirements. 620 o Mapping of PDU session parameters to underlay SST paths need to be 621 done. One way to do this to let the SMF install a Forwarding 622 Action Rule (FAR) in the UPF via N4 with the FAR pointing to a 623 "Network Instance" in the UPF. A "Network Instance" is a logical 624 identifier for an underlying network. The "Network Instance" 625 pointed by the FAR can be mapped to a transport path (through L2/ 626 L3 VPN). FARs are associated with Packet Detection Rule (PDR). 627 PDRs are used to classify packets in the uplink (UL) and the 628 downlink (DL) direction. For UL procedures specified in 629 (Section 2.5), (Section 2.6) can be used for classifying a packet 630 belonging to a particular slice characteristics. For DL, at a PSA 631 UPF, the UE IP address is used to identify the PDU session, and 632 hence the slice a packet belongs to and the IP 5 tuple can be used 633 for identifying the flow and QoS characteristics to be applied on 634 the packet at UPF. If a PE is not co-located at the UPF then 635 mapping to the underlying TE paths at PE happens based on the 636 encapsulated GTP-US packet as specified in (Section 2.6). 638 o If any other form of encapsulation (other than GTP-U) either on N3 639 or N9 corresponding QFI information MUST be there in the 640 encapsulation header. 642 o In some SSC modes (Appendix B), if segmented path (CSR to 643 PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then 644 corresponding path characteristics MUST be used. This includes a 645 path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF 646 to eventual UPF access to DN. 648 o Continuous monitoring of the underlying transport path 649 characteristics should be enabled at the endpoints (technologies 650 for monitoring depends traffic engineering technique used as 651 described in (Section 3.1) and (Section 3.2)). If path 652 characteristics are degraded, reassignment of the paths at the 653 endpoints should be performed. For all the affected PDU sessions, 654 degraded transport paths need to be updated dynamically with 655 similar alternate paths. 657 o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn 658 based or N2 based), for target gNB selection, apart from radio 659 resources, transport resources MUST be factored. This enables 660 handling of all PDU sessions from the UE to target gNB and this 661 require co-ordination of gNB, AMF, SMF with the TNF module. 663 Integrating the TNF as part of the 5GS Service Based Interfaces, 664 provides the flexibility to control the allocation of required 665 characteristics from the TN during a 5GS signaling procedure (e.g. 666 PDU Session Establishment). If TNF is seen as part of management 667 plane, this real time flexibility is lost. Changes to detailed 668 signaling to integrate the above for various 5GS procedures as 669 defined in [TS.23.502-3GPP] is beyond the scope of this document. 671 3. Transport Network Underlays 673 Apart from the various flavors of IETF VPN technologies to share the 674 transport network resources and capacity, TE capabilities in the 675 underlay network is an essential component to realize the 5G TN 676 requirements. This section focuses on various transport underlay 677 technologies (not exhaustive) and their applicability to realize 678 Midhaul/Backhaul transport networks. Focus is on the user/data plane 679 i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1. 681 3.1. Using PPR as TN Underlay 683 In a network implementing source routing, packets may be transported 684 through the use of Segment Identifiers (SIDs), where a SID uniquely 685 identifies a segment as defined in [I-D.ietf-spring-segment-routing]. 686 Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out 687 all SRv6 features along with a few concerns in Section 5.3.7 of the 688 same document. Those concerns as well as need for underlay agnostic 689 (L2/IPv4/IPv6/MPLS) TE requirements are addressed by a new XHaul 690 routing mechanism called Preferred Path Routing (PPR), of which this 691 section provides an overview. 693 With PPR, the label/PPR-ID refer not to individual segments of which 694 the path is composed, but to the identifier of a path that is 695 deployed on network nodes. The fact that paths and path identifiers 696 can be computed and controlled by a controller, not a routing 697 protocol, allows the deployment of any path that network operators 698 prefer, not just shortest paths. As packets refer to a path towards 699 a given destination and nodes make their forwarding decision based on 700 the identifier of a path, not the identifier of a next segment node, 701 it is no longer necessary to carry a sequence of labels. This 702 results in multiple benefits including significant reduction in 703 network layer overhead, increased performance and hardware 704 compatibility for carrying both path and services along the path. 706 Details of the IGP extensions for PPR are provided here: 708 o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] 710 o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] 712 3.1.1. PPR on F1-U/N3/N9 Interfaces 714 PPR does not remove GTP-U, unlike some other proposals laid out in 715 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 716 with the existing cellular user plane (GTP-U) for F1-U/N3 and any 717 approach selected for N9 (encapsulation or no-encapsulation). In 718 this scenario, PPR will only help providing TE benefits needed for 5G 719 slices from transport domain perspective. It does so for any 720 underlying user/data plane used in the transport network 721 (L2/IPv4/IPv6/MPLS). This is achieved by: 723 o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in 724 the transport network. For Uplink traffic, the 5G-AN will choose 725 the right PPR-ID of the UPF based on the S-NSSAI the PDU Session 726 belongs to and/or the UDP Source port (corresponds to the MTNC-ID 727 (Section 2.5)) of the GTP-U encapsulation header. Similarly in 728 the Downlink direction matching PPR-ID of the 5G-AN is chosen 729 based on the S-NSSAI the PDU Session belongs to. The table below 730 shows a typical mapping: 732 +----------------+------------+------------------+-----------------+ 733 |GTP/UDP SRC PORT| SST | Transport Path | Transport Path | 734 | | in S-NSSAI | Info | Characteristics | 735 +----------------+------------+------------------+-----------------+ 736 | Range Xx - Xy | | | | 737 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 738 | values) | (massive | PPR-ID-A | Bit Rate) | 739 | | IOT) | | Bandwidth: Bx | 740 | | | | Delay: Dx | 741 | | | | Jitter: Jx | 742 +----------------+------------+------------------+-----------------+ 743 | Range Yx - Yy | | | | 744 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 745 | values) | (ultra-low | PPR-ID-B | Req. | 746 | | latency) | | Bandwidth: By | 747 | | | | Delay: Dy | 748 | | | | Jitter: Jy | 749 +----------------+------------+------------------+-----------------+ 750 | Range Zx - Zy | | | | 751 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 752 | values) | (broadband)| PPR-ID-C | Bandwidth: Bx | 753 +----------------+------------+------------------+-----------------+ 755 Figure 2: Mapping of PPR-IDs on N3/N9 757 o It is possible to have a single PPR-ID for multiple input points 758 through a PPR tree structure separate in UL and DL direction. 760 o Same set of PPRs are created uniformly across all needed 5G-ANs 761 and UPFs to allow various mobility scenarios. 763 o Any modification of TE parameters of the path, replacement path 764 and deleted path needed to be updated from TNF to the relevant 765 ingress points. Same information can be pushed to the NSSF, and/ 766 or SMF as needed. 768 o PPR can be supported with any native IPv4 and IPv6 data/user 769 planes ( (Section 3.1.2)) with optional TE features ( 770 (Section 3.1.3)) . As this is an underlay mechanism it can work 771 with any overlay encapsulation approach including GTP-U as defined 772 currently for N3 interface. 774 3.1.2. Path Steering Support to native IP user planes 776 PPR works in fully compatible way with SR defined user planes (SR- 777 MPLS and SRv6) by reducing the path overhead and other challenges as 778 listed in Section 5.3.7 of 779 [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the 780 source routing to user planes beyond SR-MPLS and SRv6 i.e., L2, 781 native IPv6 and IPv4 user planes. 783 This helps legacy transport networks to get the immediate path 784 steering benefits and helps in overall migration strategy of the 785 network to the desired user plane. Some of these benefits with PPR 786 can be realized with no hardware upgrade except control plane 787 software for native IPv6 and IPv4 user planes. 789 3.1.3. Service Level Guarantee in Underlay 791 PPR also optionally allows to allocate resources that are to be 792 reserved along the preferred path. These resources are required in 793 some cases (for some 5G SSTs with stringent GBR and latency 794 requirements) not only for providing committed bandwidth or 795 deterministic latency, but also for assuring overall service level 796 guarantee in the network. This approach does not require per-hop 797 provisioning and reduces the OPEX by minimizing the number of 798 protocols needed and allows dynamism with Fast-ReRoute (FRR) 799 capabilities. 801 3.2. Other TE Technologies Applicability 803 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 804 for MPLS user plane. However, it is perceived as less dynamic in 805 some cases and has some provisioning overhead across all the nodes in 806 N3 and N9 interface nodes. Also, it has another drawback with 807 excessive state refresh overhead across adjacent nodes and this can 808 be mitigated with [RFC8370]. 810 SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal 811 bandwidth reservation or mechanism to guarantee latency on the nodes/ 812 links on SR path. But SR allows path steering for any flow at the 813 ingress and particular path for a flow can be chosen. Some of the 814 issues around path overhead/tax, MTU issues are documented at 815 Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- 816 MPLS allows reduction of the control protocols to one IGP (with out 817 needing for LDP and RSVP-TE). 819 However, as specified above with PPR ( (Section 3.1)), in the 820 integrated transport network function (TNF) a particular RSVP-TE path 821 for MPLS or SR path for MPLS and IPv6 with SRH user plane, can be 822 supplied to SMF for mapping a particular PDU session to the transport 823 path. 825 4. Acknowledgements 827 Thanks to Young Lee for discussions on this document including ACTN 828 applicability for the proposed TNF. Thanks to Sri Gundavelli and 829 3GPP delegates who provided detailed feedback on this document. 831 5. IANA Considerations 833 This document has no requests for any IANA code point allocations. 835 6. Security Considerations 837 This document does not introduce any new security issues. 839 7. Contributing Authors 841 The following people contributed substantially to the content of this 842 document and should be considered co-authors. 844 Xavier De Foy 845 InterDigital Communications, LLC 846 1000 Sherbrooke West 847 Montreal 848 Canada 850 Email: Xavier.Defoy@InterDigital.com 852 8. References 854 8.1. Normative References 856 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 857 Requirement Levels", BCP 14, RFC 2119, 858 DOI 10.17487/RFC2119, March 1997, 859 . 861 8.2. Informative References 863 [ATIS075] Alliance for Telecommunications Industry Solutions (ATIS), 864 "IOT Categorization: Exploring the Need for Standardizing 865 Additional Network Slices ATIS-I-0000075", September 2019. 867 [I-D.bashandy-rtgwg-segment-routing-ti-lfa] 868 Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., 869 Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. 870 Camarillo, "Topology Independent Fast Reroute using 871 Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- 872 lfa-05 (work in progress), October 2018. 874 [I-D.bogineni-dmm-optimized-mobile-user-plane] 875 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 876 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 877 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 878 Mobile User Plane Solutions for 5G", draft-bogineni-dmm- 879 optimized-mobile-user-plane-01 (work in progress), June 880 2018. 882 [I-D.chunduri-lsr-isis-preferred-path-routing] 883 Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, 884 L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", 885 draft-chunduri-lsr-isis-preferred-path-routing-05 (work in 886 progress), March 2020. 888 [I-D.chunduri-lsr-ospf-preferred-path-routing] 889 Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. 890 Contreras, "Preferred Path Routing (PPR) in OSPF", draft- 891 chunduri-lsr-ospf-preferred-path-routing-04 (work in 892 progress), March 2020. 894 [I-D.farinacci-lisp-mobile-network] 895 Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP 896 for the Mobile Network", draft-farinacci-lisp-mobile- 897 network-06 (work in progress), September 2019. 899 [I-D.ietf-dmm-5g-uplane-analysis] 900 Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, 901 "User Plane Protocol and Architectural Analysis on 3GPP 5G 902 System", draft-ietf-dmm-5g-uplane-analysis-03 (work in 903 progress), November 2019. 905 [I-D.ietf-dmm-srv6-mobile-uplane] 906 Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., 907 Voyer, D., and C. Perkins, "Segment Routing IPv6 for 908 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07 909 (work in progress), November 2019. 911 [I-D.ietf-intarea-gue-extensions] 912 Herbert, T., Yong, L., and F. Templin, "Extensions for 913 Generic UDP Encapsulation", draft-ietf-intarea-gue- 914 extensions-06 (work in progress), March 2019. 916 [I-D.ietf-spring-segment-routing] 917 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 918 Litkowski, S., and R. Shakir, "Segment Routing 919 Architecture", draft-ietf-spring-segment-routing-15 (work 920 in progress), January 2018. 922 [IR.34-GSMA] 923 GSM Association (GSMA), "Guidelines for IPX Provider 924 Networks (Previously Inter-Service Provider IP Backbone 925 Guidelines, Version 14.0", August 2018. 927 [ORAN-WG4.CUS-O-RAN] 928 O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group; 929 Control, User and Synchronization Plane Specification; 930 v2.0.0", August 2019. 932 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 933 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 934 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 935 . 937 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 938 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 939 DOI 10.17487/RFC5440, March 2009, 940 . 942 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 943 and A. Bierman, Ed., "Network Configuration Protocol 944 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 945 . 947 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 948 Locator/ID Separation Protocol (LISP)", RFC 6830, 949 DOI 10.17487/RFC6830, January 2013, 950 . 952 [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. 953 So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", 954 RFC 7490, DOI 10.17487/RFC7490, April 2015, 955 . 957 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 958 S. Ray, "North-Bound Distribution of Link-State and 959 Traffic Engineering (TE) Information Using BGP", RFC 7752, 960 DOI 10.17487/RFC7752, March 2016, 961 . 963 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 964 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 965 . 967 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 968 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 969 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 970 . 972 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 973 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 974 DOI 10.17487/RFC8453, August 2018, 975 . 977 [TS.23.401-3GPP] 978 3rd Generation Partnership Project (3GPP), "Procedures for 979 4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018. 981 [TS.23.501-3GPP] 982 3rd Generation Partnership Project (3GPP), "System 983 Architecture for 5G System; Stage 2, 3GPP TS 23.501 984 v2.0.1", December 2017. 986 [TS.23.502-3GPP] 987 3rd Generation Partnership Project (3GPP), "Procedures for 988 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 989 2017. 991 [TS.23.503-3GPP] 992 3rd Generation Partnership Project (3GPP), "Policy and 993 Charging Control System for 5G Framework; Stage 2, 3GPP TS 994 23.503 v1.0.0", December 2017. 996 [TS.28.533-3GPP] 997 3rd Generation Partnership Project (3GPP), "Management and 998 Orchestration Architecture Framework (Release 15)", June 999 2018. 1001 [TS.29.281-3GPP] 1002 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 1003 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 1004 December 2018. 1006 [TS.38.300-3GPP] 1007 3rd Generation Partnership Project (3GPP), "NR; NR and NG- 1008 RAN Overall Description; Stage 2; v15.7.0", September 1009 2019. 1011 [TS.38.401-3GPP] 1012 3rd Generation Partnership Project (3GPP), "NG-RAN; 1013 Architecture description; v15.7.0", September 2019. 1015 Appendix A. New Control Plane and User Planes 1017 A.1. Slicing Framework and RAN Aspects 1019 The 3GPP architecture defines slicing aspects where the Network Slice 1020 Selection Function (NSSF) assists the Access Mobility Manager (AMF) 1021 and Session Management Function (SMF) to assist and select the right 1022 entities and resources corresponding to the slice requested by the 1023 User Equipment (UE). The User Equipment (UE) indicates information 1024 regarding the set of slices it wishes to connect, in the Network 1025 Slice Selection Assistance Information (NSSAI) field during network 1026 registration procedure (Attach) and the specific slice the UE wants 1027 to establish an IP session, in the Specific NSSAI (S-NSSAI) field 1028 during the session establishment procedure (PDU Session 1029 Establishment). The AMF selects the right SMF and the SMF in turn 1030 selects the User Plane Functions (UPF) so that the QoS and 1031 capabilities requested can be fulfilled. 1033 The architecture for the Radio Access Network (RAN) is defined in 1034 [TS.38.300-3GPP] and [TS.38.401-3GPP]. The 5G RAN architecture 1035 allows disaggregation of the RAN into a Distributed Unit (DU) and a 1036 Centralized Unit (CU). The CU is further split into control plane 1037 (CU-CP) and user plane (CU-UP). The interface between CU-UP and the 1038 DU for the user plane traffic is called the F1-U and between the CU- 1039 CP and DU for the control plane traffic is called the F1-C. The F1-C 1040 and the F1-U together are called the mid-haul interfaces. The DU 1041 does not have a CP/UP split. Apart from 3GPP, O-RAN Alliance has 1042 specified further disaggregation of the RAN at the lower layer 1043 (physical layer). The DU is disaggregated into a ORAN DU (O-DU) 1044 which runs the upper part of the physical layer, MAC and RLC and the 1045 ORAN Radio Unit (O-RU) which runs the lower part of the physical 1046 layer. The interface between the O-DU and the O-RU is called the 1047 Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN]. 1049 A.2. Slice aware Mobility: Discrete Approach 1051 In this approach transport network functionality from the 5G-AN to 1052 UPF is discrete and 5GS is not aware of the underlying transport 1053 network and the resources available. Deployment specific mapping 1054 function is used to map the GTP-U encapsulated traffic at the 5G-AN 1055 (e.g. gNB) in UL and UPF in DL direction to the appropriate transport 1056 slice or transport Traffic Engineered (TE) paths. These TE paths can 1057 be established using RSVP-TE [RFC3209] for MPLS underlay, SR 1058 [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or 1059 PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 1060 with SRH, native IPv6 and native IPv4 underlays. 1062 As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 1063 user plane traffic forwarding rules in the UPF. The UPFs have a 1064 concept of a "Network Instance" which logically abstracts the 1065 underlying transport path. When the SMF creates the packet detection 1066 rules (PDR) and forwarding action rules (FAR) for a PDU session at 1067 the UPF, the SMF identifies the network instance through which the 1068 packet matching the PDR has to be forwarded. A network instance can 1069 be mapped to a TE path at the UPF. In this approach, TNF as shown in 1070 (Figure 1) need not be part of the 5G Service Based Interface (SBI). 1071 Only management plane functionality is needed to create, monitor, 1072 manage and delete (life cycle management) the transport TE paths/ 1073 transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). 1074 The management plane functionality also provides the mapping of such 1075 TE paths to a network instance identifier to the SMF. The SMF uses 1076 this mapping to install appropriate FARs in the UPF. This approach 1077 provide partial integration of the transport network into 5GS with 1078 some benefits. 1080 One of the limitations of this approach is the inability of the 5GS 1081 procedures to know, if underlying transport resources are available 1082 for the traffic type being carried in PDU session before making 1083 certain decisions in the 5G CP. One example scenario/decision could 1084 be, a target 5G-AN selection during a N2 mobility event, without 1085 knowing if the target 5G-AN is having a underlay transport slice 1086 resource for the S-NSSAI and 5QI of the PDU session. The Integrated 1087 approach specified below can mitigate this. 1089 Appendix B. PPR with various 5G Mobility procedures 1091 PPR fulfills the needs of 5GS to transport the user plane traffic 1092 from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This 1093 is done in keeping the backhaul network at par with 5G slicing 1094 requirements that are applicable to Radio and virtualized core 1095 network to create a truly end-to-end slice path for 5G traffic. When 1096 UE moves across the 5G-AN (e.g. from one gNB to another gNB), there 1097 is no transport network reconfiguration required with the approach 1098 above. 1100 SSC mode would be specified/defaulted by SMF. No change in the mode 1101 once connection is initiated and this property is not altered here. 1103 B.1. SSC Mode1 1105 +--------------+ 1106 +---+----+ |NSSMF +-----+ | +----------------+ 1107 | AMF | | | TNF | | | SMF | 1108 +---+--+-+ | +-+-+-+ | +-----+----------+ 1109 N1 | +--------+-+---+ | 1110 | | | | | 1111 | | +---+-+--+ | 1112 | | | SDN-C | | 1113 | | +---+-+--+ | 1114 | | | | | 1115 +--------+ N2 +---------+ + ---+ | 1116 | | | | | 1117 + +---+--+ +--++ +---+ +-+--+ +----+ 1118 UE1 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN | 1119 == +---+ +---+ +---+ +----+ +----+ 1121 Figure 3: SSC Mode1 with integrated Transport Slice Function 1123 After UE1 moved to another gNB in the same UPF serving area 1124 +--------------+ 1125 +---+----+ |NSSMF +-----+ | +----------------+ 1126 | AMF | | | TNF | | | SMF | 1127 +------+-+ | +-+-+-+ | +-----+----------+ 1128 | +--------+-+---+ | 1129 | | | | 1130 | +---+-+--+ | 1131 | | SDN-C | | 1132 | +---+-+--+ | 1133 | | | | 1134 N2 +---------+ + ---+ | 1135 | | | | 1136 +---+--+ +--++ +---+ +-+--+ +----+ 1137 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN | 1138 +---+ +---+ +-+-+ +----+ +----+ 1139 | 1140 | 1141 | 1142 | 1143 +----+ +---+ | 1144 UE1 |gNB2|======|CSR|------N3-------+ 1145 == +----+ +---+ 1147 Figure 4: SSC Mode1 with integrated Transport Slice Function 1149 In this mode, IP address at the UE is preserved during mobility 1150 events. This is similar to 4G/LTE mechanism and for respective 1151 slices, corresponding PPR-ID (TE Path) has to be assigned to the 1152 packet at UL and DL direction. During Xn mobility as shown above, 1153 source gNB has to additionally ensure transport path's resources from 1154 TNF are available at the target gNB apart from radio resources check 1155 (at decision and request phase of Xn/N2 mobility scenario). 1157 B.2. SSC Mode2 1159 In this case, if IP Address is changed during mobility (different UPF 1160 area), then corresponding PDU session is released. No session 1161 continuity from the network is provided and this is designed as an 1162 application offload and application manages the session continuity, 1163 if needed. For PDU Session, Service Request and Mobility cases 1164 mechanism to select the transport resource and the PPR-ID (TE Path) 1165 is similar to SSC Mode1. 1167 B.3. SSC Mode3 1169 In this mode, new IP address may be assigned because of UE moved to 1170 another UPF coverage area. Network ensures UE suffers no loss of 1171 'connectivity'. A connection through new PDU session anchor point is 1172 established before the connection is terminated for better service 1173 continuity. There are two ways in which this happens. 1175 o Change of SSC Mode 3 PDU Session Anchor with multiple PDU 1176 Sessions. 1178 o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU 1179 Session. 1181 In the first mode, from user plane perspective, the two PDU sessions 1182 are independent and the use of PPR-ID by gNB and UPFs is exactly 1183 similar to SSC Mode 1 described above. The following paragraphs 1184 describe the IPv6 multi-homed PDU session case for SSC Mode 3. 1186 +--------------+ 1187 +---+----+ |NSSMF +-----+ | +----------------+ 1188 | AMF | | | TNF | | | SMF | 1189 +---+--+-+ | +-+-+-+ | +-+-----------+--+ 1190 | | +--------+-+---+ | | 1191 N1 | | | | | 1192 | | +---+-+--+ | | 1193 | | | SDN-C | | | 1194 | | +---+-+--+ | | 1195 | | | | | | 1196 to-UE+----+ N2 +-----------+ | N4 N4| 1197 +---+ | | | | 1198 | | | | | 1199 +---+ +---++ +---+ +-------+--+ +---+ +---+ 1200 |gNB|===|CSR |---N3---|PE |-| BP UPF |-N9-|PE |-|UPF|-N6-> 1201 +---+ +----+ +---+ +-------+--+ +---+ +---+ to DN 1202 | +----+ 1203 +-| DN | 1204 N6 +----+ 1206 Figure 5: SSC Mode3 and Service Continuity 1208 In the uplink direction for the traffic offloading from the Branching 1209 Point UPF, packet has to reach to the right exit UPF. In this case 1210 packet gets re-encapsulated by the BP UPF (with either GTP-U or the 1211 chosen encapsulation) after bit rate enforcement and LI, towards the 1212 anchor UPF. At this point packet has to be on the appropriate VPN/PW 1213 to the anchor UPF. This mapping is done based on the S-NSSAI the PDU 1214 session belongs to and/or with the UDP source port (corresponds to 1215 the MTNC-ID (Section 2.5)) of the GTP-U encapsulation header to the 1216 PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR 1217 path) of the UPF. If it's a non-MPLS underlay, destination IP 1218 address of the encapsulation header would be the mapped PPR-ID (TE 1219 path). 1221 In the downlink direction for the incoming packet, UPF has to 1222 encapsulate the packet (with either GTP-U or the chosen 1223 encapsulation) to reach the BP UPF. Here mapping is done based on 1224 the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the 1225 BP UPF. If it's a non-MPLS underlay, destination IP address of the 1226 encapsulation header would be the mapped PPR-ID (TE path). In 1227 summary: 1229 o Respective PPR-ID on N3 and N9 has to be selected with correct 1230 transport characteristics from TNF. 1232 o For N2 based mobility SMF has to ensure transport resources are 1233 available for N3 Interface to new BP UPF and from there the 1234 original anchor point UPF. 1236 o For Service continuity with multi-homed PDU session same transport 1237 network characteristics of the original PDU session (both on N3 1238 and N9) need to be observed for the newly configured IPv6 1239 prefixes. 1241 Authors' Addresses 1243 Uma Chunduri (editor) 1244 Futurewei 1245 2330 Central Expressway 1246 Santa Clara, CA 95050 1247 USA 1249 Email: umac.ietf@gmail.com 1251 Richard Li 1252 Futurewei 1253 2330 Central Expressway 1254 Santa Clara, CA 95050 1255 USA 1257 Email: richard.li@futurewei.com 1258 Sridhar Bhaskaran 1259 Altiostar 1261 Email: sridharb@altiostar.com 1263 John Kaippallimalil (editor) 1264 Futurewei 1266 Email: john.kaippallimalil@futurewei.com 1268 Jeff Tantsura 1269 Apstra, Inc. 1271 Email: jefftant.ietf@gmail.com 1273 Luis M. Contreras 1274 Telefonica 1275 Sur-3 building, 3rd floor 1276 Madrid 28050 1277 Spain 1279 Email: luismiguel.contrerasmurillo@telefonica.com 1281 Praveen Muley 1282 Nokia 1283 440 North Bernardo Ave 1284 Mountain View, CA 94043 1285 USA 1287 Email: praveen.muley@nokia.com