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