Mobility-aware Transport Network Slicing for 5GIntel Corporation2191 Laurelwood RdSanta ClaraCA95054USAumac.ietf@gmail.comFutureweiUSAjohn.kaippallimalil@futurewei.comStarten SystemsIndiasbhaskaran@startensystems.comNvidiaUSAjefftant.ietf@gmail.comTelefonicaTelefonica Sur-3 building, 3rd floorMadrid28050Spainluismiguel.contrerasmurillo@telefonica.com
Internet
DMM Working Groupnetwork slicingNetwork slicing in 5G enables 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 infrastructure and services,
user's data plane packets over the Radio Access Network (RAN) and Core Network (5GC)
use IP in many segments of an end-to-end 5G slice.
When end-to-end slices in a 5G System use network resources,
they are mapped to corresponding Transport Network (TN) slice(s) which in turn provide the bandwidth,
latency, isolation, and other criteria required for the realization of a 5G slice.This document describes mapping of 5G slices to TN slices using UDP source port number of the GTP-U bearer
when the TN slice provider is separated by an "attachment circuit" from the networks in which the 5G network functions
are deployed, for example, 5G functions that are distributed across data centers.
The slice mapping defined here is supported transparently when a 5G user device moves across 5G attachment points and session
anchors.3GPP architecture for 5G System (5GS) in , and
for 5GC (5G Core), and the NG-RAN architecture defined in
and describe slicing as one of the
capabilities for the communication services that 5G systems provide.
Slice types defined by the 3GPP include
enhanced mobile broadband (eMBB) communications, ultra-reliable low latency
communications (URLLC), massive internet of things (MIoT) and vehicle-to-X (V2X) and high-performance
machine type communications (HMTC).
The slice types list is illustrative and other slice types can be defined in future.5G network slicing is defined by the 3GPP as an approach,
"where logical networks/partitions are created, with appropriate isolation,
resources, and optimized topology to serve a purpose or service category
(e.g. use case/traffic category, or for MNO internal reasons) or customers
logical system created "on-demand".
A 5G slice instance requested by an end-user is realized by a 5G network slice subnet (NSS) which is a
collection of network functions across RAN and 5GC that make up the 5G slice.
However, the capabilities of TN slices and slice characteristics for
QoS, hard /soft isolation, protection and other aspects are out of scope of 3GPP standards.TN slices in this document can be used to realize slices between 3GPP control plane NFs or for a UE's user plane.
For realizing control plane slicing, the TN slice is deployed along the interface between two 3GPP NFs and this
is not considered further in this document.
User plane 5G slice for each user's Protocol Data Unit (PDU) session is mapped to corresponding TN slices and is the focus of this document.
A PDU session in 5G is a logical connection that provides a path between a User Equipment (UE)
and a data network such as internet.
Since the 3GPP Single Network Slice Selection Assistance Information (S-NSSAI) is not visible to TNs,
the source UDP port number of the GTP-U (or UDP encapsulated GTP) bearer is used to convey a mapping to the TN slices
on each 3GPP interface (i.e., F-U, N3, N9).
The source port space (~2^16) for mapping slices is more than sufficient for any realistic deployment scenario.
The number of slices is likely to be far fewer than the source port space available as each slice involves significant
configuration to setup and manage.
Following UE handover, the S-NSSAI is mapped seamlessly to the corresponding GTP-U (or UDP encapsulated GTP) source port number
of the newly attached network and can be considered to be "mobility aware".
Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port number is useful
when the 3GPP network function and PE for TN slice are in different IP subnets,
and using IP source address instead would require far more configuration.
Slice mapping using UDP source port numbers may be used in TN of public or private 3GPP networks.A TN slice across 3GPP interfaces may use multiple technologies or network providers.
In practice, the orchestration and architecture may not be monolithic or uniform.
For example, there may be distinct connectivity domains including Data Centers, Public Cloud, Wide Area Networks, and
different orchestration entities.
Several network scenarios and mechanisms to map 3GPP and IETF network slices are
found in and .
Unlike mapping of a fronthaul 3GPP slice to a TN slice, TN slice(s) for 3GPP backhaul (F1-U/N3/N9)
corresponds to slice characteristics of the UE session during initial setup (user initiates 3GPP connectivity session)
and following UE mobility.
For example, a UE served by the 3GPP system for high throughput, low latency service and related 3GPP slice
should be mapped to a TN slice that provides the corresponding characteristics even after handover.
This document defines a mechanism where the source UDP port number of a layer 3 GTP bearer (or UDP encapsulated GTP)
is used to map a 3GPP slice to the TN slice at the Provider Edge (PE).
3GPP slice management (), Attachment Circuit (AC) in
YANG model for UDP tunnel bearer in
provide the basis for the necessary mapping.
It is not the purpose of this document to standardize or constrain the implementation
of slicing or user plane functionality in 3GPP.This document describes a potential way to map user plane packets of a 3GPP PDU session
identified by a 3GPP slice (S-NSSAI) to an IETF Network Slice Service as defined in .
provides an overview on how IP transport slices apply in a 3GPP context.
describes how to map a 3GPP slice to a TN slice at a provider edge.
UDP source port ranges in TN underlays for slice mapping is
described in .3GPP discusses TN in the context of network slice subnets,
but does not specify further details.
This section provides an overview of the processes to provision and map 5G slices in
backhaul and mid-haul network segments with GTP-U (UDP) source port number.
5G Control and Management Planes
+------------------------------------------------------------------+
| +---------------------------------------------------------------+|
| | 5G E2E Network Slice Orchestrator ||
| +---+-------------+-------------+---------------+-----------+---+|
| | | | | | |
| +---+--+ | F1-C +----+-----+ | N2 +----+---+|
| | |---------(---------|gNB-CU(CP)|--------(-------| 5GC CP ||
| | | | +----+-----+ | +----+---+|
+-| |----------|-------------|---------------|-----------|----+
| | | | | |
| | +---V---+ | +---V---+ |
| | | IETF | | | IETF | |
|gNB-DU| | NSC | E1 | NSC | |
| | +---+---+ | +---+---+ |
| | | | | |
| | __ V__ | ___V__ |
| | __/ \__ +--+---+ __/ \__ +-+-+
| | / IP/L2 \ | gNB | / IP \ | |
UE-+ +-(PE) Mid-haul (PE)--+CU(UP)+--(PE) Backhaul(PE)--+UPF+-DN
+------+ \__ __/ +------+ \__ __/ +---+
\______/ \______/
|------ F1-U ------| |----- N3 or N9 -----|
depicts a 5G System (5GS) in which a gNB is split into a gNB-CU-CP,
multiple gNB-CU-UPs and multiple gNB-DUs, as described in .
In addition, the figure is expanded to show the IP transport and PE (Provider Edge) providing IP transport
service to 5GS user plane entities 5G-AN (e.g., gNB) and UPF.
Each PE hosts the Service Demarcation Points (SDPs) to the TN slice provider.
The IETF Network Slice Controller (NSC) interfaces with the 3GPP network (customer network) that requests
for TN slices (IETF network slice).
The 5G management plane in turn requests the Network Slice Controller (NSC) to setup
resources and connectivity for the network slice as defined in .
5G E2E network slice orchestration is used to manage the life cycle of 5G E2E network slice
across RAN, TN and core network.In this architecture, end-to-end user plane connectivity between the UE and a specific Data Network (DN)
is supported by the F1-U interface (between gNB-DU and gNB-CU-UP), the N3 interface
between the gNB-CU-UP and the UPF, and the N9 interface between UPFs in the core network.
Over these interfaces, GTP-U is used to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured) as specified in
.
Data in each user's PDU session is mapped to corresponding TN slices across N3/N9/F1-U interfaces
based on the 5G slice requirements.
Multiple UEs traffic (e.g., eMBB) at a location that have the same requirements may use a TN slice.
3GPP network functions (i.e., gNB-DU, gNB-CU and UPF) may however be distributed (e.g., across multiple data centers)
and therefore require multiple TN slices across the respective interfaces.
The TN PE does not consider 5QI in the DSCP or GTP-U header for mapping the 5G slice.
3GPP QoS with 5QI and corresponding DSCP mapping can be applied to traffic flows
in PDU sessions in the slice independently.
Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port number is described in .The gNB-DU can also be split into two entities (O-RU and O-DU) as defined by O-RAN Alliance
and therefore the user plane includes the fronthaul interface between O-RU and O-DU.
However, as this interface does not rely on GTP-U to transport UE PDU,
the fronthaul interface is out of scope of this document.
Mid-haul and backhaul are described further in .As described in , 3GPP functions gNB-CU (user plane) and gNB-DU
may 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 .
However, if the 3GPP network function (slice customer) is physically separated from the TN slice provider
(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 TN slice provider.
In this case, the source UDP port number of the GTP-U can be used to indicate the
slice in the TN slice provider.The backhaul transport over which the protocols for N3 and N9 interfaces run are described in
and .
The PDU session is carried over the radio network, and GTP-U transport protocol across N3 and N9 interfaces to the data network.
GTP-U between the 3GPP network functions (gNB, UPF) serves as an overlay protocol across one or more MPLS, SRv6 or Ethernet
TNs in between.
During UE session setup, a number of parameters for context management are configured in the gNB, UPF and that includes
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 .
However, if the 3GPP network function (slice customer) is physically separated from the TN slice provider
(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 TN slice provider.
In this case, the source UDP port number of the GTP-U can be used to indicate the slice in the TN slice provider.
Communication services in 3GPP and the concepts to provision and manage it
are described in .
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 signaling.
In the 3GPP management plane, the network slice identified by NSSAI is realized in
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 location.
An 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 .
From the viewpoint of IP transport slicing and mapping to 3GPP slices, a TN 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=0x02:0x0A| |NSSAI=0x01:0x00| |NSSAI=0x03:0x0C|
+-------^-------+ +-------^-------+ +--------^------+
/ / |
______/______ _______/_____ ______|______
\ 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 = TS1| \ \|NS = TS2| \ | |NS = TS3| |
\+====\===+ \ +====\===+ \ | +===|====+ |
\ \ \ \ \ \ | | |
\ +--\-----+\ +--------\-----------+ | |
\ |NSSI=AN1| \ \ \ +--\-----+ \ | |
\+--------+ \ \ \|NSSI=AN2+-----------+ |
\____________\ \ +--------+ \ |
+----\------------\-------------+
+------------+
shows the slice hierarchy
described in with 3 communication services enhanced to
show the IP transport slice instances (TS1, TS2, TS3).
NSSAI consists of an 8 bit Slice/Service Type (SST) and a 24 bit Slice Differentiator (SD)
and is represented in as SST(8):SD(24).
As an example, when a UE registers with 5GC with NSSAI 0x02:0x0A, 0x01:0x00, 0x03:0x0C or others,
5GC may allow NSSAI 0x01:0x00 in list of NSSAI for the UE based on the request from
the UE and other factors in the network.
Another factor 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 TN slice
during initial attach, and following handover.
For example, a UE that attaches to 5GC with S-NSSAI = 0x01:0x00 and served by user plane
instances CN1 and AN2 uses TN slice NS = TS2 to provide the resources
in the IP network that corresponds to the UE session.
Following handover with S-NSSAI = 0x01:0x00, the UE may be served by
user plane instances CN1' and AN2' over an IP slice TS2' in the new location.When a 3GPP user plane function (5G-AN, UPF) and IP transport PE 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 terminology, this is a
scenario where there is an AC between the 3GPP entity (customer edge)
and the SDP (Service Demarcation Point) in the TN (provider edge).
The AC is provisioned between a 3GPP user plane node (i.e., gNB, UPF) in,
for example, a data center, to a PE router
that serves as the service demarcation point for the TN slice.
The following paragraphs provide an outline of operations in a 5G system prior to PDU session setup,
and during PDU session setup in mapping 3GPP slice to IETF transport slice.
It should be noted that outlines of 3GPP procedures below and data structures in
are only to illustrate the concepts in the use of YANG model extensions for layer 3 GTP bearers
in .
It is not the purpose of this document to standardize or otherwise constrain the implementation
of slicing and user plane functionality in 3GPP.Prior to PDU session setup, the TN and 3GPP user plane nodes
are provisioned with the necessary information for mapping the slices.
The PE router in TN is provisioned to map all packets arriving on
a layer 3 attachment circuit (the outer header carrying the GTP-U tunnel), i.e., a UDP source port number/range to
corresponding slice characteristics as shown in .
3GPP user plane nodes (gNB, UPF) are provisioned with GTP transport interface
information parameters in .
Each EP_Transport (a logical transport interface in 5G user plane entities) is configured with
an ATTACHMENT_CIRCUIT containing UDP source port number/range
for each of the slices (S-NSSAI) supported by the 3GPP user plane node.
"ATTACHMENT_CIRCUIT" is one of the enumerated options in connectionPointId (externalEndPointRefList)
attribute in EP_Transport.
The YANG model for the layer 3 GTP bearer (UDP tunnel with source port number/range)
is defined in and inherits the attachment circuit in
.During PDU session setup, the 5G control plane configures parameters to setup the
user plane for the UE's PDU session across F1-U, N3 and N9 interfaces.
One of parameters configured by the 5G control plane is the S-NSSAI.
Data packets of the PDU session can be associated to the EP_Transport /S-NSSAI configured
in the user plane entities for forwarding.
The ATTACHMENT_CIRCUIT for the per S-NSSAI EP_Transport interface has UDP source port number/range
which is used when forwarding a GTP-U packet belonging to the PDU session.
The 3GPP user plane node can now associate the provisioned slice and EP_transport
to the S-NSSAI signaled for the PDU session.An example is shown in .
upstream GTP-U packet
=====================================>
customer edge attachment slice provider customer edge
circuit "ac1" ______
+-------------+ ______ __/ \__ +-----------+
| 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: | | | vlan-id = 100 |
||NSSI = AN2 | | | src-port = 5678|
|+--------------------------+ | |Action: |
|+-----------------------------+| | select NS = TS2 |
||Slice Mapping to UPF-CN1-if: || +-------------------+
|| S-NSSAI=0x01:0x00 ||
|| EP_Transport: ||
|| - ipAddress = UPF-CN1-if ||
|| - connectionPointIDType = ||
|| "ATTACHMENT_CIRCUIT" ||
|| - connectionPointId = "ac1"--------+
|+-----------------------------+| |
+-------------------------------+ |
V
+-----------------------------------------------+
| * "ac1" properties: |
| - vlan-id: 100 |
| - src-port = 5678 |
| - CE address (gNB-CU): gNB-AN2-if |
| - PE address: 203.0.113.0/24 |
+-----------------------------------------------+
shows the configuration and mapping applied to
network instances in a 3GPP network slice subnet and corresponding TN 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 (site 1) and separated from the IP transport slice provider by
an AC ("ac1" in ).
The AC ("ac1") is for an EP_Transport configured as
specified in and realized using
and related extensions
for GTP (UDP tunnel) in .In this example, a GTP-U packet at gNB-CU (user plane) is from a UE session with S-NSSAI = 0x01:0x00
and to be forwarded to UPF-CN1 (i.e., as already setup by SMF during PDU session establishment).
The associated 3GPP and TN instances in the figure provide mapping to slice resources.
The gNB-CU (UP) uses the slice mapping to "ac1" shown in
when forwarding the GTP-U packet to UPF-CN1-if with source address of gNB-AN2-if and
UDP source port number 5678 (GTP-U /UDP outer encapsulation source port).
The slice mapping proposed in this document does not depend on VLANs, however, this example is to
illustrate that the UDP mapping can be used in conjunction with other AC properties.
The GTP-U packet is forwarded by the data center network to the PE router at IP backhaul network.
The PE matches on VLAN ID of GTP-U packet and IP source port to select the provisioned slice (NS = TS2).
The GTP-U packet is then forwarded to the UPF.
For a downstream GTP-U packet, the UPF customer edge may similarly be attached to a PE and have similar
slice configuration and mapping (details are not shown in the figure).
PEs can thus be provisioned with a policy based on the source UDP port number (and other identifiers like VLAN)
to the underlying transport path and then deliver the QoS/slice resource provisioned in the TN.
The source UDP port number 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 number 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 number 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 IPsec secured GTP-U packet should be UDP encapsulated and the GTP-U source port number copied
to the outer UDP encapsulation source port number for the PE to select the slice.
When GTP-U packets use the source port number as an entropy field for load balancing, copying it to the outer
UDP source port number would preserve this as intended for load balancing , section 5.1.1.
UDP source port and ranges in allow for slice selection at the PE
when the UDP source port is also used for load balancing.
Traffic engineered underlay networks are an essential component to realize the slicing defined in this document.
TNs should be able to realize midhaul, backhaul and control plane slices shown in .
This section outlines how GTP/UDP source ports are used to map to slice types.
, section 7 describes in more detail how a network slice can be realized
over different TN technologies including enhanced VPN, IP/MPLS and SR-TE.An example with different user plane slice types and transport paths is shown in the figure.
In this case with 3 different 3GPP Slice and Service Types (SSTs), 3 transport TE paths are setup.
For uplink traffic, an underlying TE transport path may be from a gNB-CU to a UPF for example.
A similar downlink path and underlying transport from UPF to gNB-CU is configured.
The figure shows UDP port ranges, SST, transport path (in this example pseudowire/VPN) and transport path characteristics.In some E2E scenarios, additional path characteristics with finer granularity may be desired
in the underlying TN, such as for security.
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 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.There are many possible TN technologies that may be used to realize these slices.
These are described in .Thanks to Young Lee for discussions on this document including 3GPP and IETF slice orchestration 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.
Lionel Morand's suggestion to revise the UDP tunnel aspects to be applicable to not just GTPU
but also other encapsulations like ESP-UDP makes this document more broadly applicable.This document specifies the use of UDP source port to identify a (customer) 3GPP slice at the TN
provider edge (PE).
The YANG model should conform to security constraints described in
and . describes the configuration and management of slices that may be deployed with
3GPP nodes or PE nodes that are not in the trusted operator boundary.
To avoid spoofing and other attacks, security mechanisms with ACLs and IPsec must be deployed.
The configuration and management procedures here should conform to security
constraints for slice authentication, isolation, data confidentiality and integrity, and privacy
described in section 10 of .This document has no requests for IANA code point allocations.The following people contributed substantially to the content of this
document and should be considered co-authors. System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v2.0.13rd Generation Partnership Project (3GPP)Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.03rd Generation Partnership Project (3GPP)Policy and Charging Control System for 5G Framework; Stage 2, 3GPP TS 23.503 v1.0.03rd Generation Partnership Project (3GPP)Aspects; Management and Orchestration; Concepts, use cases and requirements (Release 17)3rd Generation Partnership Project (3GPP)Management and Orchestration Architecture Framework (Release 15)3rd Generation Partnership Project (3GPP)Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3 (Release 19)
3rd Generation Partnership Project (3GPP)GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v19.2.03rd Generation Partnership Project (3GPP)NR; NR and NG-RAN Overall Description; Stage 2; v15.7.03rd Generation Partnership Project (3GPP)NG-RAN; Architecture description; v15.7.03rd Generation Partnership Project (3GPP)5G Access Network5G SystemAttachment CircuitCell Site RouterControl Plane (5G)Centralized Unit (5G, gNB)Data Network (5G)Distributed Unit (5G, gNB)enhanced Mobile Broadband (5G)Next Generation Node BGuaranteed Bit Rate (5G)GPRS Tunneling Protocol - User plane (3GPP)Massive IoT (5G)Multi Protocol Label SwitchingNext Generation Radio Access Network (i.e., gNB, NG-eNB - RAN functions which connect to 5GC)Network Slice ControllerNetwork Slice SubnetNetwork Slice Selection Assistance InformationNetwork Slice Subnet IdentifierNetwork Slice Selection FunctionProtocol Data Unit (5G) PseudowireService Demarcation PointSingle Network Slice Selection Assistance InformationSlice Differentiator (5G)Slice and Service Types (5G)Segment RoutingTraffic EngineeringUser Plane(5G)User Plane Function (5G)Ultra reliable and low latency communications (5G)