DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                         Intel Corporation
Intended status: Standards Track                  J. Kaippallimalil, Ed.
Expires: 19 May 2025                                           Futurewei
                                                            S. Bhaskaran
                                                        Rakuten Symphony
                                                             J. Tantsura
                                                                  Nvidia
                                                          L.M. Contreras
                                                              Telefonica
                                                        15 November 2024


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

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 19 May 2025                  [Page 1]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   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 19 May 2025.

Copyright Notice

   Copyright (c) 2024 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Mapping 3GPP Slice to Transport Network Slices  . . . . . . .   4
     2.1.  Scope of Transport Networks in 5G Network Slicing . . . .   4
     2.2.  Fronthaul and Mid-Haul Transport Network  . . . . . . . .   7
     2.3.  Backhaul Transport Network  . . . . . . . . . . . . . . .   7
     2.4.  Slice Mapping using UDP Source Port Number  . . . . . . .   8
   3.  Transport Network Underlays . . . . . . . . . . . . . . . . .  13
   4.  Attachment Circuit as a Service Extensions  . . . . . . . . .  14
     4.1.  Attachment Circuit Extension for UDP Tunnel . . . . . . .  14
     4.2.  ietf-ac-udp-tunnel YANG Module  . . . . . . . . . . . . .  15
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  Abbreviations  . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24









Chunduri, et al.           Expires 19 May 2025                  [Page 2]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


1.  Introduction

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

   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.

   A TN slice across 3GPP interfaces N3, N9 and F1U may use multiple
   technologies or network providers.  The slice in the 3GPP domain is
   mapped to each corresponding TN on the path.  5G system slices for
   the distributed infrastructure and NFs that make up the 5GS, and 5G
   slices provided to its end users (via UE) are mapped to TN slices
   [RFC9543] to provide the corresponding level of bandwidth, isolation,
   and other capabilities.  A 3GPP F1-U slice subnet instance may be
   used to carry all user traffic between a gNB-DU and gNB-CU since the
   lower layers of the radio access do not differentiate by user.  On
   the other hand, an end-user's traffic for eMBB service and assigned
   3GPP slice may be mapped to a different TN slice across N3 and N9
   segments than traffic for URLLC service.  Unlike mapping of a
   fronthaul 3GPP slice to a TN slice, the TN slice that F1-U/N3/N9
   slice is mapped to is aware of the slice characteristics of the UE
   session during initial setup (user initiates 3GPP connectivity
   session) and following 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 an TN slice that provides the corresponding
   characteristics even after handover.

   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].  This document defines another



Chunduri, et al.           Expires 19 May 2025                  [Page 3]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   mechanism where the source UDP port number of a layer 3 GTP bearer
   (or UDP encapsulated GTP) is used to map to the TN slice at the
   Provider Edge (PE).  3GPP slice management ([TS.28.541-3GPP]) and
   Attachment Circuit (AC) in [I-D.ietf-opsawg-teas-attachment-circuit]
   provide the basis for the necessary mapping.  Extensions to
   attachment circuit as a service to support a layer 3 GTP-U (or UDP
   encapsulated GTP) bearer as an attachment circuit is described in
   Section 2.4 and Section 4.

   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.  For realizing a 3GPP slice corresponding to a UE PDU
   session, the TN slice for each 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".  Slice mapping using
   UDP source port numbers may be used in TN of public or private 3GPP
   networks.

2.  Mapping 3GPP Slice to Transport Network Slices

2.1.  Scope of Transport Networks in 5G Network Slicing

   3GPP [TS.28.530-3GPP] discusses transport network in the context of
   network slice subnets, but do not specify further details.  The
   application of 5GS slices in transport network for backhaul, mid-haul
   and front haul are not explicitly covered in 3GPP and is the topic
   here.  To support specific characteristics in backhaul (N3, N9), mid-
   haul (F1) and front haul, it is necessary to provision corresponding
   resources in the transport domain and carry a slice identifier that
   is understood by both the customer (3GPP network) and the provider
   (TN).  This section provides an overview and subsequent sections
   describe how to provision the mapping information in the TN and apply
   it so that user plane packets can be provided the transport resources
   (QoS, isolation, protection, etc.) expected by the 5GS slices.










Chunduri, et al.           Expires 19 May 2025                  [Page 4]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


                     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 5GS 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 in the transport network to realize the
   network slice.  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 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.  Further details are
   in [I-D.ietf-teas-5g-ns-ip-mpls], section 3.

   The slices provisioned in the TN correspond to 3GPP slices
   represented by NSSAI (set of 3GPP slices) available at 3GPP access/
   data networks and locations.  During 3GPP procedures for session



Chunduri, et al.           Expires 19 May 2025                  [Page 5]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   initialization, the network grants an S-NSSAI (single one out of the
   NSSAI) based on the user's session request.  The S-NSSAI for the UE's
   session is signaled to the user plane nodes (gNB, UPF) during the
   session setup and used to associate to the corresponding TN slice.
   The N3, N9 and F1-U user planes use GTP-U [TS.29.281-3GPP] to
   transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
   Unlike the slice requirements for mid-haul segment (F1-U), the slice
   requirements for the backhaul (N3, N9) are setup in the 3GPP network
   on a per UE basis.  Many UEs traffic (e.g., eMBB) at a location that
   have the same requirements from a TN slice are mapped to a single 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.

   When the gNB functionality is split between a central unit (CU) and a
   distributed unit (DU), a mid-haul transport segment provides the
   connectivity as shown in Figure 1.  Further, the gNB central unit can
   be split into the control plane (CP) and user plane (UP) logical
   functions as shown in Figure 1.  If the RAN uses lower layer split
   architecture as specified by O-RAN alliance, then the user plane path
   from UE to DN also includes the fronthaul interface.  The fronthaul
   interface carries the radio frames in the form of In-phase (I) and
   Quadrature (Q) samples using eCPRI encapsulation over Ethernet or UDP
   over IP.  Signaling and data transport over the fronthaul transport
   has no notion of an end-user/UE session, but is rather defined by low
   latency and other requirements required for processing radio
   signaling and data transport between the network entities that
   compose gNB.  Data of different users between RAN functions have the
   same requirements from a TN slice, and can therefore be carried in
   the same TN slice.  There may however be more than one TN slice
   required for RAN based on the distribution of the RAN functions.  For
   the front-haul described further in Section 2.2, an Ethernet
   transport with VLANs can be expected to be the case in many
   deployments.

   The TN slice may use 5G QoS Indicator (5QI) aware or 5QI unaware
   treatment in the provider network.  If 5QI aware treatment is
   provisioned, packets in the TN slice will additionally be
   differentiated by the 5QI value (represented by DSCP in IP header).
   If 5QI unaware treatment is provisioned, all packets in the TN slice
   regardless of the 5QI (DSCP value) will be treated by TN slice
   characteristics.  Details of the two layer QoS mechanism are found in
   section 5 of [I-D.ietf-teas-5g-ns-ip-mpls].

   Mapping a 3GPP slice to a TN slice using GTP-U (UDP) source port
   number is described in Section 2.4.




Chunduri, et al.           Expires 19 May 2025                  [Page 6]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


2.2.  Fronthaul and Mid-Haul Transport Network

   The O-RAN Alliance defined a lower layer split at the physical layer
   of the radio access network whereby the gNB-DU is split into two
   entities (O-RU and O-DU) and has specified the fronthaul interface
   between the O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN].  The radio
   layer information, in the form of In-phase (I) and Quadrature (Q)
   samples are transported using enhanced Common Public Radio Interface
   (eCPRI) framing over Ethernet or UDP.  On an Ethernet based fronthaul
   interface, the network slice instance (NSI) information is carried in
   the Ethernet header through the VLAN tags and/or PCP marking.  The
   Ethernet switches in the fronthaul transport network inspects the
   slice information (VLAN tag and/or PCP marking) in the Ethernet
   header and provide the provisioned capabilities.  The mapping of I
   and Q samples of different radio resources (radio resource blocks or
   carriers) to different slices and to their respective VLAN tags and
   or PCP marking on the fronthaul interface is controlled by the O-RAN
   fronthaul C-Plane and M-Plane interfaces.  The fronthaul transport
   network is latency and jitter sensitive.  The provisioned slice
   capabilities in the fronthaul transport network MUST take care of the
   latency and jitter budgets of the specific slice for the fronthaul
   interface.  The provisioning of the fronthaul transport network is
   handled by the NC pertaining to the fronthaul transport.  3GPP
   functions gNB-CU (user plane) and gNB-DU may also be distributed and
   have a mid-haul transport between the two 3GPP network functions.  If
   an IP based mid-haul interface is used, the network slice instance
   (NSI) information can be MPLS, SRv6 based as defined in
   [TS.28.541-3GPP].  However, if the 3GPP network function (slice
   customer) is physically separated from the slice provider network
   (e.g., a gNB-CU (user plane) with baseband units deployed in a data
   center), the MPLS, SRv6 information may not be practical to carry
   across to the separated IP transport network (slice provider).  In
   this case, the source UDP port number of the GTP-U can be used to
   indicate the slice in the transport network (slice provider).

2.3.  Backhaul Transport Network

   The backhaul transport over which the protocols for N3 and N9
   interfaces run are described in [TS.23.501-3GPP] and
   [TS.23.502-3GPP].  The end-user (UE) sessions (IP, Ethernet,
   unstructured) are carried over GTP-U transport protocol over the N3
   and N9 interfaces.  GTP-U between the 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 19 May 2025                  [Page 7]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


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

2.4.  Slice Mapping using UDP Source Port Number

   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 19 May 2025                  [Page 8]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


  +-------------------+   +-------------------+    +-------------------+
  |  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 19 May 2025                  [Page 9]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   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 may, for example, be between a UPF
   in a data center to a (provider edge) router that serves as the
   service demarcation point for the transport network slice.  The
   identification information is provisioned between the 5G provider and
   IP transport network and corresponding information should be carried
   in each IP packet on the F1-U, N3, N9 interface.  For IP transport
   edge nodes to inspect the transport context information efficiently,
   it should be carried in an IP header field that is easy to inspect.
   It may be noted that the F1-U, N3 and N9 interfaces in 5GS are IP
   interfaces.  This is illustrated in Figure 3.



































Chunduri, et al.           Expires 19 May 2025                 [Page 10]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


                          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: ||                 +-------------------+
 || EP_Transport S-NSSAI=000B   ||
 || 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

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



Chunduri, et al.           Expires 19 May 2025                 [Page 11]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   In this example, a GTP-U packet at gNB-CU (user plane) is from a UE
   session with S-NSSAI = 000B (and thus associated to 3GPP and IP
   transport network instances in the figure for providing slice
   resources).  Since the GTP-U packet belongs to a session with S-NSSAI
   = 000B, the gNB-CU (UP) maps it to UDP port 5678 in the GTP-U header
   (outer encapsulation source port) and uses VLAN ID 100 based on the
   slice mapping to EP_Transport and "ac1" as shown in the figure.  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
   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.








Chunduri, et al.           Expires 19 May 2025                 [Page 12]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


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



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




Chunduri, et al.           Expires 19 May 2025                 [Page 13]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


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

4.  Attachment Circuit as a Service Extensions

4.1.  Attachment Circuit Extension for UDP Tunnel

   Section 2.4 provided a description of how a GTP-U connection AC can
   be mapped using source address and port number to an IETF transport
   slice.  To facilitate slice capabilities within a provider network,
   the AC is a means to bind the slice service that is previously agreed
   between the customer (i.e., 3GPP network) and provider (i.e., IP
   network provider).  This section uses provisioning of attachment
   circuits described in [I-D.ietf-opsawg-teas-attachment-circuit] and
   extends it to support UDP tunnels - GTP and encapsulated GTP.

   The 'l3-service' and 'l3-tunnel-service' in the attachment circuits
   structure in [I-D.ietf-opsawg-teas-attachment-circuit] is used to
   configure the relevant layer 3 tunnel properties of a UDP tunnel AC.
   IPv4 and IPv6 properties of the UDP tunnel AC are provided in "ip-
   connection" and the extension below adds source port number and range
   for the UDP tunnel.




















Chunduri, et al.           Expires 19 May 2025                 [Page 14]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   module: ietf-ac-udpt

     augment /ac-svc:attachment-circuits/ac-svc:ac/ac-svc:ip-connection
             /ac-svc:l3-service/ac-svc:l3-tunnel-service
             /ac-svc:l3-tunnel-service:

       +--rw (udp-port)?
          +--:(port-range-or-operator)
             +--rw source-port-range-or-operator
                +--rw (port-range-or-operator)?
                   +--:(range)
                   |  +--rw lower-port    inet:port-number
                   |  +--rw upper-port    inet:port-number
                   +--:(operator)
                      +--rw operator?     operator
                      +--rw port          inet:port-number


                      Figure 5: UDP Tunnel Yang Module

   'l3-tunnel-service' in [I-D.ietf-opsawg-teas-attachment-circuit] is
   extended in this document to carry UDP source port number/range.

   For encapsulations other than UDP, the underlying transports may use
   mappings using the relevant constructs native to the respective
   technology (e.g., MPLS, SR-MPLS and SRv6).  This is not covered in
   this document.

4.2.  ietf-ac-udp-tunnel YANG Module

   The "ietf-ac-udp-tunnel" module uses definitions in
   [I-D.ietf-opsawg-teas-attachment-circuit] and [RFC8519].


   module ietf-ac-udp-tunnel {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-ac-udp-tunnel";
     prefix ac-udpt;

     import ietf-ac-common {
       prefix ac-common;
       reference
         "RFC SSSS: YANG Data Models for Bearers and 'Attachment
                    Circuits'-as-a-Service (ACaaS)";
     }
     import ietf-ac-svc {
       prefix ac-svc;
       reference



Chunduri, et al.           Expires 19 May 2025                 [Page 15]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


         "RFC SSSS: YANG Data Models for Bearers and 'Attachment
                    Circuits'-as-a-Service (ACaaS)";
     }
     import ietf-packet-fields {
       prefix packet-fields;
         reference
           "RFC 8519: YANG Data Model for Network Access
                      Control Lists (ACLs), Section 4.2";
     }

     organization
       "IETF DMM (Distributed Mobility Management)";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/dmm/>
        WG List:  <mailto:dmm@ietf.org>

        Author:   Mohamed Boucadair
                  <mailto:mohamed.boucadair@orange.com>";
     description
       "This YANG module defines a YANG model for augmenting the ACaaS
        service model with UDP Encapsulation as Layer 3 tunnel service.

        Copyright (c) 2024 IETF Trust and the persons identified as
        authors of the code.  All rights reserved.

        Redistribution and use in source and binary forms, with or
        without modification, is permitted pursuant to, and subject
        to the license terms contained in, the Revised BSD License
        set forth in Section 4.c of the IETF Trust's Legal Provisions
        Relating to IETF Documents
        (https://trustee.ietf.org/license-info).

        This version of this YANG module is part of RFC XXXX; see the
        RFC itself for full legal notices.";

     revision 2023-11-13 {
       description
         "Initial revision.";
       reference
         "RFC XXXX: Mobility-aware Transport Network Slicing for 5G";
     }

     identity udp {
       base ac-common:l3-tunnel-type;
       description
         "UDP Encapsulation.";
       reference
         "RFC 8085: UDP Usage Guidelines, Section 3.1.11";



Chunduri, et al.           Expires 19 May 2025                 [Page 16]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


     }

     augment "/ac-svc:attachment-circuits/ac-svc:ac"
           + "/ac-svc:ip-connection/ac-svc:l3-service"
           + "/ac-svc:l3-tunnel-service/ac-svc:l3-tunnel-service" {
       when "derived-from-or-self(./type, 'ac-udpt:udp')" {
         description
           "Only applicable if l3 service type is UDP encapsualtion.";
       }
       description
         "Augments Layer 3 AC service with required data nodes for
          UDP encapsulation support.";
        choice udp-port {
          description
            "Choice of specifying the source port number or referring
             to a group of port numbers.";
          container source-port-range-or-operator {
            description
               "Indicates a set of source ports numbers.";
            uses packet-fields:port-range-or-operator;
         }
       }
     }
   }


                      Figure 6: UDP Tunnel YANG Module

   Note to RFC Editor:

      Replace "RFC XXXX" with the RFC number to be assigned to this
      document.

      Replace "RFC SSSS" with the RFC number to be assigned to
      [I-D.ietf-opsawg-teas-attachment-circuit].

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.  Mohamed Boucadair provided detailed Yang structures for
   the ietf-ac-udp-tunnel attachment circuit to make it flexible for use
   in this document and for future services.  Lionel Morand's suggestion
   to revise the UDP tunnel module to be applicable to not just GTPU but
   also other encapsulations like ESP-UDP makes this document more
   broadly applicable.



Chunduri, et al.           Expires 19 May 2025                 [Page 17]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


6.  Security Considerations

   This section is modeled after the template described in Section 3.7
   of [I-D.ietf-netmod-rfc8407bis].

   The "ietf-ac-udp-tunnel" YANG module defines a data model that is
   designed to be accessed via YANG-based management protocols, such as
   NETCONF [RFC6241] and RESTCONF [RFC8040].  These protocols have to
   use a secure transport layer (e.g., SSH [RFC4252], TLS [RFC8446] or
   QUIC [RFC9000] and have to use mutual authentication.

   The Network Configuration Access Control Model (NACM) [RFC8341]
   provides the means to restrict access for particular NETCONF or
   RESTCONF users to a preconfigured subset of all available NETCONF or
   RESTCONF protocol operations and content.

   Data nodes defined in the ietf-ac-udp-tunnel YANG module are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   and delete operations to these data nodes without proper protection
   or authentication can have a negative effect on network operations.
   The 'udp-port' information may be used to track a customer of the
   slice service and may be considered a violation of the customer-
   provider trust relationship.

7.  IANA Considerations

   IANA is requested to register the following URI in the "ns"
   subregistry within the "IETF XML Registry" [RFC3688]:

      URI: urn:ietf:params:xml:ns:yang:ietf-ac-udp-tunnel

      Registrant Contact: The IESG.

      XML: N/A; the requested URI is an XML namespace.

   IANA is requested to register the following YANG module in the "YANG
   Module Names" subregistry [RFC6020] within the "YANG parameters"
   registry.

      Name: ietf-ac-udp-tunnel

      Maintained by IANA?  N

      Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-udp-tunnel

      Prefix: ac-udp-tunnel



Chunduri, et al.           Expires 19 May 2025                 [Page 18]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


      Reference: RFC XXXX

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-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-
              18, 7 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
              teas-attachment-circuit-18>.

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



Chunduri, et al.           Expires 19 May 2025                 [Page 19]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


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

9.2.  Informative References

   [I-D.ietf-netmod-rfc8407bis]
              Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
              Authors and Reviewers of Documents Containing YANG Data
              Models", Work in Progress, Internet-Draft, draft-ietf-
              netmod-rfc8407bis-21, 13 November 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              rfc8407bis-21>.

   [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-03, 10 June
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              teas-5g-network-slice-application-03>.

   [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-
              13, 11 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
              ns-ip-mpls-13>.

   [I-D.ietf-teas-ns-controller-models]
              Contreras, L. M., Rokui, R., Tantsura, J., Wu, B., and X.
              Liu, "IETF Network Slice Controller and its Associated
              Data Models", Work in Progress, Internet-Draft, draft-
              ietf-teas-ns-controller-models-03, 21 October 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ns-
              controller-models-03>.

   [ORAN-WG4.CUS-O-RAN]
              O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
              Control, User and Synchronization Plane Specification;
              v2.0.0", August 2019.






Chunduri, et al.           Expires 19 May 2025                 [Page 20]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

   [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, <https://www.rfc-editor.org/info/rfc4252>.

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

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

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [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 19 May 2025                 [Page 21]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


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

   [TS.38.401-3GPP]
              3rd Generation Partnership Project (3GPP), "NG-RAN;
              Architecture description; v15.7.0", September 2019.

Appendix A.  Abbreviations

   5G-AN –  5G Access Network

   5GS –  5G System

   AC –   Attachment Circuit

   CSR –  Cell Site Router



Chunduri, et al.           Expires 19 May 2025                 [Page 22]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   CP –   Control Plane (5G)

   CU –   Centralized Unit (5G, gNB)

   DN –   Data Network (5G)

   DU –   Distributed Unit (5G, gNB)

   eMBB –  enhanced Mobile Broadband (5G)

   gNB –  Next Generation Node B

   GBR –  Guaranteed Bit Rate (5G)

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

   MIoT –  Massive IoT (5G)

   MPLS –  Multi Protocol Label Switching

   NG-RAN –  Next Generation Radio Access Network (i.e., gNB, NG-eNB -
          RAN functions which connect to 5GC)

   NSC –  Network Slice Controller

   NSS –  Network Slice Subnet

   NSSAI –  Network Slice Selection Assistance Information

   NSSI –  Network Slice Subnet Identifier

   NSSF –  Network Slice Selection Function

   PDU –  Protocol Data Unit (5G)

   PW –   Pseudo Wire

   SDP –  Service Demarcation Point

   S-NSSAI –  Single Network Slice Selection Assistance Information

   SST –  Slice and Service Types (5G)

   SR –   Segment Routing

   TE –   Traffic Engineering

   UP –   User Plane(5G)



Chunduri, et al.           Expires 19 May 2025                 [Page 23]

Internet-Draft  Mobility-aware Transport Network Slicing   November 2024


   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
   Rakuten Symphony
   Email: sridhar.bhaskaran@rakuten.com


   Jeff Tantsura
   Nvidia
   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 19 May 2025                 [Page 24]