Mapping 5G slice to Transport Network slice with UDP Source Ports
draft-ietf-dmm-tn-aware-mobility-32

DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                         Intel Corporation
Intended status: Informational                    J. Kaippallimalil, Ed.
Expires: 20 February 2027                                      Futurewei
                                                            S. Bhaskaran
                                                         Starten Systems
                                                             J. Tantsura
                                                                  Nvidia
                                                          L.M. Contreras
                                                              Telefonica
                                                          19 August 2026

   Mapping 5G slice to Transport Network slice with UDP Source Ports
                  draft-ietf-dmm-tn-aware-mobility-32

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 20 February 2027                [Page 1]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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 20 February 2027.

Copyright Notice

   Copyright (c) 2026 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 . . . . . . . . . . . . . . . . . . . . .  16
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  16
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Appendix A.  Abbreviations  . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

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-

Chunduri, et al.        Expires 20 February 2027                [Page 2]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   reliable low latency communications (URLLC), massive internet of
   things (MIoT) and vehicle-to-X (V2X) and high-performance machine
   type communications (HMTC).

   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 Transport Network (TN) slices and slice
   characteristics for QoS, hard /soft isolation, protection and other
   aspects are out of scope of 3GPP standards.  Readers should refer to
   Section 3.2 of [RFC9889] for positioning 5G Network Slicing versus
   Transport Network Slicing.

   TN slices in this document can be used to realize slices between 3GPP
   control plane Network Functions (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 [RFC768] encapsulated GTP)
   bearer is used to convey a mapping to the TN slices on each 3GPP
   interface (i.e., F1-U, N3, N9).  The Dynamic Ports range,
   49152-65535, is set aside for local and dynamic use by [RFC6335].  A
   deployment can provision values or sub-ranges from this space for the
   mechanism described here.  The number of slices is likely to be far
   fewer than the source port space available as each slice involves
   significant configuration to set up 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.  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 different 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

Chunduri, et al.        Expires 20 February 2027                [Page 3]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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].  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 ([TS.28.541-3GPP]),
   Attachment Circuit (AC) in [RFC9834] YANG data model for UDP tunnel
   bearer in [I-D.ietf-dmm-udp-tunnel-acaas-extn] 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 20 February 2027                [Page 4]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

                      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 (Next Generation
   Node B) is split into a gNB-CU-CP (gNB Centralized Unit-Control
   Plane), multiple gNB-CU-UPs (gNB Centralized Unit-User Plane) and
   multiple gNB-DUs (gNB Distributed Unit), 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 set up 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.  TN slices configuration via
   the control plane (i.e., 5G E2E Network Slice Orchestrator, IETF NSC)
   should be within a limited domain [RFC8799].  The TN slice provider
   and the 3GPP operator enforce a strict boundary so that the source
   UDP port numbers and other configuration metadata that correspond to
   slices stay within this limited domain.

Chunduri, et al.        Expires 20 February 2027                [Page 5]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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
   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 DiffServ Code Point (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 source UDP port
   numbers that map between a 3GPP slice and TN slice are only exchanged
   within the user (data) plane of the limited domain [RFC8799] between
   3GPP operator and TN slice provider to avoid metadata leakage.

   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,

Chunduri, et al.        Expires 20 February 2027                [Page 6]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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 [IEEE802.1Q].  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 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 may be 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, 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.

Chunduri, et al.        Expires 20 February 2027                [Page 7]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   +-------------------+   +-------------------+    +------------------+
   |  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 20 February 2027                [Page 8]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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 data model extensions for
   layer 3 GTP bearers in [I-D.ietf-dmm-udp-tunnel-acaas-extn].  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

Chunduri, et al.        Expires 20 February 2027                [Page 9]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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 data model for the layer 3 GTP bearer (UDP
   tunnel with source port number/range) is defined in
   [I-D.ietf-dmm-udp-tunnel-acaas-extn] and inherits the attachment
   circuit in [RFC9834].  Isolation correctness depends on consistent
   CE-and-PE provisioning via the YANG data model.  Misconfiguration or
   NSC/management-plane compromise yields cross-tenant slice
   misassignment.

   During PDU session setup, the 5G control plane configures parameters
   to set up 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.  PE ingress
   filtering binds {AC /CE source address /VLAN} to a permitted source-
   port range within the subscribed/provisioned limits for each slice
   per 3GPP operator and drops mismatches or out of bound TN slice usage
   to prevent oversubscribing or stealing of premium TN slice resources.

   An example is shown in Figure 3.

Chunduri, et al.        Expires 20 February 2027               [Page 10]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

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

       Note: VLAN (vlan-id) is only illustrative.

               Figure 3: Slice Mapping using UDP source port

Chunduri, et al.        Expires 20 February 2027               [Page 11]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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.ietf-dmm-udp-tunnel-acaas-extn].

   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 UDP 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 slice selector is encoded in the Source Port field of
   the UDP header that carries the GTP-U PDU.  The encapsulated UE
   payload is not modified.  The encapsulating node selects the source-
   port value before calculating the UDP checksum, so no post-
   encapsulation rewrite is required.  MTU and fragmentation for GTP-U
   tunneling can continue to use procedures in 3GPP that configure
   Maximum Transmission Unit (MTU) sizes via Protocol Configuration
   Options (PCO) during connectivity session setup.  Reserved UDP ports
   or port 0 can trigger unexpected behavior in some systems and should
   not be used.

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

Chunduri, et al.        Expires 20 February 2027               [Page 12]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   - adds an outer IP header in both Authentication Header (AH) and
   Encapsulating Security Payload (ESP) modes and [RFC8221] says that
   ESP is preferred.  Many inter and intra-operator scenarios do not
   have NATs on the path between 3GPP SEGs (Security Gateways).  IPsec
   encapsulated GTP-U packets and slice information in outer UDP source
   ports can be used in these cases.  However, this method cannot be
   used as such in scenarios (e.g. mobile virtual network operators)
   where NATs may be on path, as [RFC3948] mandates setting source and
   destination ports to 4500.  Adding mechanisms for UDP port diversity
   in IPsec/NAT (Network Address Translation) scenarios is beyond the
   scope of this document and may be addressed in other future work.
   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 [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 [RFC4364], IP/MPLS [RFC5462] and SR-TE
   [RFC9256].

   An example with different user plane slice types and transport paths
   is shown in Figure 4.  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.  Figure 4 shows UDP port ranges,
   SST, transport path (in this example pseudowire/VPN) and transport
   path characteristics.

Chunduri, et al.        Expires 20 February 2027               [Page 13]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

    +----------------+------------+-----------------+-----------------+
    |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 20 February 2027               [Page 14]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

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 data
   model should conform to security constraints described in
   [I-D.ietf-dmm-udp-tunnel-acaas-extn] and [RFC9834].  Isolation
   correctness depends on consistent CE-and-PE provisioning via the YANG
   data model.  Misconfiguration or NSC/management-plane compromise
   yields cross-tenant slice misassignment.

   Section 3 describes the configuration and management of slices that
   may be deployed with 3GPP nodes and TN nodes across 3GPP operator and
   TN provider.  Slice selection, and hence resource allocation and
   isolation, hinges entirely on the UDP source port.  To avoid leakage
   of metadata outside the boundaries of the limited domain ([RFC8799])
   of 3GPP operator (CE) and TN provider (PE), the exchange of UDP
   source port number over the management and data plane should remain
   within the limited domain.  Since the slice selector (UDP source
   port) is sent in the clear, segments can be targeted and traffic
   analysis is possible if this information is available to entities
   outside the limited domain.

   A TN slice provider (PE) may serve more than one 3GPP (or other) CE.
   The PE ingress filtering is necessary to bind {AC /CE source address
   /VLAN} to a permitted source port range and within the subscribed/
   provisioned limits for each slice/3GPP operator.  This is necessary
   to prevent any party from injecting or rewriting packets on the CE to
   PE path, and thus avoid stealing of premium slice resources or
   oversubscribing and starving a slice.

   The use of UDP source port field for slice mapping has side effects
   including spoofing that are outlined in [RFC8085], section 5.1.1.  To
   mitigate spoofing and other attacks, security mechanisms with ACLs
   and IPsec must be deployed.  Overloading the source port as both ECMP
   entropy and slice selector forces range-based (coarser) validation at
   the PE, widening the spoofing surface and constraining entropy.
   Standard ESP-in-UDP in [RFC3948] fixes both source and destination
   ports to 4500 for NAT traversal and this method which requires UDP
   port diversity cannot be used when there are NATs on path.

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

Chunduri, et al.        Expires 20 February 2027               [Page 15]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

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

9.  References

9.1.  Normative References

   [I-D.ietf-dmm-udp-tunnel-acaas-extn]
              Kaippallimalil, J., Contreras, L. M., and U. Chunduri, "A
              YANG Data Model Extension for Attachment Circuit as a
              Service with UDP Tunnel Support", Work in Progress,
              Internet-Draft, draft-ietf-dmm-udp-tunnel-acaas-extn-01,
              19 July 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dmm-udp-tunnel-acaas-extn-01>.

Chunduri, et al.        Expires 20 February 2027               [Page 16]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   [IEEE802.1Q]
              Institute of Electrical and Electronics Engineers (IEEE),
              "IEEE Standard for Local and Metropolitan Area Networks -
              Bridges and Bridged Networks", December 2022.

   [RFC3948]  Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets",
              RFC 3948, DOI 10.17487/RFC3948, January 2005,
              <https://www.rfc-editor.org/info/rfc3948>.

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

   [RFC9889]  Szarkowicz, K., Ed., Roberts, R., Ed., Lucek, J.,
              Boucadair, M., Ed., and LM. Contreras, "A Realization of
              Network Slices for 5G Networks Using Current IP/MPLS
              Technologies", RFC 9889, DOI 10.17487/RFC9889, November
              2025, <https://www.rfc-editor.org/info/rfc9889>.

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

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

Chunduri, et al.        Expires 20 February 2027               [Page 17]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

              draft-ietf-teas-5g-network-slice-application-07, 6 July
              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-5g-network-slice-application-07>.

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC5462]  Andersson, L. and R. Asati, "Multiprotocol Label Switching
              (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
              Class" Field", RFC 5462, DOI 10.17487/RFC5462, February
              2009, <https://www.rfc-editor.org/info/rfc5462>.

   [RFC6335]  Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
              Cheshire, "Internet Assigned Numbers Authority (IANA)
              Procedures for the Management of the Service Name and
              Transport Protocol Port Number Registry", BCP 165,
              RFC 6335, DOI 10.17487/RFC6335, August 2011,
              <https://www.rfc-editor.org/info/rfc6335>.

   [RFC8221]  Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T.
              Kivinen, "Cryptographic Algorithm Implementation
              Requirements and Usage Guidance for Encapsulating Security
              Payload (ESP) and Authentication Header (AH)", RFC 8221,
              DOI 10.17487/RFC8221, October 2017,
              <https://www.rfc-editor.org/info/rfc8221>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [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 20 February 2027               [Page 18]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

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

   5GC –    5G Core

   AC –     Attachment Circuit

   AH –     Authentication Header

   CE –     Customer Edge

   CSR –    Cell Site Router

   CP –     Control Plane (5G)

   CU –     Centralized Unit (5G, gNB)

Chunduri, et al.        Expires 20 February 2027               [Page 19]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   DN –     Data Network (5G)

   DSCP –   DiffServ Code Point

   DU –     Distributed Unit (5G, gNB)

   eMBB –   enhanced Mobile Broadband (5G)

   ESP –    Encapsulating Security Payload

   gNB –    Next Generation Node B

   GBR –    Guaranteed Bit Rate (5G)

   GTP-U –  GPRS Tunneling Protocol - User plane (3GPP)

   HMTC –   High-performance Machine Type Communications

   MIoT –   Massive IoT (5G)

   MPLS –   Multi Protocol Label Switching

   MTU –    Maximum Transmission Unit

   NAT –    Network Address Translation

   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

   PCO –    Protocol Configuration Options (5G)

   PDU –    Protocol Data Unit (5G)

   PE –     Provider Edge

   PW –     Pseudowire

   RU –     Radio Unit

Chunduri, et al.        Expires 20 February 2027               [Page 20]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   SA –     Security Association

   SDP –    Service Demarcation Point

   S-NSSAI –  Single Network Slice Selection Assistance Information

   SD –     Slice Differentiator (5G)

   SEG –    Security Gateway (5G)

   SST –    Slice and Service Types (5G)

   SR –     Segment Routing

   TE –     Traffic Engineering

   TN –     Transport Network

   UDP –    User Datagram Protocol

   UE –     User Equipment

   UP –     User Plane(5G)

   UPF –    User Plane Function (5G)

   V2X –    Vehicle-to-Everything

   VLAN –   Virtual Local Area Network

   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

Chunduri, et al.        Expires 20 February 2027               [Page 21]
Internet-Draft  Mapping 5G slice to Transport Network sl     August 2026

   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 20 February 2027               [Page 22]