Internet-Draft Mobility aware Transport Network Slicing July 2023
Chunduri, et al. Expires 6 January 2024 [Page]
Workgroup:
DMM Working Group
Internet-Draft:
draft-ietf-dmm-tn-aware-mobility-07
Published:
Intended Status:
Informational
Expires:
Authors:
U. Chunduri, Ed.
Intel Corporation
J. Kaippallimalil, Ed.
Futurewei
S. Bhaskaran
Rakuten Symphony
J. Tantsura
Microsoft
P. Muley
Nokia

Mobility aware Transport Network Slicing for 5G

Abstract

Network slicing in 5G supports logical networks for communication services of multiple 5G customers to be multiplexed over the same infrastructure. While 5G slicing covers logical separation of various aspects of 5G services, user's data plane packets over the radio access network (RAN) and mobile core network (5GC) use IP transport in many segments of the end-to-end 5G slice. When end-to-end slices in a 5G system use IP network resources, they are mapped to corresponding IP transport network slice(s) which in turn provide the bandwidth, latency, isolation and other criteria requested by the 5G slice.

This document describes mapping of 5G slices to IP or Layer 2 transport network slices when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed, for example, 5G functions that are distributed across data centers. The slice mapping proposed here is supported transparently when a 5G user device moves across 5G attachment points and session anchors.

Requirements Language

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].

Status of This Memo

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 6 January 2024.

Table of Contents

1. Introduction

3GPP architecture for 5GS in [TS.23.501-3GPP], [TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core), and the NG-RAN architecture defined in [TS.38.300-3GPP] and [TS.38.401-3GPP] describe slicing as one of the capabilities for the communication services that 5G systems offer. Slice types defined in 3GPP and offered to its clients (UEs) include enhanced mobile broadband (eMBB) communications, ultra-reliable low latency communications(URLLC), massive internet of things (MIoT), vehicle-to-X (V2X) and high performance machine type communications (HMTC) and can be extended in future to include new slice types.

Slices in 3GPP are logical sets of 3GPP resources that may include multiple segments across 3GPP control and user plane functions in the core and radio access networks. For example, a 5G slice instance requested by an end-user may be realized by multiple slice subnets that span 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 corresponding 3GPP interfaces N3, N9, F1-U. However, considering the IP transport network aspects for realizing 3GPP slicing:

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 is mapped in each corresponding transport domain. 5G system slices for distributed infrastructure that make up the 5G system, and 5G slices offered to its end users (UE) are mapped to transport domain slices to provide the corresponding level of bandwidth, isolation and other capabilities. The gNB-CU maintains the upper layer functionality of the radio access network while the gNB-DU runs the lower layers of the radio access network stack (e.g., RLC, MAC and PHY based on the split), typically called the BBU (Base Band Unit). Thus, a 3GPP F1-U slice subnet instance would typically be used to carry all user traffic between a gNB-DU and gNB-CU. The N3 and N9 transport segments between the gNB and UPF(s) on the other hand handle user traffic based on the subscribed/offered level of service. Thus, an end-user's traffic for eMBB service and assigned 3GPP slice may be mapped to a different IP transport slice across N3 and N9 segments than traffic for URLLC service. Mapping and binding between 3GPP slice and a new IP transport slice happens transparently as the end-user moves across attachment points in the radio network and session anchors in 5GC. Unlike mapping of a fronthaul 3GPP slice to an IP transport slice, the IP transport slice that F1-U/N3/N9 slice is mapped to is aware of the slice characteristics of the UE session during initial setup (user initiates 3GPP connectivity session) and following mobility. For example, a UE served by the 3GPP system for high throughput, low latency service and related 3GPP slice should be mapped to an IP transport slice that offers the corresponding characteristics even after handover.

Different network scenarios and mechanisms to map 3GPP and IETF network slices are found in [I-D.ietf-teas-5g-network-slice-application]. [I-D.ietf-teas-5g-network-slice-application] also describes the relationship between slice handling in the 3GPP management plane ([TS.28.541-3GPP]) and IETF network slice management. This document focuses on a specific set of options outlined in [I-D.ietf-teas-5g-network-slice-application]. The use of UDP source port in GTP-U outer header and L2 VLAN to map between a 5G slice and corresponding IETF network slice segments is described in detail here. The main considerations in the mapping methods proposed here include simplicity (i.e., use of L2 VLAN across a Layer-2 network) and efficiency of inspecting the slice mapping parameters on a per packet basis (i.e., source UDP port across routed IP networks) when the IP transport network (slice provider) is separated from the networks in which the 5G network functions are deployed (for example, 5G functions distributed across data centers). Section 3 describes these methods in detail. How other IETF TE technologies applicable for this draft is described in Section 4.2.

[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. IETF Network slice in [I-D.ietf-teas-ietf-network-slices] and IP transport slice in this document are the same in the context of descriptions here. When applied to 5G, they both refer to slices for the connectivity segments between various 5G functions (i.e. 5G-AN which includes NG-RAN, ULCL UPF, BP UPF and PSA UPF).

2. Terminology

5G-AN -
5G Access Network
AC -
Attachment Circuit
AMF -
Access and Mobility Management Function (5G)
BP -
Branch Point (5G)
CSR -
Cell Site Router
CP -
Control Plane (5G)
CU -
Centralized Unit (5G, gNB)
DN -
Data Network (5G)
DU -
Distributed Unit (5G, gNB)
eMBB -
enhanced Mobile Broadband (5G)
FRR -
Fast ReRoute
gNB -
5G NodeB
GBR -
Guaranteed Bit Rate (5G)
GTP-U -
GPRS Tunneling Protocol - User plane (3GPP)
IGP -
Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)
LFA -
Loop Free Alternatives (IP FRR)
mIOT -
Massive IOT (5G)
MPLS -
Multi Protocol Label Switching
NG-RAN -
Next Generation Radio Access Network (i.e., gNB, NG-eNB - RAN functions which connect to 5GC)
NSC -
Network Slice Controller
NSSAI -
Network Slice Selection Assistance Information
NSSF -
Network Slice Selection Function
NSSMF -
Network Slice Selection Management Function
PCP -
Priority Code Point (Ethernet)
PPR -
Preferred Path Routing
PDU -
Protocol Data Unit (5G)
PW -
Pseudo Wire
RQI -
Reflective QoS Indicator (5G)
SBI -
Service Based Interface (5G)
SDP -
Service Demarcation Point
SID -
Segment Identifier
SMF -
Session Management Function (5G)
S-NSSAI -
Single Network Slice Selection Assistance Information
SSC -
Session and Service Continuity (5G)
SST -
Slice and Service Types (5G)
SR -
Segment Routing
TE -
Traffic Engineering
ULCL -
Uplink Classifier (5G)
UP -
User Plane(5G)
UPF -
User Plane Function (5G)
URLLC -
Ultra reliable and low latency communications (5G)

3. Mapping 3GPP Slices to IP Network Slices

3.1. Overview of 5G End-to-End Network Slicing

3GPP architecture in [TS.23.501-3GPP], [TS.23.502-3GPP] specify slicing in 5GS and an overview is provided here. Communication services offered to 3GPP clients (UE) are associated to one or more slices represented by NSSAI (Network Slice Selection Assistance Information). The NSSAI is realized in the 5G management plane using network slice subnet (NSS), for example, a network slice subnet that contains network function instances of the core network (e.g., UPF) and radio network (e.g,. gNB). 3GPP documents mention transport network in the context of network slice subnets, but do not provide any details. 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 provides an overiew and subsequent sections describe 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.



                5G Control and Management Planes
  +--------------------------------------------------------------------+
  | +----------------------------------------------------------------+ |
  | |                   5G Management Plane  (NSSMF)                 | |
  | +---+--------------+-------------+---------------+-----------+---+ |
  |     |              |             |               |           |     |
  | +---+--+           |   F1-C +----+-----+         |   N2 +----+---+ |
  | |      |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
  | |      |           |        +----+-----+         |      +----+---+ |
  +-|      |-----------|-------------|---------------|-----------|-----+
    |      |           |             |               |           |
    |      |           | e.g.        |               | e.g.      |
    |      |           | ACTN        |               | ACTN      |
    |      |       +---+---+         |           +---+---+       |
    |      |       |       |         |           |       |       |
    |gNB-DU|       |  NSC  |         E1          |  NSC  |       |
    |      |       |       |         |           |       |       |
    |      |       +---+---+         |           +---+---+       |
    |      |           |             |               |           |
    |      |           |             |               |           |
    |      |        __ +__           |            ___+__         |
    |      |     __/      \__     +--+---+     __/      \__    +-+-+
    |      |    /   IP/L2    \    | gNB  |    /     IP     \   |   |
UE--+      +--(PE) Mid-haul (PE)--+CU(UP)+--(PE) Backhaul(PE)--+UPF+--DN
    +------+    \__        __/    +------+    \__        __/   +---+
                   \______/                      \______/

            |------ F1-U -------|           |----- N3 or N9 ------|

Figure 1: Backhaul and Mid-haul Transport Network for 5G

Figure 1 depicts a 5G System (5GS) expanded to show the IP transport and 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 5G management plane in turn requests the Network Slice Controller (NSC) to setup resources and connectivity in the transport network to realize the particular network slice. 5G network slice orchestration is defined in [TS.28.533-3GPP] and is represented in Figure 1 as Network Slice Selection Management Function (NSSMF)) which is a part of 5G Management system responsible for managing network slice subnets. The 3GPP network (customer network) requests for IP transport network slice (slice provider network) based on estimated demand. The 5G management plane slice orchestration functionality in 3GPP requests for transport slices 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 provide data and functionality to estimate slice capabilities required from the transport network. The slices provisioned in the IP transport network correspond to 3GPP slices represented by NSSAI (set of 3GPP slices) available at 3GPP access/data networks and locations. During 3GPP procedures for session initialization, the network grants an S-NSSAI (single one out of the NSSAI) based on the user's session request. The S-NSSAI for the UE's session is signaled to the user plane nodes (gNB, UPF) during the session setup and used to associate to the corresponding IP transport slice. An overview of the sequence of operations from when a user (UE) requests during session setup to how it relates to the fronthaul, mid-haul and backhaul transport network slices is provided below.

Prior to 3GPP user (UE) signaling to setup a session, the UE attaches to the radio access 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. Further, the gNB central unit can be split into the control plane (CP) and user plane (UP) logical functions 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 fronthaul 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 3.2, an Ethernet transport with VLANs can be expected to be the case in many deployments.

Folowing the radio access 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 authenticate the UE and 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 RAN 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. Thus, in the backhaul, an IP transport slice with capabilities corresponding to the S-NSSAI negotiated between UE 5GC is provided. For example, a UE that sets up an eMBB session may require high bandwidth but can tolerate delay whereas a URLLC session requires low latency, low jitter and low error rates. 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.

3.2. Fronthaul and Mid-Haul Transport Network

The O-RAN Alliance defined a lower layer split at the physical layer of the radio access network whereby the gNB-DU is split into two entities (O-RU and O-DU) and 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 an Ethernet based fronthaul interface, the network slice instance (NSI) information is carried in the Ethernet header through the VLAN tags and/or PCP marking. The Ethernet switches in the fronthaul transport network inspects the slice information (VLAN tag and/or PCP marking) 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 and or PCP marking on the fronthaul interface is controlled by the O-RAN fronthaul C-Plane and M-Plane interfaces. 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. 3GPP functions gNB-CU (user plane) and gNB-DU may also be distributed and have a mid-haul transport between the two 3GPP network functions. If an IP based mid-haul interface is used, the network slice instance (NSI) information can be MPLS, SRv6 based as defined in [TS.28.541-3GPP]. However if the 3GPP network function (slice customer) is physically separated from the slice provider network (e.g., a gNB-CU (user plane) with baseband units deployed in a data center), the MPLS, SRv6 information may not be practical to carry across to the separated IP transport network (slice provider). In this case, the source UDP port of the GTP-U can be used to indicate the slice in the IP transport network (slice provider).

3.3. Backhaul Transport Network

The backhaul transport over which the protocols for N3 and N9 interfaces run are described in [TS.23.501-3GPP] and [TS.23.502-3GPP]. The end-user (UE) sessions (IP, Ethernet, unstructured) are carried over GTP-U transport protocol over the N3 and N9 interfaces. GTP-U between the the 3GPP network functions (gnB, UPF) serves as an overlay protocol across one or more MPLS, SRv6 or Ethernet transport networks in between. During UE session setup, a number of parameters for context management are configured in the gNB, UPF and that includes allowed network slice (S-NSSAI). On an Ethernet based backhaul interface, the slice information is carried in the Ethernet header through the VLAN tags. If an IP based backhaul interface is used, the network slice instance (NSI) information can be MPLS, SRv6 based as defined in [TS.28.541-3GPP]. However, if the 3GPP network function (slice customer) is physically separated from the slice provider network (e.g., a gNB-CU (user plane) or UPF, or both are deployed in a data center), the MPLS, SRv6 information may not be practical to carry across to the separated IP transport network (slice provider). In this case, the source UDP port of the GTP-U can be used to indicate the slice in the IP transport network (slice provider).

3.4. Slice Mapping using UDP Source Port

Communication services offered by 3GPP and the concepts used to provision and manage it are described in [TS.28.530-3GPP]. A brief overview is given here with the intent to describe how it is related to an IP transport slice and the mapping between it and the 3GPP slice. Communication services (e.g., an eMBB service) may be realized in a 3GPP network using one or more slices identified by NSSAI (Network Slice Selection Assistance Information) in the 3GPP control plane. In the 3GPP management plane, the network slice identified by NSSAI is realized in as a Network Slice Subnet (NSS). For example, a slice S-NSSAI is available to a user at different locations (and even PLMNs) and maybe realized in an NSS at that a location. The NSS consists of sets of functions from 5GC and RAN that belong to the NSS. Network interfaces of functions in an NSS may be associated to one or more slice subnets. These relationships are illustrated in Figure 2. From the viewpoint of IP transport slicing and mapping to 3GPP slices, an IP transport network slice is associated to 3GPP core or RAN network functions in a 3GPP Network Slice Subnet (NSS). Thus, it can represent a slice of a transport path for a tenant between two 3GPP user plane functions.


+-------------------+   +-------------------+    +-------------------+
|  Comm. Service A  |   |  Comm. Service B  |    |  Comm. Service C  |
+-----+-------------+   +--+-----+----------+    +--------+----------+
      |     ______________/      |                         \
      |    /                     |                          \
+-----+---+---+          +-------+-----+              +------+------+
|NSSAI = 000A |          |NSSAI = 000B |              |NSSAI = 000C |
+-------^-----+          +------^------+              +------^------+
       /                       /                             |
______/______            _____/_______                 ______|_______
\  Net.Slice \           \  Net.Slice \               | Net.Slice    |
 \  Subnet-A  \           \  Subnet-B  \              | Subnet-C     |
  \ (NSS-A)    \           \   (NSS-B)  \             |   (NSS-C)    |
   \            \           \            \            |              |
    \  +--------+\           \  +--------+\           |  +--------+  |
     \ |NSSI=CN1| \           \ |NSSI=CN1| \          |  |NSSI=CN3|  |
      \+-----\--+  \           \+---\----+  \         |  +---|----+  |
       \      \     \           \    \       \        |      |       |
        \  +===\====+\           \ +==\=====+ \       |  +===|====+  |
         \ |NS = IP1| \           \|NS = IP2|  \      |  |NS = IP3|  |
          \+====\===+  \           +====\===+   \     |  +===|====+  |
           \     \      \           \    \       \    |      |       |
            \  +--\-----+\       +--------\-----------+      |       |
             \ |NSSI=AN1| \      \    \ +--\-----+ \         |       |
              \+--------+  \      \    \|NSSI=AN2+-----------+       |
               \____________\      \    +--------+   \               |
                                    +----\------------\--------------+
                                          +------------+

Figure 2: Slice Configuration

Figure 2 shows the slice hierarchy described in [TS.28.530-3GPP] with 3 communication services enhanced to show the IP transport slice instances (IP1, IP2, IP3). As an example, when a UE registers with 5GC with NSSAI 000A, OOOB and others, the AMF may select NSSAI 000B in list of NSSAI allowed for the UE. One of the factors in selecting the NSSAI is whether the UE may move to another location during the lifetime of the session. In this case, the NSSAI should be such that it has a mapping to IP transport network slice during initial attach, and following handover. For example, a UE that attaches to 5GC with S-NSSAI = 000B and served by user plane instances CN1 and AN2 uses IP transport network slice NS = IP2 to provide the resources in the IP network that correspond to the UE session. Following handover with S-NSSAI = 000B, the UE may be served by user plane instances CN1' and AN2' over an IP slice IP2' in the new location.

When the 3GPP user plane function (5G-AN, UPF) and IP transport provider edge are on different nodes or separated across a network, 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. This is illustrated in Figure 3.

                          upstream GTP-U packet
                    =====================================>

      customer edge     attachment       slice provider     customer edge
                         circuit             ______
     +-------------+      ______          __/      \__     +-------------+
     |   gNB-CU    |   __/      \__      /     IP     \    |     UPF     |
     |N3 IP i/f =  +--/ Data Center\---(PE) Backhaul (PE)--+ N3 IP i/f = |
     |  gNB-AN2-if |  \__ Network__/     \__        __/    |  UPF-CN1-if |
     +-------\-----+     \______/           \___\__/       +-------------+
              \                                  \
               \                                  \
                \                                  \
                 \                       +----------\---------------+
 +----------------\---------------+      |   Slice Mapping:         |
 |+-------------------------+     |      |Match:                    |
 ||3GPP CP Config:          |     |      | src-IP-addr = gNB-AN2-if |
 ||NSSAI = {000B, 000C, ..} |     |      |    src-port = 5678       |
 ||NSSI  = AN2              |     |      |Action:                   |
 |+-------------------------+     |      |   select NS = IP2        |
 |                                |      +--------------------------+
 |+------------------------------+|
 ||Slice Mapping to UPF-CN1-if:  ||
 ||EP_Transport S-NSSAI=000B     ||
 ||logicInterfaceType = UDPSrcPrt||
 ||logicInterfaceId = 5678       ||
 ||ipAddress = UPF-CN1-if        ||
 |+------------------------------+|
 +--------------------------------+

Figure 3: Slice Mapping using UDP source port

Figure 3 shows the configuration and mapping applied to network instances in a 3GPP network slice subnet and corresponding IP transport network instances for sending an upstream GTP packet from gNB-CU (user plane) to UPF. The gNB-CU (user plane) function is in a data center and separated from the IP transport slice provider by an attachment circuit (AC - i.e., the data center network). In this example, a GTP-U packet at gNB-CU (user plane) belonging a UE session with S-NSSAI = 000B (and thus associated to 3GPP and IP transport network instances in the figure for providing slice resources). Since the GTP-U packet belongs to a session with S-NSSAI = 000B, the gNB-CU (UP) maps it to UDP port 5678 in the GTP-U header (outer encapsulation source port). The GTP-U packet is forwarded by the data center network to the PE router at IP backhaul network. The PE matches on GTP-U source IP address and port to select the provisioned slice (NS = IP2). The UPF customer edge may be attached to the PE as shown in the figure or alternatively via a data center network. A similar set of mappings exist for downlink GTP-U, but they do not necessarily use the same resources.

PE routers can thus provision a policy based on the source UDP port number 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 IP network slice 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 slice 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 IP network slice 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 slice encoding mechanism already accounts for this.

4. Transport Network Underlays

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.

4.1. Applicability

  • For different slice types, there maybe correspondingly different transport paths. For example, with 3 different SSTs, there are potentially 3 transport TE paths can be signaled from any node in the transport network. For uplink traffic, the 5G-AN will choose the right underlying TE path of the UPF based on the S-NSSAI the PDU Session belongs to and/or the UDP Source port of the GTP-U encapsulation header. Similarly in the downlink direction matching Transport TE Path of the 5G-AN is chosen based on the S-NSSAI to which the PDU Session belongs. The table below shows a typical mapping:

      +----------------+------------+------------------+-----------------+
      |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 |
      +----------------+------------+------------------+-----------------+


Figure 4: Mapping of Transport Paths on F1-U/N3/N9
  • It is possible to have a single TE Path for multiple input points through a MP2P TE tree structure separate in UL and DL direction.
  • Same set of TE Paths are created uniformly across all needed 5G-ANs and UPFs to allow various mobility scenarios.
  • Any modification of TE parameters of the path, replacement path and deleted path needed to be updated from NSSMF to the relevant ingress points. Same information can be pushed to the NSSF, and/or SMF as needed.
  • TE Paths support for native L2, IPv4 and IPv6 data/user planes with optional TE features are desirable in some network segments. As this is an underlay mechanism it can work with any overlay encapsulation approach including GTP-U as defined currently for F1-U/N3/N9 interface.

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 4 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.

4.2. Transport Network Technologies

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 NSSMF, 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.

5. Acknowledgements

Thanks to Young Lee for discussions on this document including ACTN applicability and relation to NSSMF in the early discussions. Thanks to Sri Gundavelli, Kausik Majumdar, Hannu Flinck, Joel Halpern, Satoru Matsushima and Tianji Jiang who provided detailed feedback on this document.

6. IANA Considerations

This document has no requests for any IANA code point allocations.

7. Security Considerations

This document does not introduce any new security issues.

8. Contributing Authors

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: [email protected]
Luis M. Contreras
Telefonica
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: [email protected]
Xavier De Foy
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal
Canada

Email: [email protected]
Reza Rokui
Ciena

Email: [email protected]

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.

9.2. Informative References

[I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Rodriguez-Natal, A., Carofiglio, G., Auge, J., Muscariello, L., Camarillo, P., and S. Homma, "Optimized Mobile User Plane Solutions for 5G", Work in Progress, Internet-Draft, draft-bogineni-dmm-optimized-mobile-user-plane-01, , <https://datatracker.ietf.org/doc/html/draft-bogineni-dmm-optimized-mobile-user-plane-01>.
[I-D.chunduri-dmm-5g-mobility-with-ppr]
Chunduri, U., Contreras, L. M., Bhaskaran, S., Tantsura, J., and P. Muley, "Transport aware 5G mobility with PPR", Work in Progress, Internet-Draft, draft-chunduri-dmm-5g-mobility-with-ppr-00, , <https://datatracker.ietf.org/doc/html/draft-chunduri-dmm-5g-mobility-with-ppr-00>.
[I-D.chunduri-rtgwg-preferred-path-routing]
Bryant, S., Chunduri, U., and A. Clemm, "Preferred Path Routing Framework", Work in Progress, Internet-Draft, draft-chunduri-rtgwg-preferred-path-routing-03, , <https://datatracker.ietf.org/doc/html/draft-chunduri-rtgwg-preferred-path-routing-03>.
[I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, "User Plane Protocol and Architectural Analysis on 3GPP 5G System", Work in Progress, Internet-Draft, draft-ietf-dmm-5g-uplane-analysis-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-dmm-5g-uplane-analysis-04>.
[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., and D. Voyer, "Segment Routing IPv6 for Mobile User Plane", Work in Progress, Internet-Draft, draft-ietf-dmm-srv6-mobile-uplane-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-dmm-srv6-mobile-uplane-24>.
[I-D.ietf-teas-5g-network-slice-application]
Geng, X., Contreras, L. M., Rokui, R., Dong, J., and I. Bykov, "IETF Network Slice Application in 3GPP 5G End-to-End Network Slice", Work in Progress, Internet-Draft, draft-ietf-teas-5g-network-slice-application-00, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-network-slice-application-00>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, "A Framework for IETF Network Slices", Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-21, , <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-21>.
[ORAN-WG4.CUS-O-RAN]
O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group; Control, User and Synchronization Plane Specification; v2.0.0", .
[RFC3209]
Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, , <https://www.rfc-editor.org/info/rfc3209>.
[RFC8370]
Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and T. Saad, "Techniques to Improve the Scalability of RSVP-TE Deployments", RFC 8370, DOI 10.17487/RFC8370, , <https://www.rfc-editor.org/info/rfc8370>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
[RFC8453]
Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, , <https://www.rfc-editor.org/info/rfc8453>.
[TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.1", .
[TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", .
[TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "Policy and Charging Control System for 5G Framework; Stage 2, 3GPP TS 23.503 v1.0.0", .
[TS.28.530-3GPP]
3rd Generation Partnership Project (3GPP), "Aspects; Management and Orchestration; Concepts, use cases and requirements (Release 17)", .
[TS.28.533-3GPP]
3rd Generation Partnership Project (3GPP), "Management and Orchestration Architecture Framework (Release 15)", .
[TS.28.541-3GPP]
3rd Generation Partnership Project (3GPP), "Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 17)", .
[TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", .
[TS.38.300-3GPP]
3rd Generation Partnership Project (3GPP), "NR; NR and NG-RAN Overall Description; Stage 2; v15.7.0", .
[TS.38.401-3GPP]
3rd Generation Partnership Project (3GPP), "NG-RAN; Architecture description; v15.7.0", .

Authors' Addresses

Uma Chunduri (editor)
Intel Corporation
2191 Laurelwood Rd
Santa Clara, CA 95054
United States of America
John Kaippallimalil (editor)
Futurewei
Sridhar Bhaskaran
Rakuten Symphony
Jeff Tantsura
Microsoft
Praveen Muley
Nokia
440 North Bernardo Ave
Mountain View, CA 94043
United States of America