< draft-clt-dmm-tn-aware-mobility-00.txt		draft-clt-dmm-tn-aware-mobility-01.txt >
	DMM Working Group U. Chunduri, Ed.		DMM Working Group U. Chunduri, Ed.
	Internet-Draft R. Li		Internet-Draft R. Li
	Intended status: Standards Track Huawei USA		Intended status: Standards Track Huawei USA
	Expires: January 16, 2019 J. Tantsura		Expires: January 17, 2019 J. Tantsura
	Nuage Networks		Nuage Networks
	July 15, 2018		L. Contreras
			Telefonica
			X. De Foy
			InterDigital Communications, LLC
			July 16, 2018
	Transport Network aware Mobility for 5G		Transport Network aware Mobility for 5G
	draft-clt-dmm-tn-aware-mobility-00		draft-clt-dmm-tn-aware-mobility-01
	Abstract		Abstract
	This document specifies a framework and a mapping function for 5G		This document specifies a framework and a mapping function for 5G
	mobile user plane with transport network slicing, integrated with		mobile user plane with transport network slicing, integrated with
	Mobile Radio Access and a Virtualized Core Network. The integrated		Mobile Radio Access and a Virtualized Core Network. The integrated
	approach specified in a way to address all the mobility scenarios		approach specified in a way to address all the mobility scenarios
	defined in [TS23.501] and to be backward compatible with LTE		defined in [TS23.501] and to be backward compatible with LTE
	[TS23.401] network deployments.		[TS.23.401-3GPP] network deployments.
	It focuses on an optimized mobile user plane functionality with		It focuses on an optimized mobile user plane functionality with
	various transport services needed for some of the 5G traffic needing		various transport services needed for some of the 5G traffic needing
	low and deterministic latency, real-time, mission-critical services.		low and deterministic latency, real-time, mission-critical services.
	This document describes, how this objective is achieved agnostic to		This document describes, how this objective is achieved agnostic to
	the transport underlay used (IPv4, IPv6, MPLS) in various deployments		the transport underlay used (IPv4, IPv6, MPLS) in various deployments
	and with a new transport network underlay routing, called Preferred		and with a new transport network underlay routing, called Preferred
	Path Routing (PPR).		Path Routing (PPR).
	Requirements Language		Requirements Language
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 9 ¶
	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 January 16, 2019.
			This Internet-Draft will expire on January 17, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Problem Statement . . . . . . . . . . . . . 3		1. Introduction and Problem Statement . . . . . . . . . . . . . 3
	1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 4		1.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 5
	2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5		2. Transport Network (TN) and Slice aware Mobility on N3/N9 . . 5
	2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6		2.1. Discrete Approach . . . . . . . . . . . . . . . . . . . . 6
	2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7		2.2. Integrated Approach . . . . . . . . . . . . . . . . . . . 7
	3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9		3. Using PPR as TN Underlay . . . . . . . . . . . . . . . . . . 9
	3.1. PPR with Transport Slicing aware Mobility on N3/N9 . . . 9		3.1. PPR with Transport Slicing aware Mobility on N3/N9 . . . 9
	3.2. Path Steering Support to native IP user planes . . . . . 11		3.2. Path Steering Support to native IP user planes . . . . . 11
	3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 11		3.3. Service Level Guarantee in Underlay . . . . . . . . . . . 11
	3.4. PPR with various 5G Mobility procedures . . . . . . . . . 11		3.4. PPR with various 5G Mobility procedures . . . . . . . . . 11
	3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 11		3.4.1. SSC Mode1 . . . . . . . . . . . . . . . . . . . . . . 12
	3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 12		3.4.2. SSC Mode2 . . . . . . . . . . . . . . . . . . . . . . 13
	3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 13		3.4.3. SSC Mode3 . . . . . . . . . . . . . . . . . . . . . . 13
	4. Other TE Technologies Applicability . . . . . . . . . . . . . 14		4. Other TE Technologies Applicability . . . . . . . . . . . . . 14
	5. New Control Plane and User Planes . . . . . . . . . . . . . . 14		5. New Control Plane and User Planes . . . . . . . . . . . . . . 15
	5.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 14		5.1. LISP and PPR . . . . . . . . . . . . . . . . . . . . . . 15
	5.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. ILA and PPR . . . . . . . . . . . . . . . . . . . . . . . 15
	6. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15		6. Summary and Benefits with PPR . . . . . . . . . . . . . . . . 15
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 16		9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction and Problem Statement		1. Introduction and Problem Statement
	3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP],		3GPP Release 15 for 5GC is defined in [TS.23.501-3GPP],
	[TS.23.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9		[TS.23.502-3GPP], [TS.23.503-3GPP]. A new user plane interface N9
	[TS.23.501-3GPP] has been created between 2 User Plane		[TS.23.501-3GPP] has been created between 2 User Plane
	Functionalities (UPFs). While user plane for N9 interface being		Functionalities (UPFs). While user plane for N9 interface being
	finalized for REL16, both GTP-U based encapsulation or any other		finalized for REL16, both GTP-U based encapsulation or any other
	compatible approach is being considered [CT4SID]. Concerning to this		compatible approach is being considered [CT4SID]. Concerning to this
	document another relevant interface is N3, which is between gNB and		document another relevant interface is N3, which is between gNB and
	the UPF. N3 interface is similar to the user plane interface S1U in		the UPF. N3 interface is similar to the user plane interface S1U in
	LTE [TS 23.401]. This document:		LTE [TS.23.401-3GPP]. This document:
	o does not propose any change to existing N3 user plane		o does not propose any change to existing N3 user plane
	encapsulations to realize the benefits with the approach specified		encapsulations to realize the benefits with the approach specified
	here		here
	o and can work with any encapsulation (including GTP-U) for the N9		o and can work with any encapsulation (including GTP-U) for the N9
	interface.		interface.
	[TS.23.501-3GPP] defines various Session and Service Continuity (SSC)		[TS.23.501-3GPP] defines various Session and Service Continuity (SSC)
	modes and mobility scenarios for 5G with slice awareness from Radio		modes and mobility scenarios for 5G with slice awareness from Radio
	skipping to change at page 3, line 50 ¶		skipping to change at page 4, line 4 ¶
	5QI - 5G QoS Indicator		5QI - 5G QoS Indicator
	AMF - Access and Mobility Management Function (5G)		AMF - Access and Mobility Management Function (5G)
	BP - Branch Point (5G)		BP - Branch Point (5G)
	CSR - Cell Site Router		CSR - Cell Site Router
	DN - Data Network (5G)		DN - Data Network (5G)
			eMBB - enhanced Mobile Broadband (5G)
	FRR - Fast ReRoute		FRR - Fast ReRoute
	gNB - 5G NodeB		gNB - 5G NodeB
	GBR - Guaranteed Bit Rate (5G)		GBR - Guaranteed Bit Rate (5G)
	IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)		IGP - Interior Gateway Protocols (e.g. IS-IS, OSPFv2, OSPFv3)
			LFA - Loop Free Alternatives (IP FRR)
			mIOT - Massive IOT (5G)
	MPLS - Multi Protocol Label Switching		MPLS - Multi Protocol Label Switching
	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
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 48 ¶
	SST - Slice and Service Types (5G)		SST - Slice and Service Types (5G)
	SR - Segment Routing		SR - Segment Routing
	TE - Traffic Engineering		TE - Traffic Engineering
	ULCL - Uplink Classifier (5G)		ULCL - Uplink Classifier (5G)
	UPF - User Plane Function (5G)		UPF - User Plane Function (5G)
			URLLC - Ultra reliable and low latency communications (5G)
	1.2. Solution Approach		1.2. Solution Approach
	This document specifies a mechanism to fulfil the needs of 5GS to		This document specifies a mechanism to fulfil the needs of 5GS to
	transport user plane traffic from gNB to UPF for all service		transport user plane traffic from gNB to UPF for all service
	continuity modes [TS.23.501-3GPP] in an optimized fashion. This is		continuity modes [TS.23.501-3GPP] in an optimized fashion. This is
	done by, keeping mobility procedures aware of underlying transport		done by, keeping mobility procedures aware of underlying transport
	network along with slicing requirements. TN with mobility awareness		network along with slicing requirements. TN with mobility awareness
	described here in a way, which does not erase performance and latency		described here in a way, which does not erase performance and latency
	gains made with 5G New Radio(5GNR) and virtualized cellular core		gains made with 5G New Radio(5GNR) and virtualized cellular core
	network features developed in [TS.23.501-3GPP].		network features developed in [TS.23.501-3GPP].
	Section 2 describes two methods, with which Transport Network (TN)		Section 2 describes two methods, with which Transport Network (TN)
	aware mobility can be built irrespective of underlying TN technology		aware mobility can be built irrespective of underlying TN technology
	used. Using Preferred Path Routing (PPR) as TN Underlay is detailed		used. Using Preferred Path Routing (PPR) as TN Underlay is detailed
	in Section 3. Section 3.4 further describes the applicability and		in Section 3. Section 3.4 further describes the applicability and
	procedures of the same with 5G SSC modes on N3 and N9 interfaces.		procedures of the same with 5G SSC modes on N3 and N9 interfaces. At
			the end, Section 6 recapitulates the benefits of specified approach
	Applicability of the TN aware mobility for other IETF Technologies		in mobile networks.
	are specified in Section 4. At the end, Section 6 recapitulates the
	benefits of specified approach in mobile networks.
	2. Transport Network (TN) and Slice aware Mobility on N3/N9		2. Transport Network (TN) and Slice aware Mobility on N3/N9
	Service Based Interfaces (SBI)		Service Based Interfaces (SBI)
	----+-----+-----+----+----+-----+----+--------+-----+----+------		----+-----+-----+----+----+-----+----+--------+-----+----+------
	| | | | | | | | | |		| | | | | | | | | |
	+---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+		+---+---+ | +--+--+ | +--+---+ | +--+--+ +--+--+ | +-+--+
	| NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF |		| NSSF | | | NRF | | | AUSF | | | UDM | | NEF | | | AF |
	+-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+		+-------+ | +-----+ | +------+ | +-----+ +-----+ | +----+
	+---+----+ +--+--+ +---=++ +--------------+-+		+---+----+ +--+--+ +---=++ +--------------+-+
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 19 ¶
	Currently specified Control Plane (CP) functions Access and Mobility		Currently specified Control Plane (CP) functions Access and Mobility
	Management Function (AMF), Session Management Function (SMF) and User		Management Function (AMF), Session Management Function (SMF) and User
	plane (UP) components gNodeB (gNB), User Plane Function (UPF) with		plane (UP) components gNodeB (gNB), User Plane Function (UPF) with
	N2, N3, N4, N6 and N9 are relevant to this document. Other		N2, N3, N4, N6 and N9 are relevant to this document. Other
	Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM,		Virtualized 5G control plane components NRF, AUSF, PCF, AUSF, UDM,
	NEF, and AF are not directly relevant for the discussion in this		NEF, and AF are not directly relevant for the discussion in this
	document and one can see the functionalities of these in		document and one can see the functionalities of these in
	[TS.23.501-3GPP].		[TS.23.501-3GPP].
	N3 interface is similar to S1U in 4G/LTE [TS23.401] network and uses		N3 interface is similar to S1U in 4G/LTE [TS.23.401-3GPP] network and
	GTP-U [TS.29.281-3GPP] encapsulation to transport any UE PDUs (IPv4,		uses GTP-U [TS.29.281-3GPP] encapsulation to transport any UE PDUs
	IPv6, IPv4v6, Ethernet or Unstructured). N9 interface is a new		(IPv4, IPv6, IPv4v6, Ethernet or Unstructured). N9 interface is a
	interface to connect UPFs in SSC Mode3 Section 3.4.3 and right user		new interface to connect UPFs in SSC Mode3 Section 3.4.3 and right
	plane protocol/encapsulation is being studied through 3GPP CT4 WG		user plane protocol/encapsulation is being studied through 3GPP CT4
	approved study item [CT4SID] for REL-16.		WG approved study item [CT4SID] for REL-16.
	TN Aware Mobility with optimized transport network functionality		TN Aware Mobility with optimized transport network functionality is
	is explained in the below section. How PPR fits in this framework		explained below. How PPR fits in this framework in detail along with
	in detail along with other various TE technologies briefly are		other various TE technologies briefly are in Section 3 and Section 4
	in Section 3 and Section 4 respectively.		respectively.
	2.1. Discrete Approach		2.1. Discrete Approach
	In this approach transport network functionality from gNB to UPF is		In this approach transport network functionality from gNB to UPF is
	discrete and 5GS is not aware of the underlying transport network and		discrete and 5GS is not aware of the underlying transport network and
	the resources available. Deployment specific mapping function is		the resources available. Deployment specific mapping function is
	used to map the GTP-U encapsulated traffic at gNB at UL and UPF in DL		used to map the GTP-U encapsulated traffic at gNB at UL and UPF in DL
	direction to the appropriate transport slice or transport Traffic		direction to the appropriate transport slice or transport Traffic
	Engineered (TE) paths. These TE paths can be established using RSVP-		Engineered (TE) paths. These TE paths can be established using RSVP-
	TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing]		TE [RFC3209] for MPLS underlay, SR [I-D.ietf-spring-segment-routing]
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 8 ¶
	Unstructured) independent of the underlying transport or user plane		Unstructured) independent of the underlying transport or user plane
	(IPv4, IPv6 or MPLS) network. Mapping of the PDU sessions to TE		(IPv4, IPv6 or MPLS) network. Mapping of the PDU sessions to TE
	paths can be done based on the source UDP port ranges (if these are		paths can be done based on the source UDP port ranges (if these are
	assigned based on the PDU session QCIs, as done in some deployments		assigned based on the PDU session QCIs, as done in some deployments
	with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or		with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or
	RQI values in the GTP-U header. Here, TNF as shown in Figure 1 need		RQI values in the GTP-U header. Here, TNF as shown in Figure 1 need
	not be part of the 5G Service Based Interface (SBI). Only management		not be part of the 5G Service Based Interface (SBI). Only management
	plane functionality is needed to create, monitor, manage and delete		plane functionality is needed to create, monitor, manage and delete
	(life cycle management) the transport TE paths/transport slices from		(life cycle management) the transport TE paths/transport slices from
	gNB to UPF (on N3/N9 interfaces). This approach provide partial		gNB to UPF (on N3/N9 interfaces). This approach provide partial
	inetgration of the transport network into 5GS with some benefits.		integration of the transport network into 5GS with some benefits.
	One of the limitations of this approach is the inability of 5GS		One of the limitations of this approach is the inability of 5GS
	procedures to know, if underlying transport resources are available		procedures to know, if underlying transport resources are available
	for the traffic type being carried in PDU session before making		for the traffic type being carried in PDU session before making
	certain decisions in the 5G CP. One example scenario/decision could		certain decisions in the 5G CP. One example scenario/decision could
	be, a target gNB selection in Xn mobility in SSC Mode1, without		be, a target gNB selection in Xn mobility in SSC Mode1, without
	knowing if the target gNB is having a underlay transport slice		knowing if the target gNB is having a underlay transport slice
	resource for the 5QI of the PDU session. The below approach can		resource for the 5QI of the PDU session. The below approach can
	mitigate this.		mitigate this.
	skipping to change at page 9, line 20 ¶		skipping to change at page 9, line 22 ¶
	In a network implementing source routing, packets may be transported		In a network implementing source routing, packets may be transported
	through the use of Segment Identifiers (SIDs), where a SID uniquely		through the use of Segment Identifiers (SIDs), where a SID uniquely
	identifies a segment as defined in [I-D.ietf-spring-segment-routing].		identifies a segment as defined in [I-D.ietf-spring-segment-routing].
	Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out		Section 5.3 [I-D.bogineni-dmm-optimized-mobile-user-plane] lays out
	all SRv6 features along with a few concerns in Section 5.3.7 of the		all SRv6 features along with a few concerns in Section 5.3.7 of the
	same document. Those concerns are addressed by a new backhaul		same document. Those concerns are addressed by a new backhaul
	routing mechanism called Preferred Path Routing (PPR), of which this		routing mechanism called Preferred Path Routing (PPR), of which this
	Section provides an overview.		Section provides an overview.
	Like SR, PPR uses the concept of identifiers that can be computed by		The label/PPR-ID refer not to individual segments of which the path
	a controller to create an end to end path. However, unlike SR, the
	labels refer not to Segment Identifiers of segments of which the path
	is composed, but to the identifier of a path that is deployed on		is composed, but to the identifier of a path that is deployed on
	network nodes. The fact that paths and path identifiers can be		network nodes. The fact that paths and path identifiers can be
	computed and controlled by a controller, not a routing protocol,		computed and controlled by a controller, not a routing protocol,
	allows the deployment of any path that network operators prefer, not		allows the deployment of any path that network operators prefer, not
	just shortest paths. As packets refer to a path towards a given		just shortest paths. As packets refer to a path towards a given
	destination and nodes make their forwarding decision based on the		destination and nodes make their forwarding decision based on the
	identifier of a path, not the identifier of a next segment node, it		identifier of a path, not the identifier of a next segment node, it
	is no longer necessary to carry a sequence of labels. This results		is no longer necessary to carry a sequence of labels. This results
	in multiple benefits including significant reduction in network layer		in multiple benefits including significant reduction in network layer
	overhead, increased performance and hardware compatibility for		overhead, increased performance and hardware compatibility for
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 12 ¶
	additional overhead to the user plane, unlike SR-MPLS or SRv6. This		additional overhead to the user plane, unlike SR-MPLS or SRv6. This
	is achieved by:		is achieved by:
	o For 3 different SSTs, 3 PPR-IDs can signaled from any node in the		o For 3 different SSTs, 3 PPR-IDs can signaled from any node in the
	transport network. For Uplink traffic, gNB will choose the right		transport network. For Uplink traffic, gNB will choose the right
	PPR-ID of the UPF based on the 5QI value in the encapsulation		PPR-ID of the UPF based on the 5QI value in the encapsulation
	header of the PDU session. Similarly in the Downlink direction		header of the PDU session. Similarly in the Downlink direction
	matching PPR-ID of the gNB is chosen for the RQI value in the		matching PPR-ID of the gNB is chosen for the RQI value in the
	encapsulated SL payload. The table below shows a typical mapping:		encapsulated SL payload. The table below shows a typical mapping:
	+--------------------------------------------------------------+		+----------------+------------+------------------+-----------------+
	| 5QI (Ranges)/ SST Transport Path Transport Path |		| 5QI (Ranges)/ | SST | Transport Path | Transport Path |
	| RQI (Ranges) Info Characteristics |		| RQI (Ranges) | | 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) PPR-ID-A Bit Rate) |		| values) | (massive | PPR-ID-A | Bit Rate) |
	| 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) PPR-ID-B Req. |		| values) | (ultra-low | PPR-ID-B | Req. |
	| 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) PPR-ID-C Bandwidth: Bx |		| values) | (broadband)| PPR-ID-C | Bandwidth: Bx |
	+--------------------------------------------------------------+		+----------------+------------+------------------+-----------------+
	Figure 2: 5QI/RQI Mapping with PPR-IDs on N3/N9		Figure 2: 5QI/RQI Mapping with PPR-IDs on N3/N9
	o It is possible to have a single PPR-ID for multiple input points		o It is possible to have a single PPR-ID for multiple input points
	through a PPR tree structure separate in UL and DL direction.		through a PPR tree structure separate in UL and DL direction.
	o Same set of PPRs are created uniformly across all needed gNBs and		o Same set of PPRs are created uniformly across all needed gNBs and
	UPFs to allow various mobility scenarios.		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
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 15 ¶
	encapsulation approach including GTP-U as defined currently for N3		encapsulation approach including GTP-U as defined currently for N3
	interface.		interface.
	3.2. Path Steering Support to native IP user planes		3.2. Path Steering Support to native IP user planes
	PPR works in fully compatible way with SR defined user planes (SR-		PPR works in fully compatible way with SR defined user planes (SR-
	MPLS and SRv6) by reducing the path overhead and other challenges as		MPLS and SRv6) by reducing the path overhead and other challenges as
	listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or		listed in [I-D.chunduri-lsr-isis-preferred-path-routing] or
	Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR		Section 5.3.7 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR
	also expands the source routing to user planes beyond SR-MPLS and		also expands the source routing to user planes beyond SR-MPLS and
	SRv6 i.e., native IPv6 and IPv4 user planes. This helps legacy		SRv6 i.e., native IPv6 and IPv4 user planes.
	transport networks to get the immediate path steering benefits and
	helps in overall migration strategy of the network to the desired		This helps legacy transport networks to get the immediate path
	user plane. It is important to note, these benefits can be realized		steering benefits and helps in overall migration strategy of the
	with no hardware upgrade except control plane software for native		network to the desired user plane. It is important to note, these
	IPv6 and IPv4 user planes.		benefits can be realized with no hardware upgrade except control
			plane software for native IPv6 and IPv4 user planes.
	3.3. Service Level Guarantee in Underlay		3.3. Service Level Guarantee in Underlay
	PPR also optionally allows to allocate resources that are to be		PPR also optionally allows to allocate resources that are to be
	reserved along the preferred path. These resources are required in		reserved along the preferred path. These resources are required in
	some cases (for some 5G SSTs with stringent GBR and latency		some cases (for some 5G SSTs with stringent GBR and latency
	requirements) not only for providing committed bandwidth or		requirements) not only for providing committed bandwidth or
	deterministic latency, but also for assuring overall service level		deterministic latency, but also for assuring overall service level
	guarantee in the network. This approach does not require per-hop		guarantee in the network. This approach does not require per-hop
	provisioning and reduces the OPEX by minimizing the number of		provisioning and reduces the OPEX by minimizing the number of
	skipping to change at page 15, line 43 ¶		skipping to change at page 16, line 4 ¶
	This also describes PPR		This also describes PPR
	[I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay		[I-D.chunduri-lsr-isis-preferred-path-routing], a transport underlay
	routing mechanism, which helps with goal of optimized user plane for		routing mechanism, which helps with goal of optimized user plane for
	N9 interface. PPR provides a method for N3 and N9 interfaces to		N9 interface. PPR provides a method for N3 and N9 interfaces to
	support transport slicing in a way which does not erase the gains		support transport slicing in a way which does not erase the gains
	made with 5GNR and virtualized cellular core network features for		made with 5GNR and virtualized cellular core network features for
	various types of 5G traffic (e.g. needing low and deterministic		various types of 5G traffic (e.g. needing low and deterministic
	latency, real-time, mission-critical or AR/VR traffic). PPR provides		latency, real-time, mission-critical or AR/VR traffic). PPR provides
	path steering, optionally guaranteed services with TE, unique Fast-		path steering, optionally guaranteed services with TE, unique Fast-
	ReRoute (FRR) mechanism beyond shortest path backups in the backhaul		ReRoute (FRR) mechanism with preferred backups (beyond shortest path
	network with any underlay being used in the operator's network (IPv4,		backups through existing LFA schemes) in the mobile backhaul network
	IPv6 or MPLS) in an optimized fashion.		with any underlay being used in the operator's network (IPv4, IPv6 or
			MPLS) in an optimized fashion.
	7. Acknowledgements		7. Acknowledgements
	TBD.		TBD.
	8. IANA Considerations		8. IANA Considerations
	This document has no requests for any IANA code point allocations.		This document has no requests for any IANA code point allocations.
	9. Security Considerations		9. Security Considerations
	skipping to change at page 16, line 28 ¶		skipping to change at page 16, line 32 ¶
	10.1. Normative References		10.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>.
	10.2. Informative References		10.2. Informative References
			[I-D.bashandy-rtgwg-segment-routing-ti-lfa]
			Bashandy, A., Filsfils, C., Decraene, B., Litkowski, S.,
			Francois, P., and d. daniel.voyer@bell.ca, "Topology
			Independent Fast Reroute using Segment Routing", draft-
			bashandy-rtgwg-segment-routing-ti-lfa-04 (work in
			progress), April 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]		[I-D.chunduri-lsr-isis-preferred-path-routing]
	Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,		Chunduri, U., Li, R., White, R., Tantsura, J., Contreras,
	skipping to change at page 18, line 5 ¶		skipping to change at page 17, line 48 ¶
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The		[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830,		Locator/ID Separation Protocol (LISP)", RFC 6830,
	DOI 10.17487/RFC6830, January 2013,		DOI 10.17487/RFC6830, January 2013,
	<https://www.rfc-editor.org/info/rfc6830>.		<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		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
	S. Ray, "North-Bound Distribution of Link-State and		S. Ray, "North-Bound Distribution of Link-State and
	Traffic Engineering (TE) Information Using BGP", RFC 7752,		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	DOI 10.17487/RFC7752, March 2016,		DOI 10.17487/RFC7752, March 2016,
	<https://www.rfc-editor.org/info/rfc7752>.		<https://www.rfc-editor.org/info/rfc7752>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<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>.
			[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 line 826 ¶		skipping to change at page 19, line 19 ¶
	Email: renwei.li@huawei.com		Email: renwei.li@huawei.com
	Jeff Tantsura		Jeff Tantsura
	Nuage Networks		Nuage Networks
	755 Ravendale Drive		755 Ravendale Drive
	Mountain View, CA 94043		Mountain View, CA 94043
	USA		USA
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
			Luis M. Contreras
			Telefonica
			Sur-3 building, 3rd floor
			Madrid 28050
			Spain
			Email: luismiguel.contrerasmurillo@telefonica.com
			Xavier De Foy
			InterDigital Communications, LLC
			1000 Sherbrooke West
			Montreal
			Canada
			Email: Xavier.Defoy@InterDigital.com
End of changes. 25 change blocks.
	61 lines changed or deleted		88 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/