< draft-clt-dmm-tn-aware-mobility-07.txt		draft-clt-dmm-tn-aware-mobility-08.txt >
	DMM Working Group U. Chunduri, Ed.		DMM Working Group U. Chunduri, Ed.
	Internet-Draft R. Li		Internet-Draft R. Li
	Intended status: Informational Futurewei		Intended status: Informational Futurewei
	Expires: April 1, 2021 S. Bhaskaran		Expires: May 6, 2021 S. Bhaskaran
	Altiostar		Altiostar
	J. Kaippallimalil, Ed.		J. Kaippallimalil, Ed.
	Futurewei		Futurewei
	J. Tantsura		J. Tantsura
	Apstra, Inc.		Apstra, Inc.
	L. Contreras		L. Contreras
	Telefonica		Telefonica
	P. Muley		P. Muley
	Nokia		Nokia
	September 28, 2020		November 2, 2020
	Transport Network aware Mobility for 5G		Transport Network aware Mobility for 5G
	draft-clt-dmm-tn-aware-mobility-07		draft-clt-dmm-tn-aware-mobility-08
	Abstract		Abstract
	This document specifies a framework and mapping from slices in 5G		This document specifies a framework and mapping from slices in 5G
	mobile systems to transport slices in IP and Layer 2 transport		mobile systems to transport slices in IP and Layer 2 transport
	networks. Slices in 5G systems are characterized by latency bounds,		networks. Slices in 5G systems are characterized by latency bounds,
	reservation guarantees, jitter, data rates, availability, mobility		reservation guarantees, jitter, data rates, availability, mobility
	speed, usage density, criticality and priority should be mapped to		speed, usage density, criticality and priority. These
	transport slice characteristics that include bandwidth, latency and		characteristics should be mapped to the transport network slice
	criteria such as isolation, directionality and disjoint routes.		characteristics that include bandwidth, latency and criteria such as
	Mobile slice criteria need to be mapped to the appropriate transport		isolation, directionality and disjoint routes. Mobile slice criteria
	slice and capabilities offered in backhaul, midhaul and fronthaul		need to be mapped to the appropriate transport slice and capabilities
	connectivity segments between radio side network functions and user		offered in backhaul, midhaul and fronthaul connectivity segments
	plane function (gateway).		between radio side network functions and user plane function
			(gateway).
	This document describes how mobile network functions map its slice		This document describes how mobile network functions map its slice
	criteria to identifiers in IP packets that transport segments use to		criteria to identifiers in IP packets that transport network segments
	grant transport layer services. This is based on mapping between		use to grant transport layer services during UE mobility scenarios.
	mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment		Applicability of this framework and underlying transport networks,
	Routing). Applicability of this framework and a new transport		which can enable different slice properties is also discussed. This
	network underlay routing mechanism, Preferred Path Routing (PPR),		is based on mapping between mobile and transport underlays (L2,
	which brings slice properties and works with any underlying transport		Segment Routing, IPv6, MPLS and IPv4).
	(L2, IPv4, SR and MPLS) is also discussed.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC2119 [RFC2119].		document are to be interpreted as described in RFC2119 [RFC2119].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 1, 2021.		This Internet-Draft will expire on May 6, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4		1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
	1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4		1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4
	1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Transport and Slice aware Mobility in 5G Networks . . . . . . 6		2. Transport and Slice aware Mobility in 5G Networks . . . . . . 6
	2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 7		2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 7
	2.2. Front Haul Transport Network . . . . . . . . . . . . . . 9		2.2. Front Haul Transport Network . . . . . . . . . . . . . . 9
	2.3. Mobile Transport Network Context (MTNC) and Scalability . 9		2.3. Mobile Transport Network Context (MTNC) and Scalability . 9
	2.4. Transport Network Function (TNF) . . . . . . . . . . . . 10		2.4. Transport Network Function (TNF) . . . . . . . . . . . . 10
	2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 11		2.5. Transport Provisioning . . . . . . . . . . . . . . . . . 11
	2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 12		2.6. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 12
	2.7. Functionality for E2E Management . . . . . . . . . . . . 13		2.7. Functionality for E2E Management . . . . . . . . . . . . 13
	3. Transport Network Underlays . . . . . . . . . . . . . . . . . 15		3. Transport Network Underlays . . . . . . . . . . . . . . . . . 15
	3.1. Using PPR as TN Underlay . . . . . . . . . . . . . . . . 15		3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 15
	3.1.1. PPR on F1-U/N3/N9 Interfaces . . . . . . . . . . . . 16		3.2. Transport Network Technologies . . . . . . . . . . . . . 17
	3.1.2. Path Steering Support to native IP user planes . . . 17
	3.1.3. Service Level Guarantee in Underlay . . . . . . . . . 17
	3.2. Other TE Technologies Applicability . . . . . . . . . . . 18
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18		7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . 19		8.1. Normative References . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . 18
	Appendix A. New Control Plane and User Planes . . . . . . . . . 22		Appendix A. New Control Plane and User Planes . . . . . . . . . 20
	A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 22		A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 20
	A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 23		A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 21
	Appendix B. PPR with various 5G Mobility procedures . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	B.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . . . 24
	B.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . . . 25
	B.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP],		The 3GPP architecture for 5GS is defined in [TS.23.501-3GPP],
	[TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a		[TS.23.502-3GPP] and [TS.23.503-3GPP]. The architecture defines a
	comprehensive set of functions for access mobility, session handling		comprehensive set of functions for access mobility, session handling
	and related functions for subscription management, authentication and		and related functions for subscription management, authentication and
	policy among others. These network functions (NF) are defined using		policy among others. These network functions (NF) are defined using
	a service-based architecture (SBA) that allows NFs to expose their		a service-based architecture (SBA) that allows NFs to expose their
	functions via an API and common service framework.		functions via an API and common service framework.
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 9 ¶
	of things (mIoT). ATIS [ATIS075] has defined an additional slice		of things (mIoT). ATIS [ATIS075] has defined an additional slice
	type for V2X services. There may be multiple instances of a slice		type for V2X services. There may be multiple instances of a slice
	type to satisfy some characteristics like isolation. The slice		type to satisfy some characteristics like isolation. The slice
	details in 3GPP, ATIS or NGMN do not specify how slice		details in 3GPP, ATIS or NGMN do not specify how slice
	characteristics for QoS, hard /soft isolation, protection and other		characteristics for QoS, hard /soft isolation, protection and other
	aspects should be satisfied in IP transport networks. This is		aspects should be satisfied in IP transport networks. This is
	explored further in this document.		explored further in this document.
	1.1. Problem Statement		1.1. Problem Statement
	[TS.23.501-3GPP] and [TS.23.502-3GPP] define network slicing as one		5GS defines network slicing as one of the core capability of 5GC with
	of the core capability of 5GC with slice awareness from Radio and 5G		slice awareness from Radio and 5G Core (5GC) network. The 5G System
	Core (5GC) network. The 5G System (5GS) as defined, does not		(5GS) as defined, does not consider the resources and functionalities
	consider the resources and functionalities needed from transport		needed from transport network for the selection of UPF. This is seen
	network for the selection of UPF. This is seen as independent		as independent functionality and currently not part of 5GS.
	functionality and currently not part of 5GS.
	However, the lack of underlying Transport Network (TN) awareness may		However, the lack of underlying Transport Network (TN) awareness may
	lead to selection of sub-optimal UPF(s) and/or 5G-AN during 5GS		lead to selection of sub-optimal UPF(s) and/or 5G-AN during various
	various procedures (e.g., session establishment, mobility). Meeting		procedures in 5GS (e.g., session establishment and various mobility
	the specific slice characteristics on the F1-U, N3, N9 interfaces		scenarios). Meeting the specific slice characteristics on the F1-U,
	depends on the IP transport underlay providing these resources and		N3, N9 interfaces depends on the IP transport underlay providing
	capabilities. This could also lead to the inability in meeting SLAs		these resources and capabilities. This could also lead to the
	for real-time, mission-critical or latency sensitive services. 5GS		inability in meeting SLAs for real-time, mission-critical or latency
	procedures including but not limited to Service Request, PDU Session		sensitive services.
	Establishment, or UE mobility need same service level characteristics
	from the Transport Network (TN) for the Protocols Data Unit (PDU)
	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].
	The 5GS provides slices to its clients (UEs). The UE's PDU session		The 5GS provides slices to its clients (UEs). The UE's PDU session
	spans the access network (radio network including the F1-U) and N3		spans the access network (radio network including the F1-U) and N3
	and N9 transport segments which have an IP transport underlay. The		and N9 transport segments which have an IP transport underlay. The
	5G operator needs to obtain slice capability from the IP transport		5G operator needs to obtain slice capability from the IP transport
	provider. Several UE sessions that match a slice may be mapped to an		provider. Several UE sessions that match a slice may be mapped to an
	IP transport segment. Thus there needs to be a mapping between the		IP transport segment. Thus there needs to be a mapping between the
	slice capability offered to the UE (S-NSSAI) and what is provided by		slice capability offered to the UE (S-NSSAI) and what is provided by
	the IP transport.		the IP transport.
	1.2. Solution Approach		1.2. Solution Approach
	This document specifies an approach to fulfil the needs of 5GS to		This document specifies an approach to fulfil the needs of 5GS to
	transport user plane traffic from 5G-AN to UPF for all service		transport user plane traffic from 5G-AN to UPF in an optimized
	continuity modes [TS.23.501-3GPP] in an optimized fashion. This is		fashion. This is done by, keeping establishment and mobility
	done by, keeping establishment and mobility procedures aware of		procedures aware of underlying transport network along with slicing
	underlying transport network along with slicing requirements.		requirements.
	Section 2 describes in detail on how TN aware mobility can be built		Section 2 describes in detail on how TN aware mobility can be built
	irrespective of underlying TN technology used. Using Preferred Path		irrespective of underlying TN technology used. How other IETF TE
	Routing (PPR), applicable to any transport network underlay (IPv6,
	MPLS and IPv4) is detailed in Section 3.1. How other IETF TE
	technologies applicable for this draft is specified in Section 3.2.		technologies applicable for this draft is specified in Section 3.2.
	At the end, Appendix B further describes the applicability and
	procedures of PPR with 5G SSC modes on F1-U, N3 and N9 interfaces.
	1.3. Acronyms		1.3. Acronyms
	5QI - 5G QoS Indicator		5QI - 5G QoS Indicator
	5G-AN - 5G Access Network		5G-AN - 5G Access Network
	AMF - Access and Mobility Management Function (5G)		AMF - Access and Mobility Management Function (5G)
	BP - Branch Point (5G)		BP - Branch Point (5G)
	CSR - Cell Site Router		CSR - Cell Site Router
	CP - Control Plane (5G)		CP - Control Plane (5G)
	CU - Centralized Unit (5G, gNB)		CU - Centralized Unit (5G, gNB)
	DN - Data Network (5G)		DN - Data Network (5G)
	skipping to change at page 6, line 50 ¶		skipping to change at page 7, line 5 ¶
	3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing		3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing
	in 5GS. However, the application of 5GS slices in transport network		in 5GS. However, the application of 5GS slices in transport network
	for backhaul, mid-haul and front haul are not explicitly covered. To		for backhaul, mid-haul and front haul are not explicitly covered. To
	support specific characteristics in backhaul (N3, N9), mid-haul (F1)		support specific characteristics in backhaul (N3, N9), mid-haul (F1)
	and front haul, it is necessary to map and provision corresponding		and front haul, it is necessary to map and provision corresponding
	resources in the transport domain. This section describes how to		resources in the transport domain. This section describes how to
	provision the mapping information in transport network and apply it		provision the mapping information in transport network and apply it
	so that user plane packets can be provided the transport resources		so that user plane packets can be provided the transport resources
	(QoS, isolation, protection, etc.) expected by the 5GS slices.		(QoS, isolation, protection, etc.) expected by the 5GS slices.
	TN Aware Mobility with optimized transport network functionality is
	explained below. How an underlay agnostic routing technology fits in
	this framework in detail along with other various TE technologies
	briefly are in Section 3.1 and Section 3.2 respectively.
	5G Control and Management Planes		5G Control and Management Planes
	+------------------------------------------------------------------------+		+------------------------------------------------------------------------+
	| +--------------------------------------------------------------------+ |		| +--------------------------------------------------------------------+ |
	| | (TNF) 5G Management Plane (TNF) | |		| | (TNF) 5G Management Plane (TNF) | |
	| +----+-----------------+-------------+---------------+-----------+---+ |		| +----+-----------------+-------------+---------------+-----------+---+ |
	| | | | | | |		| | | | | | |
	| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |		| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
	| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |		| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
	| | | | +----+-----+ | +----+---+ |		| | | | +----+-----+ | +----+---+ |
	+-| |-----------|-------------|---------------|-----------|-----+		+-| |-----------|-------------|---------------|-----------|-----+
	skipping to change at page 7, line 30 ¶		skipping to change at page 7, line 28 ¶
	| | +---+---+ | +---+---+ |		| | +---+---+ | +---+---+ |
	| | | | | | | |		| | | | | | | |
	| gNB-DU | | SDN-C | E1 | SDN-C | |		| gNB-DU | | SDN-C | E1 | SDN-C | |
	| | | | | | | |		| | | | | | | |
	| | +---+---+ | +---+---+ |		| | +---+---+ | +---+---+ |
	| | | | | |		| | | | | |
	| | | | | |		| | | | | |
	| | __ +__ | ___+__ |		| | __ +__ | ___+__ |
	| | __/ \__ +--+---+ __/ \__ +-+-+		| | __/ \__ +--+---+ __/ \__ +-+-+
	| | / IP \ | gNB | / IP \ | |		| | / IP \ | gNB | / IP \ | |
	UE---| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN		UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
	+----------| \__ __/ +------+ \__ __/ +---+		+----------+ \__ __/ +------+ \__ __/ +---+
	\______/ \______/		\______/ \______/
	|------ F1-U -------| |------ N3 OR N9 ------|		|------ F1-U -------| |------ N3 OR N9 ------|
			* Radio and Fronthaul
	Figure 1: Backhaul and Mid-haul Transport Network for 5G		Figure 1: Backhaul and Mid-haul Transport Network for 5G
	2.1. Backhaul and Mid-Haul Transport Network		2.1. Backhaul and Mid-Haul Transport Network
	Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)		Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)
	routers provide IP transport service to 5GS user plane entities 5G-AN		routers provide IP transport service to 5GS user plane entities 5G-AN
	(e.g. gNB) and UPF. 5GS architecture with high level management,		(e.g. gNB) and UPF. 5GS architecture with high level management,
	control and user plane entities and its interaction with the IP		control and user plane entities and its interaction with the IP
	transport plane is shown here. The slice capability required in IP		transport plane is shown here. The slice capability required in IP
	transport networks is estimated and provisioned by the functionality		transport networks is estimated and provisioned by the functionality
	skipping to change at page 8, line 47 ¶		skipping to change at page 8, line 45 ¶
	The N3, N9 and F1 user planes use GTP-U [TS.29.281-3GPP] to transport		The N3, N9 and F1 user planes use GTP-U [TS.29.281-3GPP] to transport
	UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). For the		UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). For the
	front haul described further in Section 2.2, an Ethernet transport		front haul described further in Section 2.2, an Ethernet transport
	with VLANs can be expected to be the case in many deployments.		with VLANs can be expected to be the case in many deployments.
	Figure 1 also depicts the PE router, where transport paths are		Figure 1 also depicts the PE router, where transport paths are
	initiated/terminated can be deployed separately with UPF or both		initiated/terminated can be deployed separately with UPF or both
	functionalities can be in the same node. The TNF provisions this in		functionalities can be in the same node. The TNF provisions this in
	the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP		the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP
	encapsulated user packet from the (R)AN (gNB) or UPF with the slice		encapsulated user packet from the (R)AN (gNB) or UPF with the slice
	information traverses the F1U/N3/N9 segment, the PE router of the IP		information traverses the F1-U/N3/N9 segment, the PE router of the IP
	transport underlay can inspect the slice information and provide the		transport underlay can inspect the slice information and provide the
	provisioned capabilities. This is elaborated further in Section 2.5.		provisioned capabilities. This is elaborated further in Section 2.5.
	2.2. Front Haul Transport Network		2.2. Front Haul Transport Network
	The O-RAN Alliance has specified the fronthaul interface between the		The O-RAN Alliance has specified the fronthaul interface between the
	O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer		O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer
	information, in the form of In-phase (I) and Quadrature (Q) samples		information, in the form of In-phase (I) and Quadrature (Q) samples
	are transported using Enhanced Common Public Radio Interface (eCPRI)		are transported using Enhanced Common Public Radio Interface (eCPRI)
	framing over Ethernet or UDP. On the Ethernet based fronthaul		framing over Ethernet or UDP. On the Ethernet based fronthaul
	skipping to change at page 10, line 17 ¶		skipping to change at page 10, line 17 ¶
	2.4. Transport Network Function (TNF)		2.4. Transport Network Function (TNF)
	Figure 1 shows a view of the functions and interfaces for		Figure 1 shows a view of the functions and interfaces for
	provisioning the MTNC-IDs. The focus is on provisioning between the		provisioning the MTNC-IDs. The focus is on provisioning between the
	3GPP management plane (NSSMF), transport network (SDN-C) and carrying		3GPP management plane (NSSMF), transport network (SDN-C) and carrying
	the MTNC-IDs in PDU packets for the transport network to grant the		the MTNC-IDs in PDU packets for the transport network to grant the
	provisioned resources.		provisioned resources.
	In Figure 1, the TNF (logical functionality within the NSSMF)		In Figure 1, the TNF (logical functionality within the NSSMF)
	requests the SDN-C in the transport domain to program the TE path		requests the SDN-C in the transport domain to program the TE path
	using ACTN [RFC 8453]. The SDN-C programs the Provider Edge (PE)		using ACTN [RFC8453]. The SDN-C programs the Provider Edge (PE)
	routers and internal routers according to the underlay transport		routers and internal routers according to the underlay transport
	technology (e.g., PPR, MPLS, SRv6). The PE router inspects incoming		technology (e.g., MPLS, SR, PPR). The PE router inspects incoming
	PDU data packets for the MTNC-ID, classifies and provides the VN		PDU data packets for the UDP SRC port which mirrors the MTNC-ID,
	service provisioned across the transport network.		classifies and provides the VN service provisioned across the
			transport network.
	The detailed mechanisms by which the NSSMF provides the MTNC-IDs to		The detailed mechanisms by which the NSSMF provides the MTNC-IDs to
	the control plane and user plane functions are for 3GPP to specify.		the control plane and user plane functions are for 3GPP to specify.
	Two possible options are outlined below for completeness. The NSSMF		Two possible options are outlined below for completeness. The NSSMF
	may provide the MTNC-IDs to the 3GPP control plane by either		may provide the MTNC-IDs to the 3GPP control plane by either
	providing it to the Session Management Function (SMF), and the SMF in		providing it to the Session Management Function (SMF), and the SMF in
	turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU		turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU
	session setup. Alternatively, the user plane functions may request		session setup. Alternatively, the user plane functions may request
	the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case		the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case
	where user plane entities request the TNF/NSSMF to translate the		where user plane entities request the TNF/NSSMF to translate the
	skipping to change at page 12, line 32 ¶		skipping to change at page 12, line 32 ¶
	Thus, Layer 2 alternatives such as VLAN will fail if there are		Thus, Layer 2 alternatives such as VLAN will fail if there are
	multiple L2 networks on the F1-U or N3 or N9 path. GTP (F1-U, N3, N9		multiple L2 networks on the F1-U or N3 or N9 path. GTP (F1-U, N3, N9
	encapsulation header) field extensions offer a possibility, however		encapsulation header) field extensions offer a possibility, however
	these extensions are hard for a transport edge router to parse		these extensions are hard for a transport edge router to parse
	efficiently on a per packet basis. Other IP header fields like DSCP		efficiently on a per packet basis. Other IP header fields like DSCP
	are not suitable as it only conveys the QoS aspects (but not other		are not suitable as it only conveys the QoS aspects (but not other
	aspects like isolation, protection, etc.)		aspects like isolation, protection, etc.)
	IPv6 extension headers like SRv6 may be options to carry the MTNC-ID		IPv6 extension headers like SRv6 may be options to carry the MTNC-ID
	when such mechanism is a viable (if complete transport network is		when such mechanism is a viable (if complete transport network is
	IPv6 based). To mininise the protocol changes are required and make		IPv6 based). To minimise the protocol changes are required and make
	this underlay tranport independent (IPv4/IPv6/MPLS/L2), an option is		this underlay transport independent (IPv4/IPv6/MPLS/L2), an option is
	to provision a mapping of MTNC-ID to a UDP port range of the GTP		to provision a mapping of MTNC-ID to a UDP port range of the GTP
	encapsulated user packet. A simple mapping table between the MTNC-ID		encapsulated user packet. A simple mapping table between the MTNC-ID
	and the source UDP port number can be configured to ensure that ECMP		and the source UDP port number can be configured to ensure that ECMP
	/load balancing is not affected adversely by encoding the UDP source		/load balancing is not affected adversely by encoding the UDP source
	port with an MTNC-ID mapping. This mapping is configured in 3GPP		port with an MTNC-ID mapping. This mapping is configured in 3GPP
	user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that		user plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that
	process MTNC-IDs.		process MTNC-IDs.
	PE routers can thus provision a policy based on the source UDP port		PE routers can thus provision a policy based on the source UDP port
	number (which reflects the mapped MTNC-ID) to underlying transport		number (which reflects the mapped MTNC-ID) to underlying transport
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	o Mapping of PDU session parameters to underlay SST paths need to be		o Mapping of PDU session parameters to underlay SST paths need to be
	done. One way to do this to let the SMF install a Forwarding		done. One way to do this to let the SMF install a Forwarding
	Action Rule (FAR) in the UPF via N4 with the FAR pointing to a		Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
	"Network Instance" in the UPF. A "Network Instance" is a logical		"Network Instance" in the UPF. A "Network Instance" is a logical
	identifier for an underlying network. The "Network Instance"		identifier for an underlying network. The "Network Instance"
	pointed by the FAR can be mapped to a transport path (through L2/		pointed by the FAR can be mapped to a transport path (through L2/
	L3 VPN). FARs are associated with Packet Detection Rule (PDR).		L3 VPN). FARs are associated with Packet Detection Rule (PDR).
	PDRs are used to classify packets in the uplink (UL) and the		PDRs are used to classify packets in the uplink (UL) and the
	downlink (DL) direction. For UL procedures specified in		downlink (DL) direction. For UL procedures specified in
	Section 2.5, Section 2.6 can be used for classifying a packet		Section 2.5, Section 2.6 can be used for classifying a packet
	belonging to a particular slice characteristics. For DL, at a PSA		belonging to a particular slice characteristic. For DL, at a PSA
	UPF, the UE IP address is used to identify the PDU session, and		UPF, the UE IP address is used to identify the PDU session, and
	hence the slice a packet belongs to and the IP 5 tuple can be used		hence the slice a packet belongs to and the IP 5 tuple can be used
	for identifying the flow and QoS characteristics to be applied on		for identifying the flow and QoS characteristics to be applied on
	the packet at UPF. If a PE is not co-located at the UPF then		the packet at UPF. If a PE is not co-located at the UPF then
	mapping to the underlying TE paths at PE happens based on the		mapping to the underlying TE paths at PE happens based on the
	encapsulated GTP-US packet as specified in Section 2.6.		encapsulated GTP-U packet as specified in Section 2.6.
	o If any other form of encapsulation (other than GTP-U) either on N3
	or N9 corresponding QFI information MUST be there in the
	encapsulation header.
	o In some SSC modes Appendix B, if segmented path (CSR to		o In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if
	PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then		segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-
	corresponding path characteristics MUST be used. This includes a		UPF) is needed, then corresponding path characteristics MUST be
	path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF		used. This includes a path from CSR to PE@UL-CL/BP UPF
	to eventual UPF access to DN.		[TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN.
	o Continuous monitoring of the underlying transport path		o Continuous monitoring of the underlying transport path
	characteristics should be enabled at the endpoints (technologies		characteristics should be enabled at the endpoints (technologies
	for monitoring depends traffic engineering technique used as		for monitoring depends traffic engineering technique used as
	described in Section 3.1 and Section 3.2). If path		described in Section 3.2). If path characteristics are degraded,
	characteristics are degraded, reassignment of the paths at the		reassignment of the paths at the endpoints should be performed.
	endpoints should be performed. For all the affected PDU sessions,		For all the affected PDU sessions, degraded transport paths need
	degraded transport paths need to be updated dynamically with		to be updated dynamically with similar alternate paths.
	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 (F1
	based or N2 based), for target gNB selection, apart from radio		based, Xn based or N2 based), for target gNB selection, apart from
	resources, transport resources MUST be factored. This enables		radio resources, transport resources MUST be factored. This
	handling of all PDU sessions from the UE to target gNB and this		enables handling of all PDU sessions from the UE to target gNB and
	require co-ordination of gNB, AMF, SMF with the TNF module.		this require co-ordination of gNB, AMF, SMF with the TNF module.
	Integrating the TNF as part of the 5GS Service Based Interfaces,		Integrating the TNF as part of the 5GS Service Based Interfaces,
	provides the flexibility to control the allocation of required		provides the flexibility to control the allocation of required
	characteristics from the TN during a 5GS signaling procedure (e.g.		characteristics from the TN during a 5GS signaling procedure (e.g.
	PDU Session Establishment). If TNF is seen as part of management		PDU Session Establishment). If TNF is seen as separate and in
	plane, this real time flexibility is lost. Changes to detailed		management plane, this real time flexibility is lost. Changes to
	signaling to integrate the above for various 5GS procedures as		detailed signaling to integrate the above for various 5GS procedures
	defined in [TS.23.502-3GPP] is beyond the scope of this document.		as defined in [TS.23.502-3GPP] is beyond the scope of this document.
	3. Transport Network Underlays		3. Transport Network Underlays
	Apart from the various flavors of IETF VPN technologies to share the		Apart from the various flavors of IETF VPN technologies to share the
	transport network resources and capacity, TE capabilities in the		transport network resources and capacity, TE capabilities in the
	underlay network is an essential component to realize the 5G TN		underlay network is an essential component to realize the 5G TN
	requirements. This section focuses on various transport underlay		requirements. This section focuses on various transport underlay
	technologies (not exhaustive) and their applicability to realize		technologies (not exhaustive) and their applicability to realize
	Midhaul/Backhaul transport networks. Focus is on the user/data plane		Midhaul/Backhaul transport networks. Focus is on the user/data plane
	i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.		i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.
	3.1. Using PPR as TN Underlay		3.1. Applicability
	In a network implementing source routing, packets may be transported
	through the use of Segment Identifiers (SIDs), where a SID uniquely
	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
	all SRv6 features along with a few concerns in Section 5.3.7 of the
	same document. Those concerns as well as need for underlay agnostic
	(L2/IPv4/IPv6/MPLS) TE requirements are addressed by a new XHaul
	routing mechanism called Preferred Path Routing (PPR), of which this
	section provides an overview.
	With PPR, the label/PPR-ID refer not to individual segments of which
	the path is composed, but to the identifier of a path that is
	deployed on network nodes. The fact that paths and path identifiers
	can be computed and controlled by a controller, not a routing
	protocol, allows the deployment of any path that network operators
	prefer, not just shortest paths. As packets refer to a path towards
	a given destination and nodes make their forwarding decision based on
	the 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 in multiple benefits including significant reduction in
	network layer overhead, increased performance and hardware
	compatibility for carrying both path and services along the path.
	Details of the IGP extensions for PPR are provided here:
	o IS-IS - [I-D.chunduri-lsr-isis-preferred-path-routing]
	o OSPF - [I-D.chunduri-lsr-ospf-preferred-path-routing]
	3.1.1. PPR on F1-U/N3/N9 Interfaces
	PPR does not remove GTP-U, unlike some other proposals laid out in
	[I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works
	with the existing cellular user plane (GTP-U) for F1-U/N3 and any
	approach selected for N9 (encapsulation or no-encapsulation). In
	this scenario, PPR will only help providing TE benefits needed for 5G
	slices from transport domain perspective. It does so for any
	underlying user/data plane used in the transport network
	(L2/IPv4/IPv6/MPLS). This is achieved by:
	o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in		o For 3 different SSTs, 3 transport TE paths can be signaled from
	the transport network. For Uplink traffic, the 5G-AN will choose		any node in the transport network. For Uplink traffic, the 5G-AN
	the right PPR-ID of the UPF based on the S-NSSAI the PDU Session		will choose the right underlying TE path of the UPF based on the
	belongs to and/or the UDP Source port (corresponds to the MTNC-ID		S-NSSAI the PDU Session belongs to and/or the UDP Source port
	Section 2.5) of the GTP-U encapsulation header. Similarly in the		(corresponds to the MTNC-ID Section 2.5) of the GTP-U
	Downlink direction matching PPR-ID of the 5G-AN is chosen based on		encapsulation header. Similarly in the Downlink direction
	the S-NSSAI the PDU Session belongs to. The table below shows a		matching Transport TE Path of the 5G-AN is chosen based on the
			S-NSSAI the PDU Session belongs to. The table below shows a
	typical mapping:		typical mapping:
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	|GTP/UDP SRC PORT| SST | Transport Path | Transport Path |		|GTP/UDP SRC PORT| SST | Transport Path | Transport Path |
	| | in S-NSSAI | Info | Characteristics |		| | in S-NSSAI | Info | Characteristics |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	| Range Xx - Xy | | | |		| Range Xx - Xy | | | |
	| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |		| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |
	| values) | (massive | PPR-ID-A | Bit Rate) |		| values) | (massive | TE-PATH-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 | TE-PATH-B | Req. |
	| | latency) | | Bandwidth: By |		| | latency) | | Bandwidth: By |
	| | | | Delay: Dy |		| | | | Delay: Dy |
	| | | | Jitter: Jy |		| | | | Jitter: Jy |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	| Range Zx - Zy | | | |		| Range Zx - Zy | | | |
	| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |		| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
	| values) | (broadband)| PPR-ID-C | Bandwidth: Bx |		| values) | (broadband)| TE-PATH-C | Bandwidth: Bx |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	Figure 2: Mapping of PPR-IDs on N3/N9		Figure 2: Mapping of Transport Paths on F1-U/N3/N9
	o It is possible to have a single PPR-ID for multiple input points		o It is possible to have a single TE Path for multiple input points
	through a PPR tree structure separate in UL and DL direction.		through a MP2P TE 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 TE Paths are created uniformly across all needed 5G-
	and UPFs to allow various mobility scenarios.		ANs and UPFs to allow various mobility scenarios.
	o Any modification of TE parameters of the path, replacement path		o Any modification of TE parameters of the path, replacement path
	and deleted path needed to be updated from TNF to the relevant		and deleted path needed to be updated from TNF to the relevant
	ingress points. Same information can be pushed to the NSSF, and/		ingress points. Same information can be pushed to the NSSF, and/
	or SMF as needed.		or SMF as needed.
	o PPR can be supported with any native IPv4 and IPv6 data/user		o TE Paths support for native L2, IPv4 and IPv6 data/user planes
	planes (Section 3.1.2) with optional TE features (Section 3.1.3) .		with optional TE features are desirable in some network segments.
	As this is an underlay mechanism it can work with any overlay		As this is an underlay mechanism it can work with any overlay
	encapsulation approach including GTP-U as defined currently for N3		encapsulation approach including GTP-U as defined currently for
	interface.		F1-U/N3/N9 interface.
	3.1.2. Path Steering Support to native IP user planes
	PPR works in fully compatible way with SR defined user planes (SR-
	MPLS and SRv6) by reducing the path overhead and other challenges as
	listed in Section 5.3.7 of
	[I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the
	source routing to user planes beyond SR-MPLS and SRv6 i.e., L2,
	native IPv6 and IPv4 user planes.
	This helps legacy transport networks to get the immediate path
	steering benefits and helps in overall migration strategy of the
	network to the desired user plane. Some of these benefits with PPR
	can be realized with no hardware upgrade except control plane
	software for native IPv6 and IPv4 user planes.
	3.1.3. Service Level Guarantee in Underlay		In some E2E scenarios, security is desired granularly in the
			underlying transport network. In such cases, there would be a need
			to have separate sub-ranges under each SST to provide the TE path in
			preserving the security characteristics. The UDP Source Port range
			captured in Figure 2 would be sub-divided to maintain the TE path for
			the current SSTs with the security. The current solution doesn't
			provide any mandate on the UE traffic in selecting the type of
			security.
	PPR also optionally allows to allocate resources that are to be		3.2. Transport Network Technologies
	reserved along the preferred path. These resources are required in
	some cases (for some 5G SSTs with stringent GBR and latency
	requirements) not only for providing committed bandwidth or
	deterministic latency, but also for assuring overall service level
	guarantee in the network. This approach does not require per-hop
	provisioning and reduces the OPEX by minimizing the number of
	protocols needed and allows dynamism with Fast-ReRoute (FRR)
	capabilities.
	3.2. Other TE Technologies Applicability		While there are many Software Defined Networking (SDN) approaches are
			available, this sections is not intended to list all the
			possibilities in this space but merely captures the technologies for
			various requirements discussed in this document.
	RSVP-TE [RFC3209] provides a lean transport overhead for the TE path		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 [RFC8402] does not explicitly signal bandwidth reservation or
	bandwidth reservation or mechanism to guarantee latency on the nodes/		mechanism to guarantee latency on the nodes/links on SR path. But SR
	links on SR path. But SR allows path steering for any flow at the		allows path steering for any flow at the ingress and particular path
	ingress and particular path for a flow can be chosen. Some of the		for a flow can be chosen. Some of the issues and suitability for
	issues around path overhead/tax, MTU issues are documented at		mobile use plane are documented at Section 5.3 of
	Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR-		[I-D.bogineni-dmm-optimized-mobile-user-plane]. However,
	MPLS allows reduction of the control protocols to one IGP (with out		[I-D.ietf-dmm-srv6-mobile-uplane] presents various options for
	needing for LDP and RSVP-TE).		optimized mobile user plane with SRv6 with or without GTP-U overhead
			along with traffic engineering capabilities. SR-MPLS allows
			reduction of the control protocols to one IGP (without needing for
			LDP and RSVP-TE).
	However, as specified above with PPR (Section 3.1), in the integrated		Preferred Path Routing (PPR) is an integrated routing and TE
	transport network function (TNF) a particular RSVP-TE path for MPLS		technology and the applicability for this framework is described in
	or SR path for MPLS and IPv6 with SRH user plane, can be supplied to		[I-D.chunduri-dmm-5g-mobility-with-ppr]. PPR does not remove GTP-U,
	SMF for mapping a particular PDU session to the transport path.		unlike some other proposals laid out in
			[I-D.bogineni-dmm-optimized-mobile-user-plane]. Instead, PPR works
			with the existing cellular user plane (GTP-U) for F1-U/N3 and N9. In
			this scenario, PPR will only help providing TE benefits needed for 5G
			slices from transport domain perspective. It does so for any
			underlying user/data plane used in the transport network
			(L2/IPv4/IPv6/MPLS).
			As specified with the integrated transport network function (TNF), a
			particular RSVP-TE path for MPLS or SR path for MPLS and IPv6 with
			SRH user plane or PPR with PPR-ID [I-D.chunduri-dmm-5g-mobility-with-
			ppr], can be supplied to SMF for mapping a particular PDU session to
			the transport path.
	4. Acknowledgements		4. Acknowledgements
	Thanks to Young Lee for discussions on this document including ACTN		Thanks to Young Lee for discussions on this document including ACTN
	applicability for the proposed TNF. Thanks to Sri Gundavelli and		applicability for the proposed TNF. Thanks to Sri Gundavelli, Kausik
	3GPP delegates who provided detailed feedback on this document.		Majumdar and 3GPP delegates who provided detailed feedback on this
			document.
	5. IANA Considerations		5. IANA Considerations
	This document has no requests for any IANA code point allocations.		This document has no requests for any IANA code point allocations.
	6. Security Considerations		6. Security Considerations
	This document does not introduce any new security issues.		This document does not introduce any new security issues.
	7. Contributing Authors		7. Contributing Authors
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 5 ¶
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	8.2. Informative References		8.2. Informative References
	[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),		[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),
	"IOT Categorization: Exploring the Need for Standardizing		"IOT Categorization: Exploring the Need for Standardizing
	Additional Network Slices ATIS-I-0000075", September 2019.		Additional Network Slices ATIS-I-0000075", September 2019.
	[I-D.bashandy-rtgwg-segment-routing-ti-lfa]
	Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
	Francois, P., daniel.voyer@bell.ca, d., Clad, F., and P.
	Camarillo, "Topology Independent Fast Reroute using
	Segment Routing", draft-bashandy-rtgwg-segment-routing-ti-
	lfa-05 (work in progress), October 2018.
	[I-D.bogineni-dmm-optimized-mobile-user-plane]		[I-D.bogineni-dmm-optimized-mobile-user-plane]
	Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,		Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
	Rodriguez-Natal, A., Carofiglio, G., Auge, J.,		Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
	Muscariello, L., Camarillo, P., and S. Homma, "Optimized		Muscariello, L., Camarillo, P., and S. Homma, "Optimized
	Mobile User Plane Solutions for 5G", draft-bogineni-dmm-		Mobile User Plane Solutions for 5G", 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]
	Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
	L., and Y. Qu, "Preferred Path Routing (PPR) in IS-IS",
	draft-chunduri-lsr-isis-preferred-path-routing-05 (work in
	progress), March 2020.
	[I-D.chunduri-lsr-ospf-preferred-path-routing]
	Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
	Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
	chunduri-lsr-ospf-preferred-path-routing-04 (work in
	progress), March 2020.
	[I-D.farinacci-lisp-mobile-network]
	Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
	for the Mobile Network", draft-farinacci-lisp-mobile-
	network-09 (work in progress), September 2020.
	[I-D.ietf-dmm-5g-uplane-analysis]		[I-D.ietf-dmm-5g-uplane-analysis]
	Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,		Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
	"User Plane Protocol and Architectural Analysis on 3GPP 5G		"User Plane Protocol and Architectural Analysis on 3GPP 5G
	System", draft-ietf-dmm-5g-uplane-analysis-03 (work in		System", draft-ietf-dmm-5g-uplane-analysis-03 (work in
	progress), November 2019.		progress), November 2019.
	[I-D.ietf-dmm-srv6-mobile-uplane]		[I-D.ietf-dmm-srv6-mobile-uplane]
	Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,		Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
	Voyer, D., and C. Perkins, "Segment Routing IPv6 for		Voyer, D., and C. Perkins, "Segment Routing IPv6 for
	Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09		Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09
	(work in progress), July 2020.		(work in progress), July 2020.
	[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]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-15 (work
	in progress), January 2018.
	[IR.34-GSMA]		[IR.34-GSMA]
	GSM Association (GSMA), "Guidelines for IPX Provider		GSM Association (GSMA), "Guidelines for IPX Provider
	Networks (Previously Inter-Service Provider IP Backbone		Networks (Previously Inter-Service Provider IP Backbone
	Guidelines, Version 14.0", August 2018.		Guidelines, Version 14.0", August 2018.
	[ORAN-WG4.CUS-O-RAN]		[ORAN-WG4.CUS-O-RAN]
	O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;		O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
	Control, User and Synchronization Plane Specification;		Control, User and Synchronization Plane Specification;
	v2.0.0", August 2019.		v2.0.0", August 2019.
	[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
	Element (PCE) Communication Protocol (PCEP)", RFC 5440,
	DOI 10.17487/RFC5440, March 2009,
	<https://www.rfc-editor.org/info/rfc5440>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830,
	DOI 10.17487/RFC6830, January 2013,
	<https://www.rfc-editor.org/info/rfc6830>.
	[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
	So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
	RFC 7490, DOI 10.17487/RFC7490, April 2015,
	<https://www.rfc-editor.org/info/rfc7490>.
	[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016,
	<https://www.rfc-editor.org/info/rfc7752>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.
	[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and		[RFC8370] Beeram, V., Ed., Minei, I., Shakir, R., Pacella, D., and
	T. Saad, "Techniques to Improve the Scalability of RSVP-TE		T. Saad, "Techniques to Improve the Scalability of RSVP-TE
	Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,		Deployments", RFC 8370, DOI 10.17487/RFC8370, May 2018,
	<https://www.rfc-editor.org/info/rfc8370>.		<https://www.rfc-editor.org/info/rfc8370>.
			[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
			Decraene, B., Litkowski, S., and R. Shakir, "Segment
			Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
			July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for		[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for
	Abstraction and Control of TE Networks (ACTN)", RFC 8453,		Abstraction and Control of TE Networks (ACTN)", RFC 8453,
	DOI 10.17487/RFC8453, August 2018,		DOI 10.17487/RFC8453, August 2018,
	<https://www.rfc-editor.org/info/rfc8453>.		<https://www.rfc-editor.org/info/rfc8453>.
	[TS.23.401-3GPP]
	3rd Generation Partnership Project (3GPP), "Procedures for
	4G/LTE System; 3GPP TS 23.401, v15.4.0", June 2018.
	[TS.23.501-3GPP]		[TS.23.501-3GPP]
	3rd Generation Partnership Project (3GPP), "System		3rd Generation Partnership Project (3GPP), "System
	Architecture for 5G System; Stage 2, 3GPP TS 23.501		Architecture for 5G System; Stage 2, 3GPP TS 23.501
	v2.0.1", December 2017.		v2.0.1", December 2017.
	[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.
	skipping to change at page 23, line 30 ¶		skipping to change at page 21, line 38 ¶
	A.2. Slice aware Mobility: Discrete Approach		A.2. Slice aware Mobility: Discrete Approach
	In this approach transport network functionality from the 5G-AN to		In this approach transport network functionality from the 5G-AN to
	UPF is discrete and 5GS is not aware of the underlying transport		UPF is discrete and 5GS is not aware of the underlying transport
	network and the resources available. Deployment specific mapping		network and the resources available. Deployment specific mapping
	function is used to map the GTP-U encapsulated traffic at the 5G-AN		function is used to map the GTP-U encapsulated traffic at the 5G-AN
	(e.g. gNB) in UL and UPF in DL direction to the appropriate transport		(e.g. gNB) in UL and UPF in DL direction to the appropriate transport
	slice or transport Traffic Engineered (TE) paths. These TE paths can		slice or transport Traffic Engineered (TE) paths. These TE paths can
	be established using RSVP-TE [RFC3209] for MPLS underlay, SR		be established using RSVP-TE [RFC3209] for MPLS underlay, SR
	[I-D.ietf-spring-segment-routing] for both MPLS and IPv6 underlay or		[RFC3209] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-dmm-
	PPR [I-D.chunduri-lsr-isis-preferred-path-routing] with MPLS, IPv6		5g-mobility-with-ppr] with MPLS, IPv6 with SRH, native IPv6 and
	with SRH, native IPv6 and native IPv4 underlays.		native IPv4 underlays.
	As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the		As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
	user plane traffic forwarding rules in the UPF. The UPFs have a		user plane traffic forwarding rules in the UPF. The UPFs have a
	concept of a "Network Instance" which logically abstracts the		concept of a "Network Instance" which logically abstracts the
	underlying transport path. When the SMF creates the packet detection		underlying transport path. When the SMF creates the packet detection
	rules (PDR) and forwarding action rules (FAR) for a PDU session at		rules (PDR) and forwarding action rules (FAR) for a PDU session at
	the UPF, the SMF identifies the network instance through which the		the UPF, the SMF identifies the network instance through which the
	packet matching the PDR has to be forwarded. A network instance can		packet matching the PDR has to be forwarded. A network instance can
	be mapped to a TE path at the UPF. In this approach, TNF as shown in		be mapped to a TE path at the UPF. In this approach, TNF as shown in
	Figure 1 need not be part of the 5G Service Based Interface (SBI).		Figure 1 need not be part of the 5G Service Based Interface (SBI).
	skipping to change at page 24, line 14 ¶		skipping to change at page 22, line 21 ¶
	One of the limitations of this approach is the inability of the 5GS		One of the limitations of this approach is the inability of the 5GS
	procedures to know, if underlying transport resources are available		procedures to know, if underlying transport resources are available
	for the traffic type being carried in PDU session before making		for the traffic type being carried in PDU session before making
	certain decisions in the 5G CP. One example scenario/decision could		certain decisions in the 5G CP. One example scenario/decision could
	be, a target 5G-AN selection during a N2 mobility event, without		be, a target 5G-AN selection during a N2 mobility event, without
	knowing if the target 5G-AN is having a underlay transport slice		knowing if the target 5G-AN is having a underlay transport slice
	resource for the S-NSSAI and 5QI of the PDU session. The Integrated		resource for the S-NSSAI and 5QI of the PDU session. The Integrated
	approach specified below can mitigate this.		approach specified below can mitigate this.
	Appendix B. 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.
	B.1. SSC Mode1
	+--------------+
	+---+----+ |NSSMF +-----+ | +----------------+
	| AMF | | | TNF | | | SMF |
	+---+--+-+ | +-+-+-+ | +-----+----------+
	N1 | +--------+-+---+ |
	| | | | |
	| | +---+-+--+ |
	| | | SDN-C | |
	| | +---+-+--+ |
	| | | | |
	+--------+ N2 +---------+ + ---+ |
	| | | | |
	+ +---+--+ +--++ +---+ +-+--+ +----+
	UE1 |gNB|======|CSR|---N3--------|PE |-|UPF |-N6--| DN |
	== +---+ +---+ +---+ +----+ +----+
	Figure 3: SSC Mode1 with integrated Transport Slice Function
	After UE1 moved to another gNB in the same UPF serving area
	+--------------+
	+---+----+ |NSSMF +-----+ | +----------------+
	| AMF | | | TNF | | | SMF |
	+------+-+ | +-+-+-+ | +-----+----------+
	| +--------+-+---+ |
	| | | |
	| +---+-+--+ |
	| | SDN-C | |
	| +---+-+--+ |
	| | | |
	N2 +---------+ + ---+ |
	| | | |
	+---+--+ +--++ +---+ +-+--+ +----+
	|gNB|======|CSR|---N3--------|PE |-|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).
	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.
	+--------------+
	+---+----+ |NSSMF +-----+ | +----------------+
	| AMF | | | TNF | | | SMF |
	+---+--+-+ | +-+-+-+ | +-+-----------+--+
	| | +--------+-+---+ | |
	N1 | | | | |
	| | +---+-+--+ | |
	| | | SDN-C | | |
	| | +---+-+--+ | |
	| | | | | |
	to-UE+----+ N2 +-----------+ | N4 N4|
	+---+ | | | |
	| | | | |
	+---+ +---++ +---+ +-------+--+ +---+ +---+
	|gNB|===|CSR |---N3---|PE |-| BP UPF |-N9-|PE |-|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 with the UDP source port (corresponds to
	the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the
	PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR
	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)
	Futurewei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara, CA 95050		Santa Clara, CA 95050
	USA		USA
	Email: umac.ietf@gmail.com		Email: umac.ietf@gmail.com
End of changes. 52 change blocks.
	425 lines changed or deleted		149 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/