



DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                         Intel Corporation
Intended status: Informational                    J. Kaippallimalil, Ed.
Expires: 9 April 2026                                          Futurewei
                                                            S. Bhaskaran
                                                         Starten Systems
                                                             J. Tantsura
                                                                  Nvidia
                                                          L.M. Contreras
                                                              Telefonica
                                                          6 October 2025


            Mobility-aware Transport Network Slicing for 5G
                  draft-ietf-dmm-tn-aware-mobility-22

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 IP transport network 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 transport network
   slices using UDP source port number of the GTP-U bearer when the IP
   transport network (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 9 April 2026                  [Page 1]

Internet-Draft  Mobility-aware Transport Network Slicing    October 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 9 April 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.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Abbreviations  . . . . . . . . . . . . . . . . . . .  18
   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-



Chunduri, et al.          Expires 9 April 2026                  [Page 2]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   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 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,
   3GPP standards do not specify the capabilities of transport network
   (TN) slices or slice characteristics for QoS, hard /soft isolation,
   protection and other aspects.

   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.  User plane 5G slice for each user's PDU session is
   mapped to corresponding TN slices and is the focus of this document.
   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
   mapped to a TN slice that provides the corresponding characteristics



Chunduri, et al.          Expires 9 April 2026                  [Page 3]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   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 [I-D.ietf-opsawg-teas-attachment-circuit] 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 slice in an IP
   transport network provider.  UDP source port ranges in transport
   network underlays for slice mapping is described in Section 4.

2.  Scope of Transport Networks in 5G Slicing

   3GPP [TS.28.530-3GPP] discusses transport network 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 9 April 2026                  [Page 4]

Internet-Draft  Mobility-aware Transport Network Slicing    October 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 transport network that
   provides the slice capabilities.  The IETF Network Slice Controller
   (NSC) interfaces with the 3GPP network (customer network) that
   requests for transport network slices (IETF network slice).  The 5G
   management plane in turn requests the Network Slice Controller (NSC)
   to setup resources and connectivity 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-CP 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



Chunduri, et al.          Expires 9 April 2026                  [Page 5]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   [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 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 slice
   provider network (e.g., a gNB-CU (user plane) with baseband units
   deployed in a data center), the MPLS, SRv6 information may not be
   practical to carry across to the separated IP transport network
   (slice provider).  In this case, the source UDP port number of the
   GTP-U can be used to indicate the slice in the transport network
   (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 end-user (UE) sessions (IP, Ethernet,
   unstructured) are carried over GTP-U transport protocol over the N3
   and N9 interfaces.  GTP-U between the 3GPP network functions (gNB,
   UPF) serves as an overlay protocol across one or more MPLS, SRv6 or
   Ethernet transport networks in between.  During UE session setup, a
   number of parameters for context management are configured in the
   gNB, UPF and that includes 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



Chunduri, et al.          Expires 9 April 2026                  [Page 6]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   interface is used, the network slice instance (NSI) information can
   be MPLS, SRv6 based as defined in [TS.28.541-3GPP].  However, if the
   3GPP network function (slice customer) is physically separated from
   the slice provider network (e.g., a gNB-CU (user plane) or UPF, or
   both are deployed in a data center), the MPLS, SRv6 information may
   not be practical to carry across to the separated IP transport
   network (slice provider).  In this case, the source UDP port number
   of the GTP-U can be used to indicate the slice in the IP transport
   network (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 a
   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 IP transport network slice is
   associated to 3GPP core or RAN network functions in a 3GPP Network
   Slice Subnet (NSS).  Thus, it can represent a slice of a transport
   path for a tenant between two 3GPP user plane functions.




















Chunduri, et al.          Expires 9 April 2026                  [Page 7]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


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


                       Figure 2: Slice Configuration

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





Chunduri, et al.          Expires 9 April 2026                  [Page 8]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


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 IP transport
   network (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 transport
   network 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 IP transport network and 3GPP user
   plane nodes are provisioned with the necessary information for
   mapping the slices.  The PE router in IP transport network 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 is configured with
   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
   [I-D.jlu-dmm-udp-tunnel-acaas] and inherits the attachment circuit in
   [I-D.ietf-opsawg-teas-attachment-circuit].













Chunduri, et al.          Expires 9 April 2026                  [Page 9]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   During PDU session setup, the 5G control plane configures parameters
   to setup the user plane for the PDU session across F1-U, N3 and N9
   interfaces.  One of parameters configured by the 5G control plane is
   the S-NSSAI.  This S-NSSAI in the user plane setup can be used to
   associate with the previously configured EP_Transport information per
   S-NSSAI.  The ATTACHMENT_CIRCUIT for the per S-NSSAI EP_Tansport
   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 that signaled for the PDU session.

   An example is shown in Figure 3.







































Chunduri, et al.          Expires 9 April 2026                 [Page 10]

Internet-Draft  Mobility-aware Transport Network Slicing    October 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=000B                ||
  || 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 9 April 2026                 [Page 11]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   Figure 3 shows the configuration and mapping applied to network
   instances in a 3GPP network slice subnet and corresponding IP
   transport network instances for sending an upstream GTP packet from
   gNB-CU (user plane) to UPF.  The gNB-CU (user plane) function is in a
   data center (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 [I-D.ietf-opsawg-teas-attachment-circuit] 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 = 000B and to be forwarded to UPF-CN1 (i.e., as
   already setup by SMF during PDU session establishment).  The
   associated 3GPP and IP transport network 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 transport network.  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



Chunduri, et al.          Expires 9 April 2026                 [Page 12]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   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.  Transport networks
   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
   transport network 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 9 April 2026                 [Page 13]

Internet-Draft  Mobility-aware Transport Network Slicing    October 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, security is desired granularly in the
   underlying transport network.  In such cases, there would be a need
   to have separate sub-ranges under each SST to provide the TE path in
   preserving the security characteristics.  The UDP source port range
   captured in Figure 4 would be sub-divided to maintain the TE path for
   the current SSTs with the security.  The current solution doesn't
   provide any mandate on the UE traffic in selecting the type of
   security.

   There are many possible transport network 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 9 April 2026                 [Page 14]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


6.  Security Considerations

   This document specifies the use of UDP source port to identify a
   (customer) 3GPP slice at the IP transport network provider edge (PE).
   The YANG model should conform to security constraints described in
   [I-D.jlu-dmm-udp-tunnel-acaas] and
   [I-D.ietf-opsawg-teas-attachment-circuit].

   The various management aspects described in this document to
   provision a slice are explanatory and have no direct effect on
   security of implementations or deployments.  Section 3 describes the
   configuration and management of slices.  The configuration and
   management procedures here should conform to security constraints for
   slice authenticaiton, 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 9 April 2026                 [Page 15]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


9.  References

9.1.  Normative References

   [I-D.ietf-opsawg-teas-attachment-circuit]
              Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
              and B. Wu, "YANG Data Models for Bearers and 'Attachment
              Circuits'-as-a-Service (ACaaS)", Work in Progress,
              Internet-Draft, draft-ietf-opsawg-teas-attachment-circuit-
              20, 23 January 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              teas-attachment-circuit-20>.

   [I-D.jlu-dmm-udp-tunnel-acaas]
              Kaippallimalil, J., Contreras, L. M., and U. Chunduri,
              "UDP Tunnel Attachment Circuit as a Service", Work in
              Progress, Internet-Draft, draft-jlu-dmm-udp-tunnel-acaas-
              00, 9 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-jlu-dmm-udp-
              tunnel-acaas-00>.

   [RFC8519]  Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
              "YANG Data Model for Network Access Control Lists (ACLs)",
              RFC 8519, DOI 10.17487/RFC8519, March 2019,
              <https://www.rfc-editor.org/info/rfc8519>.

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

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




Chunduri, et al.          Expires 9 April 2026                 [Page 16]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


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

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

   [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 v15.1.0",
              December 2018.

   [TS.38.300-3GPP]
              3rd Generation Partnership Project (3GPP), "NR; NR and NG-
              RAN Overall Description; Stage 2; v15.7.0", September
              2019.






Chunduri, et al.          Expires 9 April 2026                 [Page 17]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   [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

   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)



Chunduri, et al.          Expires 9 April 2026                 [Page 18]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   PW –     Pseudo Wire

   SDP –    Service Demarcation Point

   S-NSSAI –  Single Network Slice Selection Assistance Information

   SST –    Slice and Service Types (5G)

   SR –     Segment Routing

   TE –     Traffic Engineering

   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







Chunduri, et al.          Expires 9 April 2026                 [Page 19]

Internet-Draft  Mobility-aware Transport Network Slicing    October 2025


   Luis M. Contreras
   Telefonica
   Telefonica Sur-3 building, 3rd floor
   28050 Madrid
   Spain
   Email: luismiguel.contrerasmurillo@telefonica.com













































Chunduri, et al.          Expires 9 April 2026                 [Page 20]
