< draft-clt-dmm-tn-aware-mobility-03.txt   draft-clt-dmm-tn-aware-mobility-04.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: Informational Futurewei
Expires: August 18, 2019 S. Bhaskaran Expires: January 9, 2020 S. Bhaskaran
Huawei Technologies India Pvt Ltd Altiostar
J. Tantsura J. Tantsura
Apstra, Inc. Apstra, Inc.
L. Contreras L. Contreras
Telefonica Telefonica
P. Muley P. Muley
Nokia Nokia
February 14, 2019 J. Kaippallimalil
Futurewei
July 8, 2019
Transport Network aware Mobility for 5G Transport Network aware Mobility for 5G
draft-clt-dmm-tn-aware-mobility-03 draft-clt-dmm-tn-aware-mobility-04
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 is specified in a way to fit into the 5G core network approach is specified in a way to fit into the 5G core network
architecture defined in [TS23.501]. architecture defined in [TS23.501].
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 (IPv6, MPLS, IPv4) 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
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
skipping to change at page 2, line 10 skipping to change at page 2, line 12
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 August 18, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5 1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4
2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 7 2. Transport Network and Slice aware Mobility on N3/N9 . . . . . 5
2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 8 2.1. Integrated Approach with TNF in SBI . . . . . . . . . . . 6
2.3. Transport Network Function . . . . . . . . . . . . . . . 10 2.1.1. Transport Network Function and Interfaces . . . . . . 7
3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 10 2.1.2. Functionality for E2E Management . . . . . . . . . . 7
3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 11 2.2. TNF as part of existing 5G Control Function . . . . . . . 9
3.2. Path Steering Support to native IP user planes . . . . . 13 2.2.1. Mobile Transport Network Context and Scalability . . 11
3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 13 2.2.2. MTNC Identifier in the Data Packet . . . . . . . . . 12
3.4. PPR with various 5G Mobility procedures . . . . . . . . . 13 3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 12
3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 13 3.1. PPR with Transport Awareness for 5GS on N3/N9 Interfaces 13
3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Path Steering Support to native IP user planes . . . . . 15
3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 15 3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 15
4. Other TE Technologies Applicability . . . . . . . . . . . . . 16 4. Other TE Technologies Applicability . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 17 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Appendix: New Control Plane and User Planes . . . . 20 Appendix A. New Control Plane and User Planes . . . . . . . . . 19
A.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 20 A.1. Slice aware Mobility: Discrete Approach . . . . . . . . . 19
A.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. PPR with various 5G Mobility procedures . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 20
B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 21
B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction and Problem Statement 1. Introduction
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] and [TS.23.503-3GPP]. User Plane Functions (UPF) [TS.23.502-3GPP] and [TS.23.503-3GPP]. User Plane Functions (UPF)
are the data forwarding entities in the 5GC architecture. The are the data forwarding entities in the 5GC architecture. The
architecture allows the placement of Branching Point (BP) and Uplink architecture allows the placement of Branching Point (BP) and Uplink
Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G- 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 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 example, WLAN. The IP address is anchored by a PDU session anchor
UPF (PSA UPF). The interface between the BP/ULCL UPF and the PSA UPF UPF (PSA UPF).
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 N3, N9 Interfaces: The interface between the BP/ULCL UPF and the PSA
encapsulations to realize the benefits with the approach specified UPF is called N9 [TS.23.501-3GPP]. While in REL15, 3GPP has adopted
here 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 Do not need architectural change to[TS.23.501-3GPP] to provide
3GPP slice, QoS support in transport plane
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 network slicing as one of the core 1.1. Problem Statement
capability of 5GC with slice awareness from Radio and 5G Core (5GC)
network. It also defines various Session and Service Continuity
(SSC) modes and mobility scenarios for 5G. The 5G System (5GS) as
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 may lead [TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one
to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS of the core capability of 5GC with slice awareness from Radio and 5G
procedures. This could lead to inability to meet SLAs for real-time, Core (5GC) network. The 5G System (5GS) as defined, do not consider
mission-critical or latency sensitive services. These 5GS procedures the resources and functionalities needed from transport network for
the selection of UPF. This is seen as independent functionality and
currently not part of 5GS.
However, the lack of underlying Transport Network (TN) awareness may
lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS
procedures. This could also lead to inability to meet SLAs for real-
time, mission-critical or latency sensitive services. 5GS procedures
including but not limited to Service Request, PDU Session including but not limited to Service Request, PDU Session
Establishment, or User Equipment (UE) mobility need same service Establishment, or User Equipment (UE) mobility need same service
level characteristics from the TN for the Protocols Data Unit (PDU) level characteristics from the TN for the Protocols Data Unit (PDU)
session, similar to as provided in Radio and 5GC for the various 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] . Slice Service Types (SST) and 5QI's defined in [TS.23.501-3GPP].
1.1. Acronyms 1.2. Solution Approach
This document specifies 2 approaches to fulfil the needs of 5GS to
transport user plane traffic from 5G-AN to UPF for all service
continuity modes [TS.23.501-3GPP] in an optimized fashion. This is
done by, keeping mobility procedures aware of underlying transport
network along with slicing requirements.
Section 2 describes in detail on how TN aware mobility can be built
irrespective of underlying TN technology used. Using Preferred Path
Routing (PPR), applicable to any transport network underlay (IPv6,
MPLS and IPv4) is detailed in Section 3. How other IETF TE
technologies applicable for this draft is specified in Section 4. At
the end, Appendix B further describes the applicability and
procedures of PPR with 5G SSC modes on N3 and N9 interfaces.
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
skipping to change at page 5, line 4 skipping to change at page 5, line 25
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 2. Transport Network and Slice aware Mobility on N3/N9
This document specifies a mechanism to fulfil the needs of 5GS to Currently specified Control Plane (CP) functions - the Access and
transport user plane traffic from 5G-AN to UPF for all service Mobility Management Function (AMF), the Session Management Function
continuity modes [TS.23.501-3GPP] in an optimized fashion. This is (SMF) and the User plane (UP) components gNB, User Plane Function
done by, keeping mobility procedures aware of underlying transport (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to this
network along with slicing requirements. document. Other Virtualized 5G control plane components NRF, AUSF,
PCF, AUSF, UDM, NEF, and AF are not directly relevant for the
discussion in this document and one can see the functionalities of
these in [TS.23.501-3GPP].
Section 2 describes two methods, with which Transport Network (TN) From encapsulation perspective, N3 interface is similar to S1U in 4G/
aware mobility can be built irrespective of underlying TN technology LTE [TS.23.401-3GPP] network and uses GTP-U [TS.29.281-3GPP] to
used. Using Preferred Path Routing (PPR) as TN Underlay is detailed transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
in Section 3. Section 3.4 further describes the applicability and
procedures of the same with 5G SSC modes on N3 and N9 interfaces. Unlike S1U, N3 has some additional aspects as there is no bearer
concept and no per bearer GTP-U tunnels. Instead, QoS information is
carried in the PDU Session Container GTP-U extension header.
TN Aware Mobility with optimized transport network functionality is
explained below with approaches specified in Section 2.1 and
Section 2.2 . 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. Integrated Approach with TNF in SBI
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 |
to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4 to-UE+----+ N2 +----Ns---+ +-Nn-+ N4 +--Nn-+ N4
| | | | | | | | | | | |
+---+---+ +--++ +-+--+---+ +-+-----+ +----+ +---+---+ +--++ +-+--+---+ +-+-----+ +----+
|gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN | |gNB+======+CSR+------N3-----+ UPF +-N9--+ UPF +--N6--+ DN |
+---+ +---+ +-+------+ +-------+ +----+ +---+ +---+ +-+------+ +-------+ +----+
| +----+ | +----+
+-| DN | +-| DN |
skipping to change at page 6, line 34 skipping to change at page 6, line 47
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. gNB is an entity in 5G-AN. Though it is is shown connecting to gNB. gNB is an entity in 5G-AN. Though it is
shown as a separate block from gNB, in some cases both of these can shown as a separate block from gNB, in some cases both of these can
be co-located. This document concerns with backhaul TN, from CSR to be co-located. This document concerns with backhaul TN, from CSR to
UPF on N3 interface or from Staging UPF to Anchor UPF on N9 UPF on N3 interface or from Staging UPF to Anchor UPF on N9
interface. interface.
Currently specified Control Plane (CP) functions - the Access and
Mobility Management Function (AMF), the Session Management Function
(SMF) and the User plane (UP) components gNodeB (gNB), User Plane
Function (UPF) with N2, N3, N4, N6 and N9 interfaces are relevant to
this document. Other Virtualized 5G control plane components NRF,
AUSF, PCF, AUSF, UDM, NEF, and AF are not directly relevant for the
discussion in this document and one can see the functionalities of
these in [TS.23.501-3GPP].
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
transport any UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured).
Unlike S1U, N3 has some additional aspects as there is no bearer
concept and no per bearer GTP-U tunnels. Instead, QoS information is
carried in the PDU Session Container GTP-U extension header. N9
interface is a new interface to connect UPFs and the right user plane
protocols for N9, including GTP-U, are being studied through 3GPP CT4
WG approved study item [CT4SID] for REL-16.
TN Aware Mobility with optimized transport network functionality is
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. Discrete Approach
In this approach transport network functionality from the 5G-AN to
UPF is discrete and 5GS is not aware of the underlying transport
network and the resources available. Deployment specific mapping
function is used to map the GTP-U encapsulated traffic at the 5G-AN
(e.g. gNB) in UL and UPF in DL direction to the appropriate transport
slice or transport Traffic Engineered (TE) paths. These TE paths can
be established using RSVP-TE [RFC3209] for MPLS underlay, SR
[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
with SRH, native IPv6 and native IPv4 underlays.
As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
user plane traffic forwarding rules in the UPF. The UPFs have a
concept of a "Network Instance" which logically abstracts the
underlying transport path. When the SMF creates the packet detection
rules (PDR) and forwarding action rules (FAR) for a PDU session at
the UPF, the SMF identifies the network instance through which the
packet matching the PDR has to be forwarded. A network instance can
be mapped to a TE path at the UPF. In this approach, TNF as shown in
Figure 1 need not be part of the 5G Service Based Interface (SBI).
Only management plane functionality is needed to create, monitor,
manage and delete (life cycle management) the transport TE paths/
transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
The management plane functionality also provides the mapping of such
TE paths to a network instance identifier to the SMF. The SMF uses
this mapping to install appropriate FARs in the UPF. This approach
provide partial integration of the transport network into 5GS with
some benefits.
One of the limitations of this approach is the inability of the 5GS
procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could
be, a target gNB selection during a N2 mobility event, without
knowing if the target gNB is having a underlay transport slice
resource for the S-NSSAI and 5QI of the PDU session. The Integrated
approach specified below can mitigate this.
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 the control and user plane) and NG Radio Access network including the
N3IWF for the non-3GPP access. The network slice instance(s) N3IWF for the non-3GPP access. The network slice instance(s)
selected by the NSSF are applicable at a per PDU session granularity. selected by the NSSF are applicable at a per PDU session granularity.
An SMF and UPF are allocated from the selected slice instance during An SMF and UPF are allocated from the selected slice instance during
the PDU session establishment procedure. [TS.23.501-3GPP] and the PDU session establishment procedure.
[TS.23.502-3GPP] do not consider the resources and functionalities
needed from transport network for the selection of UPF. This is seen 2.1.1. Transport Network Function and Interfaces
as independent functionality and currently not part of 5GS. If
transport network is not factored in an integrated fashion w.r.t
available resources (with network characteristics from desired
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 5G A south bound interface Ns is shown which interacts with the 5G
Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism Access Network (e.g. gNB/CSR). 'Ns' can use one or more mechanism
available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF available today (PCEP [RFC5440], NETCONF [RFC6241], RESTCONF
[RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay [RFC8040] or gNMI) to provision the L2/L3 VPNs along with TE underlay
paths from gNB to UPF. Ns and Nn interfaces can be part of the paths from gNB to UPF. Ns and Nn interfaces can be part of the
integrated 3GPP architecture, but the specification/ownership of integrated 3GPP architecture, but the specification/ownership of
these interfaces SHOULD be left out of scope of 3GPP. 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 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 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].
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 Proposed TNF as part of the 5GC shown in Figure 1 can be realized
Figure 1. It would enable learning the TE characteristics of all using Abstraction and Control of TE Networks (ACTN). ACTN
links and nodes of the network continuously (through BGP-LS [RFC7752] architecture, underlying topology abstraction methods and
or through a passive IGP adjacency and PCEP [RFC5440]). manageability considerations of the same are detailed in [RFC8453].
2.1.2. Functionality for E2E Management
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
the transport network: the transport network:
o The Specific Network Slice Selection Assistance Information o The Specific Network Slice Selection Assistance Information
(SNSSAI) of PDU session's SHOULD be mapped to the assigned (SNSSAI) of PDU session's 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,
skipping to change at page 9, line 47 skipping to change at page 8, line 43
to a particular slice characteristics. For DL, at a PSA UPF, the 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 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 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 identifying the flow and QoS characteristics to be applied on the
packet. 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 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 Section 3.4, if segmented path (gNB to o In some SSC modes Appendix B, 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
affected 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.
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 allcoation of required provides the flexibility to control the allocation of required
characteristics from the TN during a 5GS signalling 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.
2.3. Transport Network Function 2.2. TNF as part of existing 5G Control Function
Proposed TNF as part of the 5GC shown in Figure 1 can be realized Another solution approach with TNF in Section 2.1 and transport
using Abstraction and Control of TE Networks (ACTN). ACTN provisioning for an engineered IP transport that supports 3GPP
architecture, underlying topology abstraction methods and slicing and QoS requirements in [TS.23.501-3GPP] is described in this
manageability considerations of the same are detailed in [RFC8453]. section.
During a PDU session setup, the 3GPP AMF using input from the NSSF
selects a network slice and SMF. The SMF with user policy from
Policy Control Function (PCF) sets 5QI (QoS parameters) and the UPF
on the path of the PDU session. While QoS and slice selection for
the PDU session can be applied across the 3GPP control and user plane
functions as outlined above, the transport underlay across N3 and N9
segments do not have enough information to apply the resource
constraints represented by the slicing and QoS classification.
Current guidelines for interconnection with transport networks
[IR.34-GSMA] provide an application mapping into DSCP. However,
apart from problems with classification of encrypted packets, these
recommendations do not take into consideration other aspects in
slicing like isolation, protection and replication.
Transport networks have their own slice and QoS configuration based
on domain policies and the underlying network capability. Transport
networks can enter into an agreement for virtual network services
(VNS) with client domains using the ACTN [RFC8453] framework. The
3GPP mobile network, on the other side, defines a Network Slice
Selection Management Function (NSSMF) [TS 28.533] that interacts with
a TN domain manager (that is out of scope of 3GPP).
The ACTN VN service can be used across the 3GPP and transport
networks to provision and map between slices, QoS in the two domains.
An abstraction that represents QoS and slice information in the
mobile domain and mapped to ACTN VN service in the transport domain
is represented here as MTNC (Mobile Transport Network Context)
identifiers. Details of how the 3GPP domain derives the MTNC
identifiers and how it programs it across its control and user plane
functions are for 3GPP standards to define. For completeness, some
minimal outlines are provided in the description below.
When the 3GPP user plane function (gNB, UPF) does not terminate the
transport underlay protocol (e.g., MPLS), it needs to be carried in
the IP protocol header from end-to-end of the mobile transport
connection (N3, N9). [I-D.ietf-dmm-5g-uplane-analysis] discusses
these scenarios in detail.
Figure 2 shows a view of the functions and interfaces for
provisioning the MTNC identifiers. The focus is on provisioning
between the 3GPP management plane (NSSMF), transport network (SDN-C)
and carrying the MTNC identifiers in PDU packets for the transport
network to grant the provisioned resources.
+----------------------------------------------------+
| 3GPP Control/Management Plane |
| +----------------------------------------|-------+
| | +---------------+ | |
| | | +-----+ NSSMF | +---+---+ |
| | | | TNF | | | SMF | |
| | | +--+--+ | +---+---+ |
| | +----|----------+ | |
| +------|---------------------------------|-------+
| |ACTN (RFC8453) |
| +---+---+ |
| | SDN-C +---+ |
| +---+---+ | |
| 3GPP N2/N4 ___^___ |3GPP N2/N4
| _____/ \_____ |
| / \ |
+---+--+ +--+ IP +--+ +---+--+
|UP-NF1|+++++++++++|PE| Backhaul |PE|+++++++++|UP-NF2|
+------+ +--+ +--+ +------+
\_____ _____/
\ /
---v---
Figure 2: 5G Transport Plane Provisioning
In Figure 2, the TNF (logical functionality within the NSSMF)
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)
routers and internal routers according to the underlay transport
technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming
PDU data packets for the MTNC identifier, classifies and provides the
VN service provisioned across the transport network.
The detailed mechanisms by which the NSSMF provides the MTNC
identifiers to the control plane and user plane functions are for
3GPP to specify. Two possible options are outlined below for
completeness. The NSSMF may provide the MTNC identifiers to the 3GPP
control plane by either providing it to the Session Management
Function (SMF), and the SMF in turn provisions the user plane
functions (UP-NF1, UP-NF2) during PDU session setup. Alternatively,
the user plane functions may request the MTNC identifiers directly
from the NSSMF.
In this approach, TNF can be seen as a logical entity that can be
part of NSSMF in the 3GPP management plane [TS.28.533-3GPP]. The
NSSMF may use network configuration, policies, history, heuristics or
some combination of these to derive traffic estimates that the TNF
would use. How these estimates are derived are not in the scope of
this document. The focus here is only in terms of how the TNF and
SDN-C are programmed given that slice and QoS characteristics across
a transport path can be represented by an MTNC identifier. The TNF
requests the SDN-C in the transport network to provision paths in the
transport domain based on the MTNC identifier. The TNF is capable of
providing the MTNC identifier provisioned to control and user plane
functions in the 3GPP domain. Detailed mechanisms for programming
the MTNC identifier should be part of the 3GPP specifications.
2.2.1. Mobile Transport Network Context and Scalability
The MTNC (Mobile Transport Network Context) represents a slice, QoS
configuration for a transport path between two 3GPP user plane
functions. The Mobile-Transport Network Context Identifier (MTNC-ID)
is generated by the TNF to be unique for 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 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 (nor is it per data
path entity). The MTNC identifiers are configured by the TNF to be
unique within a provisioning domain.
Since the MTNC identifiers are not generated per user flow or
session, there is no need for unique MTNC identifiers per flow/
session. In addition, since the traffic estimation not performed at
the time of session establishment, there is no provisioning delay
experienced during session setup. The MTNC identifier space scales
as a square of the number sites between which 3GPP user plane
functions require paths. If there are T traffic classes across N
sites, the number of MTNC identifiers in 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 identifiers required.
Multiple slices for the same QoS class that need to be fully
isolated, will add to the MTNC provisioning. An MTNC identifier
space of 16 bits (65K+ identifiers) can be expected to be sufficient.
2.2.2. MTNC Identifier in the Data Packet
When the 3GPP user plane function (gNB, UPF) and transport provider
edge are on different nodes, the PE router needs to have the means by
which to classify the PDU packet. IP header fields such as DSCP
(DiffServ Code Point) or the IPv6 Flow Label do not satisfy the
requirement as they are not immutable.
Different options for carrying the MTNC identifier in the IP data
packet or in the existing user plane overlay like GTP-U
[TS.29.281-3GPP] or a new overlay like GUE
[I-D.ietf-intarea-gue-extensions] are possible. There are various
trade-offs in terms of packet overhead, support in IPv4 and IPv6
networks as well as working across legacy and evolving transport
networks that need to be considered. These considerations will be
addressed in future revisions.
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
skipping to change at page 11, line 18 skipping to change at page 13, line 14
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. PPR with Transport Awareness for 5GS on 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 both N3 and any
approach selected for N9 (encap or no-encap). In this scenario, PPR approach selected for N9 (encapsulation or no-encapsulation). In
will only help providing TE benefits needed for 5G slices from this scenario, PPR will only help providing TE benefits needed for 5G
transport domain perspective. It does so without adding any slices from transport domain perspective. It does so without adding
additional overhead to the user plane, unlike SR-MPLS or SRv6. This any additional overhead to the user plane, unlike SR-MPLS or SRv6.
is achieved by: 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 QFI (e.g. 5QI) marking on the GTP-U belongs to and/or the QFI (e.g. 5QI) marking on the GTP-U
encapsulation header. Similarly in the Downlink direction encapsulation header. Similarly in the Downlink direction
matching PPR-ID of the 5G-AN is chosen based on the S-NSSAI the 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: PDU Session belongs to. The table below shows a typical mapping:
+----------------+------------+------------------+-----------------+ +----------------+------------+------------------+-----------------+
skipping to change at page 12, line 28 skipping to change at page 14, line 28
| 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: QFI Mapping with PPR-IDs on N3/N9 Figure 3: 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 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/
skipping to change at page 13, line 32 skipping to change at page 15, line 32
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.
3.4. PPR with various 5G Mobility procedures
PPR fulfills the needs of 5GS to transport the user plane traffic
from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This
is done in keeping the backhaul network at par with 5G slicing
requirements that are applicable to Radio and virtualized core
network to create a truly end-to-end slice path for 5G traffic. When
UE moves across the 5G-AN (e.g. from one gNB to another gNB), there
is no transport network reconfiguration required with the approach
above.
SSC mode would be specified/defaulted by SMF. No change in the mode
once connection is initiated and this property is not altered here.
3.4.1. SSC Mode1
+---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF |
+---+--+-+ +-+-+-+ +-+--------------+
N1 | | | |
+--------+ N2 +----Ns---+ +-Nn-+ N4
| | | | |
+ +---+---+ +--++ +-+--+---+ +----+
UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN |
== +---+ +---+ +--------+ +----+
Figure 3: SSC Mode1 with integrated Transport Slice Function
After UE1 moved to another gNB in the same UPF serving area
+---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF |
+---_--+-+ +-+-+-+ +-+--------------+
| | | |
N2 +----Ns---+ +-Nn-+ N4
| | | |
+----+--+ +-+-+ ++--+----+ +----+
|gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN |
+----+ +---+ +---+----+ +----+
|
|
|
|
+----+ +--++ |
UE1 |gNB2+======+CSR+------N3--------+
== +----+ +---+
Figure 4: SSC Mode1 with integrated Transport Slice Function
In this mode, IP address at the UE is preserved during mobility
events. This is similar to 4G/LTE mechanism and for respective
slices, corresponding PPR-ID (TE Path) has to be assigned to the
packet at UL and DL direction. During Xn mobility as shown above,
source gNB has to additionally ensure transport path's resources from
TNF are available at the target gNB apart from radio resources check
(at decision and request phase of Xn/N2 mobility scenario).
3.4.2. SSC Mode2
In this case, if IP Address is changed during mobility (different UPF
area), then corresponding PDU session is released. No session
continuity from the network is provided and this is designed as an
application offload and application manages the session continuity,
if needed. For PDU Session, Service Request and Mobility cases
mechanism to select the transport resource and the PPR-ID (TE Path)
is similar to SSC Mode1.
3.4.3. SSC Mode3
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
'connectivity'. A connection through new PDU session anchor point is
established before the connection is terminated for better service
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 |
+---+--+-+ +-+-+-+ +-+-----------+--+
N1 | | | | |
to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4|
| | | | |
+-------+--+ +--+-------+--+ +-----+-+
|gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6--
+----------+ +----------+--+ +-------+ to DN
| +----+
+-| DN |
N6 +----+
Figure 5: SSC Mode3 and Service Continuity
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
packet gets re-encapsulated by the BP UPF (with either GTP-U or 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
to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
session belongs to and/or the QFI marking in the GTPU encapsulation
header (e.g. 5QI value) to the 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 address of the encapsulation header would be
the mapped PPR-ID (TE path).
In the downlink direction for the incoming packet, UPF has to
encapsulate the packet (with either GTP-U or the chosen
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
BP UPF. If it's a non-MPLS underlay, destination IP address of the
encapsulation header would be the mapped PPR-ID (TE path). In
summary:
o Respective PPR-ID on N3 and N9 has to be selected with correct
transport characteristics from TNF.
o For N2 based mobility SMF has to ensure transport resources are
available for N3 Interface to new BP UPF and from there the
original anchor point UPF.
o For Service continuity with multi-homed PDU session same transport
network characteristics of the original PDU session (both on N3
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].
SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal
skipping to change at page 17, line 9 skipping to change at page 16, line 9
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. Acknowledgements 5. Acknowledgements
Thanks to Young Lee and John Kaippallimalil for discussions on this Thanks to Young Lee for discussions on this document including ACTN
document including ACTN applicability for the proposed TNF. Thanks applicability for the proposed TNF. Thanks to Sri Gundavelli and
to Sri Gundavelli and 3GPP delegates who provided detailed feedback 3GPP delegates who provided detailed feedback on this document.
on this document.
6. 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.
7. 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 8. Contributing Authors
skipping to change at page 18, line 16 skipping to change at page 17, 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-02 (work in draft-chunduri-lsr-isis-preferred-path-routing-03 (work in
progress), February 2019. progress), May 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-02 (work in chunduri-lsr-ospf-preferred-path-routing-03 (work in
progress), February 2019. progress), May 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-05 (work in progress), March 2019.
[I-D.ietf-dmm-5g-uplane-analysis]
Homma, S., Miyasaka, T., Matsushima, S., and d.
daniel.voyer@bell.ca, "User Plane Protocol and
Architectural Analysis on 3GPP 5G System", draft-ietf-dmm-
5g-uplane-analysis-02 (work in progress), July 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.,
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-03 (work in progress), October 2018. uplane-05 (work in progress), July 2019.
[I-D.ietf-intarea-gue-extensions]
Herbert, T., Yong, L., and F. Templin, "Extensions for
Generic UDP Encapsulation", draft-ietf-intarea-gue-
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]
GSM Association (GSMA), "Guidelines for IPX Provider
Networks (Previously Inter-Service Provider IP Backbone
Guidelines, Version 14.0", August 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,
<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 10 skipping to change at page 19, line 29
[TS.23.502-3GPP] [TS.23.502-3GPP]
3rd Generation Partnership Project (3GPP), "Procedures for 3rd Generation Partnership Project (3GPP), "Procedures for
5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December 5G System; Stage 2, 3GPP TS 23.502, v2.0.0", December
2017. 2017.
[TS.23.503-3GPP] [TS.23.503-3GPP]
3rd Generation Partnership Project (3GPP), "Policy and 3rd Generation Partnership Project (3GPP), "Policy and
Charging Control System for 5G Framework; Stage 2, 3GPP TS Charging Control System for 5G Framework; Stage 2, 3GPP TS
23.503 v1.0.0", December 2017. 23.503 v1.0.0", December 2017.
[TS.28.533-3GPP]
3rd Generation Partnership Project (3GPP), "Management and
Orchestration Architecture Framework (Release 15)", June
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 2017. December 2018.
Appendix A. Appendix: New Control Plane and User Planes Appendix A. New Control Plane and User Planes
A.1. LISP and PPR A.1. Slice aware Mobility: Discrete Approach
PPR can also be used with LISP control plane for 3GPP as described in In this approach transport network functionality from the 5G-AN to
[I-D.farinacci-lisp-mobile-network]. This can be achieved by mapping UPF is discrete and 5GS is not aware of the underlying transport
the UE IP address (EID) to PPR-ID, which acts as Routing Locator network and the resources available. Deployment specific mapping
(RLOC). Any encapsulation supported by LISP can work well with PPR. function is used to map the GTP-U encapsulated traffic at the 5G-AN
If the RLOC refers to an IPv4 or IPv6 destination address in the LISP (e.g. gNB) in UL and UPF in DL direction to the appropriate transport
encapsulated header, packets are transported on the preferred path in slice or transport Traffic Engineered (TE) paths. These TE paths can
the network as opposed to traditional shortest path routing with no be established using RSVP-TE [RFC3209] for MPLS underlay, SR
additional user plane overhead related to TE path in the network [I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or
layer. PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6
with SRH, native IPv6 and native IPv4 underlays.
Some of the distinct advantages of the LISP approach is, its As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
scalability, support for service continuity in SSC Mode3 as well as user plane traffic forwarding rules in the UPF. The UPFs have a
native support for session continuity (session survivable mobility). concept of a "Network Instance" which logically abstracts the
Various other advantages are documented at underlying transport path. When the SMF creates the packet detection
[I-D.farinacci-lisp-mobile-network]. rules (PDR) and forwarding action rules (FAR) for a PDU session at
the UPF, the SMF identifies the network instance through which the
packet matching the PDR has to be forwarded. A network instance can
be mapped to a TE path at the UPF. In this approach, TNF as shown in
Figure 1 need not be part of the 5G Service Based Interface (SBI).
Only management plane functionality is needed to create, monitor,
manage and delete (life cycle management) the transport TE paths/
transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
The management plane functionality also provides the mapping of such
TE paths to a network instance identifier to the SMF. The SMF uses
this mapping to install appropriate FARs in the UPF. This approach
provide partial integration of the transport network into 5GS with
some benefits.
A.2. ILA and PPR One of the limitations of this approach is the inability of the 5GS
procedures to know, if underlying transport resources are available
for the traffic type being carried in PDU session before making
certain decisions in the 5G CP. One example scenario/decision could
be, a target gNB selection during a N2 mobility event, without
knowing if the target gNB is having a underlay transport slice
resource for the S-NSSAI and 5QI of the PDU session. The Integrated
approach specified below can mitigate this.
If an ILA-prefix is allowed to refer to a PPR-ID, ILA can be Appendix B. PPR with various 5G Mobility procedures
leveraged with all the benefits (including mobility) that it
provides. This works fine in the DL direction as packet is destined PPR fulfills the needs of 5GS to transport the user plane traffic
to UE IP address at UPF. However, in the UL direction, packet is from 5G-AN to UPF in all 3 SSC modes defined [TS.23.501-3GPP]. This
destined to an external internet address (SIR Prefix to ILA Prefix is done in keeping the backhaul network at par with 5G slicing
transformation happens on the Source address of the original UE requirements that are applicable to Radio and virtualized core
packet). One way to route the packet with out bringing the complete network to create a truly end-to-end slice path for 5G traffic. When
DFZ BGP routing table is by doing a default route to the UPF (ILA-R). UE moves across the 5G-AN (e.g. from one gNB to another gNB), there
In this case, how TE can be achieved is TBD (to be expanded further is no transport network reconfiguration required with the approach
with details). above.
SSC mode would be specified/defaulted by SMF. No change in the mode
once connection is initiated and this property is not altered here.
B.1. SSC Mode1
+---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF |
+---+--+-+ +-+-+-+ +-+--------------+
N1 | | | |
+--------+ N2 +----Ns---+ +-Nn-+ N4
| | | | |
+ +---+---+ +--++ +-+--+---+ +----+
UE1 |gNB+======+CSR+------N3-----+ UPF +-N6--+ DN |
== +---+ +---+ +--------+ +----+
Figure 4: SSC Mode1 with integrated Transport Slice Function
After UE1 moved to another gNB in the same UPF serving area
+---+----+ +-----+ +----------------+
| AMF | | TNF | | SMF |
+---_--+-+ +-+-+-+ +-+--------------+
| | | |
N2 +----Ns---+ +-Nn-+ N4
| | | |
+----+--+ +-+-+ ++--+----+ +----+
|gNB1+======+CSR+------N3-----+ UPF +-N6--+ DN |
+----+ +---+ +---+----+ +----+
|
|
|
|
+----+ +--++ |
UE1 |gNB2+======+CSR+------N3--------+
== +----+ +---+
Figure 5: SSC Mode1 with integrated Transport Slice Function
In this mode, IP address at the UE is preserved during mobility
events. This is similar to 4G/LTE mechanism and for respective
slices, corresponding PPR-ID (TE Path) has to be assigned to the
packet at UL and DL direction. During Xn mobility as shown above,
source gNB has to additionally ensure transport path's resources from
TNF are available at the target gNB apart from radio resources check
(at decision and request phase of Xn/N2 mobility scenario).
B.2. SSC Mode2
In this case, if IP Address is changed during mobility (different UPF
area), then corresponding PDU session is released. No session
continuity from the network is provided and this is designed as an
application offload and application manages the session continuity,
if needed. For PDU Session, Service Request and Mobility cases
mechanism to select the transport resource and the PPR-ID (TE Path)
is similar to SSC Mode1.
B.3. SSC Mode3
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
'connectivity'. A connection through new PDU session anchor point is
established before the connection is terminated for better service
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 |
+---+--+-+ +-+-+-+ +-+-----------+--+
N1 | | | | |
to-UE+----+ N2 +-------Ns---+ +-Nn-+ N4 N4|
| | | | |
+-------+--+ +--+-------+--+ +-----+-+
|gNB/CSR +---N3---+ BP UPF +-N9--+ UPF +-N6--
+----------+ +----------+--+ +-------+ to DN
| +----+
+-| DN |
N6 +----+
Figure 6: SSC Mode3 and Service Continuity
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
packet gets re-encapsulated by the BP UPF (with either GTP-U or 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
to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
session belongs to and/or the QFI marking in the GTPU encapsulation
header (e.g. 5QI value) to the 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 address of the encapsulation header would be
the mapped PPR-ID (TE path).
In the downlink direction for the incoming packet, UPF has to
encapsulate the packet (with either GTP-U or the chosen
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
BP UPF. If it's a non-MPLS underlay, destination IP address of the
encapsulation header would be the mapped PPR-ID (TE path). In
summary:
o Respective PPR-ID on N3 and N9 has to be selected with correct
transport characteristics from TNF.
o For N2 based mobility SMF has to ensure transport resources are
available for N3 Interface to new BP UPF and from there the
original anchor point UPF.
o For Service continuity with multi-homed PDU session same transport
network characteristics of the original PDU session (both on N3
and N9) need to be observed for the newly configured IPv6
prefixes.
Authors' Addresses Authors' Addresses
Uma Chunduri (editor) Uma Chunduri (editor)
Huawei USA Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: uma.chunduri@huawei.com Email: umac.ietf@gmail.com
Richard Li Richard Li
Huawei USA Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Email: renwei.li@huawei.com Email: richard.li@futurewei.com
Sridhar Bhaskaran Sridhar Bhaskaran
Huawei Technologies India Pvt Ltd Altiostar
Survey No.37, Whitefield Road, Kundalahalli
Bengaluru, Karnataka
India
Email: sridhar.bhaskaran@huawei.com Email: sridhar.bhaskaran@gmail.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
skipping to change at page 22, line 4 skipping to change at page 24, line 21
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
440 North Bernardo Ave 440 North Bernardo Ave
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: praveen.muley@nokia.com Email: praveen.muley@nokia.com
John Kaippallimalil
Futurewei
5700 Tennyson Parkway, Suite 600
Plano, TX 75024
USA
Email: john.kaippallimalil@futurewei.com
 End of changes. 53 change blocks. 
346 lines changed or deleted 491 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/