Mobility aware Transport Network Slicing for 5G
draft-ietf-dmm-tn-aware-mobility-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Uma Chunduri , John Kaippallimalil , Sridhar Bhaskaran , Jeff Tantsura , Praveen Muley | ||
| Last updated | 2023-04-19 (Latest revision 2022-10-19) | ||
| Replaces | draft-clt-dmm-tn-aware-mobility | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| 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-06
DMM Working Group U. Chunduri, Ed.
Internet-Draft Intel Corporation
Intended status: Informational J. Kaippallimalil, Ed.
Expires: 21 October 2023 Futurewei
S. Bhaskaran
Rakuten Symphony
J. Tantsura
Microsoft
P. Muley
Nokia
19 April 2023
Mobility aware Transport Network Slicing for 5G
draft-ietf-dmm-tn-aware-mobility-06
Abstract
Network slicing in 5G enables the multiplexing of logical networks
over the same infrastructure. 5G signaling and 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 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.
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].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Chunduri, et al. Expires 21 October 2023 [Page 1]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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 21 October 2023.
Copyright Notice
Copyright (c) 2023 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
1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . 11
2.2. Mobile Transport Network Context . . . . . . . . . . . . 11
2.3. Transport Network Orchestration (TNO) . . . . . . . . . . 12
2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 13
2.5. MTNC in the Transport Network . . . . . . . . . . . . . . 14
2.6. Functionality for E2E Management . . . . . . . . . . . . 16
3. Transport Network Underlays . . . . . . . . . . . . . . . . . 18
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Transport Network Technologies . . . . . . . . . . . . . 19
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
Chunduri, et al. Expires 21 October 2023 [Page 2]
Internet-Draft Mobility aware Transport Network Slicing April 2023
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. New Control Plane and User Planes . . . . . . . . . 24
A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 24
A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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), the NG-RAN
architecture defined in [TS.38.300-3GPP] and [TS.38.401-3GPP] include
procedures for setting up network slices in the 3GPP network as well
as help provide connectivity with resource commitments to 3GPP
network users. This document discusses the details, where
connectivity and resource commitments of 3GPP slice segments are
realized by IP transport network slices.
Slice types defined in 3GPP and offered to its clients (UEs) include
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 resources. A slice in 3GPP is a
logical set of 3GPP network resources that are dynamically created
and may include control and user plane functions in the core and
radio networks. A 5G slice instance may 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 its interfaces N3, N9, F1-U, however:
* 3GPP standards do not specify the underlying IP transport network
capabilities or slices thereof.
* 3GPP standards define how interfaces N3, N9, F1-U are reselected
following mobility but they do not specify the underlying
transport network reselection aspects following mobility.
* 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.
Chunduri, et al. Expires 21 October 2023 [Page 3]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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) can be mapped to
transport domain slices. Mobilitity awareness in slicing is intended
to convey that the mapping and binding mechanism between 3GPP slice
and IP transport slice based on source UDP port of GTP-U happens
transparently as the end-user moves across attachment points in the
radio network and session anchors in 5GC.
Different network scenarios and mechanisms to map 3GPP and IETF
network slices are found in
[draft-gcdrb-teas-5g-network-slice-application]. This document
complements [draft-gcdrb-teas-5g-network-slice-application] and
describes in detail the use of UDP source port in GTP-U outer header
and L2 VLAN to map between 5G slice and corresponding IETF network
slice segments. 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).
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
slices.
[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.
1.2. Problem Statement
Chunduri, et al. Expires 21 October 2023 [Page 4]
Internet-Draft Mobility aware Transport Network Slicing April 2023
* 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).
* 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.
* 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.
* Furthermore, in scenarios where 3GPP functional entities (customer
network) in a data center request slice capabilities from an IP
transport network (provider network), the slice identifier should
be carried across the the data center network over IP header
fields and extensions (referred to as attachment circuit (AC) in
[I-D.ietf-teas-ietf-network-slices]) that are simple to lookup.
Details are in section 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
Chunduri, et al. Expires 21 October 2023 [Page 5]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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)
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)
NSC - Network Slice Controller
NSSMF - Network Slice Selection Management Function
QFI - QoS Flow ID (5G)
PPR - Preferred Path Routing
PDU - Protocol Data Unit (5G)
Chunduri, et al. Expires 21 October 2023 [Page 6]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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
RQI - Reflective QoS Indicator (5G)
SBI - Service Based Interface (5G)
SDP - Service Demarcation Point
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 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 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.
Chunduri, et al. Expires 21 October 2023 [Page 7]
Internet-Draft Mobility aware Transport Network Slicing April 2023
2.1. Backhaul and Mid-Haul Transport Network
The figure below shows the functional entities on path for 3GPP (gNB-
DU, gNB-CU, UPF) to obtain slice aware classification from an IP/L2
transport network.
5G Control and Management Planes
+------------------------------------------------------------------------+
| +--------------------------------------------------------------------+ |
| | (TNO) 5G Management Plane (TNO) | |
| +----+-----------------+-------------+---------------+-----------+---+ |
| | | | | | |
| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
| | | | +----+-----+ | +----+---+ |
+-| |-----------|-------------|---------------|-----------|-----+
| | | | | |
| | | | | |
| | | ACTN | | ACTN |
| | +---+---+ | +---+---+ |
| | | | | | | |
| gNB-DU | | NC | E1 | NC | |
| | | | | | | |
| | +---+---+ | +---+---+ |
| | | | | |
| | | | | |
| | __ +__ | ___+__ |
| | __/ \__ +--+---+ __/ \__ +-+-+
| | / IP/L2 \ | 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
Figure 1 depicts IP Xhaul network with the 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 NSC in turn
Chunduri, et al. Expires 21 October 2023 [Page 8]
Internet-Draft Mobility aware Transport Network Slicing April 2023
requests the Network Controller (NC) to setup resources and
connectivity in the transport network to realize the particular
network slice. Network slice orchestration in the 3GPP network is
defined in [TS.28.533-3GPP] and is represented in Figure 1 as
Transport Network Orchestrator (TNO). The TNO is responsible for
requesting transport slice service 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 may provide data and
functionality to estimate slice capabilities required in the
transport network but all of this functionality including the TNO are
out of scope of this document. What is important to note here is
that the requests for transport network slice configuration are
between the 3GPP network (customer network) and the IP transport
network (provider network). This should be distinguished from 3GPP
slices (S-NSSAI) which represent slice capabilities (resource and
connectivity) that the 3GPP provider offers to its clients (UE). An
overview of the sequence of operations from when a user (UE) requests
during session setup to how it relates to the front-haul and
transport network slices is provided below. Further details are
found in [TS.23.501-3GPP] and [TS.23.502-3GPP].
Prior to 3GPP user (UE) signaling to setup a session, the UE attaches
to the radio 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. 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 the mid-haul
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 2.1.2,
an Ethernet transport with VLANs can be expected to be the case in
many deployments.
Folowing the radio 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) are used to 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
Chunduri, et al. Expires 21 October 2023 [Page 9]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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 plane entities (gNB, UPF) on a
per UE basis. The GTP-U/overlay transport capabilities required are
signaled between the UE 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. Some of the slice capabilities along the user
plane path between the (R)AN and UPFs such as a low latency path,
jitter, protection and priority needs 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. This is further described in Section 2.2.
The TNO (Transport Network Orchestrator) functionality is not in the
scope of this document, but it is responsible for provisioning slice
requirements of the transport network. Specification of these
functionality is in [TS.28.533-3GPP] and other 3GPP management
specifications. Figure 1 depicts the PE router, where transport
paths are initiated/terminated and can be deployed separately from
the UPF or both functionalities can be in the same node. The TNO may
provision this in the NSC 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.
2.1.1. IETF Network Slicing Applicability
The functional elements depicted in the Figure 1 use slicing concepts
defined in [I-D.ietf-teas-ietf-network-slices]. From a 3GPP
perspective, UE and UPF are the network slice (S-NSSAI) endpoints and
routers, gNB-DU, gNB-CU, switches, PE nodes are the slice realization
endpoints. The TNO represented in the Figure 1 can be seen as a
customer higher level operation system for the management of slices
in the 3GPP network. The NSC realizes the transport network slice in
the underlay network. Various possibilities for implementation of
these interfaces including ACTN are described in the
[I-D.ietf-teas-ietf-network-slices].
Chunduri, et al. Expires 21 October 2023 [Page 10]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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) 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 NC
pertaining to the fronthaul transport.
2.2. Mobile Transport Network Context
The MTNC (Mobile Transport Network Context) represents a slice of a
transport path for a tenant between two 3GPP user plane functions.
This is defined in [TS.28.541-3GPP] transport end-point as
"logicInterfaceId" and is referred to as MTNC in this document to
describe how it applies to the IETF network slice capabilities in the
transport network. The Mobile-Transport Network Context Identifier
(MTNC-ID) is generated by the TNO 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) of the
traffic. It should be noted that MTNC are per class/instance and not
per user (UE) session. The MTNC-IDs are configured by the TNO to be
unique within a 3GPP provisioning domain.
MTNC-IDs or "logicInterfaceId" are per instance / tenant and is not
unique per UE session. The relation of an S-NSSAI signaled by the UE
during session establishment and the corresponding MTNC-ID /
logicInterfaceId in each of the transport network segments is derived
in 3GPP specifications and not in scope here. The traffic estimation
is performed prior to UE's session establishment, there is no
provisioning delay experienced by the UE during its session setup.
Chunduri, et al. Expires 21 October 2023 [Page 11]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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 sufficient.
2.3. Transport Network Orchestration (TNO)
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 (NSC) and carrying
the MTNC-IDs in PDU packets for the transport network to grant the
provisioned resources.
In Figure 1, the TNO (logical orchestration functionality within the
3GPP management plane) requests the NSC in the transport domain to
setup the TE path using ACTN [RFC8453]. The NSC sets up the Provider
Edge (PE) routers and internal routers according to the underlay
transport technology (e.g., MPLS, SR, PPR). The PE router is the
service demarcation point (SDP) and it 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 TNO/NSSMF. Figure 1 shows the case
where user plane entities request the TNO/NSSMF to translate the
Request and get the MTNC-ID. Another alternative is for the TNO 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
configuration.
Chunduri, et al. Expires 21 October 2023 [Page 12]
Internet-Draft Mobility aware Transport Network Slicing April 2023
The TNO 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
network configuration, policies, history, heuristics or some
combination of these to derive traffic estimates that the TNO 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 TNO and NSC are
programmed given that slice and QoS characteristics across a
transport path can be represented by an MTNC-ID. The TNO requests
the NSC in the transport network to provision paths in the transport
domain based on the MTNC-ID. The TNO 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
This section outlines a sequence of operations for provisioning an
engineered IP transport that supports 3GPP slicing and QoS
requirements in [TS.23.501-3GPP].
During a PDU session setup request from the UE, 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 (in this case 3GPP networks) using
the ACTN [RFC8453] framework. An IP transport network provide 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 NSC (that is out of scope of 3GPP).
Chunduri, et al. Expires 21 October 2023 [Page 13]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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
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 in the Transport Network
When the 3GPP user plane function (5G-AN, UPF) and transport provider
edge are on different nodes, the PE router needs to have the means by
which to classify the IP packet from 3GPP entity based on some header
information. In [I-D.ietf-teas-ietf-network-slices] 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. 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] and currently include VLAN, MPLS,
and segment routing. 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,
Chunduri, et al. Expires 21 October 2023 [Page 14]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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 some QoS aspects
(but not other aspects like isolation, protection, etc.)
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
minimize 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.
A 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
Chunduri, et al. Expires 21 October 2023 [Page 15]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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.
2.6. Functionality for E2E Management
With the TNO functionality in 5GS Service Based Interface, the
following steps illustrate the end-2-end slice management including
the transport network:
* 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.
* 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).
* 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.
* The TNO 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.
Chunduri, et al. Expires 21 October 2023 [Page 16]
Internet-Draft Mobility aware Transport Network Slicing April 2023
* 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 of 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.
* 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.
* 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.
* 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 TNO module.
Integrating the TNO 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 TNO 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.
Chunduri, et al. Expires 21 October 2023 [Page 17]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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
* 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:
+----------------+------------+------------------+-----------------+
|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
Chunduri, et al. Expires 21 October 2023 [Page 18]
Internet-Draft Mobility aware Transport Network Slicing April 2023
* 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.
* Same set of TE Paths are created uniformly across all needed 5G-
ANs and UPFs to allow various mobility scenarios.
* Any modification of TE parameters of the path, replacement path
and deleted path needed to be updated from TNO to the relevant
ingress points. Same information can be pushed to the NSSF, and/
or SMF as needed.
* 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
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
security.
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
Chunduri, et al. Expires 21 October 2023 [Page 19]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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-rtgwg-preferred-path-routing]. 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
(L2/IPv4/IPv6/MPLS).
As specified with the integrated transport network orchestrator
(TNO), 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-rtgwg-preferred-path-routing], can be supplied to SMF
for mapping a particular PDU session to the transport path.
4. Acknowledgements
Thanks to Young Lee for discussions on this document including ACTN
applicability for the proposed TNO. Thanks to Sri Gundavelli, Kausik
Majumdar, Hannu Flinck, Joel Halpern, Satoru Matsushima and Tianji
Jiang who provided detailed feedback on this document.
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
Futurewei
2330 Central Expressway
Santa Clara
CA 95050
USA
Email: richard.li@futurewei.com
Chunduri, et al. Expires 21 October 2023 [Page 20]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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
8. References
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,
<https://www.rfc-editor.org/info/rfc2119>.
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.
[draft-gcdrb-teas-5g-network-slice-application]
IETF, "IETF Network Slice Application in 3GPP 5G End-to-
End Network Slice", March 2023.
[I-D.bogineni-dmm-optimized-mobile-user-plane]
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", Work in Progress,
Internet-Draft, draft-bogineni-dmm-optimized-mobile-user-
plane-01, 29 June 2018,
<https://datatracker.ietf.org/doc/html/draft-bogineni-dmm-
optimized-mobile-user-plane-01>.
Chunduri, et al. Expires 21 October 2023 [Page 21]
Internet-Draft Mobility aware Transport Network Slicing April 2023
[I-D.chunduri-dmm-5g-mobility-with-ppr]
Chunduri, U., Contreras, L. M., Bhaskaran, S., Tantsura,
J., and P. Muley, "Transport aware 5G mobility with PPR",
Work in Progress, Internet-Draft, draft-chunduri-dmm-5g-
mobility-with-ppr-00, 2 November 2020,
<https://datatracker.ietf.org/doc/html/draft-chunduri-dmm-
5g-mobility-with-ppr-00>.
[I-D.chunduri-rtgwg-preferred-path-routing]
Bryant, S., Chunduri, U., and A. Clemm, "Preferred Path
Routing Framework", Work in Progress, Internet-Draft,
draft-chunduri-rtgwg-preferred-path-routing-03, 7 November
2022, <https://datatracker.ietf.org/doc/html/draft-
chunduri-rtgwg-preferred-path-routing-03>.
[I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
"User Plane Protocol and Architectural Analysis on 3GPP 5G
System", Work in Progress, Internet-Draft, draft-ietf-dmm-
5g-uplane-analysis-04, 2 November 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-5g-
uplane-analysis-04>.
[I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
and D. Voyer, "Segment Routing IPv6 for Mobile User
Plane", Work in Progress, Internet-Draft, draft-ietf-dmm-
srv6-mobile-uplane-24, 17 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-
srv6-mobile-uplane-24>.
[I-D.ietf-teas-ietf-network-slices]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
K., Contreras, L. M., and J. Tantsura, "A Framework for
IETF Network Slices", Work in Progress, Internet-Draft,
draft-ietf-teas-ietf-network-slices-19, 21 January 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-19>.
[IR.34-GSMA]
GSM Association (GSMA), "Guidelines for IPX Provider
Networks (Previously Inter-Service Provider IP Backbone
Guidelines, Version 14.0", August 2018.
[ORAN-WG4.CUS-O-RAN]
O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
Control, User and Synchronization Plane Specification;
v2.0.0", August 2019.
Chunduri, et al. Expires 21 October 2023 [Page 22]
Internet-Draft Mobility aware Transport Network Slicing April 2023
[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,
<https://www.rfc-editor.org/info/rfc3209>.
[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,
<https://www.rfc-editor.org/info/rfc8370>.
[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>.
[TS.23.501-3GPP]
3rd Generation Partnership Project (3GPP), "System
Architecture for 5G System; Stage 2, 3GPP TS 23.501
v2.0.1", December 2017.
[TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "Procedures for
5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December
2017.
[TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "Policy and
Charging Control System for 5G Framework; Stage 2, 3GPP TS
23.503 v1.0.0", December 2017.
[TS.28.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.
Chunduri, et al. Expires 21 October 2023 [Page 23]
Internet-Draft Mobility aware Transport Network Slicing April 2023
[TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "GPRS Tunneling
Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
December 2018.
[TS.38.300-3GPP]
3rd Generation Partnership Project (3GPP), "NR; NR and NG-
RAN Overall Description; Stage 2; v15.7.0", September
2019.
[TS.38.401-3GPP]
3rd Generation Partnership Project (3GPP), "NG-RAN;
Architecture description; v15.7.0", September 2019.
Appendix A. 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 21 October 2023 [Page 24]
Internet-Draft Mobility aware Transport Network Slicing April 2023
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 with MPLS, IPv6 with
SRH, native IPv6 and native IPv4 underlays. Few integrated mobility
scenarios with PPR are documented in
[I-D.chunduri-dmm-5g-mobility-with-ppr].
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, TNO 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
Uma Chunduri (editor)
Intel Corporation
2191 Laurelwood Rd
Santa Clara, CA 95054
United States of America
Chunduri, et al. Expires 21 October 2023 [Page 25]
Internet-Draft Mobility aware Transport Network Slicing April 2023
Email: umac.ietf@gmail.com
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 21 October 2023 [Page 26]