< draft-ietf-dmm-tn-aware-mobility-00.txt   draft-ietf-dmm-tn-aware-mobility-01.txt >
DMM Working Group U. Chunduri, Ed. DMM Working Group U.C. Chunduri, Ed.
Internet-Draft J. Kaippallimalil, Ed. Internet-Draft Intel
Intended status: Informational Futurewei Intended status: Informational J.K. Kaippallimalil, Ed.
Expires: September 9, 2021 S. Bhaskaran Expires: 26 March 2022 Futurewei
S.B. Bhaskaran
Altiostar Altiostar
J. Tantsura J.T. Tantsura
Juniper Networks Microsoft
P. Muley P.M. Muley
Nokia Nokia
March 8, 2021 22 September 2021
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-ietf-dmm-tn-aware-mobility-00 draft-ietf-dmm-tn-aware-mobility-01
Abstract Abstract
This document specifies a framework and mapping from slices in 5G This document specifies a framework and mapping of slices in 5G
mobile systems to transport slices in IP, Layer 2 and Layer 1 mobile systems to transport network slices in IP, Layer 2 or Layer 1
transport networks. Slices in 5G systems are characterized by transport networks. Slices in 5G systems are characterized by
latency bounds, reservation guarantees, jitter, data rates, latency bounds, reservation guarantees, jitter, data rates,
availability, mobility speed, usage density, criticality and availability, mobility speed, usage density, criticality and
priority. These characteristics should be mapped to the transport priority. These characteristics mapped to transport network slice
network slice characteristics that include bandwidth, latency and include bandwidth, latency and criteria such as isolation,
criteria such as isolation, directionality and disjoint routes. directionality and disjoint routes. Mobile slice criteria are mapped
Mobile slice criteria need to be mapped to the appropriate transport to the appropriate transport slice and capabilities offered in
slice and capabilities offered in backhaul, midhaul and fronthaul backhaul, midhaul and fronthaul connectivity segments between radio
connectivity segments between radio side network functions and user side network functions and user plane function(gateway).
plane function(gateway).
This document describes how mobile network functions map its slice This document describes how mobile network functions map its slice
criteria to identifiers in IP and Layer 2 packets that transport criteria to identifiers in IP and Layer 2 packets that transport
network segments use to grant transport layer services during UE network segments use to grant transport layer services during UE
mobility scenarios. Applicability of this framework and underlying mobility scenarios. Applicability of this framework and underlying
transport networks, which can enable different slice properties are transport networks, which can enable different slice properties are
also discussed. This is based on mapping between mobile and also discussed. This is based on mapping between mobile and
transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4). transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).
Requirements Language Requirements Language
skipping to change at page 2, line 20 skipping to change at page 2, line 15
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2021. This Internet-Draft will expire on 26 March 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4 1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5
1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Transport and Slice aware Mobility in 5G Networks . . . . . . 7 2. Transport and Slice aware Mobility in 5G Networks . . . . . . 7
2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 8 2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 9
2.1.1. IETF Network Slicing Applicability . . . . . . . . . 10 2.1.1. IETF Network Slicing Applicability . . . . . . . . . 10
2.1.2. Front Haul Transport Network . . . . . . . . . . . . 10 2.1.2. Fronthaul Transport Network . . . . . . . . . . . . . 10
2.2. Mobile Transport Network Context (MTNC) and Scalability . 10 2.2. Mobile Transport Network Context (MTNC) and
Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Transport Network Function (TNF) . . . . . . . . . . . . 11 2.3. Transport Network Function (TNF) . . . . . . . . . . . . 11
2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 12 2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 12
2.5. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 13 2.5. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 14
2.6. Functionality for E2E Management . . . . . . . . . . . . 14 2.6. Functionality for E2E Management . . . . . . . . . . . . 15
3. Transport Network Underlays . . . . . . . . . . . . . . . . . 17
3. Transport Network Underlays . . . . . . . . . . . . . . . . . 16 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 17
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Transport Network Technologies . . . . . . . . . . . . . 19
3.2. Transport Network Technologies . . . . . . . . . . . . . 18 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20
7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. New Control Plane and User Planes . . . . . . . . . 22 Appendix A. New Control Plane and User Planes . . . . . . . . . 23
A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 22 A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 23
A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 23 A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP], The 3GPP architecture for 5GS defined in [TS.23.501-3GPP],
[TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a [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. The 5GS (5G System) architecture also defines a
comprehensive set of functions for access mobility, session handling comprehensive set of functions for access mobility, session handling
and related functions for subscription management, authentication and and related functions for subscription management, authentication and
policy among others. These network functions (NF) are defined using policy among others. These network functions (NF) are defined using
a service-based architecture (SBA) that allows NFs to expose their a service-based architecture (SBA) that allows NFs to expose their
functions via an API and common service framework. functions via an API and common service framework.
UPFs are the data forwarding entities in the 5GC architecture. The IP transport is used to interconnect the data forwarding entities
architecture allows the placement of Branching Point (BP) and Uplink UPFs, gNB-CU and gNB-DU in the 5GC and NG-RAN architecture but 3GPP
Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- specifications only define the interfaces (N3, N9, F1U etc.) and the
AN can be a radio access network or any non-3GPP access network, for 3GPP transport end points [TS.28.541-3GPP]. The architecture allows
example, WLAN. The IP address is anchored by a PDU session anchor the placement of Branching Point (BP) and Uplink Classifier (ULCL)
UPF (PSA UPF). 3GPP slicing and RAN aspects are further described in UPFs closer to the access network (5G-AN). The gNB-CU and gNB-DU are
Appendix A.1. the centralized unit (CU) and distributed unit (DU) of a 5G radio
access network (NG-RAN) with gNB. The 5G-AN can be a radio access
network (NG-RAN) or any non-3GPP access network, for example, WLAN.
The IP address is anchored by a PDU session anchor UPF (PSA UPF).
3GPP slicing and RAN aspects are further described in Appendix A.1.
5GS allows more than one UPF on the path for a PDU (Protocol Data 5GS allows more than one UPF on the path for a PDU (Protocol Data
Unit) session that provides various functionality including session Unit) session that provides various functionality including session
anchoring, uplink classification and branching point for a multihomed anchoring, uplink classification and branching point for a multihomed
IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA
UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9 UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9
and N3 interface between the various UPF instances and the (R)AN and and N3 interfaces between the various UPF instances and the (R)AN and
also, for the F1-U interface between the DU and the CU in the RAN. also, for the F1-U interface between the DU and the CU in the NG-RAN.
3GPP has specified control and user plane aspects in [TS.23.501-3GPP] 3GPP has specified control and user plane aspects in [TS.23.501-3GPP]
to provide slice and QoS support. 3GPP has defined three broad slice to provide slice and QoS support. 3GPP has defined three broad slice
types to cover enhanced mobile broadband (eMBB) communications, types to cover enhanced mobile broadband (eMBB) communications,
ultra-reliable low latency communications(URLLC) and massive internet ultra-reliable low latency communications(URLLC) and massive internet
of things (mIoT). ATIS [ATIS075] has defined an additional slice of things (mIoT). ATIS [ATIS075] has defined an additional slice
type for V2X services. There may be multiple instances of a slice type for V2X services. 3GPP slice types and multiple instances of a
type to satisfy some characteristics like isolation. The slice slice type satisfy various characteristics for 5G network resources
details in 3GPP, ATIS or NGMN do not specify how slice The slice details in 3GPP, ATIS or NGMN do not specify how slice
characteristics for QoS, hard /soft isolation, protection and other characteristics for QoS, hard /soft isolation, protection and other
aspects should be satisfied in IP transport networks. aspects should be satisfied in IP transport networks.
A transport underlay across each 3GPP segment may have multiple A transport underlay across each 3GPP segment may have multiple
technologies or providers on path and the slice in 3GPP domain should technologies or providers on path and the slice in 3GPP domain should
have a corresponding mapping in the transport domain. The document have a corresponding mapping in the transport domain. This document
proposes to map a slice in the 3GPP domain to a transport domain proposes to map a slice in the 3GPP domain to a transport domain
slice. The document also proposes to carry this provisioned mapping slice. This document also proposes to carry this provisioned mapping
in an IP packet so that the IP transport domain can classify and in an IP packet so that the IP transport domain can classify and
provide the requisite service.This is explored further in this provide the required service. This is explored further in this
document. document.
1.1. IETF Network Slicing Terminology 1.1. IETF Network Slicing Terminology
[I-D.ietf-teas-ietf-network-slice-definition] draft defines the 'IETF [I-D.ietf-teas-ietf-network-slices] draft defines the 'IETF Network
Network slice', its scope and characteristics. It lists use cases slice', its scope and characteristics. It lists use cases where IETF
where IETF technologies can be used for slicing solutions, for technologies can be used for slicing solutions, for various
various connectivity segments. Transport slice terminology as used connectivity segments. Transport slice terminology as used in this
in this document refers to the connectivity segment between various document refers to the connectivity segment between various 5G
5G systems and some of these segments are referred to as IETF Network 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. slices.
[I-D.nsdt-teas-ns-framework] defines a generic framework based on the [I-D.ietf-teas-ietf-network-slices] also defines a generic framework
[I-D.ietf-teas-ietf-network-slice-definition] and how abstract and how abstract requests to set up slices can be mapped to more
requests to set up slices can be mapped to more specific technologies specific technologies (e.g., VPN and traffic-engineering
(e.g., VPN and traffic-engineering technologies). This document is technologies). This document is aimed to be specific to 3GPP use
aimed to be specific to 3GPP use case where many such connectivity case where many such connectivity segments are used in E2E slicing
segments are used in E2E slicing solutions. Some of the solutions. Some of the terminologies defined in these referred
terminologies defined in these referred drafts and applicability to drafts and applicability to this document are further described in
this document are further described in Section 2.1.1. Section 2.1.1.
1.2. Problem Statement 1.2. Problem Statement
5GS defines network slicing as one of the core capabilities of 5GC 5GS defines network slicing as one of the core capabilities of 5GC
with slice awareness from Radio and 5G Core (5GC) network. The 5G with slice awareness from Radio and 5G Core (5GC) network. The 5G
System (5GS) as defined, does not consider the resources and System (5GS) as defined in 3GPP specifications, does not consider the
functionalities needed from the transport network for the selection resources and functionalities needed from the transport network for
of UPF. This is seen as independent functionality and currently not the selection of UPF. This is seen as independent functionality and
part of 5GS. is currently not part of 5GS.
However, the lack of underlying Transport Network (TN) awareness may However, the lack of underlying Transport Network (TN) awareness may
lead to selection of sub-optimal UPF(s) and/or 5G-AN during various lead to selection of sub-optimal UPF(s) and/or 5G-AN during various
procedures in 5GS (e.g., session establishment and various mobility procedures in 5GS (e.g., session establishment and various mobility
scenarios). Meeting the specific slice characteristics on the F1-U, scenarios). Meeting the specific slice characteristics on the F1-U,
N3, N9 interfaces depends on the IP transport underlay providing N3 and N9 interfaces depends on the IP transport underlay providing
these resources and capabilities. This could also lead to the these resources and capabilities. This could also lead to the
inability in meeting SLAs for real-time, mission-critical or latency inability in meeting SLAs for real-time, mission-critical or latency
sensitive services. sensitive services.
The 5GS provides slices to its clients (UEs). The UE's PDU session The 5GS provides slices to its clients (UEs). The UE's PDU session
spans the access network (radio network including the F1-U) and N3 spans the access network (radio access network including the F1-U)
and N9 transport segments which have an IP transport underlay. The and N3 and N9 transport segments which have an IP transport underlay.
5G operator needs to obtain slice capability from the IP transport The 5G operator needs to obtain slice capability from the IP
provider. Several UE sessions that match a slice may be mapped to an transport provider. Several UE sessions that match a slice may be
IP transport segment. Thus, there needs to be a mapping between the mapped to an IP transport segment. Thus, there needs to be a mapping
slice capability offered to the UE (S-NSSAI) and what is provided by between the slice capability offered to the UE (S-NSSAI) and what is
the IP transport. provided by the IP transport.
1.3. Solution Approach 1.3. Solution Approach
This document specifies an approach to fulfil the needs of 5GS to This document specifies an approach to fulfil the needs of 5GS to
transport user plane traffic from 5G-AN to UPF in an optimized transport user plane traffic from 5G-AN (including NG-RAN) to UPF in
fashion. This is done by keeping establishment and mobility an optimized fashion. This is done by keeping establishment and
procedures aware of the underlying transport network along with mobility procedures aware of the underlying transport network along
slicing requirements. with slicing requirements.
Section 2 describes in detail on how TN aware mobility can be built Section 2 describes in detail on how TN aware mobility can be built
irrespective of underlying TN technology used. How other IETF TE irrespective of underlying TN technology used. How other IETF TE
technologies applicable for this draft is specified in Section 3.2. technologies applicable for this draft is specified in Section 3.2.
1.4. Acronyms 1.4. Acronyms
5QI - 5G QoS Indicator 5QI - 5G QoS Indicator
5G-AN - 5G Access Network 5G-AN - 5G Access Network
AMF - Access and Mobility Management Function (5G) AMF - Access and Mobility Management Function (5G)
BP - Branch Point (5G) BP - Branch Point (5G)
CSR - Cell Site Router CSR - Cell Site Router
CP - Control Plane (5G) CP - Control Plane (5G)
CU - Centralized Unit (5G, gNB) CU - Centralized Unit (5G, gNB)
DN - Data Network (5G) DN - Data Network (5G)
DU - Distributed Unit (5G, gNB) DU - Distributed Unit (5G, gNB)
eMBB - enhanced Mobile Broadband (5G) eMBB - enhanced Mobile Broadband (5G)
FRR - Fast ReRoute FRR - Fast ReRoute
gNB - 5G NodeB
gNB - 5G NodeB GBR - Guaranteed Bit Rate (5G)
GBR - Guaranteed Bit Rate (5G) GTP-U - GPRS Tunneling Protocol - User plane (3GPP)
GTP-U - GPRS Tunneling Protocol - Userplane (3GPP)
IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3) IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)
LFA - Loop Free Alternatives (IP FRR) LFA - Loop Free Alternatives (IP FRR)
mIOT - Massive IOT (5G) mIOT - Massive IOT (5G)
MPLS - Multi Protocol Label Switching MPLS - Multi Protocol Label Switching
NSSMF - Network Slice Selection Management Function NG-RAN - Next Generation Radio Access Network (i.e., gNB, NG-eNB -
RAN functions which connect to 5GC)
QFI - QoS Flow ID (5G) NSSMF - Network Slice Selection Management Function
PPR - Preferred Path Routing QFI - QoS Flow ID (5G)
PDU - Protocol Data Unit (5G) PPR - Preferred Path Routing
PW - Pseudo Wire PDU - Protocol Data Unit (5G)
RAN - Radio Access Network PW - Pseudo Wire
RQI - Reflective QoS Indicator (5G) RAN - Radio Access Network (i.e 3GPP radio access network used
synonymously with NG-RAN in this document)
SBI - Service Based Interface (5G) RAN - Radio Access Network
SID - Segment Identifier RQI - Reflective QoS Indicator (5G)
SMF - Session Management Function (5G) SBI - Service Based Interface (5G)
SSC - Session and Service Continuity (5G) SID - Segment Identifier
SST - Slice and Service Types (5G) SMF - Session Management Function (5G)
SR - Segment Routing SSC - Session and Service Continuity (5G)
TE - Traffic Engineering SST - Slice and Service Types (5G)
ULCL - Uplink Classifier (5G) SR - Segment Routing
UP - User Plane(5G) TE - Traffic Engineering
ULCL - Uplink Classifier (5G)
UPF - User Plane Function (5G) UP - User Plane(5G)
URLLC - Ultra reliable and low latency communications (5G) UPF - User Plane Function (5G)
URLLC - Ultra reliable and low latency communications (5G)
2. Transport and Slice aware Mobility in 5G Networks 2. Transport and Slice aware Mobility in 5G Networks
3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing 3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing
in 5GS. However, the application of 5GS slices in transport network in 5GS and is provided here for information. The application of 5GS
for backhaul, mid-haul and front haul are not explicitly covered. To slices in transport network for backhaul, mid-haul and front haul are
support specific characteristics in backhaul (N3, N9), mid-haul (F1) not explicitly covered in 3GPP and is the topic here. To support
and front haul, it is necessary to map and provision corresponding 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 resources in the transport domain. This section describes how to
provision the mapping information in the transport network and apply provision the mapping information in the transport network and apply
it so that user plane packets can be provided the transport resources it so that user plane packets can be provided the transport resources
(QoS, isolation, protection, etc.) expected by the 5GS slices. (QoS, isolation, protection, etc.) expected by the 5GS slices.
The figure shows the entities on path for a 3GPP Network Functions The figure shows the entities on path for 3GPP Network Functions
(gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an (gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an
IP/L2 transport network. IP/L2 transport network.
5G Control and Management Planes 5G Control and Management Planes
+------------------------------------------------------------------------+ +------------------------------------------------------------------------+
| +--------------------------------------------------------------------+ | | +--------------------------------------------------------------------+ |
| | (TNF) 5G Management Plane (TNF) | | | | (TNF) 5G Management Plane (TNF) | |
| +----+-----------------+-------------+---------------+-----------+---+ | | +----+-----------------+-------------+---------------+-----------+---+ |
| | | | | | | | | | | | | |
| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ | | +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
skipping to change at page 8, line 36 skipping to change at page 8, line 36
| | __/ \__ +--+---+ __/ \__ +-+-+ | | __/ \__ +--+---+ __/ \__ +-+-+
| | / IP \ | gNB | / IP \ | | | | / IP \ | gNB | / IP \ | |
UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
+----------+ \__ __/ +------+ \__ __/ +---+ +----------+ \__ __/ +------+ \__ __/ +---+
\______/ \______/ \______/ \______/
|------ F1-U -------| |------ N3 OR N9 ------| |------ F1-U -------| |------ N3 OR N9 ------|
* Radio and Fronthaul * Radio and Fronthaul
Figure 1: Backhaul and Mid-haul Transport Network for 5G Figure 1: Backhaul and Mid-haul Transport Network for 5G
2.1. Backhaul and Mid-Haul Transport Network 2.1. Backhaul and Mid-Haul Transport Network
Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge) Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)
routers providing IP transport service to 5GS user plane entities 5G- routers providing IP transport service to 5GS user plane entities 5G-
AN (e.g. gNB) and UPF. 5GS architecture with high level management, AN (e.g. gNB) and UPF. 5GS architecture with high level management,
control and user plane entities and its interaction with the IP control and user plane entities and its interaction with the IP
transport plane is shown here. The slice capability required in IP transport plane is shown here. The slice capability required in IP
transport networks are estimated and provisioned by the functionality transport networks are estimated and provisioned by the functionality
as specified in Section 2.3 (TNF) with support from various other as specified in Section 2.3 (TNF) with support from various other
skipping to change at page 9, line 4 skipping to change at page 9, line 19
AN (e.g. gNB) and UPF. 5GS architecture with high level management, AN (e.g. gNB) and UPF. 5GS architecture with high level management,
control and user plane entities and its interaction with the IP control and user plane entities and its interaction with the IP
transport plane is shown here. The slice capability required in IP transport plane is shown here. The slice capability required in IP
transport networks are estimated and provisioned by the functionality transport networks are estimated and provisioned by the functionality
as specified in Section 2.3 (TNF) with support from various other as specified in Section 2.3 (TNF) with support from various other
control plane functions such as the Network Data Analytics Function control plane functions such as the Network Data Analytics Function
(NWDAF), Network Function Repository Function (NRF) and Policy (NWDAF), Network Function Repository Function (NRF) and Policy
Control Function (PCF). The TNF is only a logical function that may Control Function (PCF). The TNF is only a logical function that may
be realized in a 3GPP management function such as Network Slice be realized in a 3GPP management function such as Network Slice
Selection Management Function (NSSMF) defined in [TS.28.533-3GPP]. Selection Management Function (NSSMF) defined in [TS.28.533-3GPP].
The TNF requests the SDN-C to provision the IP XHaul network using The TNF requests the SDN-C to provision the IP XHaul network using
ACTN [RFC8453]. ACTN [RFC8453].
The 5G management plane in Figure 1 interacts with the 5G control The 5G management plane in Figure 1 interacts with the 5G control
plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and
gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS) gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS)
signaling from the UE for session management, mobility is handled by signaling from the UE for session management, mobility is handled by
the 5GC. When a UE initiates session establishment, it indicates the the 5GC. When a UE initiates session establishment, it indicates the
desired slice type in the S-NSSAI (Specific Network Slice Selection desired slice type in the S-NSSAI (Specific Network Slice Selection
Assistance Information) field. The AMF uses the S-NSSAI, other Assistance Information) field. The AMF uses the S-NSSAI, other
subscription information and configuration in the NSSF to select the subscription information and configuration in the NSSF to select the
appropriate SMF and the SMF in turn selects UPFs (User Plane appropriate SMF and the SMF in turn selects UPFs (User Plane
Functions) that are able to provide the specified slice resources and Functions) that are able to provide the specified slice resources and
capabilities. capabilities.
The AMF, SMF, NSSF, PCF, NRF, NWDAF and other control functions in 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 5GC are described in [TS.23.501-3GPP]. Some of the slice
along the user plane path between the (R)AN and UPFs (F1-U, N3, N9 capabilities along the user plane path between the (R)AN and UPFs
segments) such as a low latency path, jitter, protection and priority (F1-U, N3, N9 segments) such as a low latency path, jitter,
needs these to be provided by the IP transport network. 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 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 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 between gNB - UPF; N9 between UPFs). If the RAN uses lower layer
split architecture as specified by O-RAN alliance, then the user split architecture as specified by O-RAN alliance, then the user
plane path from UE to DN also includes the fronthaul interface. The plane path from UE to DN also includes the fronthaul interface. The
fronthaul interface carries the radio frames in the form of In-phase fronthaul interface carries the radio frames in the form of In-phase
(I) and Quadrature (Q) samples using eCPRI encapsulation over (I) and Quadrature (Q) samples using eCPRI encapsulation over
Ethernet or UDP over IP. Ethernet or UDP over IP.
The N3, N9 and F1 user planes use GTP-U [TS.29.281-3GPP] to transport The N3, N9 and F1-U user planes use GTP-U [TS.29.281-3GPP] to
UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). For the transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
front haul described further in Section 2.1.2, an Ethernet transport For the front-haul described further in Section 2.1.2, an Ethernet
with VLANs can be expected to be the case in many deployments. transport with VLANs can be expected to be the case in many
deployments.
Figure 1 also depicts the PE router, where transport paths are Figure 1 also depicts the PE router, where transport paths are
initiated/terminated can be deployed separately with UPF or both initiated/terminated can be deployed separately with UPF or both
functionalities can be in the same node. The TNF provisions this in 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 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 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 information traverses the F1-U/N3/N9 segment, the PE router of the IP
transport underlay can inspect the slice information and provide the transport underlay can inspect the slice information and provide the
provisioned capabilities. This is elaborated further in Section 2.4. provisioned capabilities. This is elaborated further in Section 2.4.
2.1.1. IETF Network Slicing Applicability 2.1.1. IETF Network Slicing Applicability
Some of the functional elements depicted in the Figure 1 can be Some of the functional elements depicted in the Figure 1 can be
mapped to the terminology set forth in the mapped to the terminology set forth in the
[I-D.ietf-teas-ietf-network-slice-definition]. From 3GPP [I-D.ietf-teas-ietf-network-slices]. From 3GPP perspective, UE and
perspective, UE and UPF are the network slice endpoints and routers, UPF are the network slice endpoints and routers, gNB-DU, gNB-CU,
gNB-DU, gNB-CU, switches, PE nodes are the slice realization switches, PE nodes are the slice realization endpoints. The TNF
endpoints. The TNF represented in the Figure 1 can be seen as IETF represented in the Figure 1 can be seen as IETF Network Slice
Network Slice Controller (NSC) functionality and SDN-C maps to Controller (NSC) functionality and SDN-C maps to Network Controller
Network Controller (NC). NSC-NBI interface is the interface from (NC). NSC-NBI interface is the interface from 3GPP Management plane
3GPP Management plane (e.g., NSSMF) and NSC-SBI interface is the (e.g., NSSMF) and NSC-SBI interface is the interface between TNF and
interface between TNF and SDN-C. Various possibilities for SDN-C. Various possibilities for implementation of these interfaces
implementation of these interfaces and the relation to ACTN are and the relation to ACTN are also further described in the
further described in the [I-D.nsdt-teas-ns-framework]. [I-D.ietf-teas-ietf-network-slices].
2.1.2. Front Haul Transport Network 2.1.2. Fronthaul Transport Network
The O-RAN Alliance has specified the fronthaul interface between the 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 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 information, in the form of In-phase (I) and Quadrature (Q) samples
are transported using Enhanced Common Public Radio Interface (eCPRI) are transported using Enhanced Common Public Radio Interface (eCPRI)
framing over Ethernet or UDP. On the Ethernet based fronthaul framing over Ethernet or UDP. On the Ethernet based fronthaul
interface, the slice information is carried in the Ethernet header interface, the slice information can be carried in the Ethernet
through the VLAN tags. The Ethernet switches in the fronthaul header through the VLAN tags. The Ethernet switches in the fronthaul
transport network can inspect the slice information (VLAN tag) in the transport network can inspect the slice information (VLAN tag) in the
Ethernet header and provide the provisioned capabilities. The Ethernet header and provide the provisioned capabilities. The
mapping of I and Q samples of different radio resources (radio mapping of I and Q samples of different radio resources (radio
resource blocks or carriers etc.,.) to different slices and to their resource blocks or carriers etc.,.) to different slices and to their
respective VLAN tags on the fronthaul interface is controlled by the respective VLAN tags on the fronthaul interface is controlled by the
O-RAN fronthaul C-Plane and M-Plane interfaces. On a UDP based O-RAN fronthaul C-Plane and M-Plane interfaces. On a UDP based
fronthaul interface, the slice information is carried in the IP or fronthaul interface, the slice information can be carried in the IP
UDP header. The PE routers of the fronthaul transport network can 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 inspect the slice information in the IP or UDP header and provide the
provisioned capabilities. The fronthaul transport network is latency provisioned capabilities. The fronthaul transport network is latency
and jitter sensitive. The provisioned slice capabilities in the and jitter sensitive. The provisioned slice capabilities in the
fronthaul transport network MUST take care of the latency and jitter fronthaul transport network MUST take care of the latency and jitter
budgets of the specific slice for the fronthaul interface. The budgets of the specific slice for the fronthaul interface. The
provisioning of the fronthaul transport network is handled by the provisioning of the fronthaul transport network is handled by the
SDN-C pertaining to the fronthaul transport. SDN-C pertaining to the fronthaul transport.
2.2. Mobile Transport Network Context (MTNC) and Scalability 2.2. Mobile Transport Network Context (MTNC) and Scalability
The MTNC represents a slice, QoS configuration for a transport path The MTNC represents a slice of a transport path for a tenant between
between two 3GPP user plane functions. The Mobile-Transport Network two 3GPP user plane functions. The Mobile-Transport Network Context
Context Identifier (MTNC-ID) is generated by the TNF to be unique for Identifier (MTNC-ID) is generated by the TNF to be unique for each
each path and per traffic class (including QoS and slice aspects). instance (for a tenant) and per traffic class (including QoS and
Thus, there may be more than one MTNC-ID for the same QoS and path if slice aspects). Thus, there may be more than one MTNC-ID for the
there is a need to provide isolation (slice) of the traffic. It same QoS and instance if there is a need to provide isolation (slice)
should be noted that MTNC are per class/path and not per user session of the traffic. It should be noted that MTNC are per class/instance
(nor is it per data path entity). The MTNC-IDs are configured by the and not per user session. The MTNC-IDs are configured by the TNF to
TNF to be unique within a provisioning domain. be unique within a provisioning domain.
Since the MTNC-IDs are not generated per user flow or session, there Since the MTNC-IDs are generated per instance / tenant, there is no
is no need for unique MTNC-IDs per flow/session. In addition, since need for unique MTNC-IDs per flow/session. In addition, since the
the traffic estimation is not performed at the time of session traffic estimation is performed prior to UE's session establishment,
establishment, there is no provisioning delay experienced during there is no provisioning delay experienced by the UE during its
session setup. The MTNC-ID space scales as a square of the number session setup. For an instance/tenant, the MTNC-ID space scales
sites between which 3GPP user plane functions require paths. If roughly as a square of the number sites between which 3GPP user plane
there are T traffic classes across N sites, the number of MTNC-IDs in functions have paths. If there are T traffic classes across N sites,
a fully meshed network is (N*(N-1)/2) * T. For example, if there are the number of MTNC-IDs in a fully meshed network is (N*(N-1)/2) * T.
3 traffic classes between 25 sites, there would be at most 900 MTNC- For example, if there are 3 traffic classes between 25 sites, there
IDs required. Multiple slices for the same QoS class that need to be would be at most 900 MTNC-IDs required. Multiple instances/tenants
fully isolated, will add to the MTNC provisioning. An MTNC-ID space that need to be fully isolated, will add to the MTNC provisioning.
of 16 bits (65K+ identifiers) can be expected to be sufficient. An MTNC-ID space of 16 bits (65K identifiers) can be expected to be
sufficient.
2.3. Transport Network Function (TNF) 2.3. Transport Network Function (TNF)
Figure 1 shows a view of the functions and interfaces for Figure 1 shows a view of the functions and interfaces for
provisioning the MTNC-IDs. The focus is on provisioning between the provisioning the MTNC-IDs. The focus is on provisioning between the
3GPP management plane (NSSMF), transport network (SDN-C) and carrying 3GPP management plane (NSSMF), transport network (SDN-C) and carrying
the MTNC-IDs in PDU packets for the transport network to grant the the MTNC-IDs in PDU packets for the transport network to grant the
provisioned resources. provisioned resources.
In Figure 1, the TNF (logical functionality within the NSSMF) In Figure 1, the TNF (logical functionality within the NSSMF)
skipping to change at page 13, line 36 skipping to change at page 14, line 16
When the 3GPP user plane function (5G-AN, UPF) and transport provider 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 edge is on different nodes, the PE router needs to have the means by
which to classify the PDU packet. The mapping information is which to classify the PDU packet. The mapping information is
provisioned between the 5G provider and IP transport network and provisioned between the 5G provider and IP transport network and
corresponding information should be carried in each IP packet on the corresponding information should be carried in each IP packet on the
F1-U, N3, N9 interface. To allow the IP transport edge nodes to F1-U, N3, N9 interface. To allow the IP transport edge nodes to
inspect the transport context information efficiently, it should be inspect the transport context information efficiently, it should be
carried in an IP header field that is easy to inspect. It may 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. noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces.
Thus, Layer 2 alternatives such as VLAN will fail if there are If the fronthaul, midhaul or backhaul IP path is bounded by an L2
multiple L2 networks on the F1-U or N3 or N9 path. GTP (F1-U, N3, N9 network, one option maybe to use VLANs to carry the MTNC-ID. 3GPP
encapsulation header) field extensions offer a possibility, however specifications for management plane defines transport end-points
these extensions are hard for a transport edge router to parse configuration in [TS.28.541-3GPP]. However, Layer 2 alternatives
efficiently on a per packet basis. Other IP header fields like DSCP such as VLAN will fail in L3/routed networks on the F1-U, N3 or N9
are not suitable as it only conveys the QoS aspects (but not other path. GTP-U (F1-U, N3, N9 encapsulation header) field extensions
aspects like isolation, protection, etc.) 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,
etc.)
IPv6 extension headers like SRv6 may be options to carry the MTNC-ID While IPv6 extension headers like SRv6 may be an option to carry the
when such a mechanism is a viable (if a complete transport network is MTNC-ID that requires the end-to-end network to be IPv6 as well as
IPv6 based). To minimise the protocol changes are required and make the capability to lookup the extension header at line rate. To
this underlay transport independent (IPv4/IPv6/MPLS/L2), an option is minimise the protocol changes and make this underlay transport
to provision a mapping of MTNC-ID to a UDP port range of the GTP independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping
encapsulated user packet. A simple mapping table between the MTNC-ID of MTNC-ID to a UDP port range of the GTP encapsulated user packet.
and the source UDP port number can be configured to ensure that ECMP A simple mapping table between the MTNC-ID and the source UDP port
/load balancing is not affected adversely by encoding the UDP source number can be configured to ensure that ECMP /load balancing is not
port with an MTNC-ID mapping. This mapping is configured in 3GPP affected adversely by encoding the UDP source port with an MTNC-ID
user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that 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. process MTNC-IDs.
PE routers can thus provision a policy based on the source UDP port PE routers can thus provision a policy based on the source UDP port
number (which reflects the mapped MTNC-ID) to the underlying number (which reflects the mapped MTNC-ID) to the underlying
transport path and then deliver the QoS/slice resource provisioned in transport path and then deliver the QoS/slice resource provisioned in
the transport network. The source UDP port that is encoded is the the transport network. The source UDP port that is encoded is the
outer IP (corresponding to GTP header) while the inner IP packet (UE outer IP (corresponding to GTP-U header) while the inner IP packet
payload) is unaltered. The source UDP port is encoded by the node (UE payload) is unaltered. The source UDP port is encoded by the
that creates the GTP-U encapsulation and therefore, this mechanism node that creates the GTP-U encapsulation and therefore, this
has no impact on UDP checksum calculations. mechanism has no impact on UDP checksum calculations.
3GPP network operators may use IPSec gateways (SEG) to secure packets 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 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 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 port even after IPSec encryption for PE transport routers to inspect
and provide the level of service provisioned. Tunnel mode - which is 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 the case for SEG/IPSec gateways - adds an outer IP header in both AH
(Authenticated Header) and ESP (Encapsulated Security Payload) modes. (Authenticated Header) and ESP (Encapsulated Security Payload) modes.
The GTP-U / UDP source port with encoded MTNC identifier should be 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 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 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 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 balancing entropy for ECMP will not be affected as the MTNC encoding
mechanism already accounts for this. mechanism already accounts for this.
If the RAN uses O-RAN lower layer split architecture, then a If the RAN uses O-RAN Alliance lower layer split architecture, then a
fronthaul network is involved. On an Ethernet based fronthaul fronthaul network is involved. On an Ethernet based fronthaul
transport network, VLAN tag may be an option to carry the MTNC-ID. 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 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 to 4096 slices on the fronthaul transport network. The mapping of
fronthaul traffic to corresponding network slices is based on the fronthaul traffic to corresponding network slices is based on the
radio resource for which the fronthaul carries the I and Q samples. radio resource for which the fronthaul carries the I and Q samples.
The mapping of fronthaul traffic to the VLAN tag corresponding to the 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 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 fronthaul transport network, the UDP source port can be used to carry
the MTNC-ID. the MTNC-ID.
2.6. Functionality for E2E Management 2.6. Functionality for E2E Management
With the TNF functionality in 5GS Service Based Interface, the With the TNF functionality in 5GS Service Based Interface, the
following additional functionalities are required for end-2-end slice following additional functionalities are required for end-2-end slice
management including the transport network: management including the transport network:
o The Specific Network Slice Selection Assistance Information * The Specific Network Slice Selection Assistance Information
(S-NSSAI) of PDU session SHOULD be mapped to the assigned (S-NSSAI) of PDU session SHOULD be mapped to the assigned
transport VPN and the TE path information for that slice. transport VPN and the TE path information for that slice.
o For transport slice assignment for various SSTs (eMBB, URLLC, * For transport slice assignment for various SSTs (eMBB, URLLC,
MIoT) corresponding underlay paths need to be created and MIoT) corresponding underlay paths need to be created and
monitored from each transport endpoint (CSR and PE@UPF). monitored from each transport endpoint (CSR and PE@UPF).
o During PDU session creation, apart from radio and 5GC resources, * During PDU session creation, apart from radio and 5GC resources,
transport network resources needed to be verified matching the transport network resources needed to be verified matching the
characteristics of the PDU session traffic type. characteristics of the PDU session traffic type.
o The TNF MUST provide an API that takes as input the source and * The TNF MUST provide an API that takes as input the source and
destination 3GPP user plane element address, required bandwidth, destination 3GPP user plane element address, required bandwidth,
latency and jitter characteristics between those user plane latency and jitter characteristics between those user plane
elements and returns as output a particular TE path's identifier, elements and returns as output a particular TE path's identifier,
that satisfies the requested requirements. that satisfies the requested requirements.
o Mapping of PDU session parameters to underlay SST paths need to be * 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 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 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 "Network Instance" in the UPF. A "Network Instance" is a logical
identifier for an underlying network. The "Network Instance" identifier for an underlying network. The "Network Instance"
pointed by the FAR can be mapped to a transport path (through L2/ pointed by the FAR can be mapped to a transport path (through L2/
L3 VPN). FARs are associated with Packet Detection Rule (PDR). L3 VPN). FARs are associated with Packet Detection Rule (PDR).
PDRs are used to classify packets in the uplink (UL) and the PDRs are used to classify packets in the uplink (UL) and the
downlink (DL) direction. For UL procedures specified in downlink (DL) direction. For UL procedures specified in
Section 2.4, Section 2.5 can be used for classifying a packet Section 2.4, Section 2.5 can be used for classifying a packet
belonging to a particular slice characteristic. For DL, at a PSA belonging to a particular slice characteristic. For DL, at a PSA
UPF, the UE IP address is used to identify the PDU session, and 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 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 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 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 mapping to the underlying TE paths at PE happens based on the
encapsulated GTP-U packet as specified in Section 2.5. encapsulated GTP-U packet as specified in Section 2.5.
o In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if * 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- segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-
UPF) is needed, then corresponding path characteristics MUST be UPF) is needed, then corresponding path characteristics MUST be
used. This includes a path from CSR to PE@UL-CL/BP UPF 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. [TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN.
o Continuous monitoring of the underlying transport path * Continuous monitoring of the underlying transport path
characteristics should be enabled at the endpoints (technologies characteristics should be enabled at the endpoints (technologies
for monitoring depends on traffic engineering technique used as for monitoring depends on traffic engineering technique used as
described in Section 3.2). If path characteristics are degraded, described in Section 3.2). If path characteristics are degraded,
reassignment of the paths at the endpoints should be performed. reassignment of the paths at the endpoints should be performed.
For all the affected PDU sessions, degraded transport paths need For all the affected PDU sessions, degraded transport paths need
to be updated dynamically with similar alternate paths. to be updated dynamically with similar alternate paths.
o During UE mobility events similar to 4G/LTE i.e., gNB mobility (F1 * 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 based, Xn based or N2 based), for target gNB selection, apart from
radio resources, transport resources MUST be factored. This radio resources, transport resources MUST be factored. This
enables handling of all PDU sessions from the UE to target gNB and 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. this require co-ordination of gNB, AMF, SMF with the TNF module.
Integrating the TNF as part of the 5GS Service Based Interfaces, Integrating the TNF as part of the 5GS Service Based Interfaces,
provides the flexibility to control the allocation of required provides the flexibility to control the allocation of required
characteristics from the TN during a 5GS signaling procedure (e.g. characteristics from the TN during a 5GS signaling procedure (e.g.
PDU Session Establishment). If TNF is seen as separate and in a PDU Session Establishment). If TNF is seen as separate and in a
management plane, this real time flexibility is lost. Changes to management plane, this real time flexibility is lost. Changes to
skipping to change at page 16, line 28 skipping to change at page 17, line 20
Apart from the various flavors of IETF VPN technologies to share the Apart from the various flavors of IETF VPN technologies to share the
transport network resources and capacity, TE capabilities in the transport network resources and capacity, TE capabilities in the
underlay network is an essential component to realize the 5G TN underlay network is an essential component to realize the 5G TN
requirements. This section focuses on various transport underlay requirements. This section focuses on various transport underlay
technologies (not exhaustive) and their applicability to realize technologies (not exhaustive) and their applicability to realize
Midhaul/Backhaul transport networks. Focus is on the user/data plane 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. i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.
3.1. Applicability 3.1. Applicability
o For 3 different SSTs, 3 transport TE paths can be signaled from * For 3 different SSTs, 3 transport TE paths can be signaled from
any node in the transport network. For Uplink traffic, the 5G-AN 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 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 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 (corresponds to the MTNC-ID Section 2.4) of the GTP-U
encapsulation header. Similarly in the Downlink direction encapsulation header. Similarly in the Downlink direction
matching Transport TE Path of the 5G-AN is chosen based on the 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 S-NSSAI the PDU Session belongs to. The table below shows a
typical mapping: typical mapping:
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
skipping to change at page 17, line 28 skipping to change at page 18, line 28
| values) | (ultra-low | TE-PATH-B | Req. | | values) | (ultra-low | TE-PATH-B | Req. |
| | latency) | | Bandwidth: By | | | latency) | | Bandwidth: By |
| | | | Delay: Dy | | | | | Delay: Dy |
| | | | Jitter: Jy | | | | | Jitter: Jy |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Zx - Zy | | | | | Range Zx - Zy | | | |
| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
| values) | (broadband)| TE-PATH-C | Bandwidth: Bx | | values) | (broadband)| TE-PATH-C | Bandwidth: Bx |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
Figure 2: Mapping of Transport Paths on F1-U/N3/N9 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 * 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. 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- * Same set of TE Paths are created uniformly across all needed 5G-
ANs and UPFs to allow various mobility scenarios. ANs and UPFs to allow various mobility scenarios.
o Any modification of TE parameters of the path, replacement path * Any modification of TE parameters of the path, replacement path
and deleted path needed to be updated from TNF to the relevant and deleted path needed to be updated from TNF to the relevant
ingress points. Same information can be pushed to the NSSF, and/ ingress points. Same information can be pushed to the NSSF, and/
or SMF as needed. or SMF as needed.
o TE Paths support for native L2, IPv4 and IPv6 data/user planes * TE Paths support for native L2, IPv4 and IPv6 data/user planes
with optional TE features are desirable in some network segments. with optional TE features are desirable in some network segments.
As this is an underlay mechanism it can work with any overlay As this is an underlay mechanism it can work with any overlay
encapsulation approach including GTP-U as defined currently for encapsulation approach including GTP-U as defined currently for
F1-U/N3/N9 interface. F1-U/N3/N9 interface.
In some E2E scenarios, security is desired granularly in the In some E2E scenarios, security is desired granularly in the
underlying transport network. In such cases, there would be a need 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 to have separate sub-ranges under each SST to provide the TE path in
preserving the security characteristics. The UDP Source Port range preserving the security characteristics. The UDP Source Port range
captured in Figure 2 would be sub-divided to maintain the TE path for captured in Figure 2 would be sub-divided to maintain the TE path for
skipping to change at page 20, line 4 skipping to change at page 20, line 49
Xavier De Foy Xavier De Foy
InterDigital Communications, LLC InterDigital Communications, LLC
1000 Sherbrooke West 1000 Sherbrooke West
Montreal Montreal
Canada Canada
Email: Xavier.Defoy@InterDigital.com Email: Xavier.Defoy@InterDigital.com
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References 8.2. Informative References
[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS), [ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),
"IOT Categorization: Exploring the Need for Standardizing "IOT Categorization: Exploring the Need for Standardizing
Additional Network Slices ATIS-I-0000075", September 2019. Additional Network Slices ATIS-I-0000075", September 2019.
[I-D.bogineni-dmm-optimized-mobile-user-plane] [I-D.bogineni-dmm-optimized-mobile-user-plane]
Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D., Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
Rodriguez-Natal, A., Carofiglio, G., Auge, J., Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
Muscariello, L., Camarillo, P., and S. Homma, "Optimized Muscariello, L., Camarillo, P., and S. Homma, "Optimized
Mobile User Plane Solutions for 5G", draft-bogineni-dmm- Mobile User Plane Solutions for 5G", Work in Progress,
optimized-mobile-user-plane-01 (work in progress), June Internet-Draft, draft-bogineni-dmm-optimized-mobile-user-
2018. plane-01, 29 June 2018, <https://www.ietf.org/archive/id/
draft-bogineni-dmm-optimized-mobile-user-plane-01.txt>.
[I-D.ietf-dmm-5g-uplane-analysis] [I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer, Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
"User Plane Protocol and Architectural Analysis on 3GPP 5G "User Plane Protocol and Architectural Analysis on 3GPP 5G
System", draft-ietf-dmm-5g-uplane-analysis-04 (work in System", Work in Progress, Internet-Draft, draft-ietf-dmm-
progress), November 2020. 5g-uplane-analysis-04, 2 November 2020,
<https://www.ietf.org/archive/id/draft-ietf-dmm-5g-uplane-
analysis-04.txt>.
[I-D.ietf-dmm-srv6-mobile-uplane] [I-D.ietf-dmm-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P., Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
Voyer, D., and C. Perkins, "Segment Routing IPv6 for Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09 Mobile User Plane", Work in Progress, Internet-Draft,
(work in progress), July 2020. draft-ietf-dmm-srv6-mobile-uplane-16, 11 August 2021,
<https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-
[I-D.ietf-teas-ietf-network-slice-definition] mobile-uplane-16.txt>.
Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
Tantsura, "Definition of IETF Network Slices", draft-ietf-
teas-ietf-network-slice-definition-00 (work in progress),
January 2021.
[I-D.nsdt-teas-ns-framework] [I-D.ietf-teas-ietf-network-slices]
Gray, E. and J. Drake, "Framework for Transport Network Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
Slices", draft-nsdt-teas-ns-framework-04 (work in Makhijani, K., Contreras, L. M., and J. Tantsura,
progress), July 2020. "Framework for IETF Network Slices", Work in Progress,
Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23
August 2021, <https://www.ietf.org/archive/id/draft-ietf-
teas-ietf-network-slices-04.txt>.
[IR.34-GSMA] [IR.34-GSMA]
GSM Association (GSMA), "Guidelines for IPX Provider GSM Association (GSMA), "Guidelines for IPX Provider
Networks (Previously Inter-Service Provider IP Backbone Networks (Previously Inter-Service Provider IP Backbone
Guidelines, Version 14.0", August 2018. Guidelines, Version 14.0", August 2018.
[ORAN-WG4.CUS-O-RAN] [ORAN-WG4.CUS-O-RAN]
O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group; O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
Control, User and Synchronization Plane Specification; Control, User and Synchronization Plane Specification;
v2.0.0", August 2019. v2.0.0", August 2019.
skipping to change at page 22, line 5 skipping to change at page 23, line 5
[TS.23.503-3GPP] [TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "Policy and 3rd Generation Partnership Project (3GPP), "Policy and
Charging Control System for 5G Framework; Stage 2, 3GPP TS Charging Control System for 5G Framework; Stage 2, 3GPP TS
23.503 v1.0.0", December 2017. 23.503 v1.0.0", December 2017.
[TS.28.533-3GPP] [TS.28.533-3GPP]
3rd Generation Partnership Project (3GPP), "Management and 3rd Generation Partnership Project (3GPP), "Management and
Orchestration Architecture Framework (Release 15)", June Orchestration Architecture Framework (Release 15)", June
2018. 2018.
[TS.28.541-3GPP]
3rd Generation Partnership Project (3GPP), "Management and
orchestration; 5G Network Resource Model (NRM); Stage 2
and stage 3 (Release 17)", June 2020.
[TS.29.281-3GPP] [TS.29.281-3GPP]
3rd Generation Partnership Project (3GPP), "GPRS Tunneling 3rd Generation Partnership Project (3GPP), "GPRS Tunneling
Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0", Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
December 2018. December 2018.
[TS.38.300-3GPP] [TS.38.300-3GPP]
3rd Generation Partnership Project (3GPP), "NR; NR and NG- 3rd Generation Partnership Project (3GPP), "NR; NR and NG-
RAN Overall Description; Stage 2; v15.7.0", September RAN Overall Description; Stage 2; v15.7.0", September
2019. 2019.
skipping to change at page 24, line 5 skipping to change at page 25, line 5
procedures to know, if underlying transport resources are available procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could certain decisions in the 5G CP. One example scenario/decision could
be, a target 5G-AN selection during a N2 mobility event, without be, a target 5G-AN selection during a N2 mobility event, without
knowing if the target 5G-AN is having a underlay transport slice 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 resource for the S-NSSAI and 5QI of the PDU session. The Integrated
approach specified below can mitigate this. approach specified below can mitigate this.
Authors' Addresses Authors' Addresses
Uma Chunduri (editor) Uma Chunduri (editor)
Futurewei Intel
2330 Central Expressway 2191 Laurelwood Rd
Santa Clara, CA 95050 Santa Clara, CA 95054
USA United States of America
Email: umac.ietf@gmail.com Email: umac.ietf@gmail.com
John Kaippallimalil (editor) John Kaippallimalil (editor)
Futurewei Futurewei
Email: john.kaippallimalil@futurewei.com Email: john.kaippallimalil@futurewei.com
Sridhar Bhaskaran Sridhar Bhaskaran
Altiostar Altiostar
Email: sridharb@altiostar.com Email: sridharb@altiostar.com
Jeff Tantsura Jeff Tantsura
Juniper Networks Microsoft
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Praveen Muley Praveen Muley
Nokia Nokia
440 North Bernardo Ave 440 North Bernardo Ave
Mountain View, CA 94043 Mountain View, CA 94043
USA United States of America
Email: praveen.muley@nokia.com Email: praveen.muley@nokia.com
 End of changes. 100 change blocks. 
243 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/