< draft-clt-dmm-tn-aware-mobility-02.txt   draft-clt-dmm-tn-aware-mobility-03.txt >
DMM Working Group U. Chunduri, Ed. DMM Working Group U. Chunduri, Ed.
Internet-Draft R. Li Internet-Draft R. Li
Intended status: Standards Track Huawei USA Intended status: Standards Track Huawei USA
Expires: April 19, 2019 J. Tantsura Expires: August 18, 2019 S. Bhaskaran
Huawei Technologies India Pvt Ltd
J. Tantsura
Apstra, Inc. Apstra, Inc.
L. Contreras L. Contreras
Telefonica Telefonica
X. De Foy P. Muley
InterDigital Communications, LLC Nokia
October 16, 2018 February 14, 2019
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-clt-dmm-tn-aware-mobility-02 draft-clt-dmm-tn-aware-mobility-03
Abstract Abstract
This document specifies a framework and a mapping function for 5G This document specifies a framework and a mapping function for 5G
mobile user plane with transport network slicing, integrated with mobile user plane with transport network slicing, integrated with
Mobile Radio Access and a Virtualized Core Network. The integrated Mobile Radio Access and a Virtualized Core Network. The integrated
approach specified in a way to address all the mobility scenarios approach is specified in a way to fit into the 5G core network
defined in [TS23.501] and to be backward compatible with LTE architecture defined in [TS23.501].
[TS.23.401-3GPP] network deployments.
It focuses on an optimized mobile user plane functionality with It focuses on an optimized mobile user plane functionality with
various transport services needed for some of the 5G traffic needing various transport services needed for some of the 5G traffic needing
low and deterministic latency, real-time, mission-critical services. low and deterministic latency, real-time, mission-critical services.
This document describes, how this objective is achieved agnostic to This document describes, how this objective is achieved agnostic to
the transport underlay used (IPv4, IPv6, MPLS) in various deployments the transport underlay used (IPv4, IPv6, MPLS) in various deployments
and with a new transport network underlay routing, called Preferred and with a new transport network underlay routing, called Preferred
Path Routing (PPR). Path Routing (PPR).
Requirements Language Requirements Language
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 April 19, 2019. This Internet-Draft will expire on August 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 and Problem Statement . . . . . . . . . . . . . 3 1. Introduction and Problem Statement . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5
2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5 2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5
2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6 2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 7
2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7 2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 8
2.3. Transport Network Function . . . . . . . . . . . . . . . 9 2.3. Transport Network Function . . . . . . . . . . . . . . . 10
3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 10
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 10 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 11
3.2. Path Steering Support to native IP user planes . . . . . 12 3.2. Path Steering Support to native IP user planes . . . . . 13
3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 12 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 13
3.4. PPR with various 5G Mobility procedures . . . . . . . . . 12 3.4. PPR with various 5G Mobility procedures . . . . . . . . . 13
3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12 3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13 3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 14 3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 15
4. Other TE Technologies Applicability . . . . . . . . . . . . . 15 4. Other TE Technologies Applicability . . . . . . . . . . . . . 16
5. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Appendix: New Control Plane and User Planes . . . . 19 Appendix A. Appendix: New Control Plane and User Planes . . . . 20
A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 19 A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 20
A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 19 A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction and Problem Statement 1. Introduction and Problem Statement
3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP], 3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP],
[TS.23.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9 [TS.23.502-3GPP] and [TS.23.503-3GPP]. User Plane Functions (UPF)
[TS.23.501-3GPP] has been created between 2 User Plane are the data forwarding entities in the 5GC architecture. The
Functionalities (UPFs). While user plane for N9 interface being architecture allows the placement of Branching Point (BP) and Uplink
finalized for REL16, both GTP-U based encapsulation or any other Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-
compatible approach is being considered [CT4SID]. Concerning to this AN can be a radio access network or any non-3GPP access network, for
document another relevant interface is N3, which is between gNB and example, WLAN. The IP address is anchored by a PDU session anchor
the UPF. N3 interface is similar to the user plane interface S1U in UPF (PSA UPF). The interface between the BP/ULCL UPF and the PSA UPF
LTE [TS.23.401-3GPP]. This document: is called N9. While in REL15, 3GPP has adopted GTP-U for the N9
interface, new user plane protocols along with GTP-U are being
investigated for N9 interface in REL16, as part of [CT4SID].
Concerning to this document another relevant interface is N3, which
is between the 5G-AN and the UPF. N3 interface is similar to the
user plane interface S1U in LTE [TS.23.401-3GPP]. This document:
o does not propose any change to existing N3 user plane o does not propose any change to existing N3 user plane
encapsulations to realize the benefits with the approach specified encapsulations to realize the benefits with the approach specified
here here
o and can work with any encapsulation (including GTP-U) for the N9 o and can work with any encapsulation (including GTP-U) for the N9
interface. interface.
[TS.23.501-3GPP] defines various Session and Service Continuity (SSC) [TS.23.501-3GPP] defines network slicing as one of the core
modes and mobility scenarios for 5G with slice awareness from Radio capability of 5GC with slice awareness from Radio and 5G Core (5GC)
and 5G Core (5GC) network. 5G System (5GS) as defined, allows network. It also defines various Session and Service Continuity
transport network between N3 and N9 interfaces work independently (SSC) modes and mobility scenarios for 5G. The 5G System (5GS) as
with various IETF Traffic Engineering (TE) technologies. defined, allows transport network between N3 and N9 interfaces work
independently with various IETF Traffic Engineering (TE)
technologies.
However, lack of underlying Transport Network (TN) awareness can be However, lack of underlying Transport Network (TN) awareness may lead
problematic for some of the 5GS procedures, for real-time, mission- to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS
critical or for any deterministic latency services. These 5GS procedures. This could lead to inability to meet SLAs for real-time,
procedures including but not limited to Service Request, PDU Session, mission-critical or latency sensitive services. These 5GS procedures
or User Equipment (UE) mobility need same service level including but not limited to Service Request, PDU Session
characteristics from the TN for the Protocols Data Unit (PDU) Establishment, or User Equipment (UE) mobility need same service
session, similar to as provided in Radio and 5GC for various 5QI's level characteristics from the TN for the Protocols Data Unit (PDU)
defined in [TS.23.501-3GPP] . session, similar to as provided in Radio and 5GC for the various
Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP] .
1.1. Acronyms 1.1. Acronyms
5QI - 5G QoS Indicator 5QI - 5G QoS Indicator
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
DN - Data Network (5G) DN - Data Network (5G)
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)
skipping to change at page 4, line 39 skipping to change at page 5, line 4
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)
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)
1.2. Solution Approach 1.2. Solution Approach
This document specifies a mechanism to fulfil the needs of 5GS to This document specifies a mechanism to fulfil the needs of 5GS to
transport user plane traffic from gNB 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 mobility procedures aware of underlying transport
network along with slicing requirements. TN with mobility awareness network along with slicing requirements.
described here in a way, which does not erase performance and latency
gains made with 5G New Radio(5GNR) and virtualized cellular core
network features developed in [TS.23.501-3GPP].
Section 2 describes two methods, with which Transport Network (TN) Section 2 describes two methods, with which Transport Network (TN)
aware mobility can be built irrespective of underlying TN technology aware mobility can be built irrespective of underlying TN technology
used. Using Preferred Path Routing (PPR) as TN Underlay is detailed used. Using Preferred Path Routing (PPR) as TN Underlay is detailed
in Section 3. Section 3.4 further describes the applicability and in Section 3. Section 3.4 further describes the applicability and
procedures of the same with 5G SSC modes on N3 and N9 interfaces. At procedures of the same with 5G SSC modes on N3 and N9 interfaces.
the end, Section 5 recapitulates the benefits of specified approach
in mobile networks.
2. Transport Network (TN) and Slice aware Mobility on N3/N9 2. Transport Network (TN) and Slice aware Mobility on N3/N9
Service Based Interfaces (SBI) Service Based Interfaces (SBI)
----+-----+-----+----+----+-----+----+--------+-----+----+------ ----+-----+-----+----+----+-----+----+--------+-----+----+------
| | | | | | | | | | | | | | | | | | | |
+---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+ +---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+
| NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF | | NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF |
+-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+ +-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+
+---+----+ +--+--+ +---=++ +--------------+-+ +---+----+ +--+--+ +---=++ +--------------+-+
| AMF | | PCF | | TNF | | SMF | | AMF | | PCF | | TNF | | SMF |
+---+--+-+ +-----+ +-+-+-+ +-+-----------+--+ +---+--+-+ +-----+ +-+-+-+ +-+-----------+--+
N1 | | | | To | N1 | | | | To |
skipping to change at page 6, line 5 skipping to change at page 6, line 28
+---+ +---+ +-+------+ +-------+ +----+ +---+ +---+ +-+------+ +-------+ +----+
| +----+ | +----+
+-| DN | +-| DN |
N6 +----+ N6 +----+
Figure 1: 5G Service Based Architecture Figure 1: 5G Service Based Architecture
The above diagrams depicts one of the scenarios of the 5G network The above diagrams depicts one of the scenarios of the 5G network
specified in [TS.23.501-3GPP] and with a new and virtualized control specified in [TS.23.501-3GPP] and with a new and virtualized control
component Transport Network Function (TNF). A Cell Site Router (CSR) component Transport Network Function (TNF). A Cell Site Router (CSR)
is shown connecting to gNB. Though it is shown as a separate block is shown connecting to gNB. gNB is an entity in 5G-AN. Though it is
from gNB, in some cases both of these can be co-located. This shown as a separate block from gNB, in some cases both of these can
document concerns with backhaul TN, from CSR to UPF on N3 interface be co-located. This document concerns with backhaul TN, from CSR to
or from Staging UPF to Anchor UPF on N9 interface. UPF on N3 interface or from Staging UPF to Anchor UPF on N9
interface.
Currently specified Control Plane (CP) functions Access and Mobility Currently specified Control Plane (CP) functions - the Access and
Management Function (AMF), Session Management Function (SMF) and User Mobility Management Function (AMF), the Session Management Function
plane (UP) components gNodeB (gNB), User Plane Function (UPF) with (SMF) and the User plane (UP) components gNodeB (gNB), User Plane
N2, N3, N4, N6 and N9 are relevant to this document. Other Function (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to
Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM, this document. Other Virtualized 5G control plane components NRF,
NEF, and AF are not directly relevant for the discussion in this AUSF, PCF, AUSF, UDM, NEF, and AF are not directly relevant for the
document and one can see the functionalities of these in discussion in this document and one can see the functionalities of
[TS.23.501-3GPP]. these in [TS.23.501-3GPP].
From encapsulation perspective, N3 interface is similar to S1U in 4G/ From encapsulation perspective, N3 interface is similar to S1U in 4G/
LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to
transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
Unlike S1U, N3 has some additional aspects as there is no bearer Unlike S1U, N3 has some additional aspects as there is no bearer
concept and per no per bearer GTP-U tunnels. Instead, QoS concept and no per bearer GTP-U tunnels. Instead, QoS information is
information is carried in the PDU Session Container GTP-U extension carried in the PDU Session Container GTP-U extension header. N9
header. N9 interface is a new interface to connect UPFs and right interface is a new interface to connect UPFs and the right user plane
user plane protocol/encapsulation is being studied through 3GPP CT4 protocols for N9, including GTP-U, are being studied through 3GPP CT4
WG approved study item [CT4SID] for REL-16. WG approved study item [CT4SID] for REL-16.
TN Aware Mobility with optimized transport network functionality is TN Aware Mobility with optimized transport network functionality is
explained below. How PPR fits in this framework in detail along with explained below. How PPR fits in this framework in detail along with
other various TE technologies briefly are in Section 3 and Section 4 other various TE technologies briefly are in Section 3 and Section 4
respectively. respectively.
2.1. Discrete Approach 2.1. Discrete Approach
In this approach transport network functionality from gNB to UPF is In this approach transport network functionality from the 5G-AN to
discrete and 5GS is not aware of the underlying transport network and UPF is discrete and 5GS is not aware of the underlying transport
the resources available. Deployment specific mapping function is network and the resources available. Deployment specific mapping
used to map the GTP-U encapsulated traffic at gNB at UL and UPF in DL function is used to map the GTP-U encapsulated traffic at the 5G-AN
direction to the appropriate transport slice or transport Traffic (e.g. gNB) in UL and UPF in DL direction to the appropriate transport
Engineered (TE) paths. These TE paths can be established using RSVP- slice or transport Traffic Engineered (TE) paths. These TE paths can
TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing] be established using RSVP-TE [RFC3209] for MPLS underlay, SR
for both MPLS and IPv6 underlay or PPR [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or
[I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6 with PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6
SRH, native IPv6 and native IPv4 underlays. with SRH, native IPv6 and native IPv4 underlays.
In this case, the encapsulation provided by GTP-U helps carry As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
different PDU session types (IPv4, IPv6, IPv4IPv6, Ethernet and user plane traffic forwarding rules in the UPF. The UPFs have a
Unstructured) independent of the underlying transport or user plane concept of a "Network Instance" which logically abstracts the
(IPv4, IPv6 or MPLS) network. Mapping of the PDU sessions to TE underlying transport path. When the SMF creates the packet detection
paths can be done based on the source UDP port ranges (if these are rules (PDR) and forwarding action rules (FAR) for a PDU session at
assigned based on the PDU session QCIs, as done in some deployments the UPF, the SMF identifies the network instance through which the
with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or packet matching the PDR has to be forwarded. A network instance can
RQI values in the GTP-U header. Here, TNF as shown in Figure 1 need be mapped to a TE path at the UPF. In this approach, TNF as shown in
not be part of the 5G Service Based Interface (SBI). Only management Figure 1 need not be part of the 5G Service Based Interface (SBI).
plane functionality is needed to create, monitor, manage and delete Only management plane functionality is needed to create, monitor,
(life cycle management) the transport TE paths/transport slices from manage and delete (life cycle management) the transport TE paths/
gNB to UPF (on N3/N9 interfaces). This approach provide partial transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
integration of the transport network into 5GS with some benefits. The management plane functionality also provides the mapping of such
TE paths to a network instance identifier to the SMF. The SMF uses
this mapping to install appropriate FARs in the UPF. This approach
provide partial integration of the transport network into 5GS with
some benefits.
One of the limitations of this approach is the inability of 5GS One of the limitations of this approach is the inability of the 5GS
procedures to know, if underlying transport resources are available procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could certain decisions in the 5G CP. One example scenario/decision could
be, a target gNB selection in Xn mobility event, without knowing if be, a target gNB selection during a N2 mobility event, without
the target gNB is having a underlay transport slice resource for the knowing if the target gNB is having a underlay transport slice
5QI of the PDU session. The below approach can mitigate this. resource for the S-NSSAI and 5QI of the PDU session. The Integrated
approach specified below can mitigate this.
2.2. Integrated Approach 2.2. Integrated Approach
Network Slice Selection Function (NSSF) as defined in Network Slice Selection Function (NSSF) as defined in
[TS.23.501-3GPP] concerns with multiple aspects including selecting a [TS.23.501-3GPP] concerns with multiple aspects including selecting a
network slice instance when requested by AMF based on the requested network slice instance when requested by AMF based on the requested
SNSSAI, current location of UE, roaming indication etc. It also SNSSAI, current location of UE, roaming indication etc. It also
notifies NF service consumers (e.g AMF) whenever the status about the notifies NF service consumers (e.g AMF) whenever the status about the
slice availability changes. However, the scope is only in 5GC (both slice availability changes. However, the scope is only in 5GC (both
control and user plane) and NG Radio Access network including N3IWF control and user plane) and NG Radio Access network including the
for non-3GPP access. Slice functionality is per PDU session N3IWF for the non-3GPP access. The network slice instance(s)
granularity, which covers needed functionality and resources from UE selected by the NSSF are applicable at a per PDU session granularity.
registration, Tracking Area (TA) updates, mobility and roaming, An SMF and UPF are allocated from the selected slice instance during
resources and functionalities needed from transport network is not the PDU session establishment procedure. [TS.23.501-3GPP] and
specified. This is seen as independent functionality and currently [TS.23.502-3GPP] do not consider the resources and functionalities
not part of 5GS. If transport network is not factored in an needed from transport network for the selection of UPF. This is seen
integrated fashion w.r.t available resources (with network as independent functionality and currently not part of 5GS. If
characteristics from desired bandwidth, latency, burst size handling transport network is not factored in an integrated fashion w.r.t
and optionally jitter) some of the gains made with optimizations available resources (with network characteristics from desired
through 5GNR and 5GC can be degraded. bandwidth, latency, burst size handling and optionally jitter) some
of the gains made with optimizations through 5GNR and 5GC can be
degraded.
To assuage the above situation, TNF is described (Figure 1) as part To assuage the above situation, TNF is described (Figure 1) as part
of control plane. This has the view of the underlying transport of control plane. This has the view of the underlying transport
network with all links and nodes as well as various possible underlay network with all links and nodes as well as various possible underlay
paths with different characteristics. TNF can be seen as supporting paths with different characteristics. TNF can be seen as supporting
PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get PCE functionality [RFC5440] and optionally BGP-LS [RFC7752] to get
the TE and topology information of the underlying IGP network. the TE and topology information of the underlying IGP network.
A south bound interface Ns is shown which interacts with the gNB/CSR. A south bound interface Ns is shown which interacts with the 5G
'Ns' can use one or more mechanism available today (PCEP [RFC5440], Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism
NETCONF [RFC6241], RESTCONF [RFC8040] or gNMI) to provision the L2/L3 available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF
VPNs along with TE underlay paths from gNB to UPF. Ns and Nn [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay
interfaces can be part of the integrated 3GPP architecture, but the paths from gNB to UPF. Ns and Nn interfaces can be part of the
specification/ownership of these interfaces SHOULD be left out of integrated 3GPP architecture, but the specification/ownership of
scope of 3GPP. these interfaces SHOULD be left out of scope of 3GPP.
These VPNs and/or underlay TE paths MUST be similar on all gNB/CSRs 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 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]. A of the Slice/Service Types (SSTs)as defined in [TS.23.501-3GPP]. A
north bound interface 'Nn' is shown from one or more of the transport north bound interface 'Nn' is shown from one or more of the transport
network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as shown in network nodes (or ULCL/BP UPF, Anchor Point UPF) to TNF as shown in
Figure 1. It would enable learning the TE characteristics of all Figure 1. It would enable learning the TE characteristics of all
links and nodes of the network continuously (through BGP-LS [RFC7752] links and nodes of the network continuously (through BGP-LS [RFC7752]
or through a passive IGP adjacency and PCEP [RFC5440]). or through a passive IGP adjacency and PCEP [RFC5440]).
With the TNF in 5GS Service Based Interface, the following additional With the TNF in 5GS Service Based Interface, the following additional
functionalities are required for end-2-end slice management including functionalities are required for end-2-end slice management including
skipping to change at page 8, line 33 skipping to change at page 9, line 21
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 (gNB/CSR and UPF). monitored from each transport end point (gNB/CSR and UPF).
o During PDU session creation, apart from radio and 5GC resources, o During PDU session creation, apart from radio and 5GC resources,
transport network resources needed to be verified matching the transport network resources needed to be verified matching the
characteristics of the PDU session traffic type. characteristics of the PDU session traffic type.
o Mapping of PDU session parameters to underlay SST paths need to be o The TNF MUST provide an API that takes as input the source and
done. One way to do this is through 5QI/QFI information in the destination 3GPP user plane element address, required bandwidth,
GTP-U header and map the same to the underlying transport path latency and jitter characteristics between those user plane
(including VPN or PW). This works for uplink (UL) direction. elements and returns as output a particular TE path's identifier,
that satisfies the requested requirements.
o For downlink direction RQI need to be considered to map the DL o Mapping of PDU session parameters to underlay SST paths need to be
packet to one of the underlay paths at the UPF. 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
"Network Instance" in the UPF. A "Network Instance" is a logical
identifier for an underlying network. The "Network Instance"
pointed by the FAR can be mapped to a transport path (through L2/
L3 VPN). FARs are associated with Packet Detection Rule (PDR).
PDRs are used to classify packets in the uplink (UL) and the
downlink (DL) direction. For UL GTP-U TEID and/or the QFI marked
in the GTPU packet can be used for classifying a packet belonging
to a particular slice characteristics. For DL, at a PSA UPF, the
UE IP address is used to identify the PDU session, and hence the
slice a packet belongs to and the IP 5 tuple can be used for
identifying the flow and QoS characteristics to be applied on the
packet.
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 5QI/QFI or RQI information MUST be there in or N9 corresponding QFI information MUST be there in the
the encapsulation header. encapsulation header.
o In some SSC modes Section 3.4, if segmented path (gNB to o In some SSC modes Section 3.4, if segmented path (gNB to
staging/ULCL/BP-UPF to anchor-point-UPF) is needed, then staging/ULCL/BP-UPF to 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 gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP path from gNB/CSR to UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP
UPF to eventual UPF access to DN. UPF to eventual UPF access to DN.
o Continuous monitoring of transport path characteristics and o Continuous monitoring of transport path characteristics and
reassignment at the endpoints MUST be performed. For all the reassignment at the endpoints MUST be performed. For all the
effected PDU sessions, degraded transport paths need to be updated affected PDU sessions, degraded transport paths need to be updated
dynamically with similar alternate paths. 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.
Changes to detailed signaling to integrate the above for various 5GS Integrating the TNF as part of the 5GS Service Based Interfaces,
procedures as defined in [TS.23.502-3GPP] is beyond the scope of this provides the flexibility to control the allcoation of required
document. characteristics from the TN during a 5GS signalling procedure (e.g.
PDU Session Establishment). If TNF is seen as part of management
plane, this real time flexibility is lost. Changes to detailed
signaling to integrate the above for various 5GS procedures as
defined in [TS.23.502-3GPP] is beyond the scope of this document.
2.3. Transport Network Function 2.3. Transport Network Function
Proposed TNF as part of the 5GC shown in Figure 1 can be realized Proposed TNF as part of the 5GC shown in Figure 1 can be realized
using Abstraction and Control of TE Networks (ACTN). ACTN using Abstraction and Control of TE Networks (ACTN). ACTN
architecture, underlying topology abstraction methods and architecture, underlying topology abstraction methods and
manageability considerations of the same are detailed in [RFC8453]. manageability considerations of the same are detailed in [RFC8453].
3. Using PPR as TN Underlay 3. 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 are addressed by a new backhaul same document. Those concerns are addressed by a new backhaul
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.
The label/PPR-ID refer not to individual segments of which the path The label/PPR-ID refer not to individual segments of which the path
is composed, but to the identifier of a path that is deployed on is composed, but to the identifier of a path that is deployed on
network nodes. The fact that paths and path identifiers can be network nodes. The fact that paths and path identifiers can be
computed and controlled by a controller, not a routing protocol, computed and controlled by a controller, not a routing protocol,
allows the deployment of any path that network operators prefer, not allows the deployment of any path that network operators prefer, not
just shortest paths. As packets refer to a path towards a given just shortest paths. As packets refer to a path towards a given
destination and nodes make their forwarding decision based on the destination and nodes make their forwarding decision based on the
identifier of a path, not the identifier of a next segment node, it identifier of a path, not the identifier of a next segment node, it
is no longer necessary to carry a sequence of labels. This results is no longer necessary to carry a sequence of labels. This results
skipping to change at page 10, line 20 skipping to change at page 11, line 24
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 both N3 and any
approach selected for N9 (encap or no-encap). In this scenario, PPR approach selected for N9 (encap or no-encap). In this scenario, PPR
will only help providing TE benefits needed for 5G slices from will only help providing TE benefits needed for 5G slices from
transport domain perspective. It does so without adding any transport domain perspective. It does so without adding any
additional overhead to the user plane, unlike SR-MPLS or SRv6. This additional overhead to the user plane, unlike SR-MPLS or SRv6. This
is achieved by: is achieved by:
o For 3 different SSTs, 3 PPR-IDs can signaled from any node in the o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in
transport network. For Uplink traffic, gNB will choose the right the transport network. For Uplink traffic, the 5G-AN will choose
PPR-ID of the UPF based on the 5QI value in the encapsulation the right PPR-ID of the UPF based on the S-NSSAI the PDU Session
header of the PDU session. Similarly in the Downlink direction belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U
matching PPR-ID of the gNB is chosen for the RQI value in the encapsulation header. Similarly in the Downlink direction
encapsulated SL payload. The table below shows a typical mapping: matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the
PDU Session belongs to. The table below shows a typical mapping:
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| 5QI (Ranges)/ | SST | Transport Path | Transport Path | | QFI (Ranges) | SST | Transport Path | Transport Path |
| RQI (Ranges) | | 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 |
| | | | Jitter: Jx | | | | | Jitter: Jx |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Yx - Yy | | | | | Range Yx - Yy | | | |
| Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay | | Y1, Y2(discrete| URLLC | PW ID/VPN info, | GBR with Delay |
| values) | (ultra-low | PPR-ID-B | Req. | | values) | (ultra-low | PPR-ID-B | Req. |
| | latency) | | Bandwidth: By | | | latency) | | Bandwidth: By |
| | | | Delay: Dy | | | | | Delay: Dy |
| | | | Jitter: Jy | | | | | Jitter: Jy |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
| Range Zx - Zy | | | | | Range Zx - Zy | | | |
| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR | | Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
| values) | (broadband)| PPR-ID-C | Bandwidth: Bx | | values) | (broadband)| PPR-ID-C | Bandwidth: Bx |
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
Figure 2: 5QI/RQI Mapping with PPR-IDs on N3/N9 Figure 2: QFI Mapping with PPR-IDs on N3/N9
o It is possible to have a single PPR-ID for multiple input points o It is possible to have a single PPR-ID for multiple input points
through a PPR tree structure separate in UL and DL direction. through a PPR tree structure separate in UL and DL direction.
o Same set of PPRs are created uniformly across all needed gNBs and o Same set of PPRs are created uniformly across all needed 5G-ANs
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, AMF ingress points. Same information can be pushed to the NSSF, and/
and 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.2) with optional TE features (Section 3.3) . As
this is an underlay mechanism it can work with any overlay this is an underlay mechanism it can work with any overlay
encapsulation approach including GTP-U as defined currently for N3 encapsulation approach including GTP-U as defined currently for N3
interface. interface.
3.2. Path Steering Support to native IP user planes 3.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 [I-D.chunduri-lsr-isis-preferred-path-routing] or listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or
Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR
skipping to change at page 12, line 35 skipping to change at page 13, line 35
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.
3.4. PPR with various 5G Mobility procedures 3.4. PPR with various 5G Mobility procedures
PPR fulfills the needs of 5GS to transport the user plane traffic PPR fulfills the needs of 5GS to transport the user plane traffic
from gNB to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This is from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This
done in keeping the backhaul network at par with 5G slicing is done in keeping the backhaul network at par with 5G slicing
requirements that are applicable to Radio and virtualized core requirements that are applicable to Radio and virtualized core
network to create a truly end-to-end slice path for 5G traffic. When network to create a truly end-to-end slice path for 5G traffic. When
UE moves from one gNB to another gNB, there is no transport network UE moves across the 5G-AN (e.g. from one gNB to another gNB), there
reconfiguration require with the approach above. is no transport network reconfiguration required with the approach
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.
3.4.1. SSC Mode1 3.4.1. SSC Mode1
+---+----+ +-----+ +----------------+ +---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF | | AMF | | TNF | | SMF |
+---+--+-+ +-+-+-+ +-+--------------+ +---+--+-+ +-+-+-+ +-+--------------+
N1 | | | | N1 | | | |
+--------+ N2 +----Ns---+ +-Nn-+ N4 +--------+ N2 +----Ns---+ +-Nn-+ N4
skipping to change at page 14, line 15 skipping to change at page 15, line 15
if needed. For PDU Session, Service Request and Mobility cases if needed. For PDU Session, Service Request and Mobility cases
mechanism to select the transport resource and the PPR-ID (TE Path) mechanism to select the transport resource and the PPR-ID (TE Path)
is similar to SSC Mode1. is similar to SSC Mode1.
3.4.3. SSC Mode3 3.4.3. SSC Mode3
In this mode, new IP address may be assigned because of UE moved to In this mode, new IP address may be assigned because of UE moved to
another UPF coverage area. Network ensures UE suffers no loss of another UPF coverage area. Network ensures UE suffers no loss of
'connectivity'. A connection through new PDU session anchor point is 'connectivity'. A connection through new PDU session anchor point is
established before the connection is terminated for better service established before the connection is terminated for better service
continuity. continuity. There are two ways in which this happens.
o Change of SSC Mode 3 PDU Session Anchor with multiple PDU
Sessions.
o Change of SSC Mode 3 PDU Session Anchor with IPv6 multi-homed PDU
Session.
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
similar to SSC Mode 1 described above. The following paragraphs
describe the IPv6 multi-homed PDU session case for SSC Mode 3.
+---+----+ +-----+ +----------------+ +---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF | | AMF | | TNF | | SMF |
+---+--+-+ +-+-+-+ +-+-----------+--+ +---+--+-+ +-+-+-+ +-+-----------+--+
N1 | | | | | N1 | | | | |
to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4| to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4|
| | | | | | | | | |
+-------+--+ +--+-------+--+ +-----+-+ +-------+--+ +--+-------+--+ +-----+-+
|gNB/CSR +---N3---+ BP/ULCL UPF +-N9--+ UPF +-N6-- |gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6--
+----------+ +----------+--+ +-------+ to DN +----------+ +----------+--+ +-------+ to DN
| +----+ | +----+
+-| DN | +-| DN |
N6 +----+ N6 +----+
Figure 5: SSC Mode3 and Service Continuity Figure 5: SSC Mode3 and Service Continuity
In the uplink direction for the traffic offloading from UL/CL case, In the uplink direction for the traffic offloading from the Branching
packet has to reach to the right exit UPF. In this case packet gets Point UPF, packet has to reach to the right exit UPF. In this case
re-encapsulated with ULCL marker (with either GTP-U or the chosen packet gets re-encapsulated by the BP UPF (with either GTP-U or the
encapsulation) after bit rate enforcement and LI to the anchor UPF. chosen encapsulation) after bit rate enforcement and LI, towards the
At this point packet has to be on the appropriate VPN/PW to the anchor UPF. At this point packet has to be on the appropriate VPN/PW
anchor UPF. This mapping is done based on the 5QI to the PPR-ID of to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
the exit node by selecting the respective TE PPR-ID (PPR path) of the session belongs to and/or the QFI marking in the GTPU encapsulation
UPF. If it's a non-MPLS underlay, destination IP address of the header (e.g. 5QI value) to the PPR-ID of the exit node by selecting
encapsulation header would be the mapped PPR-ID (TE path). the respective TE PPR-ID (PPR 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 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/ULCL UPF. Here mapping is done for encapsulation) to reach the BP UPF. Here mapping is done based on
RQI parameter in the encapsulation header to PPR-ID (TE Path) of the the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the
BP/ULCL UPF. If it's a non-MPLS underlay, destination IP address of BP UPF. If it's a non-MPLS underlay, destination IP address of the
the encapsulation header would be the mapped PPR-ID (TE path). In encapsulation header would be the mapped PPR-ID (TE path). In
summary: summary:
o Respective PPR-ID on N3 and N9 has to be selected with correct o Respective PPR-ID on N3 and N9 has to be selected with correct
transport characteristics from TNF. transport characteristics from TNF.
o For N2 based mobility AMF/SMF has to ensure transport resources o For N2 based mobility SMF has to ensure transport resources are
are available for N3 Interface to new ULCL and from there the available for N3 Interface to new BP UPF and from there the
original anchor point UPF. original anchor point UPF.
o For Service continuity with multi-homed PDU session same transport o For Service continuity with multi-homed PDU session same transport
network characteristics of the original PDU session (both on N3 network characteristics of the original PDU session (both on N3
and N9) need to be observed for the newly created PDU session. and N9) need to be observed for the newly configured IPv6
prefixes.
4. Other TE Technologies Applicability 4. 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].
skipping to change at page 15, line 41 skipping to change at page 17, line 7
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), in the integrated
transport network function (TNF) a particular RSVP-TE path for MPLS transport network function (TNF) a particular RSVP-TE path for MPLS
or SR path for MPLS and IPv6 with SRH user plane, can be supplied to or SR path for MPLS and IPv6 with SRH user plane, can be supplied to
SMF for mapping a particular PDU session to the transport path. SMF for mapping a particular PDU session to the transport path.
5. Summary and Benefits with PPR 5. Acknowledgements
This document specifies an approach to transport and slice aware
mobility with a simple mapping function from PDU Session to transport
path applicable to any TE underlay.
This also describes PPR
[I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay
routing mechanism, which helps with goal of optimized user plane for
N9 interface. PPR provides a method for N3 and N9 interfaces to
support transport slicing in a way which does not erase the gains
made with 5GNR and virtualized cellular core network features for
various types of 5G traffic (e.g. needing low and deterministic
latency, real-time, mission-critical or AR/VR traffic). PPR provides
path steering, optionally guaranteed services with TE, unique Fast-
ReRoute (FRR) mechanism with preferred backups (beyond shortest path
backups through existing LFA schemes) in the mobile backhaul network
with any underlay being used in the operator's network (IPv4, IPv6 or
MPLS) in an optimized fashion.
6. Acknowledgements
Thanks to Young Lee and John Kaippallimalil for discussions on this Thanks to Young Lee and John Kaippallimalil for discussions on this
document including ACTN applicability for the proposed TNF. Thanks document including ACTN applicability for the proposed TNF. Thanks
to Sri Gundavelli and 3GPP delegates who provided detailed feedback to Sri Gundavelli and 3GPP delegates who provided detailed feedback
on this document. on this document.
7. IANA Considerations 6. IANA Considerations
This document has no requests for any IANA code point allocations. This document has no requests for any IANA code point allocations.
8. Security Considerations 7. Security Considerations
This document does not introduce any new security issues. This document does not introduce any new security issues.
8. Contributing Authors
The following people contributed substantially to the content of this
document and should be considered co-authors.
Xavier De Foy
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
9. References 9. References
9.1. Normative References 9.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 9.2. Informative References
skipping to change at page 17, line 16 skipping to change at page 18, line 16
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-01 (work in draft-chunduri-lsr-isis-preferred-path-routing-02 (work in
progress), July 2018. progress), February 2019.
[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-01 (work in chunduri-lsr-ospf-preferred-path-routing-02 (work in
progress), July 2018. progress), February 2019.
[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-04 (work in progress), September 2018. network-04 (work in progress), September 2018.
[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.,
daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing daniel.voyer@bell.ca, d., and C. Perkins, "Segment Routing
IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile- IPv6 for Mobile User Plane", draft-ietf-dmm-srv6-mobile-
uplane-02 (work in progress), July 2018. uplane-03 (work in progress), October 2018.
[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.
[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,
skipping to change at page 20, line 20 skipping to change at page 21, line 20
Email: uma.chunduri@huawei.com Email: uma.chunduri@huawei.com
Richard Li Richard Li
Huawei USA Huawei USA
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: renwei.li@huawei.com Email: renwei.li@huawei.com
Sridhar Bhaskaran
Huawei Technologies India Pvt Ltd
Survey No.37, Whitefield Road, Kundalahalli
Bengaluru, Karnataka
India
Email: sridhar.bhaskaran@huawei.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
Nokia
440 North Bernardo Ave
Mountain View, CA 94043
USA
Xavier De Foy Email: praveen.muley@nokia.com
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal
Canada
Email: Xavier.Defoy@InterDigital.com
 End of changes. 58 change blocks. 
204 lines changed or deleted 257 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/