< draft-clt-dmm-tn-aware-mobility-06.txt		draft-clt-dmm-tn-aware-mobility-07.txt >
	DMM Working Group U. Chunduri, Ed.		DMM Working Group U. Chunduri, Ed.
	Internet-Draft R. Li		Internet-Draft R. Li
	Intended status: Informational Futurewei		Intended status: Informational Futurewei
	Expires: September 10, 2020 S. Bhaskaran		Expires: April 1, 2021 S. Bhaskaran
	Altiostar		Altiostar
	J. Kaippallimalil, Ed.		J. Kaippallimalil, Ed.
	Futurewei		Futurewei
	J. Tantsura		J. Tantsura
	Apstra, Inc.		Apstra, Inc.
	L. Contreras		L. Contreras
	Telefonica		Telefonica
	P. Muley		P. Muley
	Nokia		Nokia
	March 9, 2020		September 28, 2020
	Transport Network aware Mobility for 5G		Transport Network aware Mobility for 5G
	draft-clt-dmm-tn-aware-mobility-06		draft-clt-dmm-tn-aware-mobility-07
	Abstract		Abstract
	This document specifies a framework and mapping from slices in 5G		This document specifies a framework and mapping from slices in 5G
	mobile systems to transport slices in IP and Layer 2 transport		mobile systems to transport slices in IP and Layer 2 transport
	networks. Slices in 5G systems are characterized by latency bounds,		networks. Slices in 5G systems are characterized by latency bounds,
	reservation guarantees, jitter, data rates, availability, mobility		reservation guarantees, jitter, data rates, availability, mobility
	speed, usage density, criticality and priority should be mapped to		speed, usage density, criticality and priority should be mapped to
	transport slice characteristics that include bandwidth, latency and		transport slice characteristics that include bandwidth, latency and
	criteria such as isolation, directionality and disjoint routes.		criteria such as isolation, directionality and disjoint routes.
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 10, 2020.		This Internet-Draft will expire on April 1, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	policy among others. These network functions (NF) are defined using		policy among others. These network functions (NF) are defined using
	a service-based architecture (SBA) that allows NFs to expose their		a service-based architecture (SBA) that allows NFs to expose their
	functions via an API and common service framework.		functions via an API and common service framework.
	UPFs are the data forwarding entities in the 5GC architecture. The		UPFs are the data forwarding entities in the 5GC architecture. The
	architecture allows the placement of Branching Point (BP) and Uplink		architecture allows the placement of Branching Point (BP) and Uplink
	Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-		Classifier (ULCL) UPFs closer to the access network (5G-AN). The 5G-
	AN can be a radio access network or any non-3GPP access network, for		AN can be a radio access network or any non-3GPP access network, for
	example, WLAN. The IP address is anchored by a PDU session anchor		example, WLAN. The IP address is anchored by a PDU session anchor
	UPF (PSA UPF). 3GPP slicing and RAN aspects are further described in		UPF (PSA UPF). 3GPP slicing and RAN aspects are further described in
	(Appendix A.1).		Appendix A.1.
	5GS allows more than one UPF on the path for a PDU (Protocol Data		5GS allows more than one UPF on the path for a PDU (Protocol Data
	Unit) session that provides various functionality including session		Unit) session that provides various functionality including session
	anchoring, uplink classification and branching point for a multihomed		anchoring, uplink classification and branching point for a multihomed
	IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA		IPv6 PDU session. The interface between the BP/ULCL UPF and the PSA
	UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9		UPF is called N9 [TS.23.501-3GPP]. 3GPP has adopted GTP-U for the N9
	and N3 interface between the various UPF instances and the (R)AN and		and N3 interface between the various UPF instances and the (R)AN and
	also for the F1-U interface between the DU and the CU in the RAN.		also for the F1-U interface between the DU and the CU in the RAN.
	3GPP has specified control and user plane aspects in [TS.23.501-3GPP]		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		to provide slice and QoS support. 3GPP has defined three broad slice
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	the IP transport.		the IP transport.
	1.2. Solution Approach		1.2. Solution Approach
	This document specifies an approach to fulfil the needs of 5GS to		This document specifies an approach to fulfil the needs of 5GS to
	transport user plane traffic from 5G-AN to UPF for all service		transport user plane traffic from 5G-AN to UPF 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 establishment and mobility procedures aware of		done by, keeping establishment and mobility procedures aware of
	underlying transport network along with slicing requirements.		underlying transport network along 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. Using Preferred Path		irrespective of underlying TN technology used. Using Preferred Path
	Routing (PPR), applicable to any transport network underlay (IPv6,		Routing (PPR), applicable to any transport network underlay (IPv6,
	MPLS and IPv4) is detailed in (Section 3.1). How other IETF TE		MPLS and IPv4) is detailed in Section 3.1. How other IETF TE
	technologies applicable for this draft is specified in (Section 3.2).		technologies applicable for this draft is specified in Section 3.2.
	At the end, (Appendix B) further describes the applicability and		At the end, Appendix B further describes the applicability and
	procedures of PPR with 5G SSC modes on F1-U, N3 and N9 interfaces.		procedures of PPR with 5G SSC modes on F1-U, N3 and N9 interfaces.
	1.3. Acronyms		1.3. Acronyms
	5QI - 5G QoS Indicator		5QI - 5G QoS Indicator
	5G-AN - 5G Access Network		5G-AN - 5G Access Network
	AMF - Access and Mobility Management Function (5G)		AMF - Access and Mobility Management Function (5G)
	skipping to change at page 7, line 5 ¶		skipping to change at page 7, line 5 ¶
	support specific characteristics in backhaul (N3, N9), mid-haul (F1)		support specific characteristics in backhaul (N3, N9), mid-haul (F1)
	and front haul, it is necessary to map and provision corresponding		and front haul, it is necessary to map and provision corresponding
	resources in the transport domain. This section describes how to		resources in the transport domain. This section describes how to
	provision the mapping information in transport network and apply it		provision the mapping information in transport network and apply it
	so that user plane packets can be provided the transport resources		so that user plane packets can be provided the transport resources
	(QoS, isolation, protection, etc.) expected by the 5GS slices.		(QoS, isolation, protection, etc.) expected by the 5GS slices.
	TN Aware Mobility with optimized transport network functionality is		TN Aware Mobility with optimized transport network functionality is
	explained below. How an underlay agnostic routing technology fits in		explained below. How an underlay agnostic routing technology fits in
	this framework in detail along with other various TE technologies		this framework in detail along with other various TE technologies
	briefly are in (Section 3.1) and (Section 3.2) respectively.		briefly are in Section 3.1 and Section 3.2 respectively.
	5G Control and Management Planes		5G Control and Management Planes
	+------------------------------------------------------------------------+		+------------------------------------------------------------------------+
	| +--------------------------------------------------------------------+ |		| +--------------------------------------------------------------------+ |
	| | (TNF) 5G Management Plane (TNF) | |		| | (TNF) 5G Management Plane (TNF) | |
	| +----+-----------------+-------------+---------------+-----------+---+ |		| +----+-----------------+-------------+---------------+-----------+---+ |
	| | | | | | |		| | | | | | |
	| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |		| +----+-----+ | F1-C +----+-----+ | N2 +----+---+ |
	| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |		| | |----------(---------|gNB-CU(CP)|--------(-------| 5GC CP | |
	| | | | +----+-----+ | +----+---+ |		| | | | +----+-----+ | +----+---+ |
	skipping to change at page 8, line 49 ¶		skipping to change at page 8, line 49 ¶
	front haul described further in Section 2.2, an Ethernet transport		front haul described further in Section 2.2, an Ethernet transport
	with VLANs can be expected to be the case in many deployments.		with VLANs can be expected to be the case in many deployments.
	Figure 1 also depicts the PE router, where transport paths are		Figure 1 also depicts the PE router, where transport paths are
	initiated/terminated can be deployed separately with UPF or both		initiated/terminated can be deployed separately with UPF or both
	functionalities can be in the same node. The TNF provisions this in		functionalities can be in the same node. The TNF provisions this in
	the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP		the SDN-C of the IP XHaul network using ACTN [RFC8453]. When a GTP
	encapsulated user packet from the (R)AN (gNB) or UPF with the slice		encapsulated user packet from the (R)AN (gNB) or UPF with the slice
	information traverses the F1U/N3/N9 segment, the PE router of the IP		information traverses the F1U/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		provisioned capabilities. This is elaborated further in Section 2.5.
	(Section 2.5).
	2.2. Front Haul Transport Network		2.2. Front Haul Transport Network
	The O-RAN Alliance has specified the fronthaul interface between the		The O-RAN Alliance has specified the fronthaul interface between the
	O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer		O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer
	information, in the form of In-phase (I) and Quadrature (Q) samples		information, in the form of In-phase (I) and Quadrature (Q) samples
	are transported using Enhanced Common Public Radio Interface (eCPRI)		are transported using Enhanced Common Public Radio Interface (eCPRI)
	framing over Ethernet or UDP. On the Ethernet based fronthaul		framing over Ethernet or UDP. On the Ethernet based fronthaul
	interface, the slice information is carried in the Ethernet header		interface, the slice information is carried in the Ethernet header
	through the VLAN tags. The Ethernet switches in the fronthaul		through the VLAN tags. The Ethernet switches in the fronthaul
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	the control plane and user plane functions are for 3GPP to specify.		the control plane and user plane functions are for 3GPP to specify.
	Two possible options are outlined below for completeness. The NSSMF		Two possible options are outlined below for completeness. The NSSMF
	may provide the MTNC-IDs to the 3GPP control plane by either		may provide the MTNC-IDs to the 3GPP control plane by either
	providing it to the Session Management Function (SMF), and the SMF in		providing it to the Session Management Function (SMF), and the SMF in
	turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU		turn provisions the user plane functions (UP-NF1, UP-NF2) during PDU
	session setup. Alternatively, the user plane functions may request		session setup. Alternatively, the user plane functions may request
	the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case		the MTNC-IDs directly from the TNF/NSSMF. Figure 1 shows the case
	where user plane entities request the TNF/NSSMF to translate the		where user plane entities request the TNF/NSSMF to translate the
	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.7) and the MTNC-ID to the user plane entities via		in Section 2.7 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
	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
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	Functionality of transport provisioning for an engineered IP		Functionality of transport provisioning for an engineered IP
	transport that supports 3GPP slicing and QoS requirements in		transport that supports 3GPP slicing and QoS requirements in
	[TS.23.501-3GPP] is described in this section.		[TS.23.501-3GPP] is described in this section.
	During a PDU session setup, the AMF using input from the NSSF selects		During a PDU session setup, the AMF using input from the NSSF selects
	a network slice and SMF. The SMF with user policy from Policy		a network slice and SMF. The SMF with user policy from Policy
	Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the		Control Function (PCF) sets 5QI (QoS parameters) and the UPF on the
	path of the PDU session. While QoS and slice selection for the PDU		path of the PDU session. While QoS and slice selection for the PDU
	session can be applied across the 3GPP control and user plane		session can be applied across the 3GPP control and user plane
	functions as outlined in (Section 2), the IP transport underlay		functions as outlined in Section 2, the IP transport underlay across
	across F1-U, N3 and N9 segments do not have enough information to		F1-U, N3 and N9 segments do not have enough information to apply the
	apply the resource constraints represented by the slicing and QoS		resource constraints represented by the slicing and QoS
	classification. Current guidelines for interconnection with		classification. Current guidelines for interconnection with
	transport networks [IR.34-GSMA] provide an application mapping into		transport networks [IR.34-GSMA] provide an application mapping into
	DSCP. However, these recommendations do not take into consideration		DSCP. However, these recommendations do not take into consideration
	other aspects in slicing like isolation, protection and replication.		other aspects in slicing like isolation, protection and replication.
	IP transport networks have their own slice and QoS configuration		IP transport networks have their own slice and QoS configuration
	based on domain policies and the underlying network capability.		based on domain policies and the underlying network capability.
	Transport networks can enter into an agreement for virtual network		Transport networks can enter into an agreement for virtual network
	services (VNS) with client domains using the ACTN [RFC8453]		services (VNS) with client domains using the ACTN [RFC8453]
	framework. An IP transport network may provide such slice instances		framework. An IP transport network may provide such slice instances
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	o Mapping of PDU session parameters to underlay SST paths need to be		o Mapping of PDU session parameters to underlay SST paths need to be
	done. One way to do this to let the SMF install a Forwarding		done. One way to do this to let the SMF install a Forwarding
	Action Rule (FAR) in the UPF via N4 with the FAR pointing to a		Action Rule (FAR) in the UPF via N4 with the FAR pointing to a
	"Network Instance" in the UPF. A "Network Instance" is a logical		"Network Instance" in the UPF. A "Network Instance" is a logical
	identifier for an underlying network. The "Network Instance"		identifier for an underlying network. The "Network Instance"
	pointed by the FAR can be mapped to a transport path (through L2/		pointed by the FAR can be mapped to a transport path (through L2/
	L3 VPN). FARs are associated with Packet Detection Rule (PDR).		L3 VPN). FARs are associated with Packet Detection Rule (PDR).
	PDRs are used to classify packets in the uplink (UL) and the		PDRs are used to classify packets in the uplink (UL) and the
	downlink (DL) direction. For UL procedures specified in		downlink (DL) direction. For UL procedures specified in
	(Section 2.5), (Section 2.6) can be used for classifying a packet		Section 2.5, Section 2.6 can be used for classifying a packet
	belonging to a particular slice characteristics. For DL, at a PSA		belonging to a particular slice characteristics. For DL, at a PSA
	UPF, the UE IP address is used to identify the PDU session, and		UPF, the UE IP address is used to identify the PDU session, and
	hence the slice a packet belongs to and the IP 5 tuple can be used		hence the slice a packet belongs to and the IP 5 tuple can be used
	for identifying the flow and QoS characteristics to be applied on		for identifying the flow and QoS characteristics to be applied on
	the packet at UPF. If a PE is not co-located at the UPF then		the packet at UPF. If a PE is not co-located at the UPF then
	mapping to the underlying TE paths at PE happens based on the		mapping to the underlying TE paths at PE happens based on the
	encapsulated GTP-US packet as specified in (Section 2.6).		encapsulated GTP-US packet as specified in Section 2.6.
	o If any other form of encapsulation (other than GTP-U) either on N3		o If any other form of encapsulation (other than GTP-U) either on N3
	or N9 corresponding QFI information MUST be there in the		or N9 corresponding QFI information MUST be there in the
	encapsulation header.		encapsulation header.
	o In some SSC modes (Appendix B), if segmented path (CSR to		o In some SSC modes Appendix B, if segmented path (CSR to
	PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then		PE@staging/ULCL/BP-UPF to PE@anchor-point-UPF) is needed, then
	corresponding path characteristics MUST be used. This includes a		corresponding path characteristics MUST be used. This includes a
	path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF		path from CSR to PE@UL-CL/BP UPF [TS.23.501-3GPP] and UL-CL/BP UPF
	to eventual UPF access to DN.		to eventual UPF access to DN.
	o Continuous monitoring of the underlying transport path		o Continuous monitoring of the underlying transport path
	characteristics should be enabled at the endpoints (technologies		characteristics should be enabled at the endpoints (technologies
	for monitoring depends traffic engineering technique used as		for monitoring depends traffic engineering technique used as
	described in (Section 3.1) and (Section 3.2)). If path		described in Section 3.1 and Section 3.2). If path
	characteristics are degraded, reassignment of the paths at the		characteristics are degraded, reassignment of the paths at the
	endpoints should be performed. For all the affected PDU sessions,		endpoints should be performed. For all the affected PDU sessions,
	degraded transport paths need to be updated dynamically with		degraded transport paths need to be updated dynamically with
	similar alternate paths.		similar alternate paths.
	o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn		o During UE mobility event similar to 4G/LTE i.e., gNB mobility (Xn
	based or N2 based), for target gNB selection, apart from radio		based or N2 based), for target gNB selection, apart from radio
	resources, transport resources MUST be factored. This enables		resources, transport resources MUST be factored. This enables
	handling of all PDU sessions from the UE to target gNB and this		handling of all PDU sessions from the UE to target gNB and this
	require co-ordination of gNB, AMF, SMF with the TNF module.		require co-ordination of gNB, AMF, SMF with the TNF module.
	skipping to change at page 16, line 20 ¶		skipping to change at page 16, line 20 ¶
	approach selected for N9 (encapsulation or no-encapsulation). In		approach selected for N9 (encapsulation or no-encapsulation). In
	this scenario, PPR will only help providing TE benefits needed for 5G		this scenario, PPR will only help providing TE benefits needed for 5G
	slices from transport domain perspective. It does so for any		slices from 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). This is achieved by:		(L2/IPv4/IPv6/MPLS). This is achieved by:
	o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in		o For 3 different SSTs, 3 PPR-IDs can be signaled from any node in
	the transport network. For Uplink traffic, the 5G-AN will choose		the transport network. For Uplink traffic, the 5G-AN will choose
	the right PPR-ID of the UPF based on the S-NSSAI the PDU Session		the right PPR-ID of the UPF based on the S-NSSAI the PDU Session
	belongs to and/or the UDP Source port (corresponds to the MTNC-ID		belongs to and/or the UDP Source port (corresponds to the MTNC-ID
	(Section 2.5)) of the GTP-U encapsulation header. Similarly in		Section 2.5) of the GTP-U encapsulation header. Similarly in the
	the Downlink direction matching PPR-ID of the 5G-AN is chosen		Downlink direction matching PPR-ID of the 5G-AN is chosen based on
	based on the S-NSSAI the PDU Session belongs to. The table below		the S-NSSAI the PDU Session belongs to. The table below shows a
	shows a typical mapping:		typical mapping:
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	|GTP/UDP SRC PORT| SST | Transport Path | Transport Path |		|GTP/UDP SRC PORT| SST | Transport Path | Transport Path |
	| | in S-NSSAI | Info | Characteristics |		| | in S-NSSAI | Info | Characteristics |
	+----------------+------------+------------------+-----------------+		+----------------+------------+------------------+-----------------+
	| Range Xx - Xy | | | |		| Range Xx - Xy | | | |
	| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |		| X1, X2(discrete| MIOT | PW ID/VPN info, | GBR (Guaranteed |
	| values) | (massive | PPR-ID-A | Bit Rate) |		| values) | (massive | PPR-ID-A | Bit Rate) |
	| | IOT) | | Bandwidth: Bx |		| | IOT) | | Bandwidth: Bx |
	| | | | Delay: Dx |		| | | | Delay: Dx |
	skipping to change at page 17, line 17 ¶		skipping to change at page 17, line 17 ¶
	o Same set of PPRs are created uniformly across all needed 5G-ANs		o Same set of PPRs are created uniformly across all needed 5G-ANs
	and UPFs to allow various mobility scenarios.		and UPFs to allow various mobility scenarios.
	o Any modification of TE parameters of the path, replacement path		o Any modification of TE parameters of the path, replacement path
	and deleted path needed to be updated from TNF to the relevant		and deleted path needed to be updated from TNF to the relevant
	ingress points. Same information can be pushed to the NSSF, and/		ingress points. Same information can be pushed to the NSSF, and/
	or SMF as needed.		or SMF as needed.
	o PPR can be supported with any native IPv4 and IPv6 data/user		o PPR can be supported with any native IPv4 and IPv6 data/user
	planes ( (Section 3.1.2)) with optional TE features (		planes (Section 3.1.2) with optional TE features (Section 3.1.3) .
	(Section 3.1.3)) . As this is an underlay mechanism it can work		As this is an underlay mechanism it can work with any overlay
	with any overlay encapsulation approach including GTP-U as defined		encapsulation approach including GTP-U as defined currently for N3
	currently for N3 interface.		interface.
	3.1.2. Path Steering Support to native IP user planes		3.1.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 Section 5.3.7 of		listed in Section 5.3.7 of
	[I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the		[I-D.bogineni-dmm-optimized-mobile-user-plane]. PPR also expands the
	source routing to user planes beyond SR-MPLS and SRv6 i.e., L2,		source routing to user planes beyond SR-MPLS and SRv6 i.e., L2,
	native IPv6 and IPv4 user planes.		native IPv6 and IPv4 user planes.
	skipping to change at page 18, line 23 ¶		skipping to change at page 18, line 23 ¶
	SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal		SR-TE [I-D.ietf-spring-segment-routing] does not explicitly signal
	bandwidth reservation or mechanism to guarantee latency on the nodes/		bandwidth reservation or mechanism to guarantee latency on the nodes/
	links on SR path. But SR allows path steering for any flow at the		links on SR path. But SR allows path steering for any flow at the
	ingress and particular path for a flow can be chosen. Some of the		ingress and particular path for a flow can be chosen. Some of the
	issues around path overhead/tax, MTU issues are documented at		issues around path overhead/tax, MTU issues are documented at
	Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR-		Section 5.3 of [I-D.bogineni-dmm-optimized-mobile-user-plane]. SR-
	MPLS allows reduction of the control protocols to one IGP (with out		MPLS allows reduction of the control protocols to one IGP (with out
	needing for LDP and RSVP-TE).		needing for LDP and RSVP-TE).
	However, as specified above with PPR ( (Section 3.1)), in the		However, as specified above with PPR (Section 3.1), in the integrated
	integrated transport network function (TNF) a particular RSVP-TE path		transport network function (TNF) a particular RSVP-TE path for MPLS
	for MPLS or SR path for MPLS and IPv6 with SRH user plane, can be		or SR path for MPLS and IPv6 with SRH user plane, can be supplied to
	supplied to SMF for mapping a particular PDU session to the transport		SMF for mapping a particular PDU session to the transport path.
	path.
	4. Acknowledgements		4. Acknowledgements
	Thanks to Young Lee for discussions on this document including ACTN		Thanks to Young Lee for discussions on this document including ACTN
	applicability for the proposed TNF. Thanks to Sri Gundavelli and		applicability for the proposed TNF. Thanks to Sri Gundavelli and
	3GPP delegates who provided detailed feedback on this document.		3GPP delegates who provided detailed feedback on this document.
	5. IANA Considerations		5. IANA Considerations
	This document has no requests for any IANA code point allocations.		This document has no requests for any IANA code point allocations.
	skipping to change at page 20, line 14 ¶		skipping to change at page 20, line 14 ¶
	[I-D.chunduri-lsr-ospf-preferred-path-routing]		[I-D.chunduri-lsr-ospf-preferred-path-routing]
	Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.		Chunduri, U., Qu, Y., White, R., Tantsura, J., and L.
	Contreras, "Preferred Path Routing (PPR) in OSPF", draft-		Contreras, "Preferred Path Routing (PPR) in OSPF", draft-
	chunduri-lsr-ospf-preferred-path-routing-04 (work in		chunduri-lsr-ospf-preferred-path-routing-04 (work in
	progress), March 2020.		progress), March 2020.
	[I-D.farinacci-lisp-mobile-network]		[I-D.farinacci-lisp-mobile-network]
	Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP		Farinacci, D., Pillay-Esnault, P., and U. Chunduri, "LISP
	for the Mobile Network", draft-farinacci-lisp-mobile-		for the Mobile Network", draft-farinacci-lisp-mobile-
	network-06 (work in progress), September 2019.		network-09 (work in progress), September 2020.
	[I-D.ietf-dmm-5g-uplane-analysis]		[I-D.ietf-dmm-5g-uplane-analysis]
	Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,		Homma, S., Miyasaka, T., Matsushima, S., and D. Voyer,
	"User Plane Protocol and Architectural Analysis on 3GPP 5G		"User Plane Protocol and Architectural Analysis on 3GPP 5G
	System", draft-ietf-dmm-5g-uplane-analysis-03 (work in		System", draft-ietf-dmm-5g-uplane-analysis-03 (work in
	progress), November 2019.		progress), November 2019.
	[I-D.ietf-dmm-srv6-mobile-uplane]		[I-D.ietf-dmm-srv6-mobile-uplane]
	Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,		Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
	Voyer, D., and C. Perkins, "Segment Routing IPv6 for		Voyer, D., and C. Perkins, "Segment Routing IPv6 for
	Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-07		Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09
	(work in progress), November 2019.		(work in progress), July 2020.
	[I-D.ietf-intarea-gue-extensions]		[I-D.ietf-intarea-gue-extensions]
	Herbert, T., Yong, L., and F. Templin, "Extensions for		Herbert, T., Yong, L., and F. Templin, "Extensions for
	Generic UDP Encapsulation", draft-ietf-intarea-gue-		Generic UDP Encapsulation", draft-ietf-intarea-gue-
	extensions-06 (work in progress), March 2019.		extensions-06 (work in progress), March 2019.
	[I-D.ietf-spring-segment-routing]		[I-D.ietf-spring-segment-routing]
	Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,		Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
	Litkowski, S., and R. Shakir, "Segment Routing		Litkowski, S., and R. Shakir, "Segment Routing
	Architecture", draft-ietf-spring-segment-routing-15 (work		Architecture", draft-ietf-spring-segment-routing-15 (work
	skipping to change at page 23, line 42 ¶		skipping to change at page 23, line 42 ¶
	with SRH, native IPv6 and native IPv4 underlays.		with SRH, native IPv6 and native IPv4 underlays.
	As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the		As per [TS.23.501-3GPP] and [TS.23.502-3GPP] the SMF controls the
	user plane traffic forwarding rules in the UPF. The UPFs have a		user plane traffic forwarding rules in the UPF. The UPFs have a
	concept of a "Network Instance" which logically abstracts the		concept of a "Network Instance" which logically abstracts the
	underlying transport path. When the SMF creates the packet detection		underlying transport path. When the SMF creates the packet detection
	rules (PDR) and forwarding action rules (FAR) for a PDU session at		rules (PDR) and forwarding action rules (FAR) for a PDU session at
	the UPF, the SMF identifies the network instance through which the		the UPF, the SMF identifies the network instance through which the
	packet matching the PDR has to be forwarded. A network instance can		packet matching the PDR has to be forwarded. A network instance can
	be mapped to a TE path at the UPF. In this approach, TNF as shown in		be mapped to a TE path at the UPF. In this approach, TNF as shown in
	(Figure 1) need not be part of the 5G Service Based Interface (SBI).		Figure 1 need not be part of the 5G Service Based Interface (SBI).
	Only management plane functionality is needed to create, monitor,		Only management plane functionality is needed to create, monitor,
	manage and delete (life cycle management) the transport TE paths/		manage and delete (life cycle management) the transport TE paths/
	transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).		transport slices from the 5G-AN to the UPF (on N3/N9 interfaces).
	The management plane functionality also provides the mapping of such		The management plane functionality also provides the mapping of such
	TE paths to a network instance identifier to the SMF. The SMF uses		TE paths to a network instance identifier to the SMF. The SMF uses
	this mapping to install appropriate FARs in the UPF. This approach		this mapping to install appropriate FARs in the UPF. This approach
	provide partial integration of the transport network into 5GS with		provide partial integration of the transport network into 5GS with
	some benefits.		some benefits.
	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
	skipping to change at page 27, line 8 ¶		skipping to change at page 27, line 8 ¶
	Figure 5: SSC Mode3 and Service Continuity		Figure 5: SSC Mode3 and Service Continuity
	In the uplink direction for the traffic offloading from the Branching		In the uplink direction for the traffic offloading from the Branching
	Point UPF, packet has to reach to the right exit UPF. In this case		Point UPF, packet has to reach to the right exit UPF. In this case
	packet gets re-encapsulated by the BP UPF (with either GTP-U or the		packet gets re-encapsulated by the BP UPF (with either GTP-U or the
	chosen encapsulation) after bit rate enforcement and LI, towards the		chosen encapsulation) after bit rate enforcement and LI, towards the
	anchor UPF. At this point packet has to be on the appropriate VPN/PW		anchor UPF. At this point packet has to be on the appropriate VPN/PW
	to the anchor UPF. This mapping is done based on the S-NSSAI the PDU		to the anchor UPF. This mapping is done based on the S-NSSAI the PDU
	session belongs to and/or with the UDP source port (corresponds to		session belongs to and/or with the UDP source port (corresponds to
	the MTNC-ID (Section 2.5)) of the GTP-U encapsulation header to the		the MTNC-ID Section 2.5) of the GTP-U encapsulation header to the
	PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR		PPR-ID of the exit node by selecting the respective TE PPR-ID (PPR
	path) of the UPF. If it's a non-MPLS underlay, destination IP		path) of the UPF. If it's a non-MPLS underlay, destination IP
	address of the encapsulation header would be the mapped PPR-ID (TE		address of the encapsulation header would be the mapped PPR-ID (TE
	path).		path).
	In the downlink direction for the incoming packet, UPF has to		In the downlink direction for the incoming packet, UPF has to
	encapsulate the packet (with either GTP-U or the chosen		encapsulate the packet (with either GTP-U or the chosen
	encapsulation) to reach the BP UPF. Here mapping is done based on		encapsulation) to reach the BP UPF. Here mapping is done based on
	the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the		the S-NSSAI the PDU session belongs, to the PPR-ID (TE Path) of the
	BP UPF. If it's a non-MPLS underlay, destination IP address of the		BP UPF. If it's a non-MPLS underlay, destination IP address of the
End of changes. 22 change blocks.
	38 lines changed or deleted		36 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/