idnits 2.17.1 draft-ietf-dmm-tn-aware-mobility-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 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 (22 September 2021) is 944 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.chunduri-dmm-5g-mobility-with-ppr' is mentioned on line 817, but not defined == Outdated reference: A later version (-24) exists of draft-ietf-dmm-srv6-mobile-uplane-16 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DMM Working Group U.C. Chunduri, Ed. 3 Internet-Draft Intel 4 Intended status: Informational J.K. Kaippallimalil, Ed. 5 Expires: 26 March 2022 Futurewei 6 S.B. Bhaskaran 7 Altiostar 8 J.T. Tantsura 9 Microsoft 10 P.M. Muley 11 Nokia 12 22 September 2021 14 Transport Network aware Mobility for 5G 15 draft-ietf-dmm-tn-aware-mobility-01 17 Abstract 19 This document specifies a framework and mapping of slices in 5G 20 mobile systems to transport network slices in IP, Layer 2 or Layer 1 21 transport networks. Slices in 5G systems are characterized by 22 latency bounds, reservation guarantees, jitter, data rates, 23 availability, mobility speed, usage density, criticality and 24 priority. These characteristics mapped to transport network slice 25 include bandwidth, latency and criteria such as isolation, 26 directionality and disjoint routes. Mobile slice criteria are mapped 27 to the appropriate transport slice and capabilities offered in 28 backhaul, midhaul and fronthaul connectivity segments between radio 29 side network functions and user plane function(gateway). 31 This document describes how mobile network functions map its slice 32 criteria to identifiers in IP and Layer 2 packets that transport 33 network segments use to grant transport layer services during UE 34 mobility scenarios. Applicability of this framework and underlying 35 transport networks, which can enable different slice properties are 36 also discussed. This is based on mapping between mobile and 37 transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4). 39 Requirements Language 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC2119 [RFC2119]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on 26 March 2022. 62 Copyright Notice 64 Copyright (c) 2021 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 69 license-info) in effect on the date of publication of this document. 70 Please review these documents carefully, as they describe your rights 71 and restrictions with respect to this document. Code Components 72 extracted from this document must include Simplified BSD License text 73 as described in Section 4.e of the Trust Legal Provisions and are 74 provided without warranty as described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4 80 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 81 1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 82 1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2. Transport and Slice aware Mobility in 5G Networks . . . . . . 7 84 2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 9 85 2.1.1. IETF Network Slicing Applicability . . . . . . . . . 10 86 2.1.2. Fronthaul Transport Network . . . . . . . . . . . . . 10 87 2.2. Mobile Transport Network Context (MTNC) and 88 Scalability . . . . . . . . . . . . . . . . . . . . . . . 11 89 2.3. Transport Network Function (TNF) . . . . . . . . . . . . 11 90 2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 12 91 2.5. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 14 92 2.6. Functionality for E2E Management . . . . . . . . . . . . 15 93 3. Transport Network Underlays . . . . . . . . . . . . . . . . . 17 94 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 17 95 3.2. Transport Network Technologies . . . . . . . . . . . . . 19 96 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 97 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 8.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 8.2. Informative References . . . . . . . . . . . . . . . . . 21 103 Appendix A. New Control Plane and User Planes . . . . . . . . . 23 104 A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 23 105 A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 24 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 108 1. Introduction 110 The 3GPP architecture for 5GS defined in [TS.23.501-3GPP], 111 [TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core) and the NG- 112 RAN architecture and procedures defined in [TS.38.300-3GPP] and 113 [TS.38.401-3GPP] include procedures for setting up network slices in 114 the 3GPP network. The 5GS (5G System) architecture also defines a 115 comprehensive set of functions for access mobility, session handling 116 and related functions for subscription management, authentication and 117 policy among others. These network functions (NF) are defined using 118 a service-based architecture (SBA) that allows NFs to expose their 119 functions via an API and common service framework. 121 IP transport is used to interconnect the data forwarding entities 122 UPFs, gNB-CU and gNB-DU in the 5GC and NG-RAN architecture but 3GPP 123 specifications only define the interfaces (N3, N9, F1U etc.) and the 124 3GPP transport end points [TS.28.541-3GPP]. The architecture allows 125 the placement of Branching Point (BP) and Uplink Classifier (ULCL) 126 UPFs closer to the access network (5G-AN). The gNB-CU and gNB-DU are 127 the centralized unit (CU) and distributed unit (DU) of a 5G radio 128 access network (NG-RAN) with gNB. The 5G-AN can be a radio access 129 network (NG-RAN) or any non-3GPP access network, for example, WLAN. 130 The IP address is anchored by a PDU session anchor UPF (PSA UPF). 131 3GPP slicing and RAN aspects are further described in Appendix A.1. 133 5GS allows more than one UPF on the path for a PDU (Protocol Data 134 Unit) session that provides various functionality including session 135 anchoring, uplink classification and branching point for a multihomed 136 IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA 137 UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9 138 and N3 interfaces between the various UPF instances and the (R)AN and 139 also, for the F1-U interface between the DU and the CU in the NG-RAN. 140 3GPP has specified control and user plane aspects in [TS.23.501-3GPP] 141 to provide slice and QoS support. 3GPP has defined three broad slice 142 types to cover enhanced mobile broadband (eMBB) communications, 143 ultra-reliable low latency communications(URLLC) and massive internet 144 of things (mIoT). ATIS [ATIS075] has defined an additional slice 145 type for V2X services. 3GPP slice types and multiple instances of a 146 slice type satisfy various characteristics for 5G network resources 147 The slice details in 3GPP, ATIS or NGMN do not specify how slice 148 characteristics for QoS, hard /soft isolation, protection and other 149 aspects should be satisfied in IP transport networks. 151 A transport underlay across each 3GPP segment may have multiple 152 technologies or providers on path and the slice in 3GPP domain should 153 have a corresponding mapping in the transport domain. This document 154 proposes to map a slice in the 3GPP domain to a transport domain 155 slice. This document also proposes to carry this provisioned mapping 156 in an IP packet so that the IP transport domain can classify and 157 provide the required service. This is explored further in this 158 document. 160 1.1. IETF Network Slicing Terminology 162 [I-D.ietf-teas-ietf-network-slices] draft defines the 'IETF Network 163 slice', its scope and characteristics. It lists use cases where IETF 164 technologies can be used for slicing solutions, for various 165 connectivity segments. Transport slice terminology as used in this 166 document refers to the connectivity segment between various 5G 167 systems (i.e. 5G-AN which includes NG-RAN, ULCL UPF, BP UPF and PSA 168 UPF) and some of these segments are referred to as IETF Network 169 slices. 171 [I-D.ietf-teas-ietf-network-slices] also defines a generic framework 172 and how abstract requests to set up slices can be mapped to more 173 specific technologies (e.g., VPN and traffic-engineering 174 technologies). This document is aimed to be specific to 3GPP use 175 case where many such connectivity segments are used in E2E slicing 176 solutions. Some of the terminologies defined in these referred 177 drafts and applicability to this document are further described in 178 Section 2.1.1. 180 1.2. Problem Statement 182 5GS defines network slicing as one of the core capabilities of 5GC 183 with slice awareness from Radio and 5G Core (5GC) network. The 5G 184 System (5GS) as defined in 3GPP specifications, does not consider the 185 resources and functionalities needed from the transport network for 186 the selection of UPF. This is seen as independent functionality and 187 is currently not part of 5GS. 189 However, the lack of underlying Transport Network (TN) awareness may 190 lead to selection of sub-optimal UPF(s) and/or 5G-AN during various 191 procedures in 5GS (e.g., session establishment and various mobility 192 scenarios). Meeting the specific slice characteristics on the F1-U, 193 N3 and N9 interfaces depends on the IP transport underlay providing 194 these resources and capabilities. This could also lead to the 195 inability in meeting SLAs for real-time, mission-critical or latency 196 sensitive services. 198 The 5GS provides slices to its clients (UEs). The UE's PDU session 199 spans the access network (radio access network including the F1-U) 200 and N3 and N9 transport segments which have an IP transport underlay. 201 The 5G operator needs to obtain slice capability from the IP 202 transport provider. Several UE sessions that match a slice may be 203 mapped to an IP transport segment. Thus, there needs to be a mapping 204 between the slice capability offered to the UE (S-NSSAI) and what is 205 provided by the IP transport. 207 1.3. Solution Approach 209 This document specifies an approach to fulfil the needs of 5GS to 210 transport user plane traffic from 5G-AN (including NG-RAN) to UPF in 211 an optimized fashion. This is done by keeping establishment and 212 mobility procedures aware of the underlying transport network along 213 with slicing requirements. 215 Section 2 describes in detail on how TN aware mobility can be built 216 irrespective of underlying TN technology used. How other IETF TE 217 technologies applicable for this draft is specified in Section 3.2. 219 1.4. Acronyms 221 5QI - 5G QoS Indicator 223 5G-AN - 5G Access Network 225 AMF - Access and Mobility Management Function (5G) 227 BP - Branch Point (5G) 229 CSR - Cell Site Router 231 CP - Control Plane (5G) 233 CU - Centralized Unit (5G, gNB) 235 DN - Data Network (5G) 237 DU - Distributed Unit (5G, gNB) 239 eMBB - enhanced Mobile Broadband (5G) 241 FRR - Fast ReRoute 242 gNB - 5G NodeB 244 GBR - Guaranteed Bit Rate (5G) 246 GTP-U - GPRS Tunneling Protocol - User plane (3GPP) 248 IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) 250 LFA - Loop Free Alternatives (IP FRR) 252 mIOT - Massive IOT (5G) 254 MPLS - Multi Protocol Label Switching 256 NG-RAN - Next Generation Radio Access Network (i.e., gNB, NG-eNB - 257 RAN functions which connect to 5GC) 259 NSSMF - Network Slice Selection Management Function 261 QFI - QoS Flow ID (5G) 263 PPR - Preferred Path Routing 265 PDU - Protocol Data Unit (5G) 267 PW - Pseudo Wire 269 RAN - Radio Access Network (i.e 3GPP radio access network used 270 synonymously with NG-RAN in this document) 272 RAN - Radio Access Network 274 RQI - Reflective QoS Indicator (5G) 276 SBI - Service Based Interface (5G) 278 SID - Segment Identifier 280 SMF - Session Management Function (5G) 282 SSC - Session and Service Continuity (5G) 284 SST - Slice and Service Types (5G) 286 SR - Segment Routing 288 TE - Traffic Engineering 289 ULCL - Uplink Classifier (5G) 291 UP - User Plane(5G) 293 UPF - User Plane Function (5G) 295 URLLC - Ultra reliable and low latency communications (5G) 297 2. Transport and Slice aware Mobility in 5G Networks 299 3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing 300 in 5GS and is provided here for information. The application of 5GS 301 slices in transport network for backhaul, mid-haul and front haul are 302 not explicitly covered in 3GPP and is the topic here. To support 303 specific characteristics in backhaul (N3, N9), mid-haul (F1) and 304 front haul, it is necessary to map and provision corresponding 305 resources in the transport domain. This section describes how to 306 provision the mapping information in the transport network and apply 307 it so that user plane packets can be provided the transport resources 308 (QoS, isolation, protection, etc.) expected by the 5GS slices. 310 The figure shows the entities on path for 3GPP Network Functions 311 (gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an 312 IP/L2 transport network. 314 5G Control and Management Planes 315 +------------------------------------------------------------------------+ 316 | +--------------------------------------------------------------------+ | 317 | | (TNF) 5G Management Plane (TNF) | | 318 | +----+-----------------+-------------+---------------+-----------+---+ | 319 | | | | | | | 320 | +----+-----+ | F1-C +----+-----+ | N2 +----+---+ | 321 | | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | | 322 | | | | +----+-----+ | +----+---+ | 323 +-| |-----------|-------------|---------------|-----------|-----+ 324 | | | | | | 325 | | | | | | 326 | | | ACTN | | ACTN | 327 | | +---+---+ | +---+---+ | 328 | | | | | | | | 329 | gNB-DU | | SDN-C | E1 | SDN-C | | 330 | | | | | | | | 331 | | +---+---+ | +---+---+ | 332 | | | | | | 333 | | | | | | 334 | | __ +__ | ___+__ | 335 | | __/ \__ +--+---+ __/ \__ +-+-+ 336 | | / IP \ | gNB | / IP \ | | 337 UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN 338 +----------+ \__ __/ +------+ \__ __/ +---+ 339 \______/ \______/ 341 |------ F1-U -------| |------ N3 OR N9 ------| 343 * Radio and Fronthaul 345 Figure 1: Backhaul and Mid-haul Transport Network for 5G 347 2.1. Backhaul and Mid-Haul Transport Network 349 Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge) 350 routers providing IP transport service to 5GS user plane entities 5G- 351 AN (e.g. gNB) and UPF. 5GS architecture with high level management, 352 control and user plane entities and its interaction with the IP 353 transport plane is shown here. The slice capability required in IP 354 transport networks are estimated and provisioned by the functionality 355 as specified in Section 2.3 (TNF) with support from various other 356 control plane functions such as the Network Data Analytics Function 357 (NWDAF), Network Function Repository Function (NRF) and Policy 358 Control Function (PCF). The TNF is only a logical function that may 359 be realized in a 3GPP management function such as Network Slice 360 Selection Management Function (NSSMF) defined in [TS.28.533-3GPP]. 361 The TNF requests the SDN-C to provision the IP XHaul network using 362 ACTN [RFC8453]. 364 The 5G management plane in Figure 1 interacts with the 5G control 365 plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and 366 gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS) 367 signaling from the UE for session management, mobility is handled by 368 the 5GC. When a UE initiates session establishment, it indicates the 369 desired slice type in the S-NSSAI (Specific Network Slice Selection 370 Assistance Information) field. The AMF uses the S-NSSAI, other 371 subscription information and configuration in the NSSF to select the 372 appropriate SMF and the SMF in turn selects UPFs (User Plane 373 Functions) that are able to provide the specified slice resources and 374 capabilities. 376 The AMF, SMF, NSSF, PCF, NRF, NWDAF and other control functions in 377 5GC are described in [TS.23.501-3GPP]. Some of the slice 378 capabilities along the user plane path between the (R)AN and UPFs 379 (F1-U, N3, N9 segments) such as a low latency path, jitter, 380 protection and priority needs these to be provided by the IP 381 transport network. 383 The 5G user plane from UE to DN (Data Network) includes a mid-haul 384 segment (F1-U between gNB DU(UP), gNB CU(UP)) and backhaul (N3 385 between gNB - UPF; N9 between UPFs). If the RAN uses lower layer 386 split architecture as specified by O-RAN alliance, then the user 387 plane path from UE to DN also includes the fronthaul interface. The 388 fronthaul interface carries the radio frames in the form of In-phase 389 (I) and Quadrature (Q) samples using eCPRI encapsulation over 390 Ethernet or UDP over IP. 392 The N3, N9 and F1-U user planes use GTP-U [TS.29.281-3GPP] to 393 transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). 394 For the front-haul described further in Section 2.1.2, an Ethernet 395 transport with VLANs can be expected to be the case in many 396 deployments. 398 Figure 1 also depicts the PE router, where transport paths are 399 initiated/terminated can be deployed separately with UPF or both 400 functionalities can be in the same node. The TNF provisions this in 401 the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP-U 402 encapsulated user packet from the (R)AN (gNB) or UPF with the slice 403 information traverses the F1-U/N3/N9 segment, the PE router of the IP 404 transport underlay can inspect the slice information and provide the 405 provisioned capabilities. This is elaborated further in Section 2.4. 407 2.1.1. IETF Network Slicing Applicability 409 Some of the functional elements depicted in the Figure 1 can be 410 mapped to the terminology set forth in the 411 [I-D.ietf-teas-ietf-network-slices]. From 3GPP perspective, UE and 412 UPF are the network slice endpoints and routers, gNB-DU, gNB-CU, 413 switches, PE nodes are the slice realization endpoints. The TNF 414 represented in the Figure 1 can be seen as IETF Network Slice 415 Controller (NSC) functionality and SDN-C maps to Network Controller 416 (NC). NSC-NBI interface is the interface from 3GPP Management plane 417 (e.g., NSSMF) and NSC-SBI interface is the interface between TNF and 418 SDN-C. Various possibilities for implementation of these interfaces 419 and the relation to ACTN are also further described in the 420 [I-D.ietf-teas-ietf-network-slices]. 422 2.1.2. Fronthaul Transport Network 424 The O-RAN Alliance has specified the fronthaul interface between the 425 O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer 426 information, in the form of In-phase (I) and Quadrature (Q) samples 427 are transported using Enhanced Common Public Radio Interface (eCPRI) 428 framing over Ethernet or UDP. On the Ethernet based fronthaul 429 interface, the slice information can be carried in the Ethernet 430 header through the VLAN tags. The Ethernet switches in the fronthaul 431 transport network can inspect the slice information (VLAN tag) in the 432 Ethernet header and provide the provisioned capabilities. The 433 mapping of I and Q samples of different radio resources (radio 434 resource blocks or carriers etc.,.) to different slices and to their 435 respective VLAN tags on the fronthaul interface is controlled by the 436 O-RAN fronthaul C-Plane and M-Plane interfaces. On a UDP based 437 fronthaul interface, the slice information can be carried in the IP 438 or UDP header. The PE routers of the fronthaul transport network can 439 inspect the slice information in the IP or UDP header and provide the 440 provisioned capabilities. The fronthaul transport network is latency 441 and jitter sensitive. The provisioned slice capabilities in the 442 fronthaul transport network MUST take care of the latency and jitter 443 budgets of the specific slice for the fronthaul interface. The 444 provisioning of the fronthaul transport network is handled by the 445 SDN-C pertaining to the fronthaul transport. 447 2.2. Mobile Transport Network Context (MTNC) and Scalability 449 The MTNC represents a slice of a transport path for a tenant between 450 two 3GPP user plane functions. The Mobile-Transport Network Context 451 Identifier (MTNC-ID) is generated by the TNF to be unique for each 452 instance (for a tenant) and per traffic class (including QoS and 453 slice aspects). Thus, there may be more than one MTNC-ID for the 454 same QoS and instance if there is a need to provide isolation (slice) 455 of the traffic. It should be noted that MTNC are per class/instance 456 and not per user session. The MTNC-IDs are configured by the TNF to 457 be unique within a provisioning domain. 459 Since the MTNC-IDs are generated per instance / tenant, there is no 460 need for unique MTNC-IDs per flow/session. In addition, since the 461 traffic estimation is performed prior to UE's session establishment, 462 there is no provisioning delay experienced by the UE during its 463 session setup. For an instance/tenant, the MTNC-ID space scales 464 roughly as a square of the number sites between which 3GPP user plane 465 functions have paths. If there are T traffic classes across N sites, 466 the number of MTNC-IDs in a fully meshed network is (N*(N-1)/2) * T. 467 For example, if there are 3 traffic classes between 25 sites, there 468 would be at most 900 MTNC-IDs required. Multiple instances/tenants 469 that need to be fully isolated, will add to the MTNC provisioning. 470 An MTNC-ID space of 16 bits (65K identifiers) can be expected to be 471 sufficient. 473 2.3. Transport Network Function (TNF) 475 Figure 1 shows a view of the functions and interfaces for 476 provisioning the MTNC-IDs. The focus is on provisioning between the 477 3GPP management plane (NSSMF), transport network (SDN-C) and carrying 478 the MTNC-IDs in PDU packets for the transport network to grant the 479 provisioned resources. 481 In Figure 1, the TNF (logical functionality within the NSSMF) 482 requests the SDN-C in the transport domain to program the TE path 483 using ACTN [RFC8453]. The SDN-C programs the Provider Edge (PE) 484 routers and internal routers according to the underlay transport 485 technology (e.g., MPLS, SR, PPR). The PE router inspects incoming 486 PDU data packets for the UDP SRC port which mirrors the MTNC-ID, 487 classifies and provides the VN service provisioned across the 488 transport network. 490 The detailed mechanisms by which the NSSMF provides the MTNC-IDs to 491 the control plane and user plane functions are for 3GPP to specify. 492 Two possible options are outlined below for completeness. The NSSMF 493 may provide the MTNC-IDs to the 3GPP control plane by either 494 providing it to the Session Management Function (SMF), and the SMF in 495 turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU 496 session setup. Alternatively, the user plane functions may request 497 the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case 498 where user plane entities request the TNF/NSSMF to translate the 499 Request and get the MTNC-ID. Another alternative is for the TNF to 500 provide a mapping of the 3GPP Network Instance Identifier, described 501 in Section 2.6 and the MTNC-ID to the user plane entities via 502 configuration. 504 The TNF should be seen as a logical entity that can be part of NSSMF 505 in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use 506 network configuration, policies, history, heuristics or some 507 combination of these to derive traffic estimates that the TNF would 508 use. How these estimates are derived are not in the scope of this 509 document. The focus here is only in terms of how the TNF and SDN-C 510 are programmed given that slice and QoS characteristics across a 511 transport path can be represented by an MTNC-ID. The TNF requests 512 the SDN-C in the transport network to provision paths in the 513 transport domain based on the MTNC-ID. The TNF is capable of 514 providing the MTNC-ID provisioned to control and user plane functions 515 in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID 516 should be part of the 3GPP specifications. 518 2.4. Transport Provisioning 520 Functionality of transport provisioning for an engineered IP 521 transport that supports 3GPP slicing and QoS requirements in 522 [TS.23.501-3GPP] is described in this section. 524 During a PDU session setup, the AMF using input from the NSSF selects 525 a network slice and SMF. The SMF with user policy from Policy 526 Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the 527 path of the PDU session. While QoS and slice selection for the PDU 528 session can be applied across the 3GPP control and user plane 529 functions as outlined in Section 2, the IP transport underlay across 530 F1-U, N3 and N9 segments do not have enough information to apply the 531 resource constraints represented by the slicing and QoS 532 classification. Current guidelines for interconnection with 533 transport networks [IR.34-GSMA] provide an application mapping into 534 DSCP. However, these recommendations do not take into consideration 535 other aspects in slicing like isolation, protection and replication. 537 IP transport networks have their own slice and QoS configuration 538 based on domain policies and the underlying network capability. 539 Transport networks can enter into an agreement for virtual network 540 services (VNS) with client domains using the ACTN [RFC8453] 541 framework. An IP transport network may provide such slice instances 542 to mobile network operators, CDN providers or enterprises for 543 example. The 3GPP mobile network, on the other hand, defines a slice 544 instance for UEs as are the mobile operator's 'clients'. The Network 545 Slice Selection Management Function (NSSMF) [TS 28.533] that 546 interacts with a TN controller like an SDN-C (that is out of scope of 547 3GPP). 549 The ACTN VN service can be used across the IP transport networks to 550 provision and map the slice instance and QoS of the 3GPP domain to 551 the IP transport domain. An abstraction that represents QoS and 552 slice instances in the mobile domain and mapped to ACTN VN service in 553 the transport domain is represented here as MTNC-IDs. Details of how 554 the MTNC-IDs are derived are up to functions that can estimate the 555 level of traffic demand. 557 The 3GPP network/5GS provides slices instances to its clients (UE) 558 that include resources for radio and mobile core segments. The UE's 559 PDU session spans the access network (radio) and F1-U/N3/N9 transport 560 segments which have an IP transport underlay. The 5G operator needs 561 to obtain slice capability from the IP transport provider since these 562 resources are not seen by the 5GS. Several UE sessions that match a 563 slice may be mapped to an IP transport segment. Thus, there needs to 564 be a mapping between the slice capability offered to the UE (NSSAI) 565 and what is provided by the IP transport. 567 When the 3GPP user plane function (5G-AN, UPF) does not terminate the 568 transport underlay protocol (e.g., MPLS), it needs to be carried in 569 the IP protocol header from end-to-end of the mobile transport 570 connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses 571 these scenarios in detail. 573 2.5. MTNC-ID in the Data Packet 575 When the 3GPP user plane function (5G-AN, UPF) and transport provider 576 edge is on different nodes, the PE router needs to have the means by 577 which to classify the PDU packet. The mapping information is 578 provisioned between the 5G provider and IP transport network and 579 corresponding information should be carried in each IP packet on the 580 F1-U, N3, N9 interface. To allow the IP transport edge nodes to 581 inspect the transport context information efficiently, it should be 582 carried in an IP header field that is easy to inspect. It may be 583 noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces. 584 If the fronthaul, midhaul or backhaul IP path is bounded by an L2 585 network, one option maybe to use VLANs to carry the MTNC-ID. 3GPP 586 specifications for management plane defines transport end-points 587 configuration in [TS.28.541-3GPP]. However, Layer 2 alternatives 588 such as VLAN will fail in L3/routed networks on the F1-U, N3 or N9 589 path. GTP-U (F1-U, N3, N9 encapsulation header) field extensions 590 offer a possibility, however these extensions are not always easy for 591 a transport edge router to parse efficiently on a per packet basis. 592 Other IP header fields like DSCP are not suitable as it only conveys 593 the QoS aspects (but not other aspects like isolation, protection, 594 etc.) 596 While IPv6 extension headers like SRv6 may be an option to carry the 597 MTNC-ID that requires the end-to-end network to be IPv6 as well as 598 the capability to lookup the extension header at line rate. To 599 minimise the protocol changes and make this underlay transport 600 independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping 601 of MTNC-ID to a UDP port range of the GTP encapsulated user packet. 602 A simple mapping table between the MTNC-ID and the source UDP port 603 number can be configured to ensure that ECMP /load balancing is not 604 affected adversely by encoding the UDP source port with an MTNC-ID 605 mapping. The UDP port information containing MTNC-ID is a simple 606 extension that can be provisioned in 3GPP transport end-points 607 defined in [TS.28.541-3GPP]. This mapping is configured in 3GPP user 608 plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that 609 process MTNC-IDs. 611 PE routers can thus provision a policy based on the source UDP port 612 number (which reflects the mapped MTNC-ID) to the underlying 613 transport path and then deliver the QoS/slice resource provisioned in 614 the transport network. The source UDP port that is encoded is the 615 outer IP (corresponding to GTP-U header) while the inner IP packet 616 (UE payload) is unaltered. The source UDP port is encoded by the 617 node that creates the GTP-U encapsulation and therefore, this 618 mechanism has no impact on UDP checksum calculations. 620 3GPP network operators may use IPSec gateways (SEG) to secure packets 621 between two sites - for example over an F1-U, N3 or N9 segment. The 622 MTNC identifier in the GTP-U packet should be in the outer IP source 623 port even after IPSec encryption for PE transport routers to inspect 624 and provide the level of service provisioned. Tunnel mode - which is 625 the case for SEG/IPSec gateways - adds an outer IP header in both AH 626 (Authenticated Header) and ESP (Encapsulated Security Payload) modes. 627 The GTP-U / UDP source port with encoded MTNC identifier should be 628 copied to the IPSec tunnel ESP header. One option is to use 16 bits 629 from the SPI field of the ESP header to encode the MTNC identifier 630 and use the remaining 16 bits in SPI field to identify an SA. Load 631 balancing entropy for ECMP will not be affected as the MTNC encoding 632 mechanism already accounts for this. 634 If the RAN uses O-RAN Alliance lower layer split architecture, then a 635 fronthaul network is involved. On an Ethernet based fronthaul 636 transport network, VLAN tag may be an option to carry the MTNC-ID. 637 The VLAN ID provides a 12 bit space and is sufficient to support up 638 to 4096 slices on the fronthaul transport network. The mapping of 639 fronthaul traffic to corresponding network slices is based on the 640 radio resource for which the fronthaul carries the I and Q samples. 641 The mapping of fronthaul traffic to the VLAN tag corresponding to the 642 network slice is specified in Section 2.1.2. On the UDP based 643 fronthaul transport network, the UDP source port can be used to carry 644 the MTNC-ID. 646 2.6. Functionality for E2E Management 648 With the TNF functionality in 5GS Service Based Interface, the 649 following additional functionalities are required for end-2-end slice 650 management including the transport network: 652 * The Specific Network Slice Selection Assistance Information 653 (S-NSSAI) of PDU session SHOULD be mapped to the assigned 654 transport VPN and the TE path information for that slice. 656 * For transport slice assignment for various SSTs (eMBB, URLLC, 657 MIoT) corresponding underlay paths need to be created and 658 monitored from each transport endpoint (CSR and PE@UPF). 660 * During PDU session creation, apart from radio and 5GC resources, 661 transport network resources needed to be verified matching the 662 characteristics of the PDU session traffic type. 664 * The TNF MUST provide an API that takes as input the source and 665 destination 3GPP user plane element address, required bandwidth, 666 latency and jitter characteristics between those user plane 667 elements and returns as output a particular TE path's identifier, 668 that satisfies the requested requirements. 670 * Mapping of PDU session parameters to underlay SST paths need to be 671 done. One way to do this is to let the SMF install a Forwarding 672 Action Rule (FAR) in the UPF via N4 with the FAR pointing to a 673 "Network Instance" in the UPF. A "Network Instance" is a logical 674 identifier for an underlying network. The "Network Instance" 675 pointed by the FAR can be mapped to a transport path (through L2/ 676 L3 VPN). FARs are associated with Packet Detection Rule (PDR). 677 PDRs are used to classify packets in the uplink (UL) and the 678 downlink (DL) direction. For UL procedures specified in 679 Section 2.4, Section 2.5 can be used for classifying a packet 680 belonging to a particular slice characteristic. For DL, at a PSA 681 UPF, the UE IP address is used to identify the PDU session, and 682 hence the slice a packet belongs to and the IP 5 tuple can be used 683 for identifying the flow and QoS characteristics to be applied on 684 the packet at UPF. If a PE is not co-located at the UPF then 685 mapping to the underlying TE paths at PE happens based on the 686 encapsulated GTP-U packet as specified in Section 2.5. 688 * In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if 689 segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point- 690 UPF) is needed, then corresponding path characteristics MUST be 691 used. This includes a path from CSR to PE@UL-CL/BP UPF 692 [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN. 694 * Continuous monitoring of the underlying transport path 695 characteristics should be enabled at the endpoints (technologies 696 for monitoring depends on traffic engineering technique used as 697 described in Section 3.2). If path characteristics are degraded, 698 reassignment of the paths at the endpoints should be performed. 699 For all the affected PDU sessions, degraded transport paths need 700 to be updated dynamically with similar alternate paths. 702 * During UE mobility events similar to 4G/LTE i.e., gNB mobility (F1 703 based, Xn based or N2 based), for target gNB selection, apart from 704 radio resources, transport resources MUST be factored. This 705 enables handling of all PDU sessions from the UE to target gNB and 706 this require co-ordination of gNB, AMF, SMF with the TNF module. 708 Integrating the TNF as part of the 5GS Service Based Interfaces, 709 provides the flexibility to control the allocation of required 710 characteristics from the TN during a 5GS signaling procedure (e.g. 711 PDU Session Establishment). If TNF is seen as separate and in a 712 management plane, this real time flexibility is lost. Changes to 713 detailed signaling to integrate the above for various 5GS procedures 714 as defined in [TS.23.502-3GPP] is beyond the scope of this document. 716 3. Transport Network Underlays 718 Apart from the various flavors of IETF VPN technologies to share the 719 transport network resources and capacity, TE capabilities in the 720 underlay network is an essential component to realize the 5G TN 721 requirements. This section focuses on various transport underlay 722 technologies (not exhaustive) and their applicability to realize 723 Midhaul/Backhaul transport networks. Focus is on the user/data plane 724 i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1. 726 3.1. Applicability 728 * For 3 different SSTs, 3 transport TE paths can be signaled from 729 any node in the transport network. For Uplink traffic, the 5G-AN 730 will choose the right underlying TE path of the UPF based on the 731 S-NSSAI the PDU Session belongs to and/or the UDP Source port 732 (corresponds to the MTNC-ID Section 2.4) of the GTP-U 733 encapsulation header. Similarly in the Downlink direction 734 matching Transport TE Path of the 5G-AN is chosen based on the 735 S-NSSAI the PDU Session belongs to. The table below shows a 736 typical mapping: 738 +----------------+------------+------------------+-----------------+ 739 |GTP/UDP SRC PORT| SST | Transport Path | Transport Path | 740 | | in S-NSSAI | Info | Characteristics | 741 +----------------+------------+------------------+-----------------+ 742 | Range Xx - Xy | | | | 743 | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | 744 | values) | (massive | TE-PATH-A | Bit Rate) | 745 | | IOT) | | Bandwidth: Bx | 746 | | | | Delay: Dx | 747 | | | | Jitter: Jx | 748 +----------------+------------+------------------+-----------------+ 749 | Range Yx - Yy | | | | 750 | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | 751 | values) | (ultra-low | TE-PATH-B | Req. | 752 | | latency) | | Bandwidth: By | 753 | | | | Delay: Dy | 754 | | | | Jitter: Jy | 755 +----------------+------------+------------------+-----------------+ 756 | Range Zx - Zy | | | | 757 | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | 758 | values) | (broadband)| TE-PATH-C | Bandwidth: Bx | 759 +----------------+------------+------------------+-----------------+ 761 Figure 2: Mapping of Transport Paths on F1-U/N3/N9 763 * It is possible to have a single TE Path for multiple input points 764 through a MP2P TE tree structure separate in UL and DL direction. 766 * Same set of TE Paths are created uniformly across all needed 5G- 767 ANs and UPFs to allow various mobility scenarios. 769 * Any modification of TE parameters of the path, replacement path 770 and deleted path needed to be updated from TNF to the relevant 771 ingress points. Same information can be pushed to the NSSF, and/ 772 or SMF as needed. 774 * TE Paths support for native L2, IPv4 and IPv6 data/user planes 775 with optional TE features are desirable in some network segments. 776 As this is an underlay mechanism it can work with any overlay 777 encapsulation approach including GTP-U as defined currently for 778 F1-U/N3/N9 interface. 780 In some E2E scenarios, security is desired granularly in the 781 underlying transport network. In such cases, there would be a need 782 to have separate sub-ranges under each SST to provide the TE path in 783 preserving the security characteristics. The UDP Source Port range 784 captured in Figure 2 would be sub-divided to maintain the TE path for 785 the current SSTs with the security. The current solution doesn't 786 provide any mandate on the UE traffic in selecting the type of 787 security. 789 3.2. Transport Network Technologies 791 While there are many Software Defined Networking (SDN) approaches 792 available, this section is not intended to list all the possibilities 793 in this space but merely captures the technologies for various 794 requirements discussed in this document. 796 RSVP-TE [RFC3209] provides a lean transport overhead for the TE path 797 for MPLS user plane. However, it is perceived as less dynamic in 798 some cases and has some provisioning overhead across all the nodes in 799 N3 and N9 interface nodes. Also, it has another drawback with 800 excessive state refresh overhead across adjacent nodes and this can 801 be mitigated with [RFC8370]. 803 SR-TE [RFC8402] does not explicitly signal bandwidth reservation or 804 mechanism to guarantee latency on the nodes/links on SR path. But SR 805 allows path steering for any flow at the ingress and particular path 806 for a flow can be chosen. Some of the issues and suitability for 807 mobile use plane are documented at Section 5.3 of 808 [I-D.bogineni-dmm-optimized-mobile-user-plane]. However, 809 [I-D.ietf-dmm-srv6-mobile-uplane] presents various options for 810 optimized mobile user plane with SRv6 with or without GTP-U overhead 811 along with traffic engineering capabilities. SR-MPLS allows 812 reduction of the control protocols to one IGP (without needing for 813 LDP and RSVP-TE). 815 Preferred Path Routing (PPR) is an integrated routing and TE 816 technology and the applicability for this framework is described in 817 [I-D.chunduri-dmm-5g-mobility-with-ppr]. PPR does not remove GTP-U, 818 unlike some other proposals laid out in 819 [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works 820 with the existing cellular user plane (GTP-U) for F1-U/N3 and N9. In 821 this scenario, PPR will only help provide TE benefits needed for 5G 822 slices from a transport domain perspective. It does so for any 823 underlying user/data plane used in the transport network 824 (L2/IPv4/IPv6/MPLS). 826 As specified with the integrated transport network function (TNF), a 827 particular RSVP-TE path for MPLS or SR path for MPLS and IPv6 with 828 SRH user plane or PPR with PPR-ID [I-D.chunduri-dmm-5g-mobility-with- 829 ppr], can be supplied to SMF for mapping a particular PDU session to 830 the transport path. 832 4. Acknowledgements 834 Thanks to Young Lee for discussions on this document including ACTN 835 applicability for the proposed TNF. Thanks to Sri Gundavelli, Kausik 836 Majumdar and 3GPP delegates who provided detailed feedback on this 837 document. 839 5. IANA Considerations 841 This document has no requests for any IANA code point allocations. 843 6. Security Considerations 845 This document does not introduce any new security issues. 847 7. Contributing Authors 849 The following people contributed substantially to the content of this 850 document and should be considered co-authors. 852 Richard Li 853 Futurewei 854 2330 Central Expressway 855 Santa Clara 856 CA 95050 857 USA 858 Email: richard.li@futurewei.com 860 Luis M. Contreras 861 Telefonica 862 Sur-3 building, 3rd floor 863 Madrid 28050 864 Spain 865 Email: luismiguel.contrerasmurillo@telefonica.com 867 Xavier De Foy 868 InterDigital Communications, LLC 869 1000 Sherbrooke West 870 Montreal 871 Canada 873 Email: Xavier.Defoy@InterDigital.com 875 8. References 877 8.1. Normative References 879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 880 Requirement Levels", BCP 14, RFC 2119, 881 DOI 10.17487/RFC2119, March 1997, 882 . 884 8.2. Informative References 886 [ATIS075] Alliance for Telecommunications Industry Solutions (ATIS), 887 "IOT Categorization: Exploring the Need for Standardizing 888 Additional Network Slices ATIS-I-0000075", September 2019. 890 [I-D.bogineni-dmm-optimized-mobile-user-plane] 891 Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., 892 Rodriguez-Natal, A., Carofiglio, G., Auge, J., 893 Muscariello, L., Camarillo, P., and S. Homma, "Optimized 894 Mobile User Plane Solutions for 5G", Work in Progress, 895 Internet-Draft, draft-bogineni-dmm-optimized-mobile-user- 896 plane-01, 29 June 2018, . 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", Work in Progress, Internet-Draft, draft-ietf-dmm- 903 5g-uplane-analysis-04, 2 November 2020, 904 . 907 [I-D.ietf-dmm-srv6-mobile-uplane] 908 Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C., 909 Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for 910 Mobile User Plane", Work in Progress, Internet-Draft, 911 draft-ietf-dmm-srv6-mobile-uplane-16, 11 August 2021, 912 . 915 [I-D.ietf-teas-ietf-network-slices] 916 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 917 Makhijani, K., Contreras, L. M., and J. Tantsura, 918 "Framework for IETF Network Slices", Work in Progress, 919 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 920 August 2021, . 923 [IR.34-GSMA] 924 GSM Association (GSMA), "Guidelines for IPX Provider 925 Networks (Previously Inter-Service Provider IP Backbone 926 Guidelines, Version 14.0", August 2018. 928 [ORAN-WG4.CUS-O-RAN] 929 O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group; 930 Control, User and Synchronization Plane Specification; 931 v2.0.0", August 2019. 933 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 934 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 935 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 936 . 938 [RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and 939 T. Saad, "Techniques to Improve the Scalability of RSVP-TE 940 Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018, 941 . 943 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 944 Decraene, B., Litkowski, S., and R. Shakir, "Segment 945 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 946 July 2018, . 948 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 949 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 950 DOI 10.17487/RFC8453, August 2018, 951 . 953 [TS.23.501-3GPP] 954 3rd Generation Partnership Project (3GPP), "System 955 Architecture for 5G System; Stage 2, 3GPP TS 23.501 956 v2.0.1", December 2017. 958 [TS.23.502-3GPP] 959 3rd Generation Partnership Project (3GPP), "Procedures for 960 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 961 2017. 963 [TS.23.503-3GPP] 964 3rd Generation Partnership Project (3GPP), "Policy and 965 Charging Control System for 5G Framework; Stage 2, 3GPP TS 966 23.503 v1.0.0", December 2017. 968 [TS.28.533-3GPP] 969 3rd Generation Partnership Project (3GPP), "Management and 970 Orchestration Architecture Framework (Release 15)", June 971 2018. 973 [TS.28.541-3GPP] 974 3rd Generation Partnership Project (3GPP), "Management and 975 orchestration; 5G Network Resource Model (NRM); Stage 2 976 and stage 3 (Release 17)", June 2020. 978 [TS.29.281-3GPP] 979 3rd Generation Partnership Project (3GPP), "GPRS Tunneling 980 Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", 981 December 2018. 983 [TS.38.300-3GPP] 984 3rd Generation Partnership Project (3GPP), "NR; NR and NG- 985 RAN Overall Description; Stage 2; v15.7.0", September 986 2019. 988 [TS.38.401-3GPP] 989 3rd Generation Partnership Project (3GPP), "NG-RAN; 990 Architecture description; v15.7.0", September 2019. 992 Appendix A. New Control Plane and User Planes 994 A.1. Slicing Framework and RAN Aspects 996 The 3GPP architecture defines slicing aspects where the Network Slice 997 Selection Function (NSSF) assists the Access Mobility Manager (AMF) 998 and Session Management Function (SMF) to assist and select the right 999 entities and resources corresponding to the slice requested by the 1000 User Equipment (UE). The User Equipment (UE) indicates information 1001 regarding the set of slices it wishes to connect, in the Network 1002 Slice Selection Assistance Information (NSSAI) field during network 1003 registration procedure (Attach) and the specific slice the UE wants 1004 to establish an IP session, in the Specific NSSAI (S-NSSAI) field 1005 during the session establishment procedure (PDU Session 1006 Establishment). The AMF selects the right SMF and the SMF in turn 1007 selects the User Plane Functions (UPF) so that the QoS and 1008 capabilities requested can be fulfilled. 1010 The architecture for the Radio Access Network (RAN) is defined in 1011 [TS.38.300-3GPP] and [TS.38.401-3GPP]. The 5G RAN architecture 1012 allows disaggregation of the RAN into a Distributed Unit (DU) and a 1013 Centralized Unit (CU). The CU is further split into control plane 1014 (CU-CP) and user plane (CU-UP). The interface between CU-UP and the 1015 DU for the user plane traffic is called the F1-U and between the CU- 1016 CP and DU for the control plane traffic is called the F1-C. The F1-C 1017 and the F1-U together are called the mid-haul interfaces. The DU 1018 does not have a CP/UP split. Apart from 3GPP, O-RAN Alliance has 1019 specified further disaggregation of the RAN at the lower layer 1020 (physical layer). The DU is disaggregated into a ORAN DU (O-DU) 1021 which runs the upper part of the physical layer, MAC and RLC and the 1022 ORAN Radio Unit (O-RU) which runs the lower part of the physical 1023 layer. The interface between the O-DU and the O-RU is called the 1024 Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN]. 1026 A.2. Slice aware Mobility: Discrete Approach 1028 In this approach transport network functionality from the 5G-AN to 1029 UPF is discrete and 5GS is not aware of the underlying transport 1030 network and the resources available. Deployment specific mapping 1031 function is used to map the GTP-U encapsulated traffic at the 5G-AN 1032 (e.g. gNB) in UL and UPF in DL direction to the appropriate transport 1033 slice or transport Traffic Engineered (TE) paths. These TE paths can 1034 be established using RSVP-TE [RFC3209] for MPLS underlay, SR 1035 [RFC3209] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-dmm- 1036 5g-mobility-with-ppr] with MPLS, IPv6 with SRH, native IPv6 and 1037 native IPv4 underlays. 1039 As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 1040 user plane traffic forwarding rules in the UPF. The UPFs have a 1041 concept of a "Network Instance" which logically abstracts the 1042 underlying transport path. When the SMF creates the packet detection 1043 rules (PDR) and forwarding action rules (FAR) for a PDU session at 1044 the UPF, the SMF identifies the network instance through which the 1045 packet matching the PDR has to be forwarded. A network instance can 1046 be mapped to a TE path at the UPF. In this approach, TNF as shown in 1047 Figure 1 need not be part of the 5G Service Based Interface (SBI). 1048 Only management plane functionality is needed to create, monitor, 1049 manage and delete (life cycle management) the transport TE paths/ 1050 transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). 1051 The management plane functionality also provides the mapping of such 1052 TE paths to a network instance identifier to the SMF. The SMF uses 1053 this mapping to install appropriate FARs in the UPF. This approach 1054 provide partial integration of the transport network into 5GS with 1055 some benefits. 1057 One of the limitations of this approach is the inability of the 5GS 1058 procedures to know, if underlying transport resources are available 1059 for the traffic type being carried in PDU session before making 1060 certain decisions in the 5G CP. One example scenario/decision could 1061 be, a target 5G-AN selection during a N2 mobility event, without 1062 knowing if the target 5G-AN is having a underlay transport slice 1063 resource for the S-NSSAI and 5QI of the PDU session. The Integrated 1064 approach specified below can mitigate this. 1066 Authors' Addresses 1067 Uma Chunduri (editor) 1068 Intel 1069 2191 Laurelwood Rd 1070 Santa Clara, CA 95054 1071 United States of America 1073 Email: umac.ietf@gmail.com 1075 John Kaippallimalil (editor) 1076 Futurewei 1078 Email: john.kaippallimalil@futurewei.com 1080 Sridhar Bhaskaran 1081 Altiostar 1083 Email: sridharb@altiostar.com 1085 Jeff Tantsura 1086 Microsoft 1088 Email: jefftant.ietf@gmail.com 1090 Praveen Muley 1091 Nokia 1092 440 North Bernardo Ave 1093 Mountain View, CA 94043 1094 United States of America 1096 Email: praveen.muley@nokia.com