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