Mobility-aware Transport Network Slicing for 5G
draft-ietf-dmm-tn-aware-mobility-24
| Document | Type | Active Internet-Draft (dmm WG) | |
|---|---|---|---|
| Authors | Uma Chunduri , John Kaippallimalil , Sridhar Bhaskaran , Jeff Tantsura , Luis M. Contreras | ||
| Last updated | 2026-01-04 (Latest revision 2025-12-04) | ||
| Replaces | draft-clt-dmm-tn-aware-mobility | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Consensus: Waiting for Write-Up | |
| Document shepherd | Satoru Matsushima | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | satoru.matsushima@gmail.com |
draft-ietf-dmm-tn-aware-mobility-24
DMM Working Group U. Chunduri, Ed.
Internet-Draft Intel Corporation
Intended status: Informational J. Kaippallimalil, Ed.
Expires: 7 June 2026 Futurewei
S. Bhaskaran
Starten Systems
J. Tantsura
Nvidia
L.M. Contreras
Telefonica
4 December 2025
Mobility-aware Transport Network Slicing for 5G
draft-ietf-dmm-tn-aware-mobility-24
Abstract
Network 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.
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/.
Chunduri, et al. Expires 7 June 2026 [Page 1]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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 7 June 2026.
Copyright Notice
Copyright (c) 2025 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope of Transport Networks in 5G Slicing . . . . . . . . . . 4
3. Mapping 3GPP Slice to Transport Network Slices . . . . . . . 6
3.1. Mid-haul and Backhaul Transport Networks . . . . . . . . 6
3.2. 3GPP Slice Configuration Overview . . . . . . . . . . . . 7
3.3. Slice Mapping using UDP Source Port Number . . . . . . . 9
4. Transport Network Underlays . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 15
9. Informative References . . . . . . . . . . . . . . . . . . . 16
Appendix A. Abbreviations . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
3GPP architecture for 5G System (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 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
Chunduri, et al. Expires 7 June 2026 [Page 2]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
type communications (HMTC). The slice types list is exemplary and
other slice types can be defined in future.
5G network slicing is defined by the 3GPP [TS.28.530-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 the
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). 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. 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 [I-D.ietf-teas-5g-network-slice-application] and
[I-D.ietf-teas-5g-ns-ip-mpls]. 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
Chunduri, et al. Expires 7 June 2026 [Page 3]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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 ([TS.28.541-3GPP]), Attachment Circuit
(AC) in [RFC9834] YANG model for UDP tunnel bearer in
[I-D.jlu-dmm-udp-tunnel-acaas] 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 [RFC9543]. Section 2 provides an
overview on how IP transport slices apply in a 3GPP context.
Section 3 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 Section 4.
2. Scope of Transport Networks in 5G Slicing
3GPP [TS.28.530-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.
Chunduri, et al. Expires 7 June 2026 [Page 4]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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 -----|
Figure 1: Backhaul and Mid-haul Transport Network for 5G
Figure 1 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
[TS.38.401-3GPP]. 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 [RFC9543]. 5G E2E network slice orchestration
[TS.28.533-3GPP] 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
[TS.29.281-3GPP]. Data in each user's PDU session is mapped to
Chunduri, et al. Expires 7 June 2026 [Page 5]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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 Section 3.3.
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 Section 3.1.
3. Mapping 3GPP Slice to Transport Network Slices
3.1. Mid-haul and Backhaul Transport Networks
As described in Figure 1, 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 [TS.28.541-3GPP]. 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 [TS.23.501-3GPP] and
[TS.23.502-3GPP]. 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 [TS.28.541-3GPP]. However, if the 3GPP network function (slice
Chunduri, et al. Expires 7 June 2026 [Page 6]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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.
3.2. 3GPP Slice Configuration Overview
Communication services in 3GPP and the concepts 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
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 Figure 2. From the viewpoint of IP transport slicing
and mapping to 3GPP slices, an 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.
Chunduri, et al. Expires 7 June 2026 [Page 7]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
+-------------------+ +-------------------+ +------------------+
| 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+-----------+ |
\____________\ \ +--------+ \ |
+----\------------\-------------+
+------------+
Figure 2: Slice Configuration
Chunduri, et al. Expires 7 June 2026 [Page 8]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
Figure 2 shows the slice hierarchy described in [TS.28.530-3GPP] 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 Figure 2 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.
3.3. Slice Mapping using UDP Source Port Number
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 [RFC9543] 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 Figure 3 are only to
illustrate the concepts in the use of YANG model extensions for layer
3 GTP bearers in [I-D.jlu-dmm-udp-tunnel-acaas]. 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
[RFC9543] slice characteristics as shown in Section 4. 3GPP user
plane nodes (gNB, UPF) are provisioned with GTP transport interface
information parameters in [TS.28.541-3GPP]. Each EP_Transport (a
logical transport interface in 5G user plane entities) is configured
with an ATTACHMENT_CIRCUIT containing UDP source port number/range
Chunduri, et al. Expires 7 June 2026 [Page 9]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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
[I-D.jlu-dmm-udp-tunnel-acaas] and inherits the attachment circuit in
[RFC9834].
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 Figure 3.
Chunduri, et al. Expires 7 June 2026 [Page 10]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
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: 192.0.2.2/30 |
| - Routing: static 198.51.100.0/24 via |
| 192.9.2.1 tag primary_UP_slice |
+-----------------------------------------------+
Figure 3: Slice Mapping using UDP source port
Chunduri, et al. Expires 7 June 2026 [Page 11]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
Figure 3 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 Figure 3). The AC ("ac1") is for an EP_Transport configured as
specified in [TS.28.541-3GPP] and realized using [RFC9834] and
related extensions for GTP (UDP tunnel) in
[I-D.jlu-dmm-udp-tunnel-acaas].
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 Figure 3 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
Chunduri, et al. Expires 7 June 2026 [Page 12]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
as an entropy field for load balancing, copying it to the outer UDP
source port number would preserve this as intended for load balancing
[RFC8085], section 5.1.1. UDP source port and ranges in Figure 4
allow for slice selection at the PE when the UDP source port is also
used for load balancing.
4. Transport Network Underlays
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 Figure 1.
This section outlines how GTP/UDP source ports are used to map to
slice types. [RFC9543], 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.
Chunduri, et al. Expires 7 June 2026 [Page 13]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
+----------------+------------+-----------------+-----------------+
|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: Bx |
| | | | Delay: Dx |
| | | | Jitter: Jx |
+----------------+------------+-----------------+-----------------+
|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
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
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.
There are many possible TN technologies that may be used to realize
these slices. These are described in [RFC9543].
5. Acknowledgements
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.
Chunduri, et al. Expires 7 June 2026 [Page 14]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
6. Security Considerations
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
[I-D.jlu-dmm-udp-tunnel-acaas] and [RFC9834].
Section 3 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
[RFC9543].
7. IANA Considerations
This document has no requests for IANA code point allocations.
8. Contributing Authors
The following people contributed substantially to the content of this
document and should be considered co-authors.
Praveen Muley
Nokia
440 North Bernardo Ave
Mountain View CA 94043
USA
Email: praveen.muley@nokia.com
Richard Li
Independent
Email: richard.li@seu.edu.cn
Xavier De Foy
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
Reza Rokui
Ciena
Email: rrokui@ciena.com
Chunduri, et al. Expires 7 June 2026 [Page 15]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
9. Informative References
[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-05, 7 July
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
teas-5g-network-slice-application-05>.
[I-D.ietf-teas-5g-ns-ip-mpls]
Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M.,
and L. M. Contreras, "A Realization of Network Slices for
5G Networks Using Current IP/MPLS Technologies", Work in
Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls-
18, 3 April 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-teas-5g-ns-ip-mpls-18>.
[I-D.jlu-dmm-udp-tunnel-acaas]
Kaippallimalil, J., Contreras, L. M., and U. Chunduri, "A
YANG Data Model for Attachment Circuit as a Service with
UDP Tunnel Support", Work in Progress, Internet-Draft,
draft-jlu-dmm-udp-tunnel-acaas-01, 6 October 2025,
<https://datatracker.ietf.org/doc/html/draft-jlu-dmm-udp-
tunnel-acaas-01>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S.,
Makhijani, K., Contreras, L., and J. Tantsura, "A
Framework for Network Slices in Networks Built from IETF
Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024,
<https://www.rfc-editor.org/info/rfc9543>.
[RFC9834] Boucadair, M., Ed., Roberts, R., Ed., Gonzalez de Dios,
O., Barguil, S., and B. Wu, "YANG Data Models for Bearers
and Attachment Circuits as a Service (ACaaS)", RFC 9834,
DOI 10.17487/RFC9834, September 2025,
<https://www.rfc-editor.org/info/rfc9834>.
[TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "System
Architecture for 5G System; Stage 2, 3GPP TS 23.501
v2.0.1", December 2017.
Chunduri, et al. Expires 7 June 2026 [Page 16]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
[TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "Procedures for
5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December
2017.
[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", December 2017.
[TS.28.530-3GPP]
3rd Generation Partnership Project (3GPP), "Aspects;
Management and Orchestration; Concepts, use cases and
requirements (Release 17)", June 2022.
[TS.28.533-3GPP]
3rd Generation Partnership Project (3GPP), "Management and
Orchestration Architecture Framework (Release 15)", June
2018.
[TS.28.541-3GPP]
3rd Generation Partnership Project (3GPP), "Management and
orchestration; 5G Network Resource Model (NRM); Stage 2
and stage 3 (Release 19)", July 2024.
[TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "GPRS Tunneling
Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v19.2.0",
September 2025.
[TS.38.300-3GPP]
3rd Generation Partnership Project (3GPP), "NR; NR and NG-
RAN Overall Description; Stage 2; v15.7.0", September
2019.
[TS.38.401-3GPP]
3rd Generation Partnership Project (3GPP), "NG-RAN;
Architecture description; v15.7.0", September 2019.
Appendix A. Abbreviations
5G-AN – 5G Access Network
5GS – 5G System
AC – Attachment Circuit
CSR – Cell Site Router
Chunduri, et al. Expires 7 June 2026 [Page 17]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
CP – Control Plane (5G)
CU – Centralized Unit (5G, gNB)
DN – Data Network (5G)
DU – Distributed Unit (5G, gNB)
eMBB – enhanced Mobile Broadband (5G)
gNB – Next Generation Node B
GBR – Guaranteed Bit Rate (5G)
GTP-U – GPRS Tunneling Protocol - User plane (3GPP)
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
NSS – Network Slice Subnet
NSSAI – Network Slice Selection Assistance Information
NSSI – Network Slice Subnet Identifier
NSSF – Network Slice Selection Function
PDU – Protocol Data Unit (5G)
PW – Pseudo Wire
SDP – Service Demarcation Point
S-NSSAI – Single Network Slice Selection Assistance Information
SD – Slice Differentiator (5G)
SST – Slice and Service Types (5G)
SR – Segment Routing
TE – Traffic Engineering
Chunduri, et al. Expires 7 June 2026 [Page 18]
Internet-Draft Mobility-aware Transport Network Slicing December 2025
UP – User Plane(5G)
UPF – User Plane Function (5G)
URLLC – Ultra reliable and low latency communications (5G)
Authors' Addresses
Uma Chunduri (editor)
Intel Corporation
2191 Laurelwood Rd
Santa Clara, CA 95054
United States of America
Email: umac.ietf@gmail.com
John Kaippallimalil (editor)
Futurewei
United States of America
Email: john.kaippallimalil@futurewei.com
Sridhar Bhaskaran
Starten Systems
India
Email: sbhaskaran@startensystems.com
Jeff Tantsura
Nvidia
United States of America
Email: jefftant.ietf@gmail.com
Luis M. Contreras
Telefonica
Telefonica Sur-3 building, 3rd floor
28050 Madrid
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Chunduri, et al. Expires 7 June 2026 [Page 19]