< draft-clt-dmm-tn-aware-mobility-05.txt   draft-clt-dmm-tn-aware-mobility-06.txt >
DMM Working Group U. Chunduri, Ed. DMM Working Group U. Chunduri, Ed.
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Informational Futurewei Intended status: Informational Futurewei
Expires: May 7, 2020 S. Bhaskaran Expires: September 10, 2020 S. Bhaskaran
Altiostar Altiostar
J. Kaippallimalil J. Kaippallimalil, Ed.
Futurewei Futurewei
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
L. Contreras L. Contreras
Telefonica Telefonica
P. Muley P. Muley
Nokia Nokia
November 4, 2019 March 9, 2020
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-clt-dmm-tn-aware-mobility-05 draft-clt-dmm-tn-aware-mobility-06
Abstract Abstract
This document specifies a framework and a mapping function for 5G This document specifies a framework and mapping from slices in 5G
mobile user plane with transport network slicing, integrated with mobile systems to transport slices in IP and Layer 2 transport
Mobile Radio Access and a Virtualized Core Network. The integrated networks. Slices in 5G systems are characterized by latency bounds,
approach is specified in a way to fit into the 5G core network reservation guarantees, jitter, data rates, availability, mobility
architecture defined in [TS23.501]. speed, usage density, criticality and priority should be mapped to
transport slice characteristics that include bandwidth, latency and
criteria such as isolation, directionality and disjoint routes.
Mobile slice criteria need to be mapped to the appropriate transport
slice and capabilities offered in backhaul, midhaul and fronthaul
connectivity segments between radio side network functions and user
plane function (gateway).
It focuses on an optimized mobile user plane functionality with This document describes how mobile network functions map its slice
various transport services needed for some of the 5G traffic needing criteria to identifiers in IP packets that transport segments use to
low and deterministic latency, real-time, mission-critical services. grant transport layer services. This is based on mapping between
This document describes, how this objective is achieved agnostic to mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment
the transport underlay used (IPv6, MPLS, IPv4) in various deployments Routing). Applicability of this framework and a new transport
and with a new transport network underlay routing, called Preferred network underlay routing mechanism, Preferred Path Routing (PPR),
Path Routing (PPR). which brings slice properties and works with any underlying transport
(L2, IPv4, SR and MPLS) is also discussed.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 12 skipping to change at page 2, line 20
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 May 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are 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. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4
1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 6 2. Transport and Slice aware Mobility in 5G Networks . . . . . . 6
2.1. XHaul Transport Network . . . . . . . . . . . . . . . . . 7 2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 7
2.2. Mobile Transport Network Context (MTNC) and Scalability . 8 2.2. Front Haul Transport Network . . . . . . . . . . . . . . 9
2.3. Transport Network Function (TNF) . . . . . . . . . . . . 9 2.3. Mobile Transport Network Context (MTNC) and Scalability . 9
2.4. TNF Interfaces . . . . . . . . . . . . . . . . . . . . . 9 2.4. Transport Network Function (TNF) . . . . . . . . . . . . 10
2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 10 2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 11
2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 11 2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 12
2.7. Functionality for E2E Management . . . . . . . . . . . . 12 2.7. Functionality for E2E Management . . . . . . . . . . . . 13
3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 13 3. Transport Network Underlays . . . . . . . . . . . . . . . . . 15
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 14 3.1. Using PPR as TN Underlay . . . . . . . . . . . . . . . . 15
3.2. Path Steering Support to native IP user planes . . . . . 16 3.1.1. PPR on F1-U/N3/N9 Interfaces . . . . . . . . . . . . 16
3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 16 3.1.2. Path Steering Support to native IP user planes . . . 17
4. Other TE Technologies Applicability . . . . . . . . . . . . . 16 3.1.3. Service Level Guarantee in Underlay . . . . . . . . . 17
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Other TE Technologies Applicability . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix A. New Control Plane and User Planes . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 19
A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 20 Appendix A. New Control Plane and User Planes . . . . . . . . . 22
Appendix B. PPR with various 5G Mobility procedures . . . . . . 21 A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 22
B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 23
B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix B. PPR with various 5G Mobility procedures . . . . . . 24
B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 23 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP], The 3GPP architecture for 5GS is 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]. The architecture 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. The architecture functions via an API and common service framework.
also defines slicing aspects where the Network Slice Selection
Function (NSSF) assists the Access Mobility Manager (AMF) and Session UPFs are the data forwarding entities in the 5GC architecture. The
Management Function (SMF) to assist and select the right entities and architecture allows the placement of Branching Point (BP) and Uplink
resources corresponding to the slice requested by the user equipment Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-
(UE). The User Equipment (UE) indicates slice information in the AN can be a radio access network or any non-3GPP access network, for
Network Slice Selection Assistance Information (NSSAI) field during example, WLAN. The IP address is anchored by a PDU session anchor
session establishment (Attach). The AMF selects the right SMF and UPF (PSA UPF). 3GPP slicing and RAN aspects are further described in
the SMF in turn selects the User Plane Functions (UPF) so that the (Appendix A.1).
QoS and capabilities requested can be fulfilled. UPFs are the data
forwarding entities in the 5GC architecture. The architecture allows
the placement of Branching Point (BP) and Uplink Classifier (ULCL)
UPFs closer to the access network (5G-AN). The 5G-AN can be a radio
access network or any non-3GPP access network, for example, WLAN.
The IP address is anchored by a PDU session anchor UPF (PSA UPF).
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 N3 interface 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.
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. There may be multiple instances of a slice
type to satisfy some characteristics like isolation. The slice type to satisfy some characteristics like isolation. The slice
details in 3GPP, ATIS or NGMN do not specify how 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. This is aspects should be satisfied in IP transport networks. This is
skipping to change at page 4, line 21 skipping to change at page 4, line 25
[TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one
of the core capability of 5GC with slice awareness from Radio and 5G of the core capability of 5GC with slice awareness from Radio and 5G
Core (5GC) network. The 5G System (5GS) as defined, does not Core (5GC) network. The 5G System (5GS) as defined, does not
consider the resources and functionalities needed from transport consider the resources and functionalities needed from transport
network for the selection of UPF. This is seen as independent network for the selection of UPF. This is seen as independent
functionality and currently not part of 5GS. functionality and 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 5GS lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS
various procedures (e.g., session establishment, mobility). Meeting various procedures (e.g., session establishment, mobility). Meeting
the specific slice characteristics on the N3 and N9 interfaces the specific slice characteristics on the F1-U, N3, N9 interfaces
depends on the IP transport underlay providing these resources and depends on the IP transport underlay providing these resources and
capabilities. This could also lead to the inability in meeting SLAs capabilities. This could also lead to the inability in meeting SLAs
for real-time, mission-critical or latency sensitive services. 5GS for real-time, mission-critical or latency sensitive services. 5GS
procedures including but not limited to Service Request, PDU Session procedures including but not limited to Service Request, PDU Session
Establishment, or UE mobility need same service level characteristics Establishment, or UE mobility need same service level characteristics
from the TN for the Protocols Data Unit (PDU) session, similar to as from the Transport Network (TN) for the Protocols Data Unit (PDU)
provided in Radio and 5GC for the various Slice Service Types (SST) session, similar to as provided in Radio and 5GC for the various
and 5QI's defined in [TS.23.501-3GPP]. Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP].
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) and N3 and N9 transport segments spans the access network (radio network including the F1-U) and N3
which have an IP transport underlay. The 5G operator needs to obtain and N9 transport segments which have an IP transport underlay. The
slice capability from the IP transport provider. Several UE sessions 5G operator needs to obtain slice capability from the IP transport
that match a slice may be mapped to an IP transport segment. Thus provider. Several UE sessions that match a slice may be mapped to an
there needs to be a mapping between the slice capability offered to IP transport segment. Thus there needs to be a mapping between the
the UE (NSSAI) and what is provided by the IP transport. slice capability offered to the UE (S-NSSAI) and what is provided by
the IP transport.
1.2. Solution Approach 1.2. 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 for all service transport user plane traffic from 5G-AN to UPF for all service
continuity modes [TS.23.501-3GPP] in an optimized fashion. This is continuity modes [TS.23.501-3GPP] in an optimized fashion. This is
done by, keeping mobility procedures aware of underlying transport done by, keeping establishment and mobility procedures aware of
network along with slicing requirements. underlying transport network along 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. Using Preferred Path irrespective of underlying TN technology used. Using Preferred Path
Routing (PPR), applicable to any transport network underlay (IPv6, Routing (PPR), applicable to any transport network underlay (IPv6,
MPLS and IPv4) is detailed in Section 3. How other IETF TE MPLS and IPv4) is detailed in (Section 3.1). How other IETF TE
technologies applicable for this draft is specified in Section 4. At technologies applicable for this draft is specified in (Section 3.2).
the end, Appendix B further describes the applicability and At the end, (Appendix B) further describes the applicability and
procedures of PPR with 5G SSC modes on N3 and N9 interfaces. procedures of PPR with 5G SSC modes on F1-U, N3 and N9 interfaces.
1.3. Acronyms 1.3. 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)
CU - Centralized Unit (5G, gNB)
DN - Data Network (5G) DN - Data Network (5G)
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 - Userplane (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
QFI - QoS Flow ID (5G) QFI - QoS Flow ID (5G)
PPR - Preferred Path Routing PPR - Preferred Path Routing
PDU - Protocol Data Unit (5G) PDU - Protocol Data Unit (5G)
PW - Pseudo Wire PW - Pseudo Wire
RAN - Radio Access Network
RQI - Reflective QoS Indicator (5G) RQI - Reflective QoS Indicator (5G)
SBI - Service Based Interface (5G) SBI - Service Based Interface (5G)
SID - Segment Identifier SID - Segment Identifier
SMF - Session Management Function (5G) SMF - Session Management Function (5G)
SSC - Session and Service Continuity (5G) SSC - Session and Service Continuity (5G)
SST - Slice and Service Types (5G) SST - Slice and Service Types (5G)
SR - Segment Routing SR - Segment Routing
TE - Traffic Engineering TE - Traffic Engineering
ULCL - Uplink Classifier (5G) ULCL - Uplink Classifier (5G)
UP - User Plane(5G)
UPF - User Plane Function (5G) UPF - User Plane Function (5G)
URLLC - Ultra reliable and low latency communications (5G) URLLC - Ultra reliable and low latency communications (5G)
2. Transport Network and Slice aware Mobility on N3/N9 2. Transport and Slice aware Mobility in 5G Networks
Currently specified Control Plane (CP) functions - the AMF, the SMF 3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing
and the User plane (UP) components 5G-AN (e.g. gNB), UPF with N2, N3, in 5GS. However, the application of 5GS slices in transport network
N4, N6 and N9 interfaces are relevant to this document. Other for backhaul, mid-haul and front haul are not explicitly covered. To
Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, support specific characteristics in backhaul (N3, N9), mid-haul (F1)
NEF, and AF are not directly relevant for the discussion in this and front haul, it is necessary to map and provision corresponding
document and one can see the functionalities of these in resources in the transport domain. This section describes how to
[TS.23.501-3GPP]. provision the mapping information in 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.
From encapsulation perspective, N3 interface is similar to S1U in 4G/ TN Aware Mobility with optimized transport network functionality is
LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to explained below. How an underlay agnostic routing technology fits in
transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). this framework in detail along with other various TE technologies
Unlike S1U, N3 has some additional aspects as there is no bearer briefly are in (Section 3.1) and (Section 3.2) respectively.
concept and no per bearer GTP-U tunnels. Instead, QoS information is
carried in the PDU Session Container GTP-U extension header.
+------+ +-----+ +-------+ +-----+ 5G Control and Management Planes
| NSSF | | NRF | | NWDAF | | PCF | +------------------------------------------------------------------------+
+---+--+ +--+--+ +---+---+ +--+--+ | +--------------------------------------------------------------------+ |
| | | | | | (TNF) 5G Management Plane (TNF) | |
--+-----+--------+--+-----------+-----+-----+----- | +----+-----------------+-------------+---------------+-----------+---+ |
| | Service Based Interfaces (SBI) | | | | | | |
| +-----+--------+ | | +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
+--+--+ | +-----+ NSSMF| +--+--+ | | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
+-----+ AMF | | | TNF | | | SMF | | | | | +----+-----+ | +----+---+ |
| +--+--+ | +--+--+ | +--+--+ +-| |-----------|-------------|---------------|-----------|-----+
| +---+----------+ | | | | | | |
| |ACTN | | | | | | |
| +---+--+ | | | | ACTN | | ACTN |
N2 | +--------|SDN-C |-------+ | | | +---+---+ | +---+---+ |
| | +--+---+ | +----------+ | | | | | | | |
| |Ns _______ Nn| | N4 | | gNB-DU | | SDN-C | E1 | SDN-C | |
| | ___/ \______|_______|__________|___ | | | | | | | |
| | / | | | \ | | +---+---+ | +---+---+ |
+------+ +--+---+ IP +-++ +--+---+ +--+----+ +--+ | | | | | |
|(R)AN |====|CSR/PE| Backhaul |PE|+++|UP-NF2|+++|PE+UPF2|---|DN| | | | | | |
+------+ +------+ +--+ +------+ +-------+ +--+ | | __ +__ | ___+__ |
\___ _____________________________/ | | __/ \__ +--+---+ __/ \__ +-+-+
Front/ \ / N3 N9 N6 | | / IP \ | gNB | / IP \ | |
Midhaul +-----+ UE---| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
+----------| \__ __/ +------+ \__ __/ +---+
\______/ \______/
Figure 1: 5G Service Based Architecture with Transport Network |------ F1-U -------| |------ N3 OR N9 ------|
TN Aware Mobility with optimized transport network functionality is Figure 1: Backhaul and Mid-haul Transport Network for 5G
explained below. How PPR fits in this framework in detail along with
other various TE technologies briefly are in Section 3 and Section 4
respectively.
2.1. XHaul Transport Network 2.1. Backhaul and Mid-Haul Transport Network
Figure 1 depicts IP Xhaul network with SDN-C and CSR/PE (Provider Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)
Edge) routers provide IP transport service to 5GS user plane entities routers provide IP transport service to 5GS user plane entities 5G-AN
5G-AN (e.g. gNB) and UPF. 5GS architecture with key control and user (e.g. gNB) and UPF. 5GS architecture with high level management,
plane entities and its interaction with the IP transport plane is control and user plane entities and its interaction with the IP
shown here. When a UE initiates session establishment, it indicates transport plane is shown here. The slice capability required in IP
the desired slice type in the S-NSSAI (Specific Network Slice transport networks is estimated and provisioned by the functionality
Selection Assistance Information) field. The AMF uses the S-NSSAI, as specified in Section 2.4 (TNF) with support from various other
other subscription information and configuration in the NSSF to control plane functions such as the Network Data Analytics Function
select the appropriate SMF and the SMF in turn selects UPFs (User (NWDAF), Network Function Repository Function (NRF) and Policy
Plane Functions) that are able to provide the specified slice Control Function (PCF). The TNF is only a logical function that
resources and capabilities. Some of the slice capabilities along the maybe realized in a 3GPP management function such as Network Slice
user plane path between the (R)AM and UPFs (N3, N9 segments) such as Selection Management Function (NSSMF) defined in [TS.28.533-3GPP].
a low latency path, jitter, protection and priority needs these to be The TNF requests the SDN-C to provision the IP XHaul network using
provided by the IP transport network. ACTN [RFC8453].
Interface between (R)AN/5G-AN and CSR includes fronthaul and midhaul The 5G management plane in Figure 1 interacts with the 5G control
part of the transport network. In some cases midhaul can also a plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and
layer-2 network. In deployments where virtualized 5G-AN is used, F1U gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS)
interface with GTP encapsulation is considered between the signaling from the UE for session management, mobility is handled by
Distributed Unit (DU) and Centralized Unit (CU). the 5GC. When a UE initiates session establishment, it indicates the
desired slice type in the S-NSSAI (Specific Network Slice Selection
Assistance Information) field. The AMF uses the S-NSSAI, other
subscription information and configuration in the NSSF to select the
appropriate SMF and the SMF in turn selects UPFs (User Plane
Functions) that are able to provide the specified slice resources and
capabilities.
Slice capability required in IP transport networks is estimated and The AMF, SMF, NSSF, PCF, NRF, NWDAF and other control functions in
provisioned by the functionality as specified in Section 2.3 (TNF) 5GC are described in [TS.23.501-3GPP] Some of the slice capabilities
with support from various other functions such as the Network Data along the user plane path between the (R)AN and UPFs (F1-U, N3, N9
Analytics Function (NWDAF), Network Resource Function (NRF) and segments) such as a low latency path, jitter, protection and priority
Policy Control Function (PCF). Figure 1 depicts the PE router, where needs these to be provided by the IP transport network.
transport paths are initiated/terminated can be deployed seperately
with UPF or both functionalities can be in the same node. The TNF
provisions this in the SDN-C of the IP XHaul network using ACTN
[RFC8453]. When a GTP encapsulated user packet from the (R)AN or UPF
with the slice information traverses the F1U/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.5.
2.2. Mobile Transport Network Context (MTNC) and Scalability The 5G user plane from UE to DN (Data Network) includes a mid-haul
segment (F1-U between gNB DU(UP), gNB CU(UP)) and backhaul (N3
between gNB - UPF; N9 between UPFs). If the RAN uses lower layer
split architecture as specified by O-RAN alliance, then the user
plane path from UE to DN also includes the fronthaul interface. The
fronthaul interface carries the radio frames in the form of In-phase
(I) and Quadrature (Q) samples using eCPRI encapsulation over
Ethernet or UDP over IP.
The N3, N9 and F1 user planes use GTP-U [TS.29.281-3GPP] to transport
UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). For the
front haul described further in Section 2.2, an Ethernet transport
with VLANs can be expected to be the case in many deployments.
Figure 1 also depicts the PE router, where transport paths are
initiated/terminated can be deployed separately with UPF or both
functionalities can be in the same node. The TNF provisions this in
the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP
encapsulated user packet from the (R)AN (gNB) or UPF with the slice
information traverses the F1U/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.5).
2.2. Front Haul 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 is carried in the Ethernet header
through the VLAN tags. The Ethernet switches in the fronthaul
transport network can inspect the slice information (VLAN tag) in the
Ethernet header and provide the provisioned capabilities. The
mapping of I and Q samples of different radio resources (radio
resource blocks or carriers etc.,.) to different slices and to their
respective VLAN tags on the fronthaul interface is controlled by the
O-RAN fronthaul C-Plane and M-Plane interfaces. On UDP based
fronthaul interface, the slice information is carried in the IP or
UDP header. The PE routers of the fronthaul transport network can
inspect the slice information in the IP or UDP header and provide the
provisioned capabilities. The fronthaul transport network is latency
and jitter sensitive. The provisioned slice capabilities in the
fronthaul transport network MUST take care of the latency and jitter
budgets of the specific slice for the fronthaul interface. The
provisioning of the fronthaul transport network is handled by the
SDN-C pertaining to the fronthaul transport.
2.3. Mobile Transport Network Context (MTNC) and Scalability
The MTNC represents a slice, QoS configuration for a transport path The MTNC represents a slice, QoS configuration for a transport path
between two 3GPP user plane functions. The Mobile-Transport Network between two 3GPP user plane functions. The Mobile-Transport Network
Context Identifier (MTNC-ID) is generated by the TNF to be unique for Context Identifier (MTNC-ID) is generated by the TNF to be unique for
each path and per traffic class (including QoS and slice aspects). each path and per traffic class (including QoS and slice aspects).
Thus, there may be more than one MTNC-ID for the same QoS and path if Thus, there may be more than one MTNC-ID for the same QoS and path if
there is a need to provide isolation (slice) of the traffic. It there is a need to provide isolation (slice) of the traffic. It
should be noted that MTNC are per class/path and not per user session should be noted that MTNC are per class/path and not per user session
(nor is it per data path entity). The MTNC-IDs are configured by the (nor is it per data path entity). The MTNC-IDs are configured by the
TNF to be unique within a provisioning domain. TNF to be unique within a provisioning domain.
skipping to change at page 9, line 5 skipping to change at page 10, line 7
establishment, there is no provisioning delay experienced during establishment, there is no provisioning delay experienced during
session setup. The MTNC-ID space scales as a square of the number session setup. The MTNC-ID space scales as a square of the number
sites between which 3GPP user plane functions require paths. If sites between which 3GPP user plane functions require paths. If
there are T traffic classes across N sites, the number of MTNC-IDs in there are T traffic classes across N sites, the number of MTNC-IDs in
a fully meshed network is (N*(N-1)/2) * T. For example, if there are a fully meshed network is (N*(N-1)/2) * T. For example, if there are
3 traffic classes between 25 sites, there would be at most 900 MTNC- 3 traffic classes between 25 sites, there would be at most 900 MTNC-
IDs required. Multiple slices for the same QoS class that need to be IDs required. Multiple slices for the same QoS class that need to be
fully isolated, will add to the MTNC provisioning. An MTNC-ID space fully isolated, will add to the MTNC provisioning. An MTNC-ID space
of 16 bits (65K+ identifiers) can be expected to be sufficient. of 16 bits (65K+ identifiers) can be expected to be sufficient.
2.3. Transport Network Function (TNF) 2.4. 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)
requests the SDN-C in the transport domain to program the TE path requests the SDN-C in the transport domain to program the TE path
using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE) using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE)
skipping to change at page 9, line 30 skipping to change at page 10, line 32
The detailed mechanisms by which the NSSMF provides the MTNC-IDs to The detailed mechanisms by which the NSSMF provides the MTNC-IDs to
the control plane and user plane functions are for 3GPP to specify. the control plane and user plane functions are for 3GPP to specify.
Two possible options are outlined below for completeness. The NSSMF Two possible options are outlined below for completeness. The NSSMF
may provide the MTNC-IDs to the 3GPP control plane by either may provide the MTNC-IDs to the 3GPP control plane by either
providing it to the Session Management Function (SMF), and the SMF in providing it to the Session Management Function (SMF), and the SMF in
turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU
session setup. Alternatively, the user plane functions may request session setup. Alternatively, the user plane functions may request
the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case
where user plane entities request the TNF/NSSMF to translate the where user plane entities request the TNF/NSSMF to translate the
Request and get the MTNC-ID (over interface Ns/Nn). Request and get the MTNC-ID. Another alternative is for the TNF to
provide a mapping of the 3GPP Network Instance Identifier, described
in (Section 2.7) and the MTNC-ID to the user plane entities via
configuration.
The TNF should be seen as a logical entity that can be part of NSSMF The TNF should be seen as a logical entity that can be part of NSSMF
in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use
network configuration, policies, history, heuristics or some network configuration, policies, history, heuristics or some
combination of these to derive traffic estimates that the TNF would combination of these to derive traffic estimates that the TNF would
use. How these estimates are derived are not in the scope of this use. How these estimates are derived are not in the scope of this
document. The focus here is only in terms of how the TNF and SDN-C document. The focus here is only in terms of how the TNF and SDN-C
are programmed given that slice and QoS characteristics across a are programmed given that slice and QoS characteristics across a
transport path can be represented by an MTNC-ID. The TNF requests transport path can be represented by an MTNC-ID. The TNF requests
the SDN-C in the transport network to provision paths in the the SDN-C in the transport network to provision paths in the
transport domain based on the MTNC-ID. The TNF is capable of transport domain based on the MTNC-ID. The TNF is capable of
providing the MTNC-ID provisioned to control and user plane functions providing the MTNC-ID provisioned to control and user plane functions
in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID
should be part of the 3GPP specifications. should be part of the 3GPP specifications.
2.4. TNF Interfaces
A south bound interface Ns is shown which interacts with the 5G
Access Network (e.g. CSR). 'Ns' can use one or more mechanism
available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF
[RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay
paths from CSR to PE@UPF. Ns and Nn interfaces can be part of the
integrated 3GPP architecture, but the specification/ownership of
these interfaces SHOULD be left out of scope of 3GPP.
A north bound interface 'Nn' is shown from one or more of the
transport network nodes (or PE @ ULCL/BP UPF, Anchor Point UPF) to
TNF as shown in Figure 1. It would enable learning the TE
characteristics of all links and nodes of the network continuously
(through BGP-LS [RFC7752] or through a passive IGP adjacency and PCEP
[RFC5440]).
These VPNs and/or underlay TE paths MUST be similar on all 5G-AN/CSRs
and UPFs concerned to allow mobility of UEs while associated with one
of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP].
2.5. Transport Provisioning 2.5. Transport Provisioning
Functionality of transport provisioning for an engineered IP Functionality of transport provisioning for an engineered IP
transport that supports 3GPP slicing and QoS requirements in transport that supports 3GPP slicing and QoS requirements in
[TS.23.501-3GPP] is described in this section. [TS.23.501-3GPP] is described in this section.
During a PDU session setup, the AMF using input from the NSSF selects During a PDU session setup, the AMF using input from the NSSF selects
a network slice and SMF. The SMF with user policy from Policy a network slice and SMF. The SMF with user policy from Policy
Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the 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 path of the PDU session. While QoS and slice selection for the PDU
session can be applied across the 3GPP control and user plane session can be applied across the 3GPP control and user plane
functions as outlined in Section 2, the IP transport underlay across functions as outlined in (Section 2), the IP transport underlay
N3 and N9 segments do not have enough information to apply the across F1-U, N3 and N9 segments do not have enough information to
resource constraints represented by the slicing and QoS apply the resource constraints represented by the slicing and QoS
classification. Current guidelines for interconnection with classification. Current guidelines for interconnection with
transport networks [IR.34-GSMA] provide an application mapping into transport networks [IR.34-GSMA] provide an application mapping into
DSCP. However, these recommendations do not take into consideration DSCP. However, these recommendations do not take into consideration
other aspects in slicing like isolation, protection and replication. other aspects in slicing like isolation, protection and replication.
IP transport networks have their own slice and QoS configuration IP transport networks have their own slice and QoS configuration
based on domain policies and the underlying network capability. based on domain policies and the underlying network capability.
Transport networks can enter into an agreement for virtual network Transport networks can enter into an agreement for virtual network
services (VNS) with client domains using the ACTN [RFC8453] services (VNS) with client domains using the ACTN [RFC8453]
framework. An IP transport network may provide such slice instances framework. An IP transport network may provide such slice instances
to mobile network operators, CDN providers or enterprises for to mobile network operators, CDN providers or enterprises for
example. The 3GPP mobile network, on the other hand, defines a slice example. The 3GPP mobile network, on the other hand, defines a slice
instance for UEs as are the the mobile operator's 'clients'. The instance for UEs as are the mobile operator's 'clients'. The Network
Network Slice Selection Management Function (NSSMF) [TS 28.533] that Slice Selection Management Function (NSSMF) [TS 28.533] that
interacts with a TN controller like an SDN-C (that is out of scope of interacts with a TN controller like an SDN-C (that is out of scope of
3GPP). 3GPP).
The ACTN VN service can be used across the IP transport networks to 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 provision and map the slice instance and QoS of the 3GPP domain to
the IP transport domain. An abstraction that represents QoS and the IP transport domain. An abstraction that represents QoS and
slice instance in the mobile domain and mapped to ACTN VN service in slice instance in the mobile domain and mapped to ACTN VN service in
the transport domain is represented here as MTNC-IDs. Details of how the transport domain is represented here as MTNC-IDs. Details of how
the MTNC-IDs are derived are upto functions that can estimate the the MTNC-IDs are derived are up to functions that can estimate the
level of traffic demand. level of traffic demand.
The 3GPP network/5GS provides slices instances to its clients (UE) The 3GPP network/5GS provides slices instances to its clients (UE)
that include resources for radio and mobile core segments. The UE's that include resources for radio and mobile core segments. The UE's
PDU session spans the access network (radio) and N3 and N9 transport PDU session spans the access network (radio) and F1-U/N3/N9 transport
segments which have an IP transport underlay. The 5G operator needs segments which have an IP transport underlay. The 5G operator needs
to obtain slice capability from the IP transport provider since these to obtain slice capability from the IP transport provider since these
resources are not seen by the 5GS. Several UE sessions that match a 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 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) be a mapping between the slice capability offered to the UE (NSSAI)
and what is provided by the IP transport. and what is provided by the IP transport.
When the 3GPP user plane function (5G-AN, UPF) does not terminate the 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 transport underlay protocol (e.g., MPLS), it needs to be carried in
the IP protocol header from end-to-end of the mobile transport the IP protocol header from end-to-end of the mobile transport
connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses
these scenarios in detail. these scenarios in detail.
2.6. MTNC-ID in the Data Packet 2.6. MTNC-ID in the Data Packet
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
N3, N9 interface. To allow the IP transport edge nodes to inspect F1-U, N3, N9 interface. To allow the IP transport edge nodes to
the transport context information efficiently, it should be carried inspect the transport context information efficiently, it should be
in an IP header field that is easy to inspect. It may be noted that carried in an IP header field that is easy to inspect. It may be
the N3 and N9 interfaces in 5GS are IP interfaces. Thus, Layer 2 noted that the F1-U, N3 and N9 interfaces in 5GS are IP interfaces.
alternatives such as VLAN will fail if there are multiple L2 networks Thus, Layer 2 alternatives such as VLAN will fail if there are
on the N3 or N9 path. Another alternative is to use L3 VPNs. multiple L2 networks on the F1-U or N3 or N9 path. GTP (F1-U, N3, N9
However, in the 5G architecture, there may be a large number of encapsulation header) field extensions offer a possibility, however
smaller UPFs that are dynamically inserted on path. Adding this VPN these extensions are hard for a transport edge router to parse
information for dynamic UPF insertion is configuration intensive and efficiently on a per packet basis. Other IP header fields like DSCP
error prone. GTP (N3, N9 encapsulation header) field extensions are not suitable as it only conveys the QoS aspects (but not other
offer a possibility, however these extensions are hard for a aspects like isolation, protection, etc.)
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 FaST, or SRv6 may be options to carry the IPv6 extension headers like SRv6 may be options to carry the MTNC-ID
MTNC-ID when such mechanism is a viable (if complete transport when such mechanism is a viable (if complete transport network is
network is IPv6 based). To mininise the protocol changes are IPv6 based). To mininise the protocol changes are required and make
required and make this underlay tranport independed (IPv4/IPv6/MPLS/ this underlay tranport independent (IPv4/IPv6/MPLS/L2), an option is
L2), an option is to provision a mapping of MTNC-ID to a UDP port to provision a mapping of MTNC-ID to a UDP port range of the GTP
range of the GTP encapsulated user packet. A simple mapping table encapsulated user packet. A simple mapping table between the MTNC-ID
between the MTNC-ID and the source UDP port number can be configured and the source UDP port number can be configured to ensure that ECMP
to ensure that ECMP /load balancing is not affected adversely by /load balancing is not affected adversely by encoding the UDP source
encoding the UDP source port with an MTNC-ID mapping. This mapping port with an MTNC-ID mapping. This mapping is configured in 3GPP
is configured in 3GPP user plane functions (5G-AN, UPF) and Provider user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that
Edge (PE) Routers that process MTNC-IDs. PE routers can thus process MTNC-IDs.
provision a policy based on the source UDP port number (which
reflects the mapped MTNC-ID) to underlying transport path and then PE routers can thus provision a policy based on the source UDP port
deliver the QoS/slice resource provisioned in the transport network. number (which reflects the mapped MTNC-ID) to underlying transport
The source UDP port that is encoded is the outer IP (corresponding to path and then deliver the QoS/slice resource provisioned in the
GTP header) while the inner IP packet (UE payload) is unaltered. transport network. The source UDP port that is encoded is the outer
IP (corresponding to GTP 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 to 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 lower layer split architecture, then a
fronthaul network is involved. On an Ethernet based fronthaul
transport network, VLAN tag may be an option to carry the MTNC-ID.
The VLAN ID provides a 12 bit space and is sufficient to support up
to 4096 slices on the fronthaul transport network. The mapping of
fronthaul traffic to corresponding network slice 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.2. On UDP based fronthaul
transport network, the UDP source port can be used to carry the MTNC-
ID.
2.7. Functionality for E2E Management 2.7. Functionality for E2E Management
With the TNF finctionality 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 o 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, o 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 end point (CSR and PE@UPF). monitored from each transport end point (CSR and PE@UPF).
skipping to change at page 12, line 50 skipping to change at page 14, line 14
o Mapping of PDU session parameters to underlay SST paths need to be o Mapping of PDU session parameters to underlay SST paths need to be
done. One way to do this to let the SMF install a Forwarding done. One way to do this 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.5, Section 2.6 can be used for classifying a packet (Section 2.5), (Section 2.6) can be used for classifying a packet
belonging to a particular slice characteristics. For DL, at a PSA belonging to a particular slice characteristics. 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-US packet as specified in Section 2.6. encapsulated GTP-US packet as specified in (Section 2.6).
o If any other form of encapsulation (other than GTP-U) either on N3 o If any other form of encapsulation (other than GTP-U) either on N3
or N9 corresponding QFI information MUST be there in the or N9 corresponding QFI information MUST be there in the
encapsulation header. encapsulation header.
o In some SSC modes Appendix B, if segmented path (CSR to o In some SSC modes (Appendix B), if segmented path (CSR to
PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then
corresponding path characteristics MUST be used. This includes a 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 path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF
to eventual UPF access to DN. to eventual UPF access to DN.
o Continuous monitoring of the underlying transport path o 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 traffic engineering technique used as for monitoring depends traffic engineering technique used as
described in Section 3 and Section 4). If path characteristics described in (Section 3.1) and (Section 3.2)). If path
are degraded, reassignment of the paths at the endpoints should be characteristics are degraded, reassignment of the paths at the
performed. For all the affected PDU sessions, degraded transport endpoints should be performed. For all the affected PDU sessions,
paths need to be updated dynamically with similar alternate paths. degraded transport paths need to be updated dynamically with
similar alternate paths.
o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn
based or N2 based), for target gNB selection, apart from radio based or N2 based), for target gNB selection, apart from radio
resources, transport resources MUST be factored. This enables resources, transport resources MUST be factored. This enables
handling of all PDU sessions from the UE to target gNB and this handling of all PDU sessions from the UE to target gNB and this
require co-ordination of gNB, AMF, SMF with the TNF module. 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 part of management PDU Session Establishment). If TNF is seen as part of management
plane, this real time flexibility is lost. Changes to detailed plane, this real time flexibility is lost. Changes to detailed
signaling to integrate the above for various 5GS procedures as signaling to integrate the above for various 5GS procedures as
defined in [TS.23.502-3GPP] is beyond the scope of this document. defined in [TS.23.502-3GPP] is beyond the scope of this document.
3. Using PPR as TN Underlay 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. Using PPR as TN Underlay
In a network implementing source routing, packets may be transported In a network implementing source routing, packets may be transported
through the use of Segment Identifiers (SIDs), where a SID uniquely through the use of Segment Identifiers (SIDs), where a SID uniquely
identifies a segment as defined in [I-D.ietf-spring-segment-routing]. identifies a segment as defined in [I-D.ietf-spring-segment-routing].
Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out
all SRv6 features along with a few concerns in Section 5.3.7 of the all SRv6 features along with a few concerns in Section 5.3.7 of the
same document. Those concerns as well as need for underlay agnostic same document. Those concerns as well as need for underlay agnostic
(L2/Ipv4/IPv6/MPLS) TE requirements are addressed by a new XHaul (L2/IPv4/IPv6/MPLS) TE requirements are addressed by a new XHaul
routing mechanism called Preferred Path Routing (PPR), of which this routing mechanism called Preferred Path Routing (PPR), of which this
section provides an overview. section provides an overview.
With PPR, the label/PPR-ID refer not to individual segments of which With PPR, the label/PPR-ID refer not to individual segments of which
the path is composed, but to the identifier of a path that is the path is composed, but to the identifier of a path that is
deployed on network nodes. The fact that paths and path identifiers deployed on network nodes. The fact that paths and path identifiers
can be computed and controlled by a controller, not a routing can be computed and controlled by a controller, not a routing
protocol, allows the deployment of any path that network operators protocol, allows the deployment of any path that network operators
prefer, not just shortest paths. As packets refer to a path towards prefer, not just shortest paths. As packets refer to a path towards
a given destination and nodes make their forwarding decision based on a given destination and nodes make their forwarding decision based on
skipping to change at page 14, line 26 skipping to change at page 16, line 5
results in multiple benefits including significant reduction in results in multiple benefits including significant reduction in
network layer overhead, increased performance and hardware network layer overhead, increased performance and hardware
compatibility for carrying both path and services along the path. compatibility for carrying both path and services along the path.
Details of the IGP extensions for PPR are provided here: Details of the IGP extensions for PPR are provided here:
o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing] o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing]
o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing] o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing]
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 3.1.1. PPR on F1-U/N3/N9 Interfaces
PPR does not remove GTP-U, unlike some other proposals laid out in PPR does not remove GTP-U, unlike some other proposals laid out in
[I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works [I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works
with the existing cellular user plane (GTP-U) for both N3 and any with the existing cellular user plane (GTP-U) for F1-U/N3 and any
approach selected for N9 (encapsulation or no-encapsulation). In approach selected for N9 (encapsulation or no-encapsulation). In
this scenario, PPR will only help providing TE benefits needed for 5G this scenario, PPR will only help providing TE benefits needed for 5G
slices from transport domain perspective. It does so for any slices from transport domain perspective. It does so for any
underlying data plane used in the transport network (L2/IPv4/IPv6/ underlying user/data plane used in the transport network
MPLS). This is achieved by: (L2/IPv4/IPv6/MPLS). This is achieved by:
o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in
the transport network. For Uplink traffic, the 5G-AN will choose the transport network. For Uplink traffic, the 5G-AN will choose
the right PPR-ID of the UPF based on the S-NSSAI the PDU Session the right PPR-ID of the UPF based on the S-NSSAI the PDU Session
belongs to and/or the UDP Source port (corresponds to the MTNC-ID belongs to and/or the UDP Source port (corresponds to the MTNC-ID
Section 2.5) of the GTP-U encapsulation header. Similarly in the (Section 2.5)) of the GTP-U encapsulation header. Similarly in
Downlink direction matching PPR-ID of the 5G-AN is chosen based on the Downlink direction matching PPR-ID of the 5G-AN is chosen
the S-NSSAI the PDU Session belongs to. The table below shows a based on the S-NSSAI the PDU Session belongs to. The table below
typical mapping: shows a typical mapping:
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
|GTP/UDP SRC PORT| SST | Transport Path | Transport Path | |GTP/UDP SRC PORT| SST | Transport Path | Transport Path |
| | in S-NSSAI | Info | Characteristics | | | in S-NSSAI | Info | Characteristics |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Xx - Xy | | | | | Range Xx - Xy | | | |
| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed | | X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |
| values) | (massive | PPR-ID-A | Bit Rate) | | values) | (massive | PPR-ID-A | Bit Rate) |
| | IOT) | | Bandwidth: Bx | | | IOT) | | Bandwidth: Bx |
| | | | Delay: Dx | | | | | Delay: Dx |
skipping to change at page 15, line 42 skipping to change at page 17, line 17
o Same set of PPRs are created uniformly across all needed 5G-ANs o Same set of PPRs are created uniformly across all needed 5G-ANs
and UPFs to allow various mobility scenarios. and UPFs to allow various mobility scenarios.
o Any modification of TE parameters of the path, replacement path o 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 PPR can be supported with any native IPv4 and IPv6 data/user o PPR can be supported with any native IPv4 and IPv6 data/user
planes (Section 3.2) with optional TE features (Section 3.3) . As planes ( (Section 3.1.2)) with optional TE features (
this is an underlay mechanism it can work with any overlay (Section 3.1.3)) . As this is an underlay mechanism it can work
encapsulation approach including GTP-U as defined currently for N3 with any overlay encapsulation approach including GTP-U as defined
interface. currently for N3 interface.
3.2. Path Steering Support to native IP user planes 3.1.2. Path Steering Support to native IP user planes
PPR works in fully compatible way with SR defined user planes (SR- PPR works in fully compatible way with SR defined user planes (SR-
MPLS and SRv6) by reducing the path overhead and other challenges as MPLS and SRv6) by reducing the path overhead and other challenges as
listed in Section 5.3.7 of listed in Section 5.3.7 of
[I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the
source routing to user planes beyond SR-MPLS and SRv6 i.e., L2, source routing to user planes beyond SR-MPLS and SRv6 i.e., L2,
native IPv6 and IPv4 user planes. native IPv6 and IPv4 user planes.
This helps legacy transport networks to get the immediate path This helps legacy transport networks to get the immediate path
steering benefits and helps in overall migration strategy of the steering benefits and helps in overall migration strategy of the
network to the desired user plane. Some of these benefits with PPR network to the desired user plane. Some of these benefits with PPR
can be realized with no hardware upgrade except control plane can be realized with no hardware upgrade except control plane
software for native IPv6 and IPv4 user planes. software for native IPv6 and IPv4 user planes.
3.3. Service Level Guarantee in Underlay 3.1.3. Service Level Guarantee in Underlay
PPR also optionally allows to allocate resources that are to be PPR also optionally allows to allocate resources that are to be
reserved along the preferred path. These resources are required in reserved along the preferred path. These resources are required in
some cases (for some 5G SSTs with stringent GBR and latency some cases (for some 5G SSTs with stringent GBR and latency
requirements) not only for providing committed bandwidth or requirements) not only for providing committed bandwidth or
deterministic latency, but also for assuring overall service level deterministic latency, but also for assuring overall service level
guarantee in the network. This approach does not require per-hop guarantee in the network. This approach does not require per-hop
provisioning and reduces the OPEX by minimizing the number of provisioning and reduces the OPEX by minimizing the number of
protocols needed and allows dynamism with Fast-ReRoute (FRR) protocols needed and allows dynamism with Fast-ReRoute (FRR)
capabilities. capabilities.
4. Other TE Technologies Applicability 3.2. Other TE Technologies Applicability
RSVP-TE [RFC3209] provides a lean transport overhead for the TE path RSVP-TE [RFC3209] provides a lean transport overhead for the TE path
for MPLS user plane. However, it is perceived as less dynamic in for MPLS user plane. However, it is perceived as less dynamic in
some cases and has some provisioning overhead across all the nodes in some cases and has some provisioning overhead across all the nodes in
N3 and N9 interface nodes. Also it has another drawback with N3 and N9 interface nodes. Also, it has another drawback with
excessive state refresh overhead across adjacent nodes and this can excessive state refresh overhead across adjacent nodes and this can
be mitigated with [RFC8370]. be mitigated with [RFC8370].
SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal
bandwidth reservation or mechanism to guarantee latency on the nodes/ bandwidth reservation or mechanism to guarantee latency on the nodes/
links on SR path. But, SR allows path steering for any flow at the 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 ingress and particular path for a flow can be chosen. Some of the
issues around path overhead/tax, MTU issues are documented at issues around path overhead/tax, MTU issues are documented at
Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR- Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR-
MPLS allows reduction of the control protocols to one IGP (with out MPLS allows reduction of the control protocols to one IGP (with out
needing for LDP and RSVP-TE). needing for LDP and RSVP-TE).
However, as specified above with PPR (Section 3), in the integrated However, as specified above with PPR ( (Section 3.1)), in the
transport network function (TNF) a particular RSVP-TE path for MPLS integrated transport network function (TNF) a particular RSVP-TE path
or SR path for MPLS and IPv6 with SRH user plane, can be supplied to for MPLS or SR path for MPLS and IPv6 with SRH user plane, can be
SMF for mapping a particular PDU session to the transport path. supplied to SMF for mapping a particular PDU session to the transport
path.
5. Acknowledgements 4. Acknowledgements
Thanks to Young Lee for discussions on this document including ACTN Thanks to Young Lee for discussions on this document including ACTN
applicability for the proposed TNF. Thanks to Sri Gundavelli and applicability for the proposed TNF. Thanks to Sri Gundavelli and
3GPP delegates who provided detailed feedback on this document. 3GPP delegates who provided detailed feedback on this document.
6. IANA Considerations 5. IANA Considerations
This document has no requests for any IANA code point allocations. This document has no requests for any IANA code point allocations.
7. Security Considerations 6. Security Considerations
This document does not introduce any new security issues. This document does not introduce any new security issues.
8. Contributing Authors 7. Contributing Authors
The following people contributed substantially to the content of this The following people contributed substantially to the content of this
document and should be considered co-authors. document and should be considered co-authors.
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
9. References 8. References
9.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>.
9.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.bashandy-rtgwg-segment-routing-ti-lfa] [I-D.bashandy-rtgwg-segment-routing-ti-lfa]
Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P. Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
Camarillo, "Topology Independent Fast Reroute using Camarillo, "Topology Independent Fast Reroute using
Segment Routing", draft-bashandy-rtgwg-segment-routing-ti- Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
skipping to change at page 18, line 23 skipping to change at page 19, line 46
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", draft-bogineni-dmm-
optimized-mobile-user-plane-01 (work in progress), June optimized-mobile-user-plane-01 (work in progress), June
2018. 2018.
[I-D.chunduri-lsr-isis-preferred-path-routing] [I-D.chunduri-lsr-isis-preferred-path-routing]
Chunduri, U., Li, R., White, R., Tantsura, J., Contreras, Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS", L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
draft-chunduri-lsr-isis-preferred-path-routing-04 (work in draft-chunduri-lsr-isis-preferred-path-routing-05 (work in
progress), July 2019. progress), March 2020.
[I-D.chunduri-lsr-ospf-preferred-path-routing] [I-D.chunduri-lsr-ospf-preferred-path-routing]
Chunduri, U., Qu, Y., White, R., Tantsura, J., and L. Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
Contreras, "Preferred Path Routing (PPR) in OSPF", draft- Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
chunduri-lsr-ospf-preferred-path-routing-03 (work in chunduri-lsr-ospf-preferred-path-routing-04 (work in
progress), May 2019. progress), March 2020.
[I-D.farinacci-lisp-mobile-network] [I-D.farinacci-lisp-mobile-network]
Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
for the Mobile Network", draft-farinacci-lisp-mobile- for the Mobile Network", draft-farinacci-lisp-mobile-
network-06 (work in progress), September 2019. network-06 (work in progress), September 2019.
[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-02 (work in System", draft-ietf-dmm-5g-uplane-analysis-03 (work in
progress), July 2019. progress), November 2019.
[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., Camarillo, P.,
Voyer, D., and C. Perkins, "Segment Routing IPv6 for Voyer, D., and C. Perkins, "Segment Routing IPv6 for
Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-06 Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07
(work in progress), September 2019. (work in progress), November 2019.
[I-D.ietf-intarea-gue-extensions] [I-D.ietf-intarea-gue-extensions]
Herbert, T., Yong, L., and F. Templin, "Extensions for Herbert, T., Yong, L., and F. Templin, "Extensions for
Generic UDP Encapsulation", draft-ietf-intarea-gue- Generic UDP Encapsulation", draft-ietf-intarea-gue-
extensions-06 (work in progress), March 2019. extensions-06 (work in progress), March 2019.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[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]
O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
Control, User and Synchronization Plane Specification;
v2.0.0", August 2019.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
skipping to change at page 20, line 44 skipping to change at page 22, line 25
[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.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]
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 Appendix A. New Control Plane and User Planes
A.1. Slice aware Mobility: Discrete Approach 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].
A.2. Slice aware Mobility: Discrete Approach
In this approach transport network functionality from the 5G-AN to In this approach transport network functionality from the 5G-AN to
UPF is discrete and 5GS is not aware of the underlying transport UPF is discrete and 5GS is not aware of the underlying transport
network and the resources available. Deployment specific mapping network and the resources available. Deployment specific mapping
function is used to map the GTP-U encapsulated traffic at the 5G-AN 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 (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 slice or transport Traffic Engineered (TE) paths. These TE paths can
be established using RSVP-TE [RFC3209] for MPLS underlay, SR be established using RSVP-TE [RFC3209] for MPLS underlay, SR
[I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or
PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6
with SRH, native IPv6 and native IPv4 underlays. with SRH, native IPv6 and native IPv4 underlays.
As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the 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 user plane traffic forwarding rules in the UPF. The UPFs have a
concept of a "Network Instance" which logically abstracts the concept of a "Network Instance" which logically abstracts the
underlying transport path. When the SMF creates the packet detection underlying transport path. When the SMF creates the packet detection
rules (PDR) and forwarding action rules (FAR) for a PDU session at rules (PDR) and forwarding action rules (FAR) for a PDU session at
the UPF, the SMF identifies the network instance through which the the UPF, the SMF identifies the network instance through which the
packet matching the PDR has to be forwarded. A network instance can packet matching the PDR has to be forwarded. A network instance can
be mapped to a TE path at the UPF. In this approach, TNF as shown in be mapped to a TE path at the UPF. In this approach, TNF as shown in
Figure 1 need not be part of the 5G Service Based Interface (SBI). (Figure 1) need not be part of the 5G Service Based Interface (SBI).
Only management plane functionality is needed to create, monitor, Only management plane functionality is needed to create, monitor,
manage and delete (life cycle management) the transport TE paths/ manage and delete (life cycle management) the transport TE paths/
transport slices from the 5G-AN to the UPF (on N3/N9 interfaces). transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
The management plane functionality also provides the mapping of such The management plane functionality also provides the mapping of such
TE paths to a network instance identifier to the SMF. The SMF uses TE paths to a network instance identifier to the SMF. The SMF uses
this mapping to install appropriate FARs in the UPF. This approach this mapping to install appropriate FARs in the UPF. This approach
provide partial integration of the transport network into 5GS with provide partial integration of the transport network into 5GS with
some benefits. some benefits.
One of the limitations of this approach is the inability of the 5GS One of the limitations of this approach is the inability of the 5GS
skipping to change at page 22, line 10 skipping to change at page 24, line 33
above. above.
SSC mode would be specified/defaulted by SMF. No change in the mode SSC mode would be specified/defaulted by SMF. No change in the mode
once connection is initiated and this property is not altered here. once connection is initiated and this property is not altered here.
B.1. SSC Mode1 B.1. SSC Mode1
+--------------+ +--------------+
+---+----+ |NSSMF +-----+ | +----------------+ +---+----+ |NSSMF +-----+ | +----------------+
| AMF | | | TNF | | | SMF | | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+--------------+ +---+--+-+ | +-+-+-+ | +-----+----------+
N1 | +--------+-+---+ | N1 | +--------+-+---+ |
| | | | | | | | | |
+--------+ N2 +----Ns---+ +-Nn-+ N4 | | +---+-+--+ |
| | | | | | | | SDN-C | |
+ +---+---+ +--++ +-+--+---+ +----+ | | +---+-+--+ |
UE1 |gNB|======|CSR|------N3---- | PE+UPF |-N6--| DN | | | | | |
== +---+ +---+ +--------+ +----+ +--------+ N2 +---------+ + ---+ |
| | | | |
+ +---+--+ +--++ +---+ +-+--+ +----+
UE1 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN |
== +---+ +---+ +---+ +----+ +----+
Figure 3: SSC Mode1 with integrated Transport Slice Function Figure 3: SSC Mode1 with integrated Transport Slice Function
After UE1 moved to another gNB in the same UPF serving area After UE1 moved to another gNB in the same UPF serving area
+--------------+ +--------------+
+---+----+ |NSSMF +-----+ | +----------------+ +---+----+ |NSSMF +-----+ | +----------------+
| AMF | | | TNF | | | SMF | | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+--------------+ +------+-+ | +-+-+-+ | +-----+----------+
| +--------+-+---+ | | +--------+-+---+ |
| | | | | | | |
N2 +----Ns---+ +-Nn-+ N4 | +---+-+--+ |
| | | | | | SDN-C | |
+----+--+ +-+-+ ++--+----+ +----+ | +---+-+--+ |
|gNB1|======|CSR|------N3-----| PE+UPF |-N6--| DN | | | | |
+----+ +---+ +---+----+ +----+ N2 +---------+ + ---+ |
| | | | |
| +---+--+ +--++ +---+ +-+--+ +----+
| |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN |
| +---+ +---+ +-+-+ +----+ +----+
+----+ +--++ | |
UE1 |gNB2|======|CSR|------N3--------+ |
|
|
+----+ +---+ |
UE1 |gNB2|======|CSR|------N3-------+
== +----+ +---+ == +----+ +---+
Figure 4: SSC Mode1 with integrated Transport Slice Function Figure 4: SSC Mode1 with integrated Transport Slice Function
In this mode, IP address at the UE is preserved during mobility In this mode, IP address at the UE is preserved during mobility
events. This is similar to 4G/LTE mechanism and for respective events. This is similar to 4G/LTE mechanism and for respective
slices, corresponding PPR-ID (TE Path) has to be assigned to the slices, corresponding PPR-ID (TE Path) has to be assigned to the
packet at UL and DL direction. During Xn mobility as shown above, packet at UL and DL direction. During Xn mobility as shown above,
source gNB has to additionally ensure transport path's resources from source gNB has to additionally ensure transport path's resources from
TNF are available at the target gNB apart from radio resources check TNF are available at the target gNB apart from radio resources check
skipping to change at page 24, line 5 skipping to change at page 26, line 24
Sessions. Sessions.
o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU
Session. Session.
In the first mode, from user plane perspective, the two PDU sessions In the first mode, from user plane perspective, the two PDU sessions
are independent and the use of PPR-ID by gNB and UPFs is exactly are independent and the use of PPR-ID by gNB and UPFs is exactly
similar to SSC Mode 1 described above. The following paragraphs similar to SSC Mode 1 described above. The following paragraphs
describe the IPv6 multi-homed PDU session case for SSC Mode 3. describe the IPv6 multi-homed PDU session case for SSC Mode 3.
+--------------+ +--------------+
+---+----+ |NSSMF +-----+ | +----------------+ +---+----+ |NSSMF +-----+ | +----------------+
| AMF | | | TNF | | | SMF | | AMF | | | TNF | | | SMF |
+---+--+-+ | +-+-+-+ | +-+-----------+--+ +---+--+-+ | +-+-+-+ | +-+-----------+--+
| | +--------+-+---+ | | | | +--------+-+---+ | |
N1 | | | | | N1 | | | | |
to-UE+----+ N2 +------Ns---+ +-Nn-+ N4 N4| | | +---+-+--+ | |
+---+ | | | | | | | SDN-C | | |
| | | | | | | +---+-+--+ | |
+---+ +---++ +--+-------+--+ +---+---+ | | | | | |
|gNB|===|CSR |---N3---| PE+BP UPF |-N9--| PE+UPF|-N6-> to-UE+----+ N2 +-----------+ | N4 N4|
+---+ +----+ +----------+--+ +-------+ to DN +---+ | | | |
| +----+ | | | | |
+-| DN | +---+ +---++ +---+ +-------+--+ +---+ +---+
N6 +----+ |gNB|===|CSR |---N3---|PE |-| BP UPF |-N9-|PE |-|UPF|-N6->
+---+ +----+ +---+ +-------+--+ +---+ +---+ to DN
| +----+
+-| DN |
N6 +----+
Figure 5: SSC Mode3 and Service Continuity Figure 5: SSC Mode3 and Service Continuity
In the uplink direction for the traffic offloading from the Branching In the uplink direction for the traffic offloading from the Branching
Point UPF, packet has to reach to the right exit UPF. In this case Point UPF, packet has to reach to the right exit UPF. In this case
packet gets re-encapsulated by the BP UPF (with either GTP-U or the packet gets re-encapsulated by the BP UPF (with either GTP-U or the
chosen encapsulation) after bit rate enforcement and LI, towards the chosen encapsulation) after bit rate enforcement and LI, towards the
anchor UPF. At this point packet has to be on the appropriate VPN/PW anchor UPF. At this point packet has to be on the appropriate VPN/PW
to the anchor UPF. This mapping is done based on the S-NSSAI the PDU to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
session belongs to and/or with the UDP source port (corresponds to session belongs to and/or with the UDP source port (corresponds to
the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the the MTNC-ID (Section 2.5)) of the GTP-U encapsulation header to the
PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR
path) of the UPF. If it's a non-MPLS underlay, destination IP path) of the UPF. If it's a non-MPLS underlay, destination IP
address of the encapsulation header would be the mapped PPR-ID (TE address of the encapsulation header would be the mapped PPR-ID (TE
path). path).
In the downlink direction for the incoming packet, UPF has to In the downlink direction for the incoming packet, UPF has to
encapsulate the packet (with either GTP-U or the chosen encapsulate the packet (with either GTP-U or the chosen
encapsulation) to reach the BP UPF. Here mapping is done based on encapsulation) to reach the BP UPF. Here mapping is done based on
the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the
BP UPF. If it's a non-MPLS underlay, destination IP address of the BP UPF. If it's a non-MPLS underlay, destination IP address of the
skipping to change at page 25, line 27 skipping to change at page 28, line 4
Email: umac.ietf@gmail.com Email: umac.ietf@gmail.com
Richard Li Richard Li
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: richard.li@futurewei.com Email: richard.li@futurewei.com
Sridhar Bhaskaran Sridhar Bhaskaran
Altiostar Altiostar
Email: sridharb@altiostar.com Email: sridharb@altiostar.com
John Kaippallimalil John Kaippallimalil (editor)
Futurewei Futurewei
Email: john.kaippallimalil@futurewei.com Email: john.kaippallimalil@futurewei.com
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Apstra, Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Luis M. Contreras Luis M. Contreras
Telefonica Telefonica
Sur-3 building, 3rd floor Sur-3 building, 3rd floor
Madrid 28050 Madrid 28050
Spain Spain
Email: luismiguel.contrerasmurillo@telefonica.com Email: luismiguel.contrerasmurillo@telefonica.com
Praveen Muley Praveen Muley
Nokia Nokia
 End of changes. 84 change blocks. 
306 lines changed or deleted 446 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/