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