| Internet-Draft | Mobility aware Transport Network Slicing | October 2022 |
| Chunduri, et al. | Expires 22 April 2023 | [Page] |
Slices in a 5G system should be identified and mapped to the corresponding transport network underlay segments to provide the capabilities requested by the 5G customer. One set of slices in a 5G system correspond to resources and connectivity to carry signaling and data plane packets across a distributed infrastructure that make up the 5G system, for example, distributed entities of a radio network (gNB). Another set of 5G slices represent resource and connectivity capabilities offered by the 5G system to its end users (UE) for the lifetime of a session including UE mobility. Both depend in part on multiple transport network slice segments with requirements that include bandwidth, latency, and criteria such as isolation, directionality, and disjoint routes.¶
This document describes how a 5G slice is mapped to a slice in IP or Layer 2 transport network for both above cases, including scenarios where the 5G customer network is separated from the provider transport network by an intermediate network. Mobile slice criteria are mapped to the appropriate transport slice and capabilities offered in backhaul, mid-haul and fronthaul connectivity segments between radio side network functions and user plane function(gateway). Applicability of this framework and underlying transport networks, which can enable different slice properties are also discussed. This is based on mapping between mobile and transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The 3GPP architecture for 5GS defined in [TS.23.501-3GPP], [TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core), the NG-RAN architecture defined in [TS.38.300-3GPP] and [TS.38.401-3GPP] include procedures for setting up network slices in the 3GPP network as well as help provide connectivity with resource commitments to 3GPP network users. This document discusses the details, where connectivity and resource commitments of 3GPP slice segments are realized by IP transport network segments. Thus the 3GPP network signaling requests for connectivity with resource commitments are mapped to shared or dedicated resources in the underlay network in a way that meets customer guarantees for service level objectives and separation from other user's traffic.¶
Slice types defined in 3GPP and offered to its clients (UEs) include enhanced mobile broadband (eMBB) communications, ultra-reliable low latency communications(URLLC) and massive internet of things (mIoT)and may extend to include new slice types as needed. ATIS [ATIS075] has defined an additional slice type for V2X services. 3GPP slicing and RAN aspects are further described Appendix A.1.¶
3GPP slice types and multiple instances of a slice type satisfy various characteristics for 5G network resources. A slice in 3GPP is a logical chunk of 3GPP network resources that is dynamically created and may include core network control and user plane functions as well as access network functions. A slice instance that spans user plane network functions including the UPF (User Plane Function), gNB-CU (generalized Node-B Centralized Unit) and gNB-DU (generalized Node-B Distributed Unit) and its interfaces N3, N9, F1-U) are clearly defined, however:¶
IP transport is used to interconnect the data forwarding entities UPFs, gNB-CU and gNB-DU in the 5GC and NG-RAN architecture but 3GPP specifications only define the interfaces (N3, N9, F1U etc.) and the 3GPP transport end points [TS.28.541-3GPP]. The architecture allows the flexibility to dynamically place Branching Point (BP) and Uplink Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-AN can be a radio access network (NG-RAN) or any non-3GPP access network, for example, WLAN. The resources of gNB-CU and gNB-DU corresponding to a slice in a 5G radio access network (NG-RAN) may be interconnected using a Layer 2 or IP network transport.¶
A transport underlay across 3GPP interfaces N3, N9 and F1U may use multiple technologies or network providers on path and the slice in 3GPP domain should have a corresponding mapping in the transport domain. This document proposes to identify and map a slice in the 5G/3GPP customer domain to a transport provider domain slice. Both 5G system slices for distributed infrastructure that make up the 5G system, and 5G slices offered to its end users (UE) and the respective mapping to transport domain slices are covered. Key considerations including simplicity (e.g., use of L2 VLAN), routed networks on path (i.e., IP based mapping), efficiency of inspecting the slice mapping parameter and o thers are described in subsequent sections.¶
[I-D.ietf-teas-ietf-network-slices] draft defines the 'IETF Network slice', its scope and characteristics. It lists use cases where IETF technologies can be used for slicing solutions, for various connectivity segments. Transport slice terminology as used in this document refers to the connectivity segment between various 5G systems (i.e. 5G-AN which includes NG-RAN, ULCL UPF, BP UPF and PSA UPF) and some of these segments are referred to as IETF Network slices.¶
[I-D.ietf-teas-ietf-network-slices] also defines a generic framework and how abstract requests to set up slices can be mapped to more specific technologies (e.g., VPN and traffic-engineering technologies). This document is aimed to be specific to 3GPP use case where many such connectivity segments are used in E2E slicing solutions. Some of the terminologies defined in these referred drafts and applicability to this document are further described in Section 2.1.1.¶
This document specifies an approach to fulfil the needs of 5GS to transport user plane traffic from 5G-AN (including NG-RAN) to UPF in an optimized fashion. This is done by keeping establishment and mobility procedures aware of the underlying transport network along with slicing requirements.¶
Section 2 describes in detail on how TN aware mobility can be built irrespective of underlying TN technology used. How other IETF TE technologies applicable for this draft is specified in Section 3.2.¶
3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing in 5GS and is provided here for information. The application of 5GS slices in transport network for backhaul, mid-haul and front haul are not explicitly covered in 3GPP and is the topic here. To support specific characteristics in backhaul (N3, N9), mid-haul (F1) and front haul, it is necessary to provision corresponding resources in the transport domain and carry a slice identifier that is understood by both the customer (3GPP network) and the provider (transport network). This section describes how to provision the mapping information in the transport network and apply it so that user plane packets can be provided the transport resources (QoS, isolation, protection, etc.) expected by the 5GS slices.¶
The figure below shows the functional entities on path for 3GPP (gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an IP/L2 transport network.¶
5G Control and Management Planes
+------------------------------------------------------------------------+
| +--------------------------------------------------------------------+ |
| | (TNO) 5G Management Plane (TNO) | |
| +----+-----------------+-------------+---------------+-----------+---+ |
| | | | | | |
| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
| | | | +----+-----+ | +----+---+ |
+-| |-----------|-------------|---------------|-----------|-----+
| | | | | |
| | | | | |
| | | ACTN | | ACTN |
| | +---+---+ | +---+---+ |
| | | | | | | |
| gNB-DU | | NC | E1 | NC | |
| | | | | | | |
| | +---+---+ | +---+---+ |
| | | | | |
| | | | | |
| | __ +__ | ___+__ |
| | __/ \__ +--+---+ __/ \__ +-+-+
| | / IP/L2 \ | gNB | / IP \ | |
UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
+----------+ \__ __/ +------+ \__ __/ +---+
\______/ \______/
|------ F1-U -------| |------ N3 OR N9 ------|
* Radio and Fronthaul
Figure 1 depicts IP Xhaul network with the PE (Provider Edge) routers providing IP transport service to 5GS user plane entities 5G-AN (e.g. gNB) and UPF. The Provider Edge (PE) represents the Service Demarcation Point (SDP) to the transport network that provides the slice capabilities. The IETF Network Slice Controller (NSC) interfaces with the 3GPP network (customer network) that requests for transport network slices (IETF network slice). The NSC in turn requests the Network Controller (NC) to setup resources and connectivity in the transport network to realize the particular network slice. Network slice orchestration in the 3GPP network is defined in [TS.28.533-3GPP] and is represented in Figure 1 as Transport Network Orchestrator (TNO). The TNO is responsible for requesting transport slice service via the NSC and may use ACTN [RFC8453]. The Network Data Analytics Function (NWDAF), Network Slice Selection Management Function (NSSMF) and other 3GPP functions in the control and management planes may provide data and functionality to estimate slice capabilities required in the transport network but all of this functionality including the TNO are out of scope of this document. What is important to note here is that the requests for transport network slice configuration are between the 3GPP network (customer network) and the IP transport network (provider network). This should be distinguished from 3GPP slices (S-NSSAI) which represent slice capabilities (resource and connectivity) that the 3GPP provider offers to its clients (UE). An overview of the sequence of operations from when a user (UE) requests during session setup to how it relates to the front-haul and transport network slices is provided below. Further details are found in [TS.23.501-3GPP] and [TS.23.502-3GPP].¶
Prior to 3GPP user (UE) signaling to setup a session, the UE attaches to the radio network and has the parameters for operation configured. During this sequence of operation, the signaling is between the UE and the gNB. When the gNB functionality is split between a central unit (CU) and a distributed unit (DU), a mid-haul transport segment provides the connectivity as shown in Figure 1. If the RAN uses lower layer split architecture as specified by O-RAN alliance, then the user plane path from UE to DN also includes the fronthaul interface. The fronthaul interface carries the radio frames in the form of In-phase (I) and Quadrature (Q) samples using eCPRI encapsulation over Ethernet or UDP over IP. An important point to note is that signaling and data transport over the the mid-haul transport has no notion of an end-user/UE session, but is rather defined by low latency and other requirements required for processing radio signaling and data transport between the network entities that compose gNB. For the front-haul described further in Section 2.1.2, an Ethernet transport with VLANs can be expected to be the case in many deployments.¶
Folowing the radio setup and attach, the 3GPP user (UE) signals to setup a session. 5G core network (5GC) functionality to handle access mobility (AMF), UE session management (SMF), policy (PCF) and various other assisting functionality including 3GPP slice selection (NSSF) are used to setup the data plane to transport the UE PDU (Protocol Data Units). The N3, N9 and F1-U user planes use GTP-U [TS.29.281-3GPP] to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). From an IP transport network perspective, these GTP-U connections can be viewed as multiple overlay connection segments between each of the 3GPP data plane entities (gNB, UPF) on a per UE basis. The GTP-U/overlay transport capabilities required are signaled between the UE and 5GC during UE session setup. Note that unlike the slice requirements for mid-haul segment (F1-U), the slice requirements for the backhaul (N3, N9) are setup in the 3GPP network on a per UE basis. Some of the slice capabilities along the user plane path between the (R)AN and UPFs such as a low latency path, jitter, protection and priority needs to be provided by the IP transport network. 3GPP core network entities may be deployed across multiple data centers and in such cases require the IP transport network to provide the resources and connectivity for each of the slice segments. This is further described in Section 2.2.¶
The TNO (Transport Network Orchestrator) functionality is not in the scope of this document, but it is responsible for provisioning slice requirements of the transport network. Specification of these functionality is in [TS.28.533-3GPP] and other 3GPP management specifications. Figure 1 depicts the PE router, where transport paths are initiated/terminated and can be deployed separately from the UPF or both functionalities can be in the same node. The TNO may provision this in the NSC of the IP XHaul network using ACTN [RFC8453]. When a GTP-U encapsulated user packet from the (R)AN (gNB) or UPF with the slice information traverses the F1-U/N3/N9 segment, the PE router of the IP transport underlay can inspect the slice information and provide the provisioned capabilities. This is elaborated further in Section 2.4.¶
The functional elements depicted in the Figure 1 use slicing concepts defined in [I-D.ietf-teas-ietf-network-slices]. From a 3GPP perspective, UE and UPF are the network slice (S-NSSAI) endpoints and routers, gNB-DU, gNB-CU, switches, PE nodes are the slice realization endpoints. The TNO represented in the Figure 1 can be seen as a customer higher level operation system for the management of slices in the 3GPP network. The NSC realizes the transport network slice in the underlay network. Various possibilities for implementation of these interfaces including ACTN are described in the [I-D.ietf-teas-ietf-network-slices].¶
The O-RAN Alliance has specified the fronthaul interface between the O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer information, in the form of In-phase (I) and Quadrature (Q) samples are transported using Enhanced Common Public Radio Interface (eCPRI) framing over Ethernet or UDP. On the Ethernet based fronthaul interface, the slice information can be carried in the Ethernet header through the VLAN tags. The Ethernet switches in the fronthaul transport network can inspect the slice information (VLAN tag) in the Ethernet header and provide the provisioned capabilities. The mapping of I and Q samples of different radio resources (radio resource blocks or carriers) to different slices and to their respective VLAN tags on the fronthaul interface is controlled by the O-RAN fronthaul C-Plane and M-Plane interfaces. On a UDP based fronthaul interface, the slice information can be carried in the IP or UDP header. The PE routers of the fronthaul transport network can inspect the slice information in the IP or UDP header and provide the provisioned capabilities. The fronthaul transport network is latency and jitter sensitive. The provisioned slice capabilities in the fronthaul transport network MUST take care of the latency and jitter budgets of the specific slice for the fronthaul interface. The provisioning of the fronthaul transport network is handled by the NC pertaining to the fronthaul transport.¶
The MTNC (Mobile Transport Network Context) represents a slice of a transport path for a tenant between two 3GPP user plane functions. This is defined in [TS.28.541-3GPP] transport end-point as "logicInterfaceId" and is referred to as MTNC in this document to describe how it applies to the IETF network slice capabilities in the transport network. The Mobile-Transport Network Context Identifier (MTNC-ID) is generated by the TNO to be unique for each instance (for a tenant) and per traffic class (including QoS and slice aspects). Thus, there may be more than one MTNC-ID for the same QoS and instance if there is a need to provide isolation (slice) of the traffic. It should be noted that MTNC are per class/instance and not per user (UE) session. The MTNC-IDs are configured by the TNO to be unique within a 3GPP provisioning domain.¶
MTNC-IDs or "logicInterfaceId" are per instance / tenant and is not unique per UE session. The relation of an S-NSSAI signaled by the UE during session establishment and the corresponding MTNC-ID / logicInterfaceId in each of the transport network segments is derived in 3GPP specifications and not in scope here. The traffic estimation is performed prior to UE's session establishment, there is no provisioning delay experienced by the UE during its session setup. For an instance/tenant, the MTNC-ID space scales roughly as a square of the number sites between which 3GPP user plane functions have paths. If there are T traffic classes and C Tenants, the number of MTNC-IDs in a fully meshed network is T * C. An MTNC-ID space of 16 bits (65K identifiers) can be expected to be sufficient.¶
Figure 1 shows a view of the functions and interfaces for provisioning the MTNC-IDs. The focus is on provisioning between the 3GPP management plane (NSSMF), transport network (NSC) and carrying the MTNC-IDs in PDU packets for the transport network to grant the provisioned resources.¶
In Figure 1, the TNO (logical orchestration functionality within the 3GPP management plane) requests the NSC in the transport domain to setup the TE path using ACTN [RFC8453]. The NSC sets up the Provider Edge (PE) routers and internal routers according to the underlay transport technology (e.g., MPLS, SR, PPR). The PE router is the service demarcation point (SDP) and it inspects incoming PDU data packets for the UDP SRC port which mirrors the MTNC-ID, classifies and provides the VN service provisioned across the transport network.¶
The detailed mechanisms by which the NSSMF provides the MTNC-IDs to the control plane and user plane functions are for 3GPP to specify. Two possible options are outlined below for completeness. The NSSMF may provide the MTNC-IDs to the 3GPP control plane by either providing it to the Session Management Function (SMF), and the SMF in turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU session setup. Alternatively, the user plane functions may request the MTNC-IDs directly from the TNO/NSSMF. Figure 1 shows the case where user plane entities request the TNO/NSSMF to translate the Request and get the MTNC-ID. Another alternative is for the TNO to provide a mapping of the 3GPP Network Instance Identifier, described in Section 2.6 and the MTNC-ID to the user plane entities via configuration.¶
The TNO should be seen as a logical entity that can be part of NSSMF in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use network configuration, policies, history, heuristics or some combination of these to derive traffic estimates that the TNO would use. How these estimates are derived are not in the scope of this document. The focus here is only in terms of how the TNO and NSC are programmed given that slice and QoS characteristics across a transport path can be represented by an MTNC-ID. The TNO requests the NSC in the transport network to provision paths in the transport domain based on the MTNC-ID. The TNO is capable of providing the MTNC-ID provisioned to control and user plane functions in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID should be part of the 3GPP specifications.¶
This section outlines a sequence of operations for provisioning an engineered IP transport that supports 3GPP slicing and QoS requirements in [TS.23.501-3GPP].¶
During a PDU session setup request from the UE, the AMF using input from the NSSF selects a network slice and SMF. The SMF with user policy from Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the path of the PDU session. While QoS and slice selection for the PDU session can be applied across the 3GPP control and user plane functions as outlined in Section 2, the IP transport underlay across F1-U, N3 and N9 segments do not have enough information to apply the resource constraints represented by the slicing and QoS classification. Current guidelines for interconnection with transport networks [IR.34-GSMA] provide an application mapping into DSCP. However, these recommendations do not take into consideration other aspects in slicing like isolation, protection and replication.¶
IP transport networks have their own slice and QoS configuration based on domain policies and the underlying network capability. Transport networks can enter into an agreement for virtual network services (VNS) with client domains (in this case 3GPP networks) using the ACTN [RFC8453] framework. An IP transport network provide may provide such slice instances to mobile network operators, CDN providers or enterprises for example. The 3GPP mobile network, on the other hand, defines a slice instance for UEs as are the mobile operator's 'clients'. The Network Slice Selection Management Function (NSSMF) [TS 28.533] that interacts with a TN controller like an NSC (that is out of scope of 3GPP).¶
The ACTN VN service can be used across the IP transport networks to provision and map the slice instance and QoS of the 3GPP domain to the IP transport domain. An abstraction that represents QoS and slice instances in the mobile domain and mapped to ACTN VN service in the transport domain is represented here as MTNC-IDs. Details of how the MTNC-IDs are derived are up to functions that can estimate the level of traffic demand.¶
The 3GPP network/5GS provides slices instances to its clients (UE) that include resources for radio and mobile core segments. The UE's PDU session spans the access network (radio) and F1-U/N3/N9 transport segments which have an IP transport underlay. The 5G operator needs to obtain slice capability from the IP transport provider since these resources are not seen by the 5GS. Several UE sessions that match a slice may be mapped to an IP transport segment. Thus, there needs to be a mapping between the slice capability offered to the UE (NSSAI) and what is provided by the IP transport.¶
When the 3GPP user plane function (5G-AN, UPF) does not terminate the transport underlay protocol (e.g., MPLS), it needs to be carried in the IP protocol header from end-to-end of the mobile transport connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses these scenarios in detail.¶
When the 3GPP user plane function (5G-AN, UPF) and transport provider edge are on different nodes, the PE router needs to have the means by which to classify the IP packet from 3GPP entity based on some header information. In [I-D.ietf-teas-ietf-network-slices] terminology, this is a scenario where there is an Attachment Circuit (AC) between the 3GPP entity (customer edge) and the SDP (Service Demarcation Point) in the IP transport network (provider edge). The Attachment Circuit(AC) may for example be between a UPF in a data center to a (provider edge) router that serves as the service demarcation point for the transport network slice. The identification information is provisioned between the 5G provider and IP transport network and corresponding information should be carried in each IP packet on the F1-U, N3, N9 interface. For IP transport edge nodes to inspect the transport context information efficiently, it should be carried in an IP header field that is easy to inspect. It may be noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces. If the fronthaul, midhaul or backhaul IP path is bounded by an L2 network, one option maybe to use VLANs to carry the MTNC-ID. 3GPP specifications for management plane defines transport end-points configuration in [TS.28.541-3GPP] and currently include VLAN, MPLS, and segment routing. However, Layer 2 alternatives such as VLAN will fail in L3/routed networks on the F1-U, N3 or N9 path. GTP-U (F1-U, N3, N9 encapsulation header) field extensions offer a possibility, however these extensions are not always easy for a transport edge router to parse efficiently on a per packet basis. Other IP header fields like DSCP are not suitable as it only conveys some QoS aspects (but not other aspects like isolation, protection, etc.)¶
While IPv6 extension headers like SRv6 may be an option to carry the MTNC-ID that requires the end-to-end network to be IPv6 as well as the capability to lookup the extension header at line rate. To minimize the protocol changes and make this underlay transport independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping of MTNC-ID to a UDP port range of the GTP encapsulated user packet. A mapping table between the MTNC-ID and the source UDP port number can be configured to ensure that ECMP /load balancing is not affected adversely by encoding the UDP source port with an MTNC-ID mapping. The UDP port information containing MTNC-ID is a simple extension that can be provisioned in 3GPP transport end-points defined in [TS.28.541-3GPP]. This mapping is configured in 3GPP user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that process MTNC-IDs.¶
PE routers can thus provision a policy based on the source UDP port number (which reflects the mapped MTNC-ID) to the underlying transport path and then deliver the QoS/slice resource provisioned in the transport network. The source UDP port that is encoded is the outer IP (corresponding to GTP-U header) while the inner IP packet (UE payload) is unaltered. The source UDP port is encoded by the node that creates the GTP-U encapsulation and therefore, this mechanism has no impact on UDP checksum calculations.¶
3GPP network operators may use IPSec gateways (SEG) to secure packets between two sites - for example over an F1-U, N3 or N9 segment. The MTNC identifier in the GTP-U packet should be in the outer IP source port even after IPSec encryption for PE transport routers to inspect and provide the level of service provisioned. Tunnel mode - which is the case for SEG/IPSec gateways - adds an outer IP header in both AH (Authenticated Header) and ESP (Encapsulated Security Payload) modes. The GTP-U / UDP source port with encoded MTNC identifier should be copied to the IPSec tunnel ESP header. One option is to use 16 bits from the SPI field of the ESP header to encode the MTNC identifier and use the remaining 16 bits in SPI field to identify an SA. Load balancing entropy for ECMP will not be affected as the MTNC encoding mechanism already accounts for this.¶
If the RAN uses O-RAN Alliance lower layer split architecture, then a fronthaul network is involved. On an Ethernet based fronthaul transport network, VLAN tag may be an option to carry the MTNC-ID. The VLAN ID provides a 12 bit space and is sufficient to support up to 4096 slices on the fronthaul transport network. The mapping of fronthaul traffic to corresponding network slices is based on the radio resource for which the fronthaul carries the I and Q samples. The mapping of fronthaul traffic to the VLAN tag corresponding to the network slice is specified in Section 2.1.2. On the UDP based fronthaul transport network, the UDP source port can be used to carry the MTNC-ID.¶
With the TNO functionality in 5GS Service Based Interface, the following steps illustrate the end-2-end slice management including the transport network:¶
Integrating the TNO as part of the 5GS Service Based Interfaces, provides the flexibility to control the allocation of required characteristics from the TN during a 5GS signaling procedure (e.g. PDU Session Establishment). If TNO is seen as separate and in a management plane, this real time flexibility is lost. Changes to detailed signaling to integrate the above for various 5GS procedures as defined in [TS.23.502-3GPP] is beyond the scope of this document.¶
Apart from the various flavors of IETF VPN technologies to share the transport network resources and capacity, TE capabilities in the underlay network is an essential component to realize the 5G TN requirements. This section focuses on various transport underlay technologies (not exhaustive) and their applicability to realize Midhaul/Backhaul transport networks. Focus is on the user/data plane i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.¶
+----------------+------------+------------------+-----------------+
|GTP/UDP SRC PORT| SST | Transport Path | Transport Path |
| | in S-NSSAI | Info | Characteristics |
+----------------+------------+------------------+-----------------+
| Range Xx - Xy | | | |
| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |
| values) | (massive | TE-PATH-A | Bit Rate) |
| | IOT) | | Bandwidth: Bx |
| | | | Delay: Dx |
| | | | Jitter: Jx |
+----------------+------------+------------------+-----------------+
| Range Yx - Yy | | | |
| Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay |
| values) | (ultra-low | TE-PATH-B | Req. |
| | latency) | | Bandwidth: By |
| | | | Delay: Dy |
| | | | Jitter: Jy |
+----------------+------------+------------------+-----------------+
| Range Zx - Zy | | | |
| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
| values) | (broadband)| TE-PATH-C | Bandwidth: Bx |
+----------------+------------+------------------+-----------------+
In some E2E scenarios, security is desired granularly in the underlying transport network. In such cases, there would be a need to have separate sub-ranges under each SST to provide the TE path in preserving the security characteristics. The UDP Source Port range captured in Figure 2 would be sub-divided to maintain the TE path for the current SSTs with the security. The current solution doesn't provide any mandate on the UE traffic in selecting the type of security.¶
While there are many Software Defined Networking (SDN) approaches available, this section is not intended to list all the possibilities in this space but merely captures the technologies for various requirements discussed in this document.¶
RSVP-TE [RFC3209] provides a lean transport overhead for the TE path for MPLS user plane. However, it is perceived as less dynamic in some cases and has some provisioning overhead across all the nodes in N3 and N9 interface nodes. Also, it has another drawback with excessive state refresh overhead across adjacent nodes and this can be mitigated with [RFC8370].¶
SR-TE [RFC8402] does not explicitly signal bandwidth reservation or mechanism to guarantee latency on the nodes/links on SR path. But SR allows path steering for any flow at the ingress and particular path for a flow can be chosen. Some of the issues and suitability for mobile use plane are documented at Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. However, [I-D.ietf-dmm-srv6-mobile-uplane] presents various options for optimized mobile user plane with SRv6 with or without GTP-U overhead along with traffic engineering capabilities. SR-MPLS allows reduction of the control protocols to one IGP (without needing for LDP and RSVP-TE).¶
Preferred Path Routing (PPR) is an integrated routing and TE technology and the applicability for this framework is described in [I-D.chunduri-rtgwg-preferred-path-routing]. PPR does not remove GTP-U, unlike some other proposals laid out in [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works with the existing cellular user plane (GTP-U) for F1-U/N3 and N9. In this scenario, PPR will only help provide TE benefits needed for 5G slices from a transport domain perspective. It does so for any underlying user/data plane used in the transport network (L2/IPv4/IPv6/MPLS).¶
As specified with the integrated transport network orchestrator (TNO), a particular RSVP-TE path for MPLS or SR path for MPLS and IPv6 with SRH user plane or PPR with PPR-ID [I-D.chunduri-rtgwg-preferred-path-routing], can be supplied to SMF for mapping a particular PDU session to the transport path.¶
Thanks to Young Lee for discussions on this document including ACTN applicability for the proposed TNO. Thanks to Sri Gundavelli, Kausik Majumdar, Hannu Flinck, Joel Halpern and 3GPP delegates who provided detailed feedback on this document.¶
This document has no requests for any IANA code point allocations.¶
This document does not introduce any new security issues.¶
The following people contributed substantially to the content of this document and should be considered co-authors.¶
Richard Li Futurewei 2330 Central Expressway Santa Clara CA 95050 USA Email: richard.li@futurewei.com¶
Luis M. Contreras Telefonica Sur-3 building, 3rd floor Madrid 28050 Spain Email: luismiguel.contrerasmurillo@telefonica.com¶
Xavier De Foy InterDigital Communications, LLC 1000 Sherbrooke West Montreal Canada Email: Xavier.Defoy@InterDigital.com¶
Reza Rokui Ciena Email: rrokui@ciena.com¶
The 3GPP architecture defines slicing aspects where the Network Slice Selection Function (NSSF) assists the Access Mobility Manager (AMF) and Session Management Function (SMF) to assist and select the right entities and resources corresponding to the slice requested by the User Equipment (UE). The User Equipment (UE) indicates information regarding the set of slices it wishes to connect, in the Network Slice Selection Assistance Information (NSSAI) field during network registration procedure (Attach) and the specific slice the UE wants to establish an IP session, in the Specific NSSAI (S-NSSAI) field during the session establishment procedure (PDU Session Establishment). The AMF selects the right SMF and the SMF in turn selects the User Plane Functions (UPF) so that the QoS and capabilities requested can be fulfilled.¶
The architecture for the Radio Access Network (RAN) is defined in [TS.38.300-3GPP] and [TS.38.401-3GPP]. The 5G RAN architecture allows disaggregation of the RAN into a Distributed Unit (DU) and a Centralized Unit (CU). The CU is further split into control plane (CU-CP) and user plane (CU-UP). The interface between CU-UP and the DU for the user plane traffic is called the F1-U and between the CU-CP and DU for the control plane traffic is called the F1-C. The F1-C and the F1-U together are called the mid-haul interfaces. The DU does not have a CP/UP split. Apart from 3GPP, O-RAN Alliance has specified further disaggregation of the RAN at the lower layer (physical layer). The DU is disaggregated into a ORAN DU (O-DU) which runs the upper part of the physical layer, MAC and RLC and the ORAN Radio Unit (O-RU) which runs the lower part of the physical layer. The interface between the O-DU and the O-RU is called the Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN].¶
In this approach transport network functionality from the 5G-AN to UPF is discrete and 5GS is not aware of the underlying transport network and the resources available. Deployment specific mapping function is used to map the GTP-U encapsulated traffic at the 5G-AN (e.g. gNB) in UL and UPF in DL direction to the appropriate transport slice or transport Traffic Engineered (TE) paths. These TE paths can be established using RSVP-TE [RFC3209] for MPLS underlay, SR [RFC3209] for both MPLS and IPv6 underlay or PPR with MPLS, IPv6 with SRH, native IPv6 and native IPv4 underlays. Few integrated mobility scenarios with PPR are documented in [I-D.chunduri-dmm-5g-mobility-with-ppr].¶
As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the user plane traffic forwarding rules in the UPF. The UPFs have a concept of a "Network Instance" which logically abstracts the underlying transport path. When the SMF creates the packet detection rules (PDR) and forwarding action rules (FAR) for a PDU session at the UPF, the SMF identifies the network instance through which the packet matching the PDR has to be forwarded. A network instance can be mapped to a TE path at the UPF. In this approach, TNO as shown in Figure 1 need not be part of the 5G Service Based Interface (SBI). Only management plane functionality is needed to create, monitor, manage and delete (life cycle management) the transport TE paths/transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). The management plane functionality also provides the mapping of such TE paths to a network instance identifier to the SMF. The SMF uses this mapping to install appropriate FARs in the UPF. This approach provide partial integration of the transport network into 5GS with some benefits.¶
One of the limitations of this approach is the inability of the 5GS procedures to know, if underlying transport resources are available for the traffic type being carried in PDU session before making certain decisions in the 5G CP. One example scenario/decision could be, a target 5G-AN selection during a N2 mobility event, without knowing if the target 5G-AN is having a underlay transport slice resource for the S-NSSAI and 5QI of the PDU session. The Integrated approach specified below can mitigate this.¶