Skip to main content

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

Document Type Active Internet-Draft (dmm WG)
Authors Uma Chunduri , John Kaippallimalil , Sridhar Bhaskaran , Jeff Tantsura , Praveen Muley
Last updated 2024-08-23
Replaces draft-clt-dmm-tn-aware-mobility
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-dmm-tn-aware-mobility-10
DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                         Intel Corporation
Intended status: Informational                    J. Kaippallimalil, Ed.
Expires: 24 February 2025                                      Futurewei
                                                            S. Bhaskaran
                                                        Rakuten Symphony
                                                             J. Tantsura
                                                               Microsoft
                                                                P. Muley
                                                                   Nokia
                                                          23 August 2024

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

Abstract

   Network slicing in 5G supports 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 services, user's data plane packets over the
   radio access network (RAN) and mobile core network (5GC) use IP
   transport in many segments of the end-to-end 5G slice.  When end-to-
   end slices in a 5G system use IP network resources, they are mapped
   to corresponding IP transport network slice(s) which in turn provide
   the bandwidth, latency, isolation and other criteria requested by the
   5G slice.

   This document describes mapping of 5G slices to IP or Layer 2
   transport network slices when the IP transport network (slice
   provider) is separated from the networks in which the 5G network
   functions are deployed, for example, 5G functions that are
   distributed across data centers.  The slice mapping proposed here is
   supported transparently when a 5G user device moves across 5G
   attachment points and session anchors.

   NOTE: This document will be updated to address 3GPP TS 28.541
   (6.3.41) ConnectionPointInfo and Attachment-Circuits-as-a-Service in
   Section 3.4 prior to WGLC reviews.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

Chunduri, et al.        Expires 24 February 2025                [Page 1]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

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

   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 24 February 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Mapping 3GPP Slices to IP Network Slices  . . . . . . . . . .   7
     3.1.  Overview of 5G End-to-End Network Slicing . . . . . . . .   7
     3.2.  Fronthaul and Mid-Haul Transport Network  . . . . . . . .  10
     3.3.  Backhaul Transport Network  . . . . . . . . . . . . . . .  11
     3.4.  Slice Mapping using UDP Source Port . . . . . . . . . . .  11
   4.  Transport Network Underlays . . . . . . . . . . . . . . . . .  15
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   8.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  18

Chunduri, et al.        Expires 24 February 2025                [Page 2]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   3GPP architecture for 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 offer.  Slice types defined in 3GPP and offered to its
   clients (UEs) 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) and can be extended in
   future to include new slice types.

   Slices in 3GPP are logical sets of 3GPP resources that may include
   multiple segments across 3GPP control and user plane functions in the
   core and radio access networks.  For example, a 5G slice instance
   requested by an end-user may be realized by multiple slice subnets
   that span user plane network functions including the UPF (User Plane
   Function), gNB-CU (generalized Node-B Centralized Unit) and gNB-DU
   (generalized Node-B Distributed Unit) and corresponding 3GPP
   interfaces N3, N9, F1-U.  However, considering the IP transport
   network aspects for realizing 3GPP slicing:

   *  3GPP standards do not specify the capabilities needed by
      underlying IP transport network or slices.

   *  3GPP standards define how interfaces N3, N9, F1-U are (re)selected
      but they do not specify the underlying transport network
      (re)selection.

   *  Slice details in 3GPP, ATIS or NGMN do not specify how slice
      characteristics for QoS, hard /soft isolation, protection and
      other aspects should be satisfied in IP transport networks.

   A transport underlay across 3GPP interfaces N3, N9 and F1U may use
   multiple technologies or network providers on path and the slice in
   3GPP domain is mapped in each corresponding transport domain.  5G
   system slices for distributed infrastructure that make up the 5G
   system, and 5G slices offered to its end users (UE) are mapped to
   transport domain slices to provide the corresponding level of
   bandwidth, isolation and other capabilities.  The gNB-CU maintains
   the upper layer functionality of the radio access network while the
   gNB-DU runs the lower layers of the radio access network stack (e.g.,
   RLC, MAC and PHY based on the split), typically called the BBU (Base
   Band Unit).  Thus, a 3GPP F1-U slice subnet instance would typically
   be used to carry all user traffic between a gNB-DU and gNB-CU.  The

Chunduri, et al.        Expires 24 February 2025                [Page 3]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   N3 and N9 transport segments between the gNB and UPF(s) on the other
   hand handle user traffic based on the subscribed/offered level of
   service.  Thus, an end-user's traffic for eMBB service and assigned
   3GPP slice may be mapped to a different IP transport slice across N3
   and N9 segments than traffic for URLLC service.  Mapping and binding
   between 3GPP slice and a new IP transport slice happens transparently
   as the end-user moves across attachment points in the radio network
   and session anchors in 5GC.  Unlike mapping of a fronthaul 3GPP slice
   to an IP transport slice, the IP transport 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 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 IP transport slice that offers the
   corresponding characteristics even after handover.

   Slicing in this document mainly refers to user plane slices as these
   are used by the 3GPP network to provide the level of service offered
   to a user.  For example, 5GS that sets up a session for a user for
   eMBB service would need to provide the guarantees for the service
   across the user plane segments including F1-U, N3 and N9.  During the
   session setup phase, the control plane signaling may use other 5G
   provider slices for messages that carry session signaling, or to
   carry signaling data between 5G network functions.  The techniques
   described here can be applied to control plane in the same manner as
   it is applied for transport segments of the user plane.  The slicing
   requirements for the control plane are defined by the 5G service
   provider and not specified by a 3GPP standard.  Slice mapping using
   UDP source port may be used in IP transport networks for public or
   non public 3GPP networks.

Chunduri, et al.        Expires 24 February 2025                [Page 4]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   Different network scenarios and mechanisms to map 3GPP and IETF
   network slices are found in
   [I-D.ietf-teas-5g-network-slice-application].
   [I-D.ietf-teas-5g-network-slice-application] also describes the
   relationship between slice handling in the 3GPP management plane
   ([TS.28.541-3GPP]) and IETF network slice management.  This document
   focuses on a specific set of options outlined in
   [I-D.ietf-teas-5g-network-slice-application].  The use of UDP source
   port in GTP-U outer header and L2 VLAN to map between a 5G slice and
   corresponding IETF network slice segments is described in detail
   here.  The main considerations in the mapping methods proposed here
   include simplicity (i.e., use of L2 VLAN across a Layer-2 network)
   and efficiency of inspecting the slice mapping parameters on a per
   packet basis (i.e., source UDP port across routed IP networks) when
   the IP transport network (slice provider) is separated from the
   networks in which the 5G network functions are deployed (for example,
   5G functions distributed across data centers).  Section 3 describes
   these methods in detail.

   [RFC9543] draft defines the 'IETF Network slice', its scope and
   characteristics.  It lists use cases where IETF technologies can be
   used for slicing solutions, for various connectivity segments.  IETF
   Network slice in [RFC9543] and IP transport slice in this document
   are the same in the context of descriptions here.  When applied to
   5G, they both refer to slices for the connectivity segments between
   various 5G functions (i.e. 5G-AN which includes NG-RAN, ULCL UPF, BP
   UPF and PSA UPF).

2.  Terminology

   5G-AN –  5G Access Network

   AC –   Attachment Circuit

   AMF –  Access and Mobility Management Function (5G)

   BP –   Branch Point (5G)

   CSR –  Cell Site Router

   CP –   Control Plane (5G)

   CU –   Centralized Unit (5G, gNB)

   DN –   Data Network (5G)

   DU –   Distributed Unit (5G, gNB)

Chunduri, et al.        Expires 24 February 2025                [Page 5]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   eMBB –  enhanced Mobile Broadband (5G)

   gNB –  5G NodeB

   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

   NSSAI –  Network Slice Selection Assistance Information

   NSSF –  Network Slice Selection Function

   NSSMF –  Network Slice Selection Management Function

   PDU –  Protocol Data Unit (5G)

   PW –   Pseudo Wire

   SDP –  Service Demarcation Point

   SMF –  Session Management Function (5G)

   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)

Chunduri, et al.        Expires 24 February 2025                [Page 6]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

3.  Mapping 3GPP Slices to IP Network Slices

3.1.  Overview of 5G End-to-End Network Slicing

   3GPP architecture in [TS.23.501-3GPP], [TS.23.502-3GPP] specify
   slicing in 5GS and an overview is provided here.  5GS comprises of
   control plane network functions and user plane network functions.
   Communication services offered to 3GPP clients (UE) are associated to
   one or more slices represented by NSSAI (Network Slice Selection
   Assistance Information) both on the control plane and the user plane.
   The NSSAI is realized through the 5G management plane using network
   slice subnet (NSS), for example, a network slice subnet that contains
   network function instances of the core network control plane
   functions (e.g., SMF, NRF), user plane network functions (e.g., UPF),
   radio network slice common functions (e.g., gNB-DU, gNB-CU-CP) and
   and radio network (e.g., gNB-CU-UP).  Within the 3GPP domain, the
   control plane slicing is end-to-end while the user plane slicing ends
   at the UPF.  User plane slicing outside of the UPF towards IP
   services is outside the scope of 3GPP and is addressed in
   [I-D.mcd-rtgwg-extension-tn-aware-mobility].  3GPP documents mention
   transport network in the context of network slice subnets, but do not
   provide any 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 (transport network).  This
   section provides an overview and subsequent sections describe how to
   provision the mapping information in the transport network 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 24 February 2025                [Page 7]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

                5G Control and Management Planes
  +--------------------------------------------------------------------+
  | +----------------------------------------------------------------+ |
  | |                   5G Management Plane  (NSSMF)                 | |
  | +---+--------------+-------------+---------------+-----------+---+ |
  |     |              |             |               |           |     |
  | +---+--+           |   F1-C +----+-----+         |   N2 +----+---+ |
  | |      |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
  | |      |           |        +----+-----+         |      +----+---+ |
  +-|      |-----------|-------------|---------------|-----------|-----+
    |      |           |             |               |           |
    |      |           | e.g.,        |              | e.g.,     |
    |      |           | ACTN        |               | ACTN      |
    |      |       +---+---+         |           +---+---+       |
    |      |       |       |         |           |       |       |
    |gNB-DU|       |  NSC  |         E1          |  NSC  |       |
    |      |       |       |         |           |       |       |
    |      |       +---+---+         |           +---+---+       |
    |      |           |             |               |           |
    |      |           |             |               |           |
    |      |        __ +__           |            ___+__         |
    |      |     __/      \__     +--+---+     __/      \__    +-+-+
    |      |    /   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) expanded to show the IP transport
   and PE (Provider Edge) routers providing IP transport service to 5GS
   user plane entities 5G-AN (e.g., gNB) and UPF.  The Provider Edge
   (PE) represents the Service Demarcation Point (SDP) 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 particular network slice.  5G network slice orchestration
   is defined in [TS.28.533-3GPP] and is represented in Figure 1 as
   Network Slice Selection Management Function (NSSMF)) which is a part
   of 5G Management system responsible for managing network slice
   subnets.  The 3GPP network (customer network) requests for IP
   transport network slice (slice provider network) based on estimated
   demand.  The 5G management plane slice orchestration functionality in

Chunduri, et al.        Expires 24 February 2025                [Page 8]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   3GPP requests for transport slices via the NSC and may use ACTN
   [RFC8453].  The Network Data Analytics Function (NWDAF), Network
   Slice Selection Management Function (NSSMF) and other 3GPP functions
   in the control and management planes provide data and functionality
   to estimate slice capabilities required from the transport network.
   The slices provisioned in the IP transport network correspond to 3GPP
   slices represented by NSSAI (set of 3GPP slices) available at 3GPP
   access/data networks and locations.  During 3GPP procedures for
   session 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
   IP transport slice.  An overview of the sequence of operations from
   when a user (UE) requests during session setup to how it relates to
   the fronthaul, mid-haul and backhaul transport network slices is
   provided below.

   Prior to 3GPP user (UE) signaling to setup a session, the UE attaches
   to the radio access network and has the parameters for operation
   configured.  During this sequence of operation, the signaling is
   between the UE and the gNB.  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.  An important point
   to note is that 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.  For the front-haul described further in Section 3.2, an
   Ethernet transport with VLANs can be expected to be the case in many
   deployments.

   Following the radio access setup and attach, the 3GPP user (UE)
   signals to setup a session.  5G core network (5GC) functionality to
   handle access mobility (AMF), UE session management (SMF), policy
   (PCF) and various other assisting functionality including 3GPP slice
   selection (NSSF) is used to authenticate the UE and setup the data
   plane to transport the UE PDU (Protocol Data Units).  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).  From an IP transport
   network perspective, these GTP-U connections can be viewed as
   multiple overlay connection segments between each of the 3GPP data

Chunduri, et al.        Expires 24 February 2025                [Page 9]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   plane entities (gNB, UPF) on a per UE basis.  The GTP-U/overlay
   transport capabilities required are signaled between the RAN and 5GC
   during UE session setup.  Note that 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.  Thus, in the
   backhaul, an IP transport slice with capabilities corresponding to
   the S-NSSAI negotiated between UE 5GC is provided.  For example, a UE
   that sets up an eMBB session may require high bandwidth but can
   tolerate delay whereas a URLLC session requires low latency, low
   jitter and low error rates.  Slice capabilities along the user plane
   path between the (R)AN and UPFs such as a low latency path, jitter,
   protection and priority need to be provided by the IP transport
   network.  3GPP core network entities may be deployed across multiple
   data centers and in such cases require the IP transport network to
   provide the resources and connectivity for each of the slice
   segments.

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

Chunduri, et al.        Expires 24 February 2025               [Page 10]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   across to the separated IP transport network (slice provider).  In
   this case, the source UDP port of the GTP-U can be used to indicate
   the slice in the IP transport network (slice provider).

3.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 allowed network slice (S-NSSAI).  On an
   Ethernet based backhaul interface, the slice information is carried
   in the Ethernet header through the VLAN tags.  If an IP based
   backhaul interface is used, the network slice instance (NSI)
   information can be MPLS, SRv6 based as defined in [TS.28.541-3GPP].
   However, if the 3GPP network function (slice 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 of the GTP-U can be used to indicate the slice in the IP
   transport network (slice provider).

3.4.  Slice Mapping using UDP Source Port

   Communication services offered by 3GPP and the concepts used 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 as 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.  The 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 24 February 2025               [Page 11]
Internet-Draft  Mobility aware Transport Network Slicing     August 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 = IP1| \           \|NS = IP2|  \      |  |NS = IP3|  |
            \+====\===+  \           +====\===+   \     |  +===|====+  |
             \     \      \           \    \       \    |      |       |
              \  +--\-----+\       +--------\-----------+      |       |
               \ |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 (IP1, IP2, IP3).  As an example, when a UE registers with
   5GC with NSSAI 000A, OOOB and others, the AMF 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 = IP2 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 IP2' in the new location.

Chunduri, et al.        Expires 24 February 2025               [Page 12]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   When the 3GPP user plane function (5G-AN, UPF) and IP transport
   provider edge 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
   Attachment Circuit (AC) between the 3GPP entity (customer edge) and
   the SDP (Service Demarcation Point) in the IP transport network
   (provider edge).  The Attachment Circuit(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 24 February 2025               [Page 13]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

                          upstream GTP-U packet
                    =====================================>

      customer edge     attachment       slice provider    customer edge
                         circuit             ______
     +-------------+      ______          __/      \__     +-----------+
     |   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:          |     |      | src-IP-addr = gNB-AN2-if |
 ||NSSAI = {000B, 000C, ..} |     |      |    src-port = 5678       |
 ||NSSI  = AN2              |     |      |Action:                   |
 |+-------------------------+     |      |   select NS = IP2        |
 |                                |      +--------------------------+
 |+------------------------------+|
 ||Slice Mapping to UPF-CN1-if:  ||
 ||EP_Transport S-NSSAI=000B     ||
 ||logicInterfaceType = UDPSrcPrt||
 ||logicInterfaceId = 5678       ||
 ||ipAddress = UPF-CN1-if        ||
 |+------------------------------+|
 +--------------------------------+

            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 and separated from the IP transport slice provider by an
   attachment circuit (AC - i.e., the data center network).  In this
   example, a GTP-U packet at gNB-CU (user plane) belonging 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).  The GTP-U packet is forwarded by the
   data center network to the PE router at IP backhaul network.  The PE
   matches on GTP-U source IP address and port to select the provisioned
   slice (NS = IP2).  The UPF customer edge may be attached to the PE as

Chunduri, et al.        Expires 24 February 2025               [Page 14]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   shown in the figure or alternatively via a data center network.  A
   similar set of mappings exist for downlink GTP-U, but they do not
   necessarily use the same resources.

   PE routers can thus provision a policy based on the source UDP port
   number to the underlying transport path and then deliver the QoS/
   slice resource provisioned in the transport network.  The source UDP
   port 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 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 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 GTP-U / UDP source port
   with encoded slice identifier should be copied to the IPSec tunnel
   ESP header.  One option is to use 16 bits from the SPI field of the
   ESP header to encode the IP network slice identifier and use the
   remaining 16 bits in SPI field to identify an SA.  Load balancing
   entropy for ECMP will not be affected as the slice encoding mechanism
   already accounts for this.

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 work 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 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 24 February 2025               [Page 15]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

      +----------------+------------+------------------+-----------------+
      |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: By |
      |                |            |                  |   Delay:     Dy |
      |                |            |                  |   Jitter:    Jy |
      +----------------+------------+------------------+-----------------+
      | 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 ACTN
   applicability and relation to NSSMF 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.

Chunduri, et al.        Expires 24 February 2025               [Page 16]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

6.  IANA Considerations

   This document has no requests for any IANA code point allocations.

7.  Security Considerations

   This document does not introduce any new security issues.

8.  Contributing Authors

   The following people contributed substantially to the content of this
   document and should be considered co-authors.

   Richard Li
   Futurewei
   2330 Central Expressway
   Santa Clara
   CA 95050
   USA
   Email: richard.li@futurewei.com

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

   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

Chunduri, et al.        Expires 24 February 2025               [Page 17]
Internet-Draft  Mobility aware Transport Network Slicing     August 2024

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

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

   [I-D.mcd-rtgwg-extension-tn-aware-mobility]
              Majumdar, K., Chunduri, U., and L. Dunbar, "Extension of
              Transport Aware Mobility in Data Network", Work in
              Progress, Internet-Draft, draft-mcd-rtgwg-extension-tn-
              aware-mobility-08, 12 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-mcd-rtgwg-
              extension-tn-aware-mobility-08>.

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8453]  Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
              Abstraction and Control of TE Networks (ACTN)", RFC 8453,
              DOI 10.17487/RFC8453, August 2018,
              <https://www.rfc-editor.org/info/rfc8453>.

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

Chunduri, et al.        Expires 24 February 2025               [Page 18]
Internet-Draft  Mobility aware Transport Network Slicing     August 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 17)", June 2020.

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

Authors' Addresses

   Uma Chunduri (editor)
   Intel Corporation
   2191 Laurelwood Rd
   Santa Clara, CA 95054
   United States of America
   Email: umac.ietf@gmail.com

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

   John Kaippallimalil (editor)
   Futurewei
   Email: john.kaippallimalil@futurewei.com

   Sridhar Bhaskaran
   Rakuten Symphony
   Email: sridhar.bhaskaran@rakuten.com

   Jeff Tantsura
   Microsoft
   Email: jefftant.ietf@gmail.com

   Praveen Muley
   Nokia
   440 North Bernardo Ave
   Mountain View, CA 94043
   United States of America
   Email: praveen.muley@nokia.com

Chunduri, et al.        Expires 24 February 2025               [Page 20]