DMM Working Group                                       U. Chunduri, Ed.
Internet-Draft                                         Intel Corporation
Intended status: Informational                    J. Kaippallimalil, Ed.
Expires: September 6, 2022                                     Futurewei
                                                            S. Bhaskaran
                                                             J. Tantsura
                                                                P. Muley
                                                           March 5, 2022

            Mobility aware Transport Network Slicing for 5G


   This document specifies a framework and mapping of slices in 5G
   mobile systems to transport network slices in IP, Layer 2 or Layer 1
   transport networks.  Slices in 5G systems are characterized by
   latency bounds, reservation guarantees, jitter, data rates,
   availability, mobility speed, usage density, criticality and
   priority.  These characteristics are mapped to transport network
   slice include bandwidth, latency and criteria such as isolation,
   directionality and disjoint routes.  Mobile slice criteria are mapped
   to the appropriate transport slice and capabilities offered in
   backhaul, midhaul and fronthaul connectivity segments between radio
   side network functions and user plane function(gateway).

   This document describes how a mobile network slice is mapped to a
   slice in IP or Layer 2 transport network between 3GPP provisioning
   end points.  The same mapping mechanisms apply during initial UE
   session setup and following UE mobility.  Applicability of this
   framework and underlying transport networks, which can enable
   different slice properties are also discussed.  This is based on
   mapping between mobile and transport underlays (L2, Segment Routing,
   IPv6, MPLS and IPv4).

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119 [RFC2119].

Chunduri, et al.        Expires September 6, 2022               [Page 1]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

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

   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 September 6, 2022.

Copyright Notice

   Copyright (c) 2022 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
   ( 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  IETF Network Slicing Terminology  . . . . . . . . . . . .   4
     1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
     1.3.  Solution Approach . . . . . . . . . . . . . . . . . . . .   5
     1.4.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Transport and Slice aware Mobility in 5G Networks . . . . . .   7
     2.1.  Backhaul and Mid-Haul Transport Network . . . . . . . . .   8
       2.1.1.  IETF Network Slicing Applicability  . . . . . . . . .  10
       2.1.2.  Fronthaul Transport Network . . . . . . . . . . . . .  10
     2.2.  Mobile Transport Network Context (MTNC) and Scalability .  10
     2.3.  Transport Network Function (TNF)  . . . . . . . . . . . .  11
     2.4.  Transport Provisioning  . . . . . . . . . . . . . . . . .  12
     2.5.  MTNC-ID in the Data Packet  . . . . . . . . . . . . . . .  13
     2.6.  Functionality for E2E Management  . . . . . . . . . . . .  15

Chunduri, et al.        Expires September 6, 2022               [Page 2]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   3.  Transport Network Underlays . . . . . . . . . . . . . . . . .  16
     3.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .  16
     3.2.  Transport Network Technologies  . . . . . . . . . . . . .  18
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  19
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   7.  Contributing Authors  . . . . . . . . . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  New Control Plane and User Planes  . . . . . . . . .  22
     A.1.  Slicing Framework and RAN Aspects . . . . . . . . . . . .  22
     A.2.  Slice aware Mobility: Discrete Approach . . . . . . . . .  23
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Introduction

   The 3GPP architecture for 5GS defined in [TS.23.501-3GPP],
   [TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core) and the NG-
   RAN architecture and procedures defined in [TS.38.300-3GPP] and
   [TS.38.401-3GPP] include procedures for setting up network slices in
   the 3GPP network.

   3GPP has defined slice types to cover enhanced mobile broadband
   (eMBB) communications, ultra-reliable low latency
   communications(URLLC) and massive internet of things (mIoT)and may
   extend to include new slice types as needed.  ATIS [ATIS075] has
   defined an additional slice type for V2X services.  3GPP slicing and
   RAN aspects are further described Appendix A.1.

   3GPP slice types and multiple instances of a slice type satisfy
   various characteristics for 5G network resources.  A slice in 3GPP is
   a logical chunk of 3GPP network resources that is dynamically created
   and may include core network control and user plane functions as well
   as access network functions.  A slice instance that spans 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 its interfaces N3, N9, F1-U) are clearly
   defined, however:

   o  3GPP standards do not specify the underlying IP transport network
      capabilities or slices thereof.

   o  Though 3GPP standards define how interfaces N3, N9, F1-U are
      reselected following mobility but do not specify the underlying
      transport network reselection aspects following mobility.

Chunduri, et al.        Expires September 6, 2022               [Page 3]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

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

   IP transport is used to interconnect the data forwarding entities
   UPFs, gNB-CU and gNB-DU in the 5GC and NG-RAN architecture but 3GPP
   specifications only define the interfaces (N3, N9, F1U etc.) and the
   3GPP transport end points [TS.28.541-3GPP].  The architecture allows
   the flexibility to dynamically place Branching Point (BP) and Uplink
   Classifier (ULCL) UPFs closer to the access network (5G-AN).  The 5G-
   AN can be a radio access network (NG-RAN) or any non-3GPP access
   network, for example, WLAN.  The resources of gNB-CU and gNB-DU
   corresponding to a slice in a 5G radio access network (NG-RAN) may be
   interconnected using a Layer 2 or IP network transport.

   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 should have a corresponding mapping in the transport
   domain.  This document proposes to map a slice in the 3GPP domain to
   a transport domain slice.  Key considerations including simplicity
   (e.g., use of L2 VLAN), routed networks on path (i.e., IP based
   mapping), efficiency of inspecting the slice mapping parameter and
   others are described in subsequent sections.

1.1.  IETF Network Slicing Terminology

   [I-D.ietf-teas-ietf-network-slices] 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.  Transport slice terminology as used in this
   document refers to the connectivity segment between various 5G
   systems (i.e. 5G-AN which includes NG-RAN, ULCL UPF, BP UPF and PSA
   UPF) and some of these segments are referred to as IETF Network

   [I-D.ietf-teas-ietf-network-slices] also defines a generic framework
   and how abstract requests to set up slices can be mapped to more
   specific technologies (e.g., VPN and traffic-engineering
   technologies).  This document is aimed to be specific to 3GPP use
   case where many such connectivity segments are used in E2E slicing
   solutions.  Some of the terminologies defined in these referred
   drafts and applicability to this document are further described in
   Section 2.1.1.

Chunduri, et al.        Expires September 6, 2022               [Page 4]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

1.2.  Problem Statement

   o  The 5G System (5GS) as defined in 3GPP specifications, does not
      consider the resources and functionalities needed from the
      transport network for the path between UPF, gNB corresponding to
      the N3, N9 and F1-U interfaces.  The lack of underlying Transport
      Network (TN) awareness in 3GPP may lead to selection of sub-
      optimal UPF(s) and/or 5G-AN during various procedures in 5GS
      (e.g., session establishment and various mobility scenarios).

   o  Meeting the specific slice characteristics on the F1-U, N3 and N9
      interfaces depends on the IP transport underlay providing these
      resources and capabilities.  There should also be a means by which
      3GPP slices are mapped to corresponding transport network slices
      and the means to carry this mapping in N3, N9, F1-U packets over
      the transport network.  This is needed to meet SLAs for real-time,
      mission-critical or latency sensitive services.

   o  3GPP defines configuration for its transport end-points in
      [TS.28.541-3GPP].  These end-points may be for Layer 2
      alternatives such as VLAN or L3/routed networks on the F1-U, N3 or
      N9 path based on desired capabilities.  When L3/routed networks
      and IP transport are used, IP header fields like DSCP are not
      sufficient as they convey QoS but not the other aspects like
      isolation or protection.  Other fields and extensions to carry a
      slice mapping, simplicity of lookup, implementation and scale are
      discussed in Section 2.

1.3.  Solution Approach

   This document specifies an approach to fulfil the needs of 5GS to
   transport user plane traffic from 5G-AN (including NG-RAN) to UPF in
   an optimized fashion.  This is done by keeping establishment and
   mobility procedures aware of the underlying transport network along
   with slicing requirements.

   Section 2 describes in detail on how TN aware mobility can be built
   irrespective of underlying TN technology used.  How other IETF TE
   technologies applicable for this draft is specified in Section 3.2.

1.4.  Acronyms

   5QI      -  5G QoS Indicator

   5G-AN    -  5G Access Network

   AMF      -  Access and Mobility Management Function (5G)

Chunduri, et al.        Expires September 6, 2022               [Page 5]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   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)

   eMBB     -  enhanced Mobile Broadband (5G)

   FRR      -  Fast ReRoute

   gNB      -  5G NodeB

   GBR      -  Guaranteed Bit Rate (5G)

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

   IGP      -  Interior Gateway Protocols (e.g.  IS-IS, OSPFv2, OSPFv3)

   LFA      -  Loop Free Alternatives (IP FRR)

   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)

   NSSMF    -  Network Slice Selection Management Function

   QFI      -  QoS Flow ID (5G)

   PPR      -  Preferred Path Routing

   PDU      -  Protocol Data Unit (5G)

   PW       -  Pseudo Wire

   RAN      -  Radio Access Network (i.e 3GPP radio access network used
          synonymously with NG-RAN in this document)

   RAN      -  Radio Access Network

Chunduri, et al.        Expires September 6, 2022               [Page 6]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   RQI      -  Reflective QoS Indicator (5G)

   SBI      -  Service Based Interface (5G)

   SID      -  Segment Identifier

   SMF      -  Session Management Function (5G)

   SSC      -  Session and Service Continuity (5G)

   SST      -  Slice and Service Types (5G)

   SR       -  Segment Routing

   TE       -  Traffic Engineering

   ULCL     -  Uplink Classifier (5G)

   UP       -  User Plane(5G)

   UPF      -  User Plane Function (5G)

   URLLC    -  Ultra reliable and low latency communications (5G)

2.  Transport and Slice aware Mobility in 5G Networks

   3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing
   in 5GS and is provided here for information.  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 map and provision corresponding
   resources in the transport domain.  This section describes 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.

   The figure shows the entities on path for 3GPP Network Functions
   (gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an
   IP/L2 transport network.

Chunduri, et al.        Expires September 6, 2022               [Page 7]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

                5G Control and Management Planes
    | +--------------------------------------------------------------------+ |
    | |                    (TNF)    5G Management Plane  (TNF)             | |
    | +----+-----------------+-------------+---------------+-----------+---+ |
    |      |                 |             |               |           |     |
    | +----+-----+           |   F1-C +----+-----+         |   N2 +----+---+ |
    | |          |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
    | |          |           |        +----+-----+         |      +----+---+ |
    +-|          |-----------|-------------|---------------|-----------|-----+
      |          |           |             |               |           |
      |          |           |             |               |           |
      |          |           | ACTN        |               | ACTN      |
      |          |       +---+---+         |           +---+---+       |
      |          |       |       |         |           |       |       |
      | gNB-DU   |       | SDN-C |         E1          | SDN-C |       |
      |          |       |       |         |           |       |       |
      |          |       +---+---+         |           +---+---+       |
      |          |           |             |               |           |
      |          |           |             |               |           |
      |          |        __ +__           |            ___+__         |
      |          |     __/      \__     +--+---+     __/      \__    +-+-+
      |          |    /     IP     \    | gNB  |    /     IP     \   |   |
 UE--*|          |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
      +----------+    \__        __/    +------+    \__        __/   +---+
                         \______/                      \______/

                   |------ F1-U -------|        |------ N3 OR N9 ------|

          * Radio and Fronthaul

         Figure 1: Backhaul and Mid-haul Transport Network for 5G

2.1.  Backhaul and Mid-Haul Transport Network

   Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)
   routers providing IP transport service to 5GS user plane entities 5G-
   AN (e.g. gNB) and UPF.  5GS architecture with high level management,
   control and user plane entities and its interaction with the IP
   transport plane is shown here.  The slice capability required in IP
   transport networks are estimated and provisioned by the functionality
   as specified in Section 2.3 (TNF) with support from various other
   control plane functions such as the Network Data Analytics Function
   (NWDAF), Network Function Repository Function (NRF) and Policy
   Control Function (PCF).  The TNF is only a logical function that may
   be realized in a 3GPP management function such as Network Slice
   Selection Management Function (NSSMF) defined in [TS.28.533-3GPP].

Chunduri, et al.        Expires September 6, 2022               [Page 8]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   The TNF requests the SDN-C to provision the IP XHaul network using
   ACTN [RFC8453].

   The 5G management plane in Figure 1 interacts with the 5G control
   plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and
   gNB-DU (5G Node B Distributed Unit).  Non-access stratum (NAS)
   signaling from the UE for session management, mobility is handled by
   the 5GC.  When a UE initiates session establishment, it indicates the
   desired slice type in the S-NSSAI (Specific Network Slice Selection
   Assistance Information) field.  The AMF uses the S-NSSAI, other
   subscription information and configuration in the NSSF to select the
   appropriate SMF and the SMF in turn selects UPFs (User Plane
   Functions) that are able to provide the specified slice resources and

   The AMF, SMF, NSSF, PCF, NRF, NWDAF and other control functions in
   5GC are described in [TS.23.501-3GPP].  Some of the slice
   capabilities along the user plane path between the (R)AN and UPFs
   (F1-U, N3, N9 segments) such as a low latency path, jitter,
   protection and priority needs these to be provided by the IP
   transport network.

   The 5G user plane from UE to DN (Data Network) includes a mid-haul
   segment (F1-U between gNB DU(UP), gNB CU(UP)) and backhaul (N3
   between gNB - UPF; N9 between UPFs).  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.

   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).
   For the front-haul described further in Section 2.1.2, an Ethernet
   transport with VLANs can be expected to be the case in many

   Figure 1 also depicts the PE router, where transport paths are
   initiated/terminated can be deployed separately with UPF or both
   functionalities can be in the same node.  The TNF provisions this in
   the SDN-C of the IP XHaul network using ACTN [RFC8453].  When a GTP-U
   encapsulated user packet from the (R)AN (gNB) or UPF with the slice
   information traverses the F1-U/N3/N9 segment, the PE router of the IP
   transport underlay can inspect the slice information and provide the
   provisioned capabilities.  This is elaborated further in Section 2.4.

Chunduri, et al.        Expires September 6, 2022               [Page 9]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

2.1.1.  IETF Network Slicing Applicability

   Some of the functional elements depicted in the Figure 1 can be
   mapped to the terminology set forth in the
   [I-D.ietf-teas-ietf-network-slices].  From 3GPP perspective, UE and
   UPF are the network slice endpoints and routers, gNB-DU, gNB-CU,
   switches, PE nodes are the slice realization endpoints.  The TNF
   represented in the Figure 1 can be seen as IETF Network Slice
   Controller (NSC) functionality and SDN-C maps to Network Controller
   (NC).  NSC-NBI interface is the interface from 3GPP Management plane
   (e.g., NSSMF) and NSC-SBI interface is the interface between TNF and
   SDN-C.  Various possibilities for implementation of these interfaces
   and the relation to ACTN are also further described in the

2.1.2.  Fronthaul Transport Network

   The O-RAN Alliance 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 the Ethernet based fronthaul
   interface, the slice information can be carried in the Ethernet
   header through the VLAN tags.  The Ethernet switches in the fronthaul
   transport network can inspect the slice information (VLAN tag) 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 etc.,.) to different slices and to their
   respective VLAN tags on the fronthaul interface is controlled by the
   O-RAN fronthaul C-Plane and M-Plane interfaces.  On a UDP based
   fronthaul interface, the slice information can be carried in the IP
   or UDP header.  The PE routers of the fronthaul transport network can
   inspect the slice information in the IP or UDP header and provide the
   provisioned capabilities.  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
   SDN-C pertaining to the fronthaul transport.

2.2.  Mobile Transport Network Context (MTNC) and Scalability

   The MTNC represents a slice of a transport path for a tenant between
   two 3GPP user plane functions.  The Mobile-Transport Network Context
   Identifier (MTNC-ID) is generated by the TNF to be unique for each
   instance (for a tenant) and per traffic class (including QoS and
   slice aspects).  Thus, there may be more than one MTNC-ID for the
   same QoS and instance if there is a need to provide isolation (slice)

Chunduri, et al.        Expires September 6, 2022              [Page 10]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   of the traffic.  It should be noted that MTNC are per class/instance
   and not per user session.  The MTNC-IDs are configured by the TNF to
   be unique within a provisioning domain.

   Since the MTNC-IDs are generated per instance / tenant, there is no
   need for unique MTNC-IDs per flow/session.  In addition, since the
   traffic estimation is performed prior to UE's session establishment,
   there is no provisioning delay experienced by the UE during its
   session setup.  For an instance/tenant, the MTNC-ID space scales
   roughly as a square of the number sites between which 3GPP user plane
   functions have paths.  If there are T traffic classes and C Tenants,
   the number of MTNC-IDs in a fully meshed network is T * C.  An MTNC-
   ID space of 16 bits (65K identifiers) can be expected to be

2.3.  Transport Network Function (TNF)

   Figure 1 shows a view of the functions and interfaces for
   provisioning the MTNC-IDs.  The focus is on provisioning between the
   3GPP management plane (NSSMF), transport network (SDN-C) and carrying
   the MTNC-IDs in PDU packets for the transport network to grant the
   provisioned resources.

   In Figure 1, the TNF (logical functionality within the NSSMF)
   requests the SDN-C in the transport domain to program the TE path
   using ACTN [RFC8453].  The SDN-C programs the Provider Edge (PE)
   routers and internal routers according to the underlay transport
   technology (e.g., MPLS, SR, PPR).  The PE router inspects incoming
   PDU data packets for the UDP SRC port which mirrors the MTNC-ID,
   classifies and provides the VN service provisioned across the
   transport network.

   The detailed mechanisms by which the NSSMF provides the MTNC-IDs to
   the control plane and user plane functions are for 3GPP to specify.
   Two possible options are outlined below for completeness.  The NSSMF
   may provide the MTNC-IDs to the 3GPP control plane by either
   providing it to the Session Management Function (SMF), and the SMF in
   turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU
   session setup.  Alternatively, the user plane functions may request
   the MTNC-IDs directly from the TNF/NSSMF.  Figure 1 shows the case
   where user plane entities request the TNF/NSSMF to translate the
   Request and get the MTNC-ID.  Another alternative is for the TNF to
   provide a mapping of the 3GPP Network Instance Identifier, described
   in Section 2.6 and the MTNC-ID to the user plane entities via

   The TNF should be seen as a logical entity that can be part of NSSMF
   in the 3GPP management plane [TS.28.533-3GPP].  The NSSMF may use

Chunduri, et al.        Expires September 6, 2022              [Page 11]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   network configuration, policies, history, heuristics or some
   combination of these to derive traffic estimates that the TNF would
   use.  How these estimates are derived are not in the scope of this
   document.  The focus here is only in terms of how the TNF and SDN-C
   are programmed given that slice and QoS characteristics across a
   transport path can be represented by an MTNC-ID.  The TNF requests
   the SDN-C in the transport network to provision paths in the
   transport domain based on the MTNC-ID.  The TNF is capable of
   providing the MTNC-ID provisioned to control and user plane functions
   in the 3GPP domain.  Detailed mechanisms for programming the MTNC-ID
   should be part of the 3GPP specifications.

2.4.  Transport Provisioning

   Functionality of transport provisioning for an engineered IP
   transport that supports 3GPP slicing and QoS requirements in
   [TS.23.501-3GPP] is described in this section.

   During a PDU session setup, the AMF using input from the NSSF selects
   a network slice and SMF.  The SMF with user policy from Policy
   Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the
   path of the PDU session.  While QoS and slice selection for the PDU
   session can be applied across the 3GPP control and user plane
   functions as outlined in Section 2, the IP transport underlay across
   F1-U, N3 and N9 segments do not have enough information to apply the
   resource constraints represented by the slicing and QoS
   classification.  Current guidelines for interconnection with
   transport networks [IR.34-GSMA] provide an application mapping into
   DSCP.  However, these recommendations do not take into consideration
   other aspects in slicing like isolation, protection and replication.

   IP transport networks have their own slice and QoS configuration
   based on domain policies and the underlying network capability.
   Transport networks can enter into an agreement for virtual network
   services (VNS) with client domains using the ACTN [RFC8453]
   framework.  An IP transport network may provide such slice instances
   to mobile network operators, CDN providers or enterprises for
   example.  The 3GPP mobile network, on the other hand, defines a slice
   instance for UEs as are the mobile operator's 'clients'.  The Network
   Slice Selection Management Function (NSSMF) [TS 28.533] that
   interacts with a TN controller like an SDN-C (that is out of scope of

   The ACTN VN service can be used across the IP transport networks to
   provision and map the slice instance and QoS of the 3GPP domain to
   the IP transport domain.  An abstraction that represents QoS and
   slice instances in the mobile domain and mapped to ACTN VN service in
   the transport domain is represented here as MTNC-IDs.  Details of how

Chunduri, et al.        Expires September 6, 2022              [Page 12]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   the MTNC-IDs are derived are up to functions that can estimate the
   level of traffic demand.

   The 3GPP network/5GS provides slices instances to its clients (UE)
   that include resources for radio and mobile core segments.  The UE's
   PDU session spans the access network (radio) and F1-U/N3/N9 transport
   segments which have an IP transport underlay.  The 5G operator needs
   to obtain slice capability from the IP transport provider since these
   resources are not seen by the 5GS.  Several UE sessions that match a
   slice may be mapped to an IP transport segment.  Thus, there needs to
   be a mapping between the slice capability offered to the UE (NSSAI)
   and what is provided by the IP transport.

   When the 3GPP user plane function (5G-AN, UPF) does not terminate the
   transport underlay protocol (e.g., MPLS), it needs to be carried in
   the IP protocol header from end-to-end of the mobile transport
   connection (N3, N9).  [I-D.ietf-dmm-5g-uplane-analysis] discusses
   these scenarios in detail.

2.5.  MTNC-ID in the Data Packet

   When the 3GPP user plane function (5G-AN, UPF) and transport provider
   edge is on different nodes, the PE router needs to have the means by
   which to classify the PDU packet.  The mapping 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.  To allow the 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.
   If the fronthaul, midhaul or backhaul IP path is bounded by an L2
   network, one option maybe to use VLANs to carry the MTNC-ID. 3GPP
   specifications for management plane defines transport end-points
   configuration in [TS.28.541-3GPP].  However, Layer 2 alternatives
   such as VLAN will fail in L3/routed networks on the F1-U, N3 or N9
   path.  GTP-U (F1-U, N3, N9 encapsulation header) field extensions
   offer a possibility, however these extensions are not always easy for
   a transport edge router to parse efficiently on a per packet basis.
   Other IP header fields like DSCP are not suitable as it only conveys
   the QoS aspects (but not other aspects like isolation, protection,

   While IPv6 extension headers like SRv6 may be an option to carry the
   MTNC-ID that requires the end-to-end network to be IPv6 as well as
   the capability to lookup the extension header at line rate.  To
   minimise the protocol changes and make this underlay transport
   independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping
   of MTNC-ID to a UDP port range of the GTP encapsulated user packet.

Chunduri, et al.        Expires September 6, 2022              [Page 13]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   A simple mapping table between the MTNC-ID and the source UDP port
   number can be configured to ensure that ECMP /load balancing is not
   affected adversely by encoding the UDP source port with an MTNC-ID
   mapping.  The UDP port information containing MTNC-ID is a simple
   extension that can be provisioned in 3GPP transport end-points
   defined in [TS.28.541-3GPP].  This mapping is configured in 3GPP user
   plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that
   process MTNC-IDs.

   PE routers can thus provision a policy based on the source UDP port
   number (which reflects the mapped MTNC-ID) 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
   MTNC 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 MTNC 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 MTNC 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 MTNC encoding
   mechanism already accounts for this.

   If the RAN uses O-RAN Alliance lower layer split architecture, then a
   fronthaul network is involved.  On an Ethernet based fronthaul
   transport network, VLAN tag may be an option to carry the MTNC-ID.
   The VLAN ID provides a 12 bit space and is sufficient to support up
   to 4096 slices on the fronthaul transport network.  The mapping of
   fronthaul traffic to corresponding network slices is based on the
   radio resource for which the fronthaul carries the I and Q samples.
   The mapping of fronthaul traffic to the VLAN tag corresponding to the
   network slice is specified in Section 2.1.2.  On the UDP based
   fronthaul transport network, the UDP source port can be used to carry
   the MTNC-ID.

Chunduri, et al.        Expires September 6, 2022              [Page 14]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

2.6.  Functionality for E2E Management

   With the TNF functionality in 5GS Service Based Interface, the
   following additional functionalities are required for end-2-end slice
   management including the transport network:

   o  The Specific Network Slice Selection Assistance Information
      (S-NSSAI) of PDU session SHOULD be mapped to the assigned
      transport VPN and the TE path information for that slice.

   o  For transport slice assignment for various SSTs (eMBB, URLLC,
      MIoT) corresponding underlay paths need to be created and
      monitored from each transport endpoint (CSR and PE@UPF).

   o  During PDU session creation, apart from radio and 5GC resources,
      transport network resources needed to be verified matching the
      characteristics of the PDU session traffic type.

   o  The TNF MUST provide an API that takes as input the source and
      destination 3GPP user plane element address, required bandwidth,
      latency and jitter characteristics between those user plane
      elements and returns as output a particular TE path's identifier,
      that satisfies the requested requirements.

   o  Mapping of PDU session parameters to underlay SST paths need to be
      done.  One way to do this is to let the SMF install a Forwarding
      Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
      "Network Instance" in the UPF.  A "Network Instance" is a logical
      identifier for an underlying network.  The "Network Instance"
      pointed by the FAR can be mapped to a transport path (through L2/
      L3 VPN).  FARs are associated with Packet Detection Rule (PDR).
      PDRs are used to classify packets in the uplink (UL) and the
      downlink (DL) direction.  For UL procedures specified in
      Section 2.4, Section 2.5 can be used for classifying a packet
      belonging to a particular slice characteristic.  For DL, at a PSA
      UPF, the UE IP address is used to identify the PDU session, and
      hence the slice a packet belongs to and the IP 5 tuple can be used
      for identifying the flow and QoS characteristics to be applied on
      the packet at UPF.  If a PE is not co-located at the UPF then
      mapping to the underlying TE paths at PE happens based on the
      encapsulated GTP-U packet as specified in Section 2.5.

   o  In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if
      segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-
      UPF) is needed, then corresponding path characteristics MUST be
      used.  This includes a path from CSR to PE@UL-CL/BP UPF
      [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN.

Chunduri, et al.        Expires September 6, 2022              [Page 15]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   o  Continuous monitoring of the underlying transport path
      characteristics should be enabled at the endpoints (technologies
      for monitoring depends on traffic engineering technique used as
      described in Section 3.2).  If path characteristics are degraded,
      reassignment of the paths at the endpoints should be performed.
      For all the affected PDU sessions, degraded transport paths need
      to be updated dynamically with similar alternate paths.

   o  During UE mobility events similar to 4G/LTE i.e., gNB mobility (F1
      based, Xn based or N2 based), for target gNB selection, apart from
      radio resources, transport resources MUST be factored.  This
      enables handling of all PDU sessions from the UE to target gNB and
      this require co-ordination of gNB, AMF, SMF with the TNF module.

   Integrating the TNF as part of the 5GS Service Based Interfaces,
   provides the flexibility to control the allocation of required
   characteristics from the TN during a 5GS signaling procedure (e.g.
   PDU Session Establishment).  If TNF is seen as separate and in a
   management plane, this real time flexibility is lost.  Changes to
   detailed signaling to integrate the above for various 5GS procedures
   as defined in [TS.23.502-3GPP] is beyond the scope of this document.

3.  Transport Network Underlays

   Apart from the various flavors of IETF VPN technologies to share the
   transport network resources and capacity, TE capabilities in the
   underlay network is an essential component to realize the 5G TN
   requirements.  This section focuses on various transport underlay
   technologies (not exhaustive) and their applicability to realize
   Midhaul/Backhaul transport networks.  Focus is on the user/data plane
   i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.

3.1.  Applicability

   o  For 3 different SSTs, 3 transport TE paths can be signaled from
      any node in the transport network.  For Uplink traffic, the 5G-AN
      will choose the right underlying TE path of the UPF based on the
      S-NSSAI the PDU Session belongs to and/or the UDP Source port
      (corresponds to the MTNC-ID Section 2.4) of the GTP-U
      encapsulation header.  Similarly in the Downlink direction
      matching Transport TE Path of the 5G-AN is chosen based on the
      S-NSSAI the PDU Session belongs to.  The table below shows a
      typical mapping:

Chunduri, et al.        Expires September 6, 2022              [Page 16]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

      |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 2: Mapping of Transport Paths on F1-U/N3/N9

   o  It is possible to have a single TE Path for multiple input points
      through a MP2P TE tree structure separate in UL and DL direction.

   o  Same set of TE Paths are created uniformly across all needed 5G-
      ANs and UPFs to allow various mobility scenarios.

   o  Any modification of TE parameters of the path, replacement path
      and deleted path needed to be updated from TNF to the relevant
      ingress points.  Same information can be pushed to the NSSF, and/
      or SMF as needed.

   o  TE Paths support for native L2, IPv4 and IPv6 data/user planes
      with optional TE features are desirable in some network segments.
      As this is an underlay mechanism it can work with any overlay
      encapsulation approach including GTP-U as defined currently for
      F1-U/N3/N9 interface.

   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

Chunduri, et al.        Expires September 6, 2022              [Page 17]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   captured in Figure 2 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

3.2.  Transport Network Technologies

   While there are many Software Defined Networking (SDN) approaches
   available, this section is not intended to list all the possibilities
   in this space but merely captures the technologies for various
   requirements discussed in this document.

   RSVP-TE [RFC3209] provides a lean transport overhead for the TE path
   for MPLS user plane.  However, it is perceived as less dynamic in
   some cases and has some provisioning overhead across all the nodes in
   N3 and N9 interface nodes.  Also, it has another drawback with
   excessive state refresh overhead across adjacent nodes and this can
   be mitigated with [RFC8370].

   SR-TE [RFC8402] does not explicitly signal bandwidth reservation or
   mechanism to guarantee latency on the nodes/links on SR path.  But SR
   allows path steering for any flow at the ingress and particular path
   for a flow can be chosen.  Some of the issues and suitability for
   mobile use plane are documented at Section 5.3 of
   [I-D.bogineni-dmm-optimized-mobile-user-plane].  However,
   [I-D.ietf-dmm-srv6-mobile-uplane] presents various options for
   optimized mobile user plane with SRv6 with or without GTP-U overhead
   along with traffic engineering capabilities.  SR-MPLS allows
   reduction of the control protocols to one IGP (without needing for
   LDP and RSVP-TE).

   Preferred Path Routing (PPR) is an integrated routing and TE
   technology and the applicability for this framework is described in
   [I-D.chunduri-dmm-5g-mobility-with-ppr].  PPR does not remove GTP-U,
   unlike some other proposals laid out in
   [I-D.bogineni-dmm-optimized-mobile-user-plane].  Instead, PPR works
   with the existing cellular user plane (GTP-U) for F1-U/N3 and N9.  In
   this scenario, PPR will only help provide TE benefits needed for 5G
   slices from a transport domain perspective.  It does so for any
   underlying user/data plane used in the transport network

   As specified with the integrated transport network function (TNF), a
   particular RSVP-TE path for MPLS or SR path for MPLS and IPv6 with
   SRH user plane or PPR with PPR-ID [I-D.chunduri-dmm-5g-mobility-with-
   ppr], can be supplied to SMF for mapping a particular PDU session to
   the transport path.

Chunduri, et al.        Expires September 6, 2022              [Page 18]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

4.  Acknowledgements

   Thanks to Young Lee for discussions on this document including ACTN
   applicability for the proposed TNF.  Thanks to Sri Gundavelli, Kausik
   Majumdar and 3GPP delegates who provided detailed feedback on this

5.  IANA Considerations

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

6.  Security Considerations

   This document does not introduce any new security issues.

7.  Contributing Authors

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

   Richard Li
   2330 Central Expressway
   Santa Clara
   CA 95050

   Luis M. Contreras
   Sur-3 building, 3rd floor
   Madrid 28050

   Xavier De Foy
   InterDigital Communications, LLC
   1000 Sherbrooke West


8.  References

Chunduri, et al.        Expires September 6, 2022              [Page 19]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

8.2.  Informative References

   [ATIS075]  Alliance for Telecommunications Industry Solutions (ATIS),
              "IOT Categorization: Exploring the Need for Standardizing
              Additional Network Slices ATIS-I-0000075", September 2019.

              Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
              Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
              Muscariello, L., Camarillo, P., and S. Homma, "Optimized
              Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
              optimized-mobile-user-plane-01 (work in progress), June

              Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
              "User Plane Protocol and Architectural Analysis on 3GPP 5G
              System", draft-ietf-dmm-5g-uplane-analysis-04 (work in
              progress), November 2020.

              Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
              Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
              Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-18
              (work in progress), February 2022.

              Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
              K., Contreras, L. M., and J. Tantsura, "Framework for IETF
              Network Slices", draft-ietf-teas-ietf-network-slices-07
              (work in progress), March 2022.

              GSM Association (GSMA), "Guidelines for IPX Provider
              Networks (Previously Inter-Service Provider IP Backbone
              Guidelines, Version 14.0", August 2018.

              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 September 6, 2022              [Page 20]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,

   [RFC8370]  Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
              T. Saad, "Techniques to Improve the Scalability of RSVP-TE
              Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,

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

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

              3rd Generation Partnership Project (3GPP), "System
              Architecture for 5G System; Stage 2, 3GPP TS 23.501
              v2.0.1", December 2017.

              3rd Generation Partnership Project (3GPP), "Procedures for
              5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December

              3rd Generation Partnership Project (3GPP), "Policy and
              Charging Control System for 5G Framework; Stage 2, 3GPP TS
              23.503 v1.0.0", December 2017.

              3rd Generation Partnership Project (3GPP), "Management and
              Orchestration Architecture Framework (Release 15)", June

              3rd Generation Partnership Project (3GPP), "Management and
              orchestration; 5G Network Resource Model (NRM); Stage 2
              and stage 3 (Release 17)", June 2020.

Chunduri, et al.        Expires September 6, 2022              [Page 21]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

              3rd Generation Partnership Project (3GPP), "GPRS Tunneling
              Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
              December 2018.

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

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

Appendix A.  New Control Plane and User Planes

A.1.  Slicing Framework and RAN Aspects

   The 3GPP architecture defines slicing aspects where the Network Slice
   Selection Function (NSSF) assists the Access Mobility Manager (AMF)
   and Session Management Function (SMF) to assist and select the right
   entities and resources corresponding to the slice requested by the
   User Equipment (UE).  The User Equipment (UE) indicates information
   regarding the set of slices it wishes to connect, in the Network
   Slice Selection Assistance Information (NSSAI) field during network
   registration procedure (Attach) and the specific slice the UE wants
   to establish an IP session, in the Specific NSSAI (S-NSSAI) field
   during the session establishment procedure (PDU Session
   Establishment).  The AMF selects the right SMF and the SMF in turn
   selects the User Plane Functions (UPF) so that the QoS and
   capabilities requested can be fulfilled.

   The architecture for the Radio Access Network (RAN) is defined in
   [TS.38.300-3GPP] and [TS.38.401-3GPP].  The 5G RAN architecture
   allows disaggregation of the RAN into a Distributed Unit (DU) and a
   Centralized Unit (CU).  The CU is further split into control plane
   (CU-CP) and user plane (CU-UP).  The interface between CU-UP and the
   DU for the user plane traffic is called the F1-U and between the CU-
   CP and DU for the control plane traffic is called the F1-C.  The F1-C
   and the F1-U together are called the mid-haul interfaces.  The DU
   does not have a CP/UP split.  Apart from 3GPP, O-RAN Alliance has
   specified further disaggregation of the RAN at the lower layer
   (physical layer).  The DU is disaggregated into a ORAN DU (O-DU)
   which runs the upper part of the physical layer, MAC and RLC and the
   ORAN Radio Unit (O-RU) which runs the lower part of the physical
   layer.  The interface between the O-DU and the O-RU is called the
   Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN].

Chunduri, et al.        Expires September 6, 2022              [Page 22]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

A.2.  Slice aware Mobility: Discrete Approach

   In this approach transport network functionality from the 5G-AN to
   UPF is discrete and 5GS is not aware of the underlying transport
   network and the resources available.  Deployment specific mapping
   function is used to map the GTP-U encapsulated traffic at the 5G-AN
   (e.g. gNB) in UL and UPF in DL direction to the appropriate transport
   slice or transport Traffic Engineered (TE) paths.  These TE paths can
   be established using RSVP-TE [RFC3209] for MPLS underlay, SR
   [RFC3209] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-dmm-
   5g-mobility-with-ppr] with MPLS, IPv6 with SRH, native IPv6 and
   native IPv4 underlays.

   As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
   user plane traffic forwarding rules in the UPF.  The UPFs have a
   concept of a "Network Instance" which logically abstracts the
   underlying transport path.  When the SMF creates the packet detection
   rules (PDR) and forwarding action rules (FAR) for a PDU session at
   the UPF, the SMF identifies the network instance through which the
   packet matching the PDR has to be forwarded.  A network instance can
   be mapped to a TE path at the UPF.  In this approach, TNF as shown in
   Figure 1 need not be part of the 5G Service Based Interface (SBI).
   Only management plane functionality is needed to create, monitor,
   manage and delete (life cycle management) the transport TE paths/
   transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
   The management plane functionality also provides the mapping of such
   TE paths to a network instance identifier to the SMF.  The SMF uses
   this mapping to install appropriate FARs in the UPF.  This approach
   provide partial integration of the transport network into 5GS with
   some benefits.

   One of the limitations of this approach is the inability of the 5GS
   procedures to know, if underlying transport resources are available
   for the traffic type being carried in PDU session before making
   certain decisions in the 5G CP.  One example scenario/decision could
   be, a target 5G-AN selection during a N2 mobility event, without
   knowing if the target 5G-AN is having a underlay transport slice
   resource for the S-NSSAI and 5QI of the PDU session.  The Integrated
   approach specified below can mitigate this.

Authors' Addresses

Chunduri, et al.        Expires September 6, 2022              [Page 23]

Internet-DrafMobility aware Transport Network Slicing for 5G  March 2022

   Uma Chunduri (editor)
   Intel Corporation
   2191 Laurelwood Rd
   Santa Clara, CA  95054


   John Kaippallimalil (editor)


   Sridhar Bhaskaran


   Jeff Tantsura


   Praveen Muley
   440 North Bernardo Ave
   Mountain View, CA  94043


Chunduri, et al.        Expires September 6, 2022              [Page 24]