< draft-ietf-dmm-tn-aware-mobility-01.txt		draft-ietf-dmm-tn-aware-mobility-02.txt >
	DMM Working Group U.C. Chunduri, Ed.		DMM Working Group U. Chunduri, Ed.
	Internet-Draft Intel		Internet-Draft Intel Corporation
	Intended status: Informational J.K. Kaippallimalil, Ed.		Intended status: Informational J. Kaippallimalil, Ed.
	Expires: 26 March 2022 Futurewei		Expires: April 25, 2022 Futurewei
	S.B. Bhaskaran		S. Bhaskaran
	Altiostar		Altiostar
	J.T. Tantsura		J. Tantsura
	Microsoft		Microsoft
	P.M. Muley		P. Muley
	Nokia		Nokia
	22 September 2021		October 22, 2021
	Transport Network aware Mobility for 5G		Mobility aware Transport Network Slicing for 5G
	draft-ietf-dmm-tn-aware-mobility-01		draft-ietf-dmm-tn-aware-mobility-02
	Abstract		Abstract
	This document specifies a framework and mapping of slices in 5G		This document specifies a framework and mapping of slices in 5G
	mobile systems to transport network slices in IP, Layer 2 or Layer 1		mobile systems to transport network slices in IP, Layer 2 or Layer 1
	transport networks. Slices in 5G systems are characterized by		transport networks. Slices in 5G systems are characterized by
	latency bounds, reservation guarantees, jitter, data rates,		latency bounds, reservation guarantees, jitter, data rates,
	availability, mobility speed, usage density, criticality and		availability, mobility speed, usage density, criticality and
	priority. These characteristics mapped to transport network slice		priority. These characteristics are mapped to transport network
	include bandwidth, latency and criteria such as isolation,		slice include bandwidth, latency and criteria such as isolation,
	directionality and disjoint routes. Mobile slice criteria are mapped		directionality and disjoint routes. Mobile slice criteria are mapped
	to the appropriate transport slice and capabilities offered in		to the appropriate transport slice and capabilities offered in
	backhaul, midhaul and fronthaul connectivity segments between radio		backhaul, midhaul and fronthaul connectivity segments between radio
	side network functions and user plane function(gateway).		side network functions and user plane function(gateway).
	This document describes how mobile network functions map its slice		This document describes how a mobile network slice is mapped to a
	criteria to identifiers in IP and Layer 2 packets that transport		slice in IP or Layer 2 transport network between 3GPP provisioning
	network segments use to grant transport layer services during UE		end points. The same mapping mechanisms apply during initial UE
	mobility scenarios. Applicability of this framework and underlying		session setup and following UE mobility. Applicability of this
	transport networks, which can enable different slice properties are		framework and underlying transport networks, which can enable
	also discussed. This is based on mapping between mobile and		different slice properties are also discussed. This is based on
	transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).		mapping between mobile and transport underlays (L2, Segment Routing,
			IPv6, MPLS and IPv4).
	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].
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 26 March 2022.		This Internet-Draft will expire on April 25, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.		(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components		carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Simplified BSD License text		to this document. Code Components extracted from this document must
	as described in Section 4.e of the Trust Legal Provisions and are		include Simplified BSD License text as described in Section 4.e of
	provided without warranty as described in the Simplified BSD License.		the Trust Legal Provisions and are provided without warranty as
			described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4		1.1. IETF Network Slicing Terminology . . . . . . . . . . . . 4
	1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4		1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
	1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5		1.3. Solution Approach . . . . . . . . . . . . . . . . . . . . 5
	1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5		1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Transport and Slice aware Mobility in 5G Networks . . . . . . 7		2. Transport and Slice aware Mobility in 5G Networks . . . . . . 7
	2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 9		2.1. Backhaul and Mid-Haul Transport Network . . . . . . . . . 8
	2.1.1. IETF Network Slicing Applicability . . . . . . . . . 10		2.1.1. IETF Network Slicing Applicability . . . . . . . . . 10
	2.1.2. Fronthaul Transport Network . . . . . . . . . . . . . 10		2.1.2. Fronthaul Transport Network . . . . . . . . . . . . . 10
	2.2. Mobile Transport Network Context (MTNC) and		2.2. Mobile Transport Network Context (MTNC) and Scalability . 10
	Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
	2.3. Transport Network Function (TNF) . . . . . . . . . . . . 11		2.3. Transport Network Function (TNF) . . . . . . . . . . . . 11
	2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 12		2.4. Transport Provisioning . . . . . . . . . . . . . . . . . 12
	2.5. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 14		2.5. MTNC-ID in the Data Packet . . . . . . . . . . . . . . . 13
	2.6. Functionality for E2E Management . . . . . . . . . . . . 15		2.6. Functionality for E2E Management . . . . . . . . . . . . 15
	3. Transport Network Underlays . . . . . . . . . . . . . . . . . 17
	3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 17		Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	3.2. Transport Network Technologies . . . . . . . . . . . . . 19
	4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20		3. Transport Network Underlays . . . . . . . . . . . . . . . . . 16
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		3.2. Transport Network Technologies . . . . . . . . . . . . . 18
	7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 20		4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
			7. Contributing Authors . . . . . . . . . . . . . . . . . . . . 19
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . 20		8.1. Normative References . . . . . . . . . . . . . . . . . . 20
	8.2. Informative References . . . . . . . . . . . . . . . . . 21		8.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. New Control Plane and User Planes . . . . . . . . . 23		Appendix A. New Control Plane and User Planes . . . . . . . . . 22
	A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 23		A.1. Slicing Framework and RAN Aspects . . . . . . . . . . . . 22
	A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 24		A.2. Slice aware Mobility: Discrete Approach . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	The 3GPP architecture for 5GS defined in [TS.23.501-3GPP],		The 3GPP architecture for 5GS defined in [TS.23.501-3GPP],
	[TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core) and the NG-		[TS.23.502-3GPP] and [TS.23.503-3GPP] for 5GC (5G Core) and the NG-
	RAN architecture and procedures defined in [TS.38.300-3GPP] and		RAN architecture and procedures defined in [TS.38.300-3GPP] and
	[TS.38.401-3GPP] include procedures for setting up network slices in		[TS.38.401-3GPP] include procedures for setting up network slices in
	the 3GPP network. The 5GS (5G System) architecture also defines a		the 3GPP network. The 5GS (5G System) architecture also defines a
	comprehensive set of functions for access mobility, session handling		comprehensive set of functions for access mobility, session handling
	and related functions for subscription management, authentication and		and related functions for subscription management, authentication and
	skipping to change at page 3, line 39 ¶		skipping to change at page 3, line 47 ¶
	specifications only define the interfaces (N3, N9, F1U etc.) and the		specifications only define the interfaces (N3, N9, F1U etc.) and the
	3GPP transport end points [TS.28.541-3GPP]. The architecture allows		3GPP transport end points [TS.28.541-3GPP]. The architecture allows
	the placement of Branching Point (BP) and Uplink Classifier (ULCL)		the placement of Branching Point (BP) and Uplink Classifier (ULCL)
	UPFs closer to the access network (5G-AN). The gNB-CU and gNB-DU are		UPFs closer to the access network (5G-AN). The gNB-CU and gNB-DU are
	the centralized unit (CU) and distributed unit (DU) of a 5G radio		the centralized unit (CU) and distributed unit (DU) of a 5G radio
	access network (NG-RAN) with gNB. The 5G-AN can be a radio access		access network (NG-RAN) with gNB. The 5G-AN can be a radio access
	network (NG-RAN) or any non-3GPP access network, for example, WLAN.		network (NG-RAN) or any non-3GPP access network, for example, WLAN.
	The IP address is anchored by a PDU session anchor UPF (PSA UPF).		The IP address is anchored by a PDU session anchor UPF (PSA UPF).
	3GPP slicing and RAN aspects are further described in Appendix A.1.		3GPP slicing and RAN aspects are further described in Appendix A.1.
	5GS allows more than one UPF on the path for a PDU (Protocol Data		3GPP has defined three broad slice types to cover enhanced mobile
	Unit) session that provides various functionality including session		broadband (eMBB) communications, ultra-reliable low latency
	anchoring, uplink classification and branching point for a multihomed		communications(URLLC) and massive internet of things (mIoT). ATIS
	IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA		[ATIS075] has defined an additional slice type for V2X services.
	UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9		3GPP slice types and multiple instances of a slice type satisfy
	and N3 interfaces between the various UPF instances and the (R)AN and		various characteristics for 5G network resources The slice details in
	also, for the F1-U interface between the DU and the CU in the NG-RAN.		3GPP, ATIS or NGMN do not specify how slice characteristics for QoS,
	3GPP has specified control and user plane aspects in [TS.23.501-3GPP]
	to provide slice and QoS support. 3GPP has defined three broad slice		Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	types to cover enhanced mobile broadband (eMBB) communications,
	ultra-reliable low latency communications(URLLC) and massive internet		hard /soft isolation, protection and other aspects should be
	of things (mIoT). ATIS [ATIS075] has defined an additional slice		satisfied in IP transport networks.
	type for V2X services. 3GPP slice types and multiple instances of a
	slice type satisfy various characteristics for 5G network resources
	The slice details in 3GPP, ATIS or NGMN do not specify how slice
	characteristics for QoS, hard /soft isolation, protection and other
	aspects should be satisfied in IP transport networks.
	A transport underlay across each 3GPP segment may have multiple		A transport underlay across each 3GPP segment may have multiple
	technologies or providers on path and the slice in 3GPP domain should		technologies or providers on path and the slice in 3GPP domain should
	have a corresponding mapping in the transport domain. This document		have a corresponding mapping in the transport domain. This document
	proposes to map a slice in the 3GPP domain to a transport domain		proposes to map a slice in the 3GPP domain to a transport domain
	slice. This document also proposes to carry this provisioned mapping		slice. This document also proposes to carry this provisioned mapping
	in an IP packet so that the IP transport domain can classify and		in an IP packet so that the IP transport domain can classify and
	provide the required service. This is explored further in this		provide the required service. This is explored further in this
	document.		document.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 4 ¶
	resources and functionalities needed from the transport network for		resources and functionalities needed from the transport network for
	the selection of UPF. This is seen as independent functionality and		the selection of UPF. This is seen as independent functionality and
	is currently not part of 5GS.		is currently not part of 5GS.
	However, the lack of underlying Transport Network (TN) awareness may		However, the lack of underlying Transport Network (TN) awareness may
	lead to selection of sub-optimal UPF(s) and/or 5G-AN during various		lead to selection of sub-optimal UPF(s) and/or 5G-AN during various
	procedures in 5GS (e.g., session establishment and various mobility		procedures in 5GS (e.g., session establishment and various mobility
	scenarios). Meeting the specific slice characteristics on the F1-U,		scenarios). Meeting the specific slice characteristics on the F1-U,
	N3 and N9 interfaces depends on the IP transport underlay providing		N3 and N9 interfaces depends on the IP transport underlay providing
	these resources and capabilities. This could also lead to the		these resources and capabilities. This could also lead to the
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	inability in meeting SLAs for real-time, mission-critical or latency		inability in meeting SLAs for real-time, mission-critical or latency
	sensitive services.		sensitive services.
	The 5GS provides slices to its clients (UEs). The UE's PDU session		The 5GS provides slices to its clients (UEs). The UE's PDU session
	spans the access network (radio access network including the F1-U)		spans the access network (radio access network including the F1-U)
	and N3 and N9 transport segments which have an IP transport underlay.		and N3 and N9 transport segments which have an IP transport underlay.
	The 5G operator needs to obtain slice capability from the IP		The 5G operator needs to obtain slice capability from the IP
	transport provider. Several UE sessions that match a slice may be		transport provider. Several UE sessions that match a slice may be
	mapped to an IP transport segment. Thus, there needs to be a mapping		mapped to an IP transport segment. Thus, there needs to be a mapping
	between the slice capability offered to the UE (S-NSSAI) and what is		between the slice capability offered to the UE (S-NSSAI) and what is
	skipping to change at page 5, line 31 ¶		skipping to change at page 5, line 33 ¶
	an optimized fashion. This is done by keeping establishment and		an optimized fashion. This is done by keeping establishment and
	mobility procedures aware of the underlying transport network along		mobility procedures aware of the underlying transport network along
	with slicing requirements.		with slicing requirements.
	Section 2 describes in detail on how TN aware mobility can be built		Section 2 describes in detail on how TN aware mobility can be built
	irrespective of underlying TN technology used. How other IETF TE		irrespective of underlying TN technology used. How other IETF TE
	technologies applicable for this draft is specified in Section 3.2.		technologies applicable for this draft is specified in Section 3.2.
	1.4. Acronyms		1.4. Acronyms
	5QI - 5G QoS Indicator		5QI - 5G QoS Indicator
	5G-AN - 5G Access Network		5G-AN - 5G Access Network
	AMF - Access and Mobility Management Function (5G)		AMF - Access and Mobility Management Function (5G)
	BP - Branch Point (5G)		BP - Branch Point (5G)
	CSR - Cell Site Router		CSR - Cell Site Router
	CP - Control Plane (5G)		CP - Control Plane (5G)
	CU - Centralized Unit (5G, gNB)		CU - Centralized Unit (5G, gNB)
	DN - Data Network (5G)		DN - Data Network (5G)
	DU - Distributed Unit (5G, gNB)		DU - Distributed Unit (5G, gNB)
	eMBB - enhanced Mobile Broadband (5G)		eMBB - enhanced Mobile Broadband (5G)
	FRR - Fast ReRoute		FRR - Fast ReRoute
	gNB - 5G NodeB
	GBR - Guaranteed Bit Rate (5G)		Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	GTP-U - GPRS Tunneling Protocol - User plane (3GPP)		gNB - 5G NodeB
	IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)		GBR - Guaranteed Bit Rate (5G)
	LFA - Loop Free Alternatives (IP FRR)		GTP-U - GPRS Tunneling Protocol - User plane (3GPP)
	mIOT - Massive IOT (5G)		IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)
	MPLS - Multi Protocol Label Switching		LFA - Loop Free Alternatives (IP FRR)
	NG-RAN - Next Generation Radio Access Network (i.e., gNB, NG-eNB -		mIOT - Massive IOT (5G)
			MPLS - Multi Protocol Label Switching
			NG-RAN - Next Generation Radio Access Network (i.e., gNB, NG-eNB -
	RAN functions which connect to 5GC)		RAN functions which connect to 5GC)
	NSSMF - Network Slice Selection Management Function		NSSMF - Network Slice Selection Management Function
	QFI - QoS Flow ID (5G)		QFI - QoS Flow ID (5G)
	PPR - Preferred Path Routing		PPR - Preferred Path Routing
	PDU - Protocol Data Unit (5G)		PDU - Protocol Data Unit (5G)
	PW - Pseudo Wire		PW - Pseudo Wire
	RAN - Radio Access Network (i.e 3GPP radio access network used		RAN - Radio Access Network (i.e 3GPP radio access network used
	synonymously with NG-RAN in this document)		synonymously with NG-RAN in this document)
	RAN - Radio Access Network		RAN - Radio Access Network
	RQI - Reflective QoS Indicator (5G)		RQI - Reflective QoS Indicator (5G)
	SBI - Service Based Interface (5G)		SBI - Service Based Interface (5G)
	SID - Segment Identifier		SID - Segment Identifier
	SMF - Session Management Function (5G)		SMF - Session Management Function (5G)
	SSC - Session and Service Continuity (5G)		SSC - Session and Service Continuity (5G)
	SST - Slice and Service Types (5G)		SST - Slice and Service Types (5G)
	SR - Segment Routing		SR - Segment Routing
	TE - Traffic Engineering		TE - Traffic Engineering
	ULCL - Uplink Classifier (5G)
	UP - User Plane(5G)		Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	UPF - User Plane Function (5G)		ULCL - Uplink Classifier (5G)
	URLLC - Ultra reliable and low latency communications (5G)		UP - User Plane(5G)
			UPF - User Plane Function (5G)
			URLLC - Ultra reliable and low latency communications (5G)
	2. Transport and Slice aware Mobility in 5G Networks		2. Transport and Slice aware Mobility in 5G Networks
	3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing		3GPP architecture [TS.23.501-3GPP], [TS.23.502-3GPP] describe slicing
	in 5GS and is provided here for information. The application of 5GS		in 5GS and is provided here for information. The application of 5GS
	slices in transport network for backhaul, mid-haul and front haul are		slices in transport network for backhaul, mid-haul and front haul are
	not explicitly covered in 3GPP and is the topic here. To support		not explicitly covered in 3GPP and is the topic here. To support
	specific characteristics in backhaul (N3, N9), mid-haul (F1) and		specific characteristics in backhaul (N3, N9), mid-haul (F1) and
	front haul, it is necessary to map and provision corresponding		front haul, it is necessary to map and provision corresponding
	resources in the transport domain. This section describes how to		resources in the transport domain. This section describes how to
	provision the mapping information in the transport network and apply		provision the mapping information in the transport network and apply
	it so that user plane packets can be provided the transport resources		it so that user plane packets can be provided the transport resources
	(QoS, isolation, protection, etc.) expected by the 5GS slices.		(QoS, isolation, protection, etc.) expected by the 5GS slices.
	The figure shows the entities on path for 3GPP Network Functions		The figure shows the entities on path for 3GPP Network Functions
	(gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an		(gNB-DU, gNB-CU, UPF) to obtain slice aware classification from an
	IP/L2 transport network.		IP/L2 transport network.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	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 8, line 36 ¶		skipping to change at page 8, line 38 ¶
	| | __/ \__ +--+---+ __/ \__ +-+-+		| | __/ \__ +--+---+ __/ \__ +-+-+
	| | / IP \ | gNB | / IP \ | |		| | / IP \ | gNB | / IP \ | |
	UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN		UE--*| |-(PE) Mid-haul (PE)---+CU(UP)+--(PE) Backhaul(PE)--+UPF|--DN
	+----------+ \__ __/ +------+ \__ __/ +---+		+----------+ \__ __/ +------+ \__ __/ +---+
	\______/ \______/		\______/ \______/
	|------ F1-U -------| |------ N3 OR N9 ------|		|------ F1-U -------| |------ N3 OR N9 ------|
	* Radio and Fronthaul		* Radio and Fronthaul
	Figure 1: Backhaul and Mid-haul Transport Network for 5G		Figure 1: Backhaul and Mid-haul Transport Network for 5G
	2.1. Backhaul and Mid-Haul Transport Network		2.1. Backhaul and Mid-Haul Transport Network
	Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)		Figure 1 depicts IP Xhaul network with SDN-C and PE (Provider Edge)
	routers providing IP transport service to 5GS user plane entities 5G-		routers providing IP transport service to 5GS user plane entities 5G-
	AN (e.g. gNB) and UPF. 5GS architecture with high level management,		AN (e.g. gNB) and UPF. 5GS architecture with high level management,
	control and user plane entities and its interaction with the IP		control and user plane entities and its interaction with the IP
	transport plane is shown here. The slice capability required in IP		transport plane is shown here. The slice capability required in IP
	transport networks are estimated and provisioned by the functionality		transport networks are estimated and provisioned by the functionality
	as specified in Section 2.3 (TNF) with support from various other		as specified in Section 2.3 (TNF) with support from various other
	control plane functions such as the Network Data Analytics Function		control plane functions such as the Network Data Analytics Function
	(NWDAF), Network Function Repository Function (NRF) and Policy		(NWDAF), Network Function Repository Function (NRF) and Policy
	Control Function (PCF). The TNF is only a logical function that may		Control Function (PCF). The TNF is only a logical function that may
	be realized in a 3GPP management function such as Network Slice		be realized in a 3GPP management function such as Network Slice
	Selection Management Function (NSSMF) defined in [TS.28.533-3GPP].		Selection Management Function (NSSMF) defined in [TS.28.533-3GPP].
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	The TNF requests the SDN-C to provision the IP XHaul network using		The TNF requests the SDN-C to provision the IP XHaul network using
	ACTN [RFC8453].		ACTN [RFC8453].
	The 5G management plane in Figure 1 interacts with the 5G control		The 5G management plane in Figure 1 interacts with the 5G control
	plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and		plane - the 5GC (5G Core), gNB-CU (5G NodeB Centralized Unit) and
	gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS)		gNB-DU (5G Node B Distributed Unit). Non-access stratum (NAS)
	signaling from the UE for session management, mobility is handled by		signaling from the UE for session management, mobility is handled by
	the 5GC. When a UE initiates session establishment, it indicates the		the 5GC. When a UE initiates session establishment, it indicates the
	desired slice type in the S-NSSAI (Specific Network Slice Selection		desired slice type in the S-NSSAI (Specific Network Slice Selection
	Assistance Information) field. The AMF uses the S-NSSAI, other		Assistance Information) field. The AMF uses the S-NSSAI, other
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 5 ¶
	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-U		the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP-U
	encapsulated user packet from the (R)AN (gNB) or UPF with the slice		encapsulated user packet from the (R)AN (gNB) or UPF with the slice
	information traverses the F1-U/N3/N9 segment, the PE router of the IP		information traverses the F1-U/N3/N9 segment, the PE router of the IP
	transport underlay can inspect the slice information and provide the		transport underlay can inspect the slice information and provide the
	provisioned capabilities. This is elaborated further in Section 2.4.		provisioned capabilities. This is elaborated further in Section 2.4.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	2.1.1. IETF Network Slicing Applicability		2.1.1. IETF Network Slicing Applicability
	Some of the functional elements depicted in the Figure 1 can be		Some of the functional elements depicted in the Figure 1 can be
	mapped to the terminology set forth in the		mapped to the terminology set forth in the
	[I-D.ietf-teas-ietf-network-slices]. From 3GPP perspective, UE and		[I-D.ietf-teas-ietf-network-slices]. From 3GPP perspective, UE and
	UPF are the network slice endpoints and routers, gNB-DU, gNB-CU,		UPF are the network slice endpoints and routers, gNB-DU, gNB-CU,
	switches, PE nodes are the slice realization endpoints. The TNF		switches, PE nodes are the slice realization endpoints. The TNF
	represented in the Figure 1 can be seen as IETF Network Slice		represented in the Figure 1 can be seen as IETF Network Slice
	Controller (NSC) functionality and SDN-C maps to Network Controller		Controller (NSC) functionality and SDN-C maps to Network Controller
	(NC). NSC-NBI interface is the interface from 3GPP Management plane		(NC). NSC-NBI interface is the interface from 3GPP Management plane
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 4 ¶
	SDN-C pertaining to the fronthaul transport.		SDN-C pertaining to the fronthaul transport.
	2.2. Mobile Transport Network Context (MTNC) and Scalability		2.2. Mobile Transport Network Context (MTNC) and Scalability
	The MTNC represents a slice of a transport path for a tenant between		The MTNC represents a slice of a transport path for a tenant between
	two 3GPP user plane functions. The Mobile-Transport Network Context		two 3GPP user plane functions. The Mobile-Transport Network Context
	Identifier (MTNC-ID) is generated by the TNF to be unique for each		Identifier (MTNC-ID) is generated by the TNF to be unique for each
	instance (for a tenant) and per traffic class (including QoS and		instance (for a tenant) and per traffic class (including QoS and
	slice aspects). Thus, there may be more than one MTNC-ID for the		slice aspects). Thus, there may be more than one MTNC-ID for the
	same QoS and instance if there is a need to provide isolation (slice)		same QoS and instance if there is a need to provide isolation (slice)
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	of the traffic. It should be noted that MTNC are per class/instance		of the traffic. It should be noted that MTNC are per class/instance
	and not per user session. The MTNC-IDs are configured by the TNF to		and not per user session. The MTNC-IDs are configured by the TNF to
	be unique within a provisioning domain.		be unique within a provisioning domain.
	Since the MTNC-IDs are generated per instance / tenant, there is no		Since the MTNC-IDs are generated per instance / tenant, there is no
	need for unique MTNC-IDs per flow/session. In addition, since the		need for unique MTNC-IDs per flow/session. In addition, since the
	traffic estimation is performed prior to UE's session establishment,		traffic estimation is performed prior to UE's session establishment,
	there is no provisioning delay experienced by the UE during its		there is no provisioning delay experienced by the UE during its
	session setup. For an instance/tenant, the MTNC-ID space scales		session setup. For an instance/tenant, the MTNC-ID space scales
	roughly as a square of the number sites between which 3GPP user plane		roughly as a square of the number sites between which 3GPP user plane
	functions have paths. If there are T traffic classes across N sites,		functions have paths. If there are T traffic classes and C Tenants,
	the number of MTNC-IDs in a fully meshed network is (N*(N-1)/2) * T.		the number of MTNC-IDs in a fully meshed network is T * C. An MTNC-
	For example, if there are 3 traffic classes between 25 sites, there		ID space of 16 bits (65K identifiers) can be expected to be
	would be at most 900 MTNC-IDs required. Multiple instances/tenants
	that need to be fully isolated, will add to the MTNC provisioning.
	An MTNC-ID space of 16 bits (65K identifiers) can be expected to be
	sufficient.		sufficient.
	2.3. Transport Network Function (TNF)		2.3. Transport Network Function (TNF)
	Figure 1 shows a view of the functions and interfaces for		Figure 1 shows a view of the functions and interfaces for
	provisioning the MTNC-IDs. The focus is on provisioning between the		provisioning the MTNC-IDs. The focus is on provisioning between the
	3GPP management plane (NSSMF), transport network (SDN-C) and carrying		3GPP management plane (NSSMF), transport network (SDN-C) and carrying
	the MTNC-IDs in PDU packets for the transport network to grant the		the MTNC-IDs in PDU packets for the transport network to grant the
	provisioned resources.		provisioned resources.
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 4 ¶
	session setup. Alternatively, the user plane functions may request		session setup. Alternatively, the user plane functions may request
	the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case		the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case
	where user plane entities request the TNF/NSSMF to translate the		where user plane entities request the TNF/NSSMF to translate the
	Request and get the MTNC-ID. Another alternative is for the TNF to		Request and get the MTNC-ID. Another alternative is for the TNF to
	provide a mapping of the 3GPP Network Instance Identifier, described		provide a mapping of the 3GPP Network Instance Identifier, described
	in Section 2.6 and the MTNC-ID to the user plane entities via		in Section 2.6 and the MTNC-ID to the user plane entities via
	configuration.		configuration.
	The TNF should be seen as a logical entity that can be part of NSSMF		The TNF should be seen as a logical entity that can be part of NSSMF
	in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use		in the 3GPP management plane [TS.28.533-3GPP]. The NSSMF may use
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	network configuration, policies, history, heuristics or some		network configuration, policies, history, heuristics or some
	combination of these to derive traffic estimates that the TNF would		combination of these to derive traffic estimates that the TNF would
	use. How these estimates are derived are not in the scope of this		use. How these estimates are derived are not in the scope of this
	document. The focus here is only in terms of how the TNF and SDN-C		document. The focus here is only in terms of how the TNF and SDN-C
	are programmed given that slice and QoS characteristics across a		are programmed given that slice and QoS characteristics across a
	transport path can be represented by an MTNC-ID. The TNF requests		transport path can be represented by an MTNC-ID. The TNF requests
	the SDN-C in the transport network to provision paths in the		the SDN-C in the transport network to provision paths in the
	transport domain based on the MTNC-ID. The TNF is capable of		transport domain based on the MTNC-ID. The TNF is capable of
	providing the MTNC-ID provisioned to control and user plane functions		providing the MTNC-ID provisioned to control and user plane functions
	in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID		in the 3GPP domain. Detailed mechanisms for programming the MTNC-ID
	skipping to change at page 13, line 29 ¶		skipping to change at page 13, line 4 ¶
	instance for UEs as are the mobile operator's 'clients'. The Network		instance for UEs as are the mobile operator's 'clients'. The Network
	Slice Selection Management Function (NSSMF) [TS 28.533] that		Slice Selection Management Function (NSSMF) [TS 28.533] that
	interacts with a TN controller like an SDN-C (that is out of scope of		interacts with a TN controller like an SDN-C (that is out of scope of
	3GPP).		3GPP).
	The ACTN VN service can be used across the IP transport networks to		The ACTN VN service can be used across the IP transport networks to
	provision and map the slice instance and QoS of the 3GPP domain to		provision and map the slice instance and QoS of the 3GPP domain to
	the IP transport domain. An abstraction that represents QoS and		the IP transport domain. An abstraction that represents QoS and
	slice instances in the mobile domain and mapped to ACTN VN service in		slice instances in the mobile domain and mapped to ACTN VN service in
	the transport domain is represented here as MTNC-IDs. Details of how		the transport domain is represented here as MTNC-IDs. Details of how
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	the MTNC-IDs are derived are up to functions that can estimate the		the MTNC-IDs are derived are up to functions that can estimate the
	level of traffic demand.		level of traffic demand.
	The 3GPP network/5GS provides slices instances to its clients (UE)		The 3GPP network/5GS provides slices instances to its clients (UE)
	that include resources for radio and mobile core segments. The UE's		that include resources for radio and mobile core segments. The UE's
	PDU session spans the access network (radio) and F1-U/N3/N9 transport		PDU session spans the access network (radio) and F1-U/N3/N9 transport
	segments which have an IP transport underlay. The 5G operator needs		segments which have an IP transport underlay. The 5G operator needs
	to obtain slice capability from the IP transport provider since these		to obtain slice capability from the IP transport provider since these
	resources are not seen by the 5GS. Several UE sessions that match a		resources are not seen by the 5GS. Several UE sessions that match a
	slice may be mapped to an IP transport segment. Thus, there needs to		slice may be mapped to an IP transport segment. Thus, there needs to
	skipping to change at page 14, line 34 ¶		skipping to change at page 14, line 4 ¶
	Other IP header fields like DSCP are not suitable as it only conveys		Other IP header fields like DSCP are not suitable as it only conveys
	the QoS aspects (but not other aspects like isolation, protection,		the QoS aspects (but not other aspects like isolation, protection,
	etc.)		etc.)
	While IPv6 extension headers like SRv6 may be an option to carry the		While IPv6 extension headers like SRv6 may be an option to carry the
	MTNC-ID that requires the end-to-end network to be IPv6 as well as		MTNC-ID that requires the end-to-end network to be IPv6 as well as
	the capability to lookup the extension header at line rate. To		the capability to lookup the extension header at line rate. To
	minimise the protocol changes and make this underlay transport		minimise the protocol changes and make this underlay transport
	independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping		independent (IPv4/IPv6/MPLS/L2), an option is to provision a mapping
	of MTNC-ID to a UDP port range of the GTP encapsulated user packet.		of MTNC-ID to a UDP port range of the GTP encapsulated user packet.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	A simple mapping table between the MTNC-ID and the source UDP port		A simple mapping table between the MTNC-ID and the source UDP port
	number can be configured to ensure that ECMP /load balancing is not		number can be configured to ensure that ECMP /load balancing is not
	affected adversely by encoding the UDP source port with an MTNC-ID		affected adversely by encoding the UDP source port with an MTNC-ID
	mapping. The UDP port information containing MTNC-ID is a simple		mapping. The UDP port information containing MTNC-ID is a simple
	extension that can be provisioned in 3GPP transport end-points		extension that can be provisioned in 3GPP transport end-points
	defined in [TS.28.541-3GPP]. This mapping is configured in 3GPP user		defined in [TS.28.541-3GPP]. This mapping is configured in 3GPP user
	plane functions (5G-AN, UPF) and Provider Edge (PE) Routers that		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
	skipping to change at page 15, line 31 ¶		skipping to change at page 15, line 5 ¶
	transport network, VLAN tag may be an option to carry the MTNC-ID.		transport network, VLAN tag may be an option to carry the MTNC-ID.
	The VLAN ID provides a 12 bit space and is sufficient to support up		The VLAN ID provides a 12 bit space and is sufficient to support up
	to 4096 slices on the fronthaul transport network. The mapping of		to 4096 slices on the fronthaul transport network. The mapping of
	fronthaul traffic to corresponding network slices is based on the		fronthaul traffic to corresponding network slices is based on the
	radio resource for which the fronthaul carries the I and Q samples.		radio resource for which the fronthaul carries the I and Q samples.
	The mapping of fronthaul traffic to the VLAN tag corresponding to the		The mapping of fronthaul traffic to the VLAN tag corresponding to the
	network slice is specified in Section 2.1.2. On the UDP based		network slice is specified in Section 2.1.2. On the UDP based
	fronthaul transport network, the UDP source port can be used to carry		fronthaul transport network, the UDP source port can be used to carry
	the MTNC-ID.		the MTNC-ID.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	2.6. Functionality for E2E Management		2.6. Functionality for E2E Management
	With the TNF functionality in 5GS Service Based Interface, the		With the TNF functionality in 5GS Service Based Interface, the
	following additional functionalities are required for end-2-end slice		following additional functionalities are required for end-2-end slice
	management including the transport network:		management including the transport network:
	* The Specific Network Slice Selection Assistance Information		o The Specific Network Slice Selection Assistance Information
	(S-NSSAI) of PDU session SHOULD be mapped to the assigned		(S-NSSAI) of PDU session SHOULD be mapped to the assigned
	transport VPN and the TE path information for that slice.		transport VPN and the TE path information for that slice.
	* For transport slice assignment for various SSTs (eMBB, URLLC,		o For transport slice assignment for various SSTs (eMBB, URLLC,
	MIoT) corresponding underlay paths need to be created and		MIoT) corresponding underlay paths need to be created and
	monitored from each transport endpoint (CSR and PE@UPF).		monitored from each transport endpoint (CSR and PE@UPF).
	* During PDU session creation, apart from radio and 5GC resources,		o During PDU session creation, apart from radio and 5GC resources,
	transport network resources needed to be verified matching the		transport network resources needed to be verified matching the
	characteristics of the PDU session traffic type.		characteristics of the PDU session traffic type.
	* The TNF MUST provide an API that takes as input the source and		o The TNF MUST provide an API that takes as input the source and
	destination 3GPP user plane element address, required bandwidth,		destination 3GPP user plane element address, required bandwidth,
	latency and jitter characteristics between those user plane		latency and jitter characteristics between those user plane
	elements and returns as output a particular TE path's identifier,		elements and returns as output a particular TE path's identifier,
	that satisfies the requested requirements.		that satisfies the requested requirements.
	* 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 is to let the SMF install a Forwarding		done. One way to do this is to let the SMF install a Forwarding
	Action Rule (FAR) in the UPF via N4 with the FAR pointing to a		Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
	"Network Instance" in the UPF. A "Network Instance" is a logical		"Network Instance" in the UPF. A "Network Instance" is a logical
	identifier for an underlying network. The "Network Instance"		identifier for an underlying network. The "Network Instance"
	pointed by the FAR can be mapped to a transport path (through L2/		pointed by the FAR can be mapped to a transport path (through L2/
	L3 VPN). FARs are associated with Packet Detection Rule (PDR).		L3 VPN). FARs are associated with Packet Detection Rule (PDR).
	PDRs are used to classify packets in the uplink (UL) and the		PDRs are used to classify packets in the uplink (UL) and the
	downlink (DL) direction. For UL procedures specified in		downlink (DL) direction. For UL procedures specified in
	Section 2.4, Section 2.5 can be used for classifying a packet		Section 2.4, Section 2.5 can be used for classifying a packet
	belonging to a particular slice characteristic. For DL, at a PSA		belonging to a particular slice characteristic. For DL, at a PSA
	UPF, the UE IP address is used to identify the PDU session, and		UPF, the UE IP address is used to identify the PDU session, and
	hence the slice a packet belongs to and the IP 5 tuple can be used		hence the slice a packet belongs to and the IP 5 tuple can be used
	for identifying the flow and QoS characteristics to be applied on		for identifying the flow and QoS characteristics to be applied on
	the packet at UPF. If a PE is not co-located at the UPF then		the packet at UPF. If a PE is not co-located at the UPF then
	mapping to the underlying TE paths at PE happens based on the		mapping to the underlying TE paths at PE happens based on the
	encapsulated GTP-U packet as specified in Section 2.5.		encapsulated GTP-U packet as specified in Section 2.5.
	* In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if		o In some SSC modes [I-D.chunduri-dmm-5g-mobility-with-ppr], if
	segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-		segmented path (CSR to PE@staging/ULCL/BP-UPF to PE@anchor-point-
	UPF) is needed, then corresponding path characteristics MUST be		UPF) is needed, then corresponding path characteristics MUST be
	used. This includes a path from CSR to PE@UL-CL/BP UPF		used. This includes a path from CSR to PE@UL-CL/BP UPF
	[TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN.		[TS.23.501-3GPP] and UL-CL/BP UPF to eventual UPF access to DN.
	* Continuous monitoring of the underlying transport path		Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
			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 on traffic engineering technique used as		for monitoring depends on traffic engineering technique used as
	described in Section 3.2). If path characteristics are degraded,		described in Section 3.2). If path characteristics are degraded,
	reassignment of the paths at the endpoints should be performed.		reassignment of the paths at the endpoints should be performed.
	For all the affected PDU sessions, degraded transport paths need		For all the affected PDU sessions, degraded transport paths need
	to be updated dynamically with similar alternate paths.		to be updated dynamically with similar alternate paths.
	* During UE mobility events similar to 4G/LTE i.e., gNB mobility (F1		o During UE mobility events similar to 4G/LTE i.e., gNB mobility (F1
	based, Xn based or N2 based), for target gNB selection, apart from		based, Xn based or N2 based), for target gNB selection, apart from
	radio resources, transport resources MUST be factored. This		radio resources, transport resources MUST be factored. This
	enables handling of all PDU sessions from the UE to target gNB and		enables handling of all PDU sessions from the UE to target gNB and
	this require co-ordination of gNB, AMF, SMF with the TNF module.		this require co-ordination of gNB, AMF, SMF with the TNF module.
	Integrating the TNF as part of the 5GS Service Based Interfaces,		Integrating the TNF as part of the 5GS Service Based Interfaces,
	provides the flexibility to control the allocation of required		provides the flexibility to control the allocation of required
	characteristics from the TN during a 5GS signaling procedure (e.g.		characteristics from the TN during a 5GS signaling procedure (e.g.
	PDU Session Establishment). If TNF is seen as separate and in a		PDU Session Establishment). If TNF is seen as separate and in a
	management plane, this real time flexibility is lost. Changes to		management plane, this real time flexibility is lost. Changes to
	skipping to change at page 17, line 20 ¶		skipping to change at page 16, line 41 ¶
	Apart from the various flavors of IETF VPN technologies to share the		Apart from the various flavors of IETF VPN technologies to share the
	transport network resources and capacity, TE capabilities in the		transport network resources and capacity, TE capabilities in the
	underlay network is an essential component to realize the 5G TN		underlay network is an essential component to realize the 5G TN
	requirements. This section focuses on various transport underlay		requirements. This section focuses on various transport underlay
	technologies (not exhaustive) and their applicability to realize		technologies (not exhaustive) and their applicability to realize
	Midhaul/Backhaul transport networks. Focus is on the user/data plane		Midhaul/Backhaul transport networks. Focus is on the user/data plane
	i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.		i.e., F1-U/N3/N9 interfaces as laid out in the framework Figure 1.
	3.1. Applicability		3.1. Applicability
	* For 3 different SSTs, 3 transport TE paths can be signaled from		o For 3 different SSTs, 3 transport TE paths can be signaled from
	any node in the transport network. For Uplink traffic, the 5G-AN		any node in the transport network. For Uplink traffic, the 5G-AN
	will choose the right underlying TE path of the UPF based on the		will choose the right underlying TE path of the UPF based on the
	S-NSSAI the PDU Session belongs to and/or the UDP Source port		S-NSSAI the PDU Session belongs to and/or the UDP Source port
	(corresponds to the MTNC-ID Section 2.4) of the GTP-U		(corresponds to the MTNC-ID Section 2.4) of the GTP-U
	encapsulation header. Similarly in the Downlink direction		encapsulation header. Similarly in the Downlink direction
	matching Transport TE Path of the 5G-AN is chosen based on the		matching Transport TE Path of the 5G-AN is chosen based on the
	S-NSSAI the PDU Session belongs to. The table below shows a		S-NSSAI the PDU Session belongs to. The table below shows a
	typical mapping:		typical mapping:
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	|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 | TE-PATH-A | Bit Rate) |		| values) | (massive | TE-PATH-A | Bit Rate) |
	| | IOT) | | Bandwidth: Bx |		| | IOT) | | Bandwidth: Bx |
	| | | | Delay: Dx |		| | | | Delay: Dx |
	| | | | Jitter: Jx |		| | | | Jitter: Jx |
	skipping to change at page 18, line 28 ¶		skipping to change at page 17, line 30 ¶
	| values) | (ultra-low | TE-PATH-B | Req. |		| values) | (ultra-low | TE-PATH-B | Req. |
	| | latency) | | Bandwidth: By |		| | latency) | | Bandwidth: By |
	| | | | Delay: Dy |		| | | | Delay: Dy |
	| | | | Jitter: Jy |		| | | | Jitter: Jy |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	| Range Zx - Zy | | | |		| Range Zx - Zy | | | |
	| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |		| Z1, Z2(discrete| EMBB | PW ID/VPN info, | Non-GBR |
	| values) | (broadband)| TE-PATH-C | Bandwidth: Bx |		| values) | (broadband)| TE-PATH-C | Bandwidth: Bx |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	Figure 2: Mapping of Transport Paths on F1-U/N3/N9		Figure 2: Mapping of Transport Paths on F1-U/N3/N9
	* It is possible to have a single TE Path for multiple input points		o It is possible to have a single TE Path for multiple input points
	through a MP2P TE tree structure separate in UL and DL direction.		through a MP2P TE tree structure separate in UL and DL direction.
	* Same set of TE Paths are created uniformly across all needed 5G-		o Same set of TE Paths are created uniformly across all needed 5G-
	ANs and UPFs to allow various mobility scenarios.		ANs and UPFs to allow various mobility scenarios.
	* 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.
	* TE Paths support for native L2, IPv4 and IPv6 data/user planes		o TE Paths support for native L2, IPv4 and IPv6 data/user planes
	with optional TE features are desirable in some network segments.		with optional TE features are desirable in some network segments.
	As this is an underlay mechanism it can work with any overlay		As this is an underlay mechanism it can work with any overlay
	encapsulation approach including GTP-U as defined currently for		encapsulation approach including GTP-U as defined currently for
	F1-U/N3/N9 interface.		F1-U/N3/N9 interface.
	In some E2E scenarios, security is desired granularly in the		In some E2E scenarios, security is desired granularly in the
	underlying transport network. In such cases, there would be a need		underlying transport network. In such cases, there would be a need
	to have separate sub-ranges under each SST to provide the TE path in		to have separate sub-ranges under each SST to provide the TE path in
	preserving the security characteristics. The UDP Source Port range		preserving the security characteristics. The UDP Source Port range
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	captured in Figure 2 would be sub-divided to maintain the TE path for		captured in Figure 2 would be sub-divided to maintain the TE path for
	the current SSTs with the security. The current solution doesn't		the current SSTs with the security. The current solution doesn't
	provide any mandate on the UE traffic in selecting the type of		provide any mandate on the UE traffic in selecting the type of
	security.		security.
	3.2. Transport Network Technologies		3.2. Transport Network Technologies
	While there are many Software Defined Networking (SDN) approaches		While there are many Software Defined Networking (SDN) approaches
	available, this section is not intended to list all the possibilities		available, this section is not intended to list all the possibilities
	in this space but merely captures the technologies for various		in this space but merely captures the technologies for various
	skipping to change at page 20, line 5 ¶		skipping to change at page 19, line 5 ¶
	slices from a transport domain perspective. It does so for any		slices from a transport domain perspective. It does so for any
	underlying user/data plane used in the transport network		underlying user/data plane used in the transport network
	(L2/IPv4/IPv6/MPLS).		(L2/IPv4/IPv6/MPLS).
	As specified with the integrated transport network function (TNF), a		As specified with the integrated transport network function (TNF), a
	particular RSVP-TE path for MPLS or SR path for MPLS and IPv6 with		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-		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		ppr], can be supplied to SMF for mapping a particular PDU session to
	the transport path.		the transport path.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	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, Kausik		applicability for the proposed TNF. Thanks to Sri Gundavelli, Kausik
	Majumdar and 3GPP delegates who provided detailed feedback on this		Majumdar and 3GPP delegates who provided detailed feedback on this
	document.		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.
	skipping to change at page 20, line 49 ¶		skipping to change at page 20, line 4 ¶
	Xavier De Foy		Xavier De Foy
	InterDigital Communications, LLC		InterDigital Communications, LLC
	1000 Sherbrooke West		1000 Sherbrooke West
	Montreal		Montreal
	Canada		Canada
	Email: Xavier.Defoy@InterDigital.com		Email: Xavier.Defoy@InterDigital.com
	8. References		8. References
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	8.2. Informative References		8.2. Informative References
	[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),		[ATIS075] Alliance for Telecommunications Industry Solutions (ATIS),
	"IOT Categorization: Exploring the Need for Standardizing		"IOT Categorization: Exploring the Need for Standardizing
	Additional Network Slices ATIS-I-0000075", September 2019.		Additional Network Slices ATIS-I-0000075", September 2019.
	[I-D.bogineni-dmm-optimized-mobile-user-plane]		[I-D.bogineni-dmm-optimized-mobile-user-plane]
	Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,		Bogineni, K., Akhavain, A., Herbert, T., Farinacci, D.,
	Rodriguez-Natal, A., Carofiglio, G., Auge, J.,		Rodriguez-Natal, A., Carofiglio, G., Auge, J.,
	Muscariello, L., Camarillo, P., and S. Homma, "Optimized		Muscariello, L., Camarillo, P., and S. Homma, "Optimized
	Mobile User Plane Solutions for 5G", Work in Progress,		Mobile User Plane Solutions for 5G", draft-bogineni-dmm-
	Internet-Draft, draft-bogineni-dmm-optimized-mobile-user-		optimized-mobile-user-plane-01 (work in progress), June
	plane-01, 29 June 2018, <https://www.ietf.org/archive/id/		2018.
	draft-bogineni-dmm-optimized-mobile-user-plane-01.txt>.
	[I-D.ietf-dmm-5g-uplane-analysis]		[I-D.ietf-dmm-5g-uplane-analysis]
	Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,		Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
	"User Plane Protocol and Architectural Analysis on 3GPP 5G		"User Plane Protocol and Architectural Analysis on 3GPP 5G
	System", Work in Progress, Internet-Draft, draft-ietf-dmm-		System", draft-ietf-dmm-5g-uplane-analysis-04 (work in
	5g-uplane-analysis-04, 2 November 2020,		progress), November 2020.
	<https://www.ietf.org/archive/id/draft-ietf-dmm-5g-uplane-
	analysis-04.txt>.
	[I-D.ietf-dmm-srv6-mobile-uplane]		[I-D.ietf-dmm-srv6-mobile-uplane]
	Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,		Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
	Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for		Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
	Mobile User Plane", Work in Progress, Internet-Draft,		Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-17
	draft-ietf-dmm-srv6-mobile-uplane-16, 11 August 2021,		(work in progress), October 2021.
	<https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-
	mobile-uplane-16.txt>.
	[I-D.ietf-teas-ietf-network-slices]		[I-D.ietf-teas-ietf-network-slices]
	Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,		Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
	Makhijani, K., Contreras, L. M., and J. Tantsura,		Makhijani, K., Contreras, L. M., and J. Tantsura,
	"Framework for IETF Network Slices", Work in Progress,		"Framework for IETF Network Slices", draft-ietf-teas-ietf-
	Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23		network-slices-04 (work in progress), August 2021.
	August 2021, <https://www.ietf.org/archive/id/draft-ietf-
	teas-ietf-network-slices-04.txt>.
	[IR.34-GSMA]		[IR.34-GSMA]
	GSM Association (GSMA), "Guidelines for IPX Provider		GSM Association (GSMA), "Guidelines for IPX Provider
	Networks (Previously Inter-Service Provider IP Backbone		Networks (Previously Inter-Service Provider IP Backbone
	Guidelines, Version 14.0", August 2018.		Guidelines, Version 14.0", August 2018.
	[ORAN-WG4.CUS-O-RAN]		[ORAN-WG4.CUS-O-RAN]
	O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;		O-RAN Alliance (O-RAN), "O-RAN Fronthaul Working Group;
	Control, User and Synchronization Plane Specification;		Control, User and Synchronization Plane Specification;
	v2.0.0", August 2019.		v2.0.0", August 2019.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	[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>.
	[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>.
	skipping to change at page 23, line 10 ¶		skipping to change at page 22, line 5 ¶
	[TS.28.533-3GPP]		[TS.28.533-3GPP]
	3rd Generation Partnership Project (3GPP), "Management and		3rd Generation Partnership Project (3GPP), "Management and
	Orchestration Architecture Framework (Release 15)", June		Orchestration Architecture Framework (Release 15)", June
	2018.		2018.
	[TS.28.541-3GPP]		[TS.28.541-3GPP]
	3rd Generation Partnership Project (3GPP), "Management and		3rd Generation Partnership Project (3GPP), "Management and
	orchestration; 5G Network Resource Model (NRM); Stage 2		orchestration; 5G Network Resource Model (NRM); Stage 2
	and stage 3 (Release 17)", June 2020.		and stage 3 (Release 17)", June 2020.
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	[TS.29.281-3GPP]		[TS.29.281-3GPP]
	3rd Generation Partnership Project (3GPP), "GPRS Tunneling		3rd Generation Partnership Project (3GPP), "GPRS Tunneling
	Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",		Protocol User Plane (GTPv1-U), 3GPP TS 29.281 v15.1.0",
	December 2018.		December 2018.
	[TS.38.300-3GPP]		[TS.38.300-3GPP]
	3rd Generation Partnership Project (3GPP), "NR; NR and NG-		3rd Generation Partnership Project (3GPP), "NR; NR and NG-
	RAN Overall Description; Stage 2; v15.7.0", September		RAN Overall Description; Stage 2; v15.7.0", September
	2019.		2019.
	skipping to change at page 24, line 9 ¶		skipping to change at page 23, line 5 ¶
	CP and DU for the control plane traffic is called the F1-C. The F1-C		CP and DU for the control plane traffic is called the F1-C. The F1-C
	and the F1-U together are called the mid-haul interfaces. The DU		and the F1-U together are called the mid-haul interfaces. The DU
	does not have a CP/UP split. Apart from 3GPP, O-RAN Alliance has		does not have a CP/UP split. Apart from 3GPP, O-RAN Alliance has
	specified further disaggregation of the RAN at the lower layer		specified further disaggregation of the RAN at the lower layer
	(physical layer). The DU is disaggregated into a ORAN DU (O-DU)		(physical layer). The DU is disaggregated into a ORAN DU (O-DU)
	which runs the upper part of the physical layer, MAC and RLC and the		which runs the upper part of the physical layer, MAC and RLC and the
	ORAN Radio Unit (O-RU) which runs the lower part of the physical		ORAN Radio Unit (O-RU) which runs the lower part of the physical
	layer. The interface between the O-DU and the O-RU is called the		layer. The interface between the O-DU and the O-RU is called the
	Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN].		Fronthaul interface and is specified in [ORAN-WG4.CUS-O-RAN].
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	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
	[RFC3209] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-dmm-		[RFC3209] for both MPLS and IPv6 underlay or PPR [I-D.chunduri-dmm-
	skipping to change at page 25, line 4 ¶		skipping to change at page 24, line 4 ¶
	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.
	Authors' Addresses		Authors' Addresses
			Internet-DrafMobility aware Transport Network Slicing for 5 October 2021
	Uma Chunduri (editor)		Uma Chunduri (editor)
	Intel		Intel Corporation
	2191 Laurelwood Rd		2191 Laurelwood Rd
	Santa Clara, CA 95054		Santa Clara, CA 95054
	United States of America		USA
	Email: umac.ietf@gmail.com		Email: umac.ietf@gmail.com
	John Kaippallimalil (editor)		John Kaippallimalil (editor)
	Futurewei		Futurewei
	Email: john.kaippallimalil@futurewei.com		Email: john.kaippallimalil@futurewei.com
	Sridhar Bhaskaran		Sridhar Bhaskaran
	Altiostar		Altiostar
	skipping to change at page 25, line 30 ¶		skipping to change at page 24, line 32 ¶
	Email: sridharb@altiostar.com		Email: sridharb@altiostar.com
	Jeff Tantsura		Jeff Tantsura
	Microsoft		Microsoft
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Praveen Muley		Praveen Muley
	Nokia		Nokia
	440 North Bernardo Ave		440 North Bernardo Ave
	Mountain View, CA 94043		Mountain View, CA 94043
	United States of America		USA
	Email: praveen.muley@nokia.com		Email: praveen.muley@nokia.com
End of changes. 92 change blocks.
	141 lines changed or deleted		180 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/