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