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