draft-ietf-dmm-srv6-mobile-uplane-04.txt		draft-ietf-dmm-srv6-mobile-uplane-05.txt
	DMM Working Group S. Matsushima		DMM Working Group S. Matsushima
	Internet-Draft SoftBank		Internet-Draft SoftBank
	Intended status: Standards Track C. Filsfils		Intended status: Standards Track C. Filsfils
	Expires: September 12, 2019 M. Kohno		Expires: January 9, 2020 M. Kohno
	P. Camarillo		P. Camarillo
	Cisco Systems, Inc.		Cisco Systems, Inc.
	D. Voyer		D. Voyer
	Bell Canada		Bell Canada
	C. Perkins		C. Perkins
	Futurewei		Futurewei
	March 11, 2019		July 8, 2019
	Segment Routing IPv6 for Mobile User Plane		Segment Routing IPv6 for Mobile User Plane
	draft-ietf-dmm-srv6-mobile-uplane-04		draft-ietf-dmm-srv6-mobile-uplane-05
	Abstract		Abstract
	This document shows the applicability of SRv6 (Segment Routing IPv6)		This document shows the applicability of SRv6 (Segment Routing IPv6)
	to the user-plane of mobile networks. The network programming nature		to the user-plane of mobile networks. The network programming nature
	of SRv6 accomplish mobile user-plane functions in a simple manner.		of SRv6 accomplish mobile user-plane functions in a simple manner.
	The statelessness of SRv6 and its ability to control both service		The statelessness of SRv6 and its ability to control both service
	layer path and underlying transport can be beneficial to the mobile		layer path and underlying transport can be beneficial to the mobile
	user-plane, providing flexibility and SLA control for various		user-plane, providing flexibility, end-to-end network slicing and SLA
	applications. This document describes the SRv6 mobile user plane		control for various applications. This document describes the SRv6
	behavior and defines the SID functions for that.		mobile user plane behavior and defines the SID functions for that.
	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 http://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 12, 2019.		This Internet-Draft will expire on January 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11		5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 11
	5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12		5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
	5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15		5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
	5.3.3. Extensions to the interworking mechanisms . . . . . . 17		5.3.3. Extensions to the interworking mechanisms . . . . . . 17
	6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18		6. SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . . 18
	6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18		6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 18
	6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18		6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19		6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 19
	6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19		6.4. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 19
	6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20		6.5. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 20
	6.6. T.M.Tmap . . . . . . . . . . . . . . . . . . . . . . . . 20		6.6. T.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 21
	6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 21		6.7. End.Limit: Rate Limiting function . . . . . . . . . . . . 22
	7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22		7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 22
	8. Network Slicing Considerations . . . . . . . . . . . . . . . 22		8. Network Slicing Considerations . . . . . . . . . . . . . . . 23
	9. Control Plane Considerations . . . . . . . . . . . . . . . . 22		9. Control Plane Considerations . . . . . . . . . . . . . . . . 23
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 23		10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	14.1. Normative References . . . . . . . . . . . . . . . . . . 24		14.1. Normative References . . . . . . . . . . . . . . . . . . 24
	14.2. Informative References . . . . . . . . . . . . . . . . . 25		14.2. Informative References . . . . . . . . . . . . . . . . . 25
	Appendix A. Implementations . . . . . . . . . . . . . . . . . . 26		Appendix A. Implementations . . . . . . . . . . . . . . . . . . 27
	Appendix B. Changes from revision 02 to revision 03 . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	In mobile networks, mobility management systems provide connectivity		In mobile networks, mobility management systems provide connectivity
	while mobile nodes move. While the control-plane of the system		while mobile nodes move. While the control-plane of the system
	signals movements of a mobile node, the user-plane establishes a		signals movements of a mobile node, the user-plane establishes a
	tunnel between the mobile node and its anchor node over IP-based		tunnel between the mobile node and its anchor node over IP-based
	backhaul and core networks.		backhaul and core networks.
	skipping to change at page 4, line 48 ¶		skipping to change at page 4, line 47 ¶
	detailed behavior, the (S3, S2, S1; SL) notation is more		detailed behavior, the (S3, S2, S1; SL) notation is more
	convenient.		convenient.
	o SRH[SL] represents the SID pointed by the SL field in the first		o SRH[SL] represents the SID pointed by the SL field in the first
	SRH. In our example, SRH[2] represents S1, SRH[1] represents S2		SRH. In our example, SRH[2] represents S1, SRH[1] represents S2
	and SRH[0] represents S3.		and SRH[0] represents S3.
	o SRH[SL] can be different from the DA of the IPv6 header.		o SRH[SL] can be different from the DA of the IPv6 header.
	2.3. Predefined SRv6 Functions		2.3. Predefined SRv6 Functions
	The following functions are defined in		The following functions are defined in
	[I-D.filsfils-spring-srv6-network-programming].		[I-D.ietf-spring-srv6-network-programming].
	o End.DT4 means to decapsulate and forward using a specific IPv4		o End.DT4 means to decapsulate and forward using a specific IPv4
	table lookup.		table lookup.
	o End.DT6 means to decapsulate and forward using a specific IPv6		o End.DT6 means to decapsulate and forward using a specific IPv6
	table lookup.		table lookup.
	o End.DX4 means to decapsulate the packet and forward through a		o End.DX4 means to decapsulate the packet and forward through a
	particular outgoing interface -or set of OIFs- configured with the		particular outgoing interface -or set of OIFs- configured with the
	SID.		SID.
	o End.DX6 means to decapsulate and forward through a particular		o End.DX6 means to decapsulate and forward through a particular
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 49 ¶
	In the meantime, applications have shifted to use IPv6, and network		In the meantime, applications have shifted to use IPv6, and network
	operators have started adopting IPv6 as their IP transport. SRv6,		operators have started adopting IPv6 as their IP transport. SRv6,
	the IPv6 dataplane instantiation of Segment Routing [RFC8402],		the IPv6 dataplane instantiation of Segment Routing [RFC8402],
	integrates both the application data-path and the underlying		integrates both the application data-path and the underlying
	transport layer into a single protocol, allowing operators to		transport layer into a single protocol, allowing operators to
	optimize the network in a simplified manner and removing forwarding		optimize the network in a simplified manner and removing forwarding
	state from the network. It is also suitable for virtualized		state from the network. It is also suitable for virtualized
	environments, VNF/CNF to VNF/CNF networking.		environments, VNF/CNF to VNF/CNF networking.
	SRv6 specifies network-programming (see		SRv6 specifies network-programming (see
	[I-D.filsfils-spring-srv6-network-programming]). Applied to		[I-D.ietf-spring-srv6-network-programming]). Applied to mobility,
	mobility, SRv6 can provide the user-plane functions needed for		SRv6 can provide the user-plane functions needed for mobility
	mobility management. SRv6 takes advantage of underlying transport		management. SRv6 takes advantage of underlying transport awareness
	awareness and flexibility to improve mobility user-plane functions.		and flexibility to improve mobility user-plane functions.
	The use-cases for SRv6 mobility are discussed in		The use-cases for SRv6 mobility are discussed in
	[I-D.camarilloelmalky-springdmm-srv6-mob-usecases].		[I-D.camarilloelmalky-springdmm-srv6-mob-usecases].
	4. A 3GPP Reference Architecture		4. A 3GPP Reference Architecture
	This section presents a reference architecture and possible		This section presents a reference architecture and possible
	deployment scenarios.		deployment scenarios.
	Figure 1 shows a reference diagram from the 5G packet core		Figure 1 shows a reference diagram from the 5G packet core
	skipping to change at page 7, line 35 ¶		skipping to change at page 7, line 35 ¶
	We introduce two mechanisms for interworking with legacy access		We introduce two mechanisms for interworking with legacy access
	networks (N3 interface is unmodified). In these document we		networks (N3 interface is unmodified). In these document we
	introduce them applied to the Enhanced mode, although they could be		introduce them applied to the Enhanced mode, although they could be
	used in combination with the Traditional mode as well.		used in combination with the Traditional mode as well.
	One of these mechanisms is designed to interwork with legacy gNBs		One of these mechanisms is designed to interwork with legacy gNBs
	using GTP/IPv4. The second method is designed to interwork with		using GTP/IPv4. The second method is designed to interwork with
	legacy gNBs using GTP/IPv6.		legacy gNBs using GTP/IPv6.
	This document uses SRv6 functions defined in		This document uses SRv6 functions defined in
	[I-D.filsfils-spring-srv6-network-programming] as well as new SRv6		[I-D.ietf-spring-srv6-network-programming] as well as new SRv6
	functions designed for the mobile user plane. The new SRv6 functions		functions designed for the mobile user plane. The new SRv6 functions
	are detailed in Section 6.		are detailed in Section 6.
	5.1. Traditional mode		5.1. Traditional mode
	In the traditional mode, the existing mobile UPFs remain unchanged		In the traditional mode, the existing mobile UPFs remain unchanged
	except for the use of SRv6 as the data plane instead of GTP-U. There		except for the use of SRv6 as the data plane instead of GTP-U. There
	is no impact to the rest of mobile system.		is no impact to the rest of mobile system.
	In existing 3GPP mobile networks, an UE session is mapped 1-for-1		In existing 3GPP mobile networks, an UE PDU Session is mapped 1-for-1
	with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored		with a specific GTP tunnel (TEID). This 1-for-1 mapping is mirrored
	here to replace GTP encapsulation with the SRv6 encapsulation, while		here to replace GTP encapsulation with the SRv6 encapsulation, while
	not changing anything else. There will be a unique SRv6 SID		not changing anything else. There will be a unique SRv6 SID
	associated with each UE session.		associated with each UE PDU Session.
	The traditional mode minimizes the changes required to the mobile		The traditional mode minimizes the changes required to the mobile
	system; it is a good starting point for forming a common basis.		system; it is a good starting point for forming a common basis.
	Our example topology is shown in Figure 2. In traditional mode the		Our example topology is shown in Figure 2. In traditional mode the
	gNB and the UPFs are SR-aware. In the descriptions of the uplink and		gNB and the UPFs are SR-aware. In the descriptions of the uplink and
	downlink packet flow, A is an IPv6 address of the UE, and Z is an		downlink packet flow, A is an IPv6 address of the UE, and Z is an
	IPv6 address reachable within the Data Network DN. A new SRv6		IPv6 address reachable within the Data Network DN. A new SRv6
	function End.MAP, defined in Section 6.2, is used.		function End.MAP, defined in Section 6.2, is used.
	skipping to change at page 9, line 11 ¶		skipping to change at page 9, line 11 ¶
	5.1.2. Packet flow - Downlink		5.1.2. Packet flow - Downlink
	The downlink packet flow is as follows:		The downlink packet flow is as follows:
	UPF2_in : (Z,A)		UPF2_in : (Z,A)
	UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red <U1::1>		UPF2_out: (U2::, U1::1) (Z,A) -> T.Encaps.Red <U1::1>
	UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP		UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
	gNB_out : (Z,A) -> End.DX4 or End.DX6		gNB_out : (Z,A) -> End.DX4 or End.DX6
	When the packet arrives at the UPF2, the UPF2 maps that flow into a		When the packet arrives at the UPF2, the UPF2 maps that flow into a
	UE session. This UE session is associated with the segment endpoint		UE PDU Session. This UE PDU Session is associated with the segment
	<U1::1>. UPF2 performs a T.Encaps.Red operation, encapsulating the		endpoint <U1::1>. UPF2 performs a T.Encaps.Red operation,
	packet into a new IPv6 header with no SRH since there is only one		encapsulating the packet into a new IPv6 header with no SRH since
	SID.		there is only one SID.
	Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP		Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP
	function. This function maps the SID to the next anchoring point and		function. This function maps the SID to the next anchoring point and
	replaces U1::1 by gNB::1, that belongs to the next hop.		replaces U1::1 by gNB::1, that belongs to the next hop.
	Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4		Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4
	or End.DX6 function. The gNB decapsulates the packet, removing the		or End.DX6 function. The gNB decapsulates the packet, removing the
	IPv6 header and all its extensions headers, and forwards the traffic		IPv6 header and all its extensions headers, and forwards the traffic
	toward the UE.		toward the UE.
	5.1.3. IPv6 user-traffic		5.1.3. IPv6 user-traffic
	For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.		For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
	However based on local policy, a service provider MAY choose to do		However based on local policy, a service provider MAY choose to do
	SRH insertion [I-D.voyer-6man-extension-header-insertion] . The main		SRH insertion. The main benefit is a lower overhead(40B less). In
	benefit is a lower overhead (40B less). In such case, the functions		such case, the functions used are T.Insert.Red at gNB, End.MAP at
	used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T at UPF2 on		UPF1 and End.T at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at
	Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at gNB on		UPF1 and End.X at gNB on Downlink.
	Downlink.
	5.2. Enhanced Mode		5.2. Enhanced Mode
	Enhanced mode improves scalability, traffic steering and service		Enhanced mode improves scalability, traffic steering and service
	programming [I-D.xuclad-spring-sr-service-programming], thanks to the		programming [I-D.xuclad-spring-sr-service-programming], thanks to the
	use of multiple SIDs, instead of a single SID as done in the		use of multiple SIDs, instead of a single SID as done in the
	Traditional mode.		Traditional mode.
	The main difference is that the SR policy MAY include SIDs for		The main difference is that the SR policy MAY include SIDs for
	traffic engineering and service programming in addition to the UPFs		traffic engineering and service programming in addition to the UPFs
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	The downlink packet flow is as follows:		The downlink packet flow is as follows:
	UPF2_in : (Z,A) -> UPF2 maps the flow w/		UPF2_in : (Z,A) -> UPF2 maps the flow w/
	SID list <C1,S1, gNB>		SID list <C1,S1, gNB>
	UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red		UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A) -> T.Encaps.Red
	C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)		C1_out : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
	S1_out : (U2::1, gNB)(Z,A) -> PSP		S1_out : (U2::1, gNB)(Z,A) -> PSP
	gNB_out : (Z,A) -> End.DX4 or End.DX6		gNB_out : (Z,A) -> End.DX4 or End.DX6
	When the packet arrives at the UPF2, the UPF2 maps that particular		When the packet arrives at the UPF2, the UPF2 maps that particular
	flow into a UE session. This UE session is associated with the		flow into a UE PDU Session. This UE PDU Session is associated with
	policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red operation,		the policy <C1, S1, gNB>. The UPF2 performs a T.Encaps.Red
	encapsulating the packet into a new IPv6 header with its		operation, encapsulating the packet into a new IPv6 header with its
	corresponding SRH.		corresponding SRH.
	The nodes C1 and S1 perform their related Endpoint processing.		The nodes C1 and S1 perform their related Endpoint processing.
	Once the packet arrives at the gNB, the IPv6 DA corresponds to an		Once the packet arrives at the gNB, the IPv6 DA corresponds to an
	End.DX4 or End.DX6 (depending on the underlying traffic). The gNB		End.DX4 or End.DX6 (depending on the underlying traffic). The gNB
	decapsulates the packet, removing the IPv6 header and all its		decapsulates the packet, removing the IPv6 header and all its
	extensions headers and forwards the traffic toward the UE.		extensions headers and forwards the traffic toward the UE.
	5.2.3. IPv6 user-traffic		5.2.3. IPv6 user-traffic
	skipping to change at page 13, line 36 ¶		skipping to change at page 13, line 36 ¶
	S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)		S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
	C1_out : (SRGW, U2::1)(A,Z) -> PSP		C1_out : (SRGW, U2::1)(A,Z) -> PSP
	UPF2_out: (A,Z) -> End.DT4 or End.DT6		UPF2_out: (A,Z) -> End.DT4 or End.DT6
	The UE sends a packet destined to Z toward the gNB on a specific		The UE sends a packet destined to Z toward the gNB on a specific
	bearer for that session. The gNB, which is unmodified, encapsulates		bearer for that session. The gNB, which is unmodified, encapsulates
	the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the		the packet into IPv6, UDP and GTP headers. The IPv6 DA B, and the
	GTP TEID T are the ones received in the N2 interface.		GTP TEID T are the ones received in the N2 interface.
	The IPv6 address that was signalled over the N2 interface for that UE		The IPv6 address that was signalled over the N2 interface for that UE
	session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the		PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the
	SRGW. Hence the packet is routed to the SRGW.		SRGW. Hence the packet is routed to the SRGW.
	When the packet arrives at the SRGW, the SRGW identifies B as an		When the packet arrives at the SRGW, the SRGW identifies B as an
	End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes		End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes
	the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own		the IPv6, UDP and GTP headers, and pushes an IPv6 header with its own
	SRH containing the SIDs bound to the SR policy associated with this		SRH containing the SIDs bound to the SR policy associated with this
	BindingSID. There is one instance of the End.M.GTP6.D SID per PDU		BindingSID. There is one instance of the End.M.GTP6.D SID per PDU
	type.		type.
	S1 and C1 perform their related Endpoint functionality and forward		S1 and C1 perform their related Endpoint functionality and forward
	skipping to change at page 14, line 46 ¶		skipping to change at page 14, line 46 ¶
	and forward it on the bearer. This gNB behavior is not modified from		and forward it on the bearer. This gNB behavior is not modified from
	current and previous generations.		current and previous generations.
	5.3.1.3. Scalability		5.3.1.3. Scalability
	For the downlink traffic, the SRGW is stateless. All the state is in		For the downlink traffic, the SRGW is stateless. All the state is in
	the SRH inserted by the UPF2. The UPF2 must have the UE states since		the SRH inserted by the UPF2. The UPF2 must have the UE states since
	it is the UE's session anchor point.		it is the UE's session anchor point.
	For the uplink traffic, the state at the SRGW does not necessarily		For the uplink traffic, the state at the SRGW does not necessarily
	need to be unique per UE session; the state state can be shared among		need to be unique per UE PDU Session; the state state can be shared
	UEs. This enables much more scalable SRGW deployments compared to a		among UEs. This enables much more scalable SRGW deployments compared
	solution holding millions of states, one or more per UE.		to a solution holding millions of states, one or more per UE.
	5.3.1.4. IPv6 user-traffic		5.3.1.4. IPv6 user-traffic
	For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.		For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
	However based on local policy, a service provider MAY choose to do		However based on local policy, a service provider MAY choose to do
	SRH insertion. The main benefit is lower overhead.		SRH insertion. The main benefit is lower overhead.
	5.3.2. Interworking with IPv4 GTP		5.3.2. Interworking with IPv4 GTP
	In this interworking mode the gNB uses GTP over IPv4 in the N3		In this interworking mode the gNB uses GTP over IPv4 in the N3
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	-| UPF1 |- SRv6 SRv6		-| UPF1 |- SRv6 SRv6
	+------+ TE		+------+ TE
	SR Gateway		SR Gateway
	Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior		Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior
	5.3.2.1. Packet flow - Uplink		5.3.2.1. Packet flow - Uplink
	The uplink packet flow is as follows:		The uplink packet flow is as follows:
	gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3		gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
	unchanged IPv4/GTP		unchanged IPv4/GTP
	SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.Tmap function		SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> T.M.GTP4.D function
	S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)		S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
	C1_out : (SRGW, U2::1) (A,Z) -> PSP		C1_out : (SRGW, U2::1) (A,Z) -> PSP
	UPF2_out: (A,Z) -> End.DT4 or End.DT6		UPF2_out: (A,Z) -> End.DT4 or End.DT6
	The UE sends a packet destined to Z toward the gNB on a specific		The UE sends a packet destined to Z toward the gNB on a specific
	bearer for that session. The gNB, which is unmodified, encapsulates		bearer for that session. The gNB, which is unmodified, encapsulates
	the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and		the packet into a new IPv4, UDP and GTP headers. The IPv4 DA, B, and
	the GTP TEID are the ones received at the N2 interface.		the GTP TEID are the ones received at the N2 interface.
	When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink		When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink
	Classifier rule for incoming traffic from the gNB, that steers the		Classifier rule for incoming traffic from the gNB, that steers the
	traffic into an SR policy by using the function T.M.TMap. The SRGW		traffic into an SR policy by using the function T.M.GTP4.D. The SRGW
	removes the IPv4, UDP and GTP headers and pushes an IPv6 header with		removes the IPv4, UDP and GTP headers and pushes an IPv6 header with
	its own SRH containing the SIDs related to the SR policy associated		its own SRH containing the SIDs related to the SR policy associated
	with this traffic. The SRGW forwards according to the new IPv6 DA.		with this traffic. The SRGW forwards according to the new IPv6 DA.
	S1 and C1 perform their related Endpoint functionality and forward		S1 and C1 perform their related Endpoint functionality and forward
	the packet.		the packet.
	When the packet arrives at UPF2, the active segment is (U2::1) which		When the packet arrives at UPF2, the active segment is (U2::1) which
	is bound to End.DT4/6 which performs the decapsulation (removing the		is bound to End.DT4/6 which performs the decapsulation (removing the
	outer IPv6 header with all its extension headers) and forwards toward		outer IPv6 header with all its extension headers) and forwards toward
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	6.2. End.MAP		6.2. End.MAP
	The "Endpoint function with SID mapping" function (End.MAP for short)		The "Endpoint function with SID mapping" function (End.MAP for short)
	is used in several scenarios. Particularly in mobility, End.MAP is		is used in several scenarios. Particularly in mobility, End.MAP is
	used in the UPFs for the PDU Session anchor functionality.		used in the UPFs for the PDU Session anchor functionality.
	When a SR node N receives a packet destined to S and S is a local		When a SR node N receives a packet destined to S and S is a local
	End.MAP SID, N does the following:		End.MAP SID, N does the following:
	1. look up the IPv6 DA in the mapping table		1. Lookup the IPv6 DA in the mapping table
	2. update the IPv6 DA with the new mapped SID ;; Note 1		2. update the IPv6 DA with the new mapped SID ;; Ref1
	3. IF segment_list > 1		3. IF segment_list > 1
	4. insert a new SRH		4. insert a new SRH
	5. forward according to the new mapped SID		5. forward according to the new mapped SID
	6. ELSE
	7. Drop the packet
	Note 1: The SID in the SRH is NOT modified.		Ref1: The SIDs in the SRH are NOT modified.
	6.3. End.M.GTP6.D		6.3. End.M.GTP6.D
	The "Endpoint function with IPv6/GTP decapsulation into SR policy"		The "Endpoint function with IPv6/GTP decapsulation into SR policy"
	function (End.M.GTP6.D for short) is used in interworking scenario		function (End.M.GTP6.D for short) is used in interworking scenario
	for the uplink toward from the legacy gNB using IPv6/GTP. Suppose,		for the uplink toward from the legacy gNB using IPv6/GTP. Suppose,
	for example, this SID is associated with an SR policy <S1, S2, S3>		for example, this SID is associated with an SR policy <S1, S2, S3>
	and an IPv6 Source Address A.		and an IPv6 Source Address A.
	When the SR Gateway node N receives a packet destined to S and S is a		When the SR Gateway node N receives a packet destined to S and S is a
	local End.M.GTP6.D SID, N does:		local End.M.GTP6.D SID, N does:
	1. IF NH=UDP & UDP_PORT = GTP THEN		1. IF NH=UDP & UDP_DST_PORT = GTP THEN
	2. pop the IPv6, UDP and GTP headers		2. copy TEID to form SID S3
	3. push a new IPv6 header with its own SRH <S2, S3>		3. pop the IPv6, UDP and GTP headers
	4. set the outer IPv6 SA to A		4. push a new IPv6 header with a SR policy in SRH <S1, S2, S3>
	5. set the outer IPv6 DA to S1		5. set the outer IPv6 SA to A
	6. forward according to the S1 segment of the SRv6 Policy		6. set the outer IPv6 DA to S1
	7. ELSE		7. set the outer IPv6 NH ;; Ref1
	8. Drop the packet		8. forward according to the S1 segment of the SRv6 Policy
			9. ELSE
			10. Drop the packet
			Ref1: The NH is set based on the SID parameter. There is one
			instantiation of the End.M.GTP6.D SID per PDU Session Type, hence the
			NH is already known in advance. For the IPv4v6 PDU Session Type, in
			addition we inspect the first nibble of the PDU to know the NH value.
			The prefix of last segment(S3 in above example) SHOULD be followed by
			an Arg.Mob.Session argument space which is used to provide the
			session identifiers.
			The prefix of A SHOULD be an End.M.GTP6.E SID instantiated at an SR
			gateway.
	6.4. End.M.GTP6.E		6.4. End.M.GTP6.E
	The "Endpoint function with encapsulation for IPv6/GTP tunnel"		The "Endpoint function with encapsulation for IPv6/GTP tunnel"
	function (End.M.GTP6.E for short) is used in interworking scenario		function (End.M.GTP6.E for short) is used in interworking scenario
	for the downlink toward the legacy gNB using IPv6/GTP.		for the downlink toward the legacy gNB using IPv6/GTP.
	The End.M.GTP6.E function has a 32-bit argument space which is used		The prefix of End.M.GTP6.E SID MUST be followed by the
	to provide the GTP TEID.		Arg.Mob.Session argument space which is used to provide the session
			identifiers.
	When the SR Gateway node N receives a packet destined to S, and S is		When the SR Gateway node N receives a packet destined to S, and S is
	a local End.M.GTP6.E SID, N does the following:		a local End.M.GTP6.E SID, N does the following:
	1. IF NH=SRH & SL = 1 THEN ;; Note 1		1. IF NH=SRH & SL = 1 THEN ;; Ref1
	2. decrement SL		2. store SRH[0] in variable new_DA
	3. store SRH[SL] in variable new_DA		3. store TEID in variable new_TEID from IPv6 DA ;; Ref2
	4. store TEID in variable new_TEID ;; Note 2		4. pop IP header and all its extension headers
	5. pop IP header and all its extension headers		5. push new IPv6 header and GTP-U header
	6. push new IPv6 header and GTP-U header		6. set IPv6 DA to new_DA
	7. set IPv6 DA to new_DA		7. set IPv6 SA to A
	8. set GTP_TEID to new_TEID		8. set GTP_TEID to new_TEID
	9. lookup the new_DA and forward the packet accordingly		9. lookup the new_DA and forward the packet accordingly
	10. ELSE		10. ELSE
	11. Drop the packet		11. Drop the packet
	Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID.		Ref1: An End.M.GTP6.E SID MUST always be the penultimate SID.
	Note 2: TEID is extracted from the argument space of the current SID.		Ref2: TEID is extracted from the argument space of the current SID.
			The source address A SHOULD be an End.M.GTP6.D SID instantiated at an
			SR gateway.
	6.5. End.M.GTP4.E		6.5. End.M.GTP4.E
	The "Endpoint function with encapsulation for IPv4/GTP tunnel"		The "Endpoint function with encapsulation for IPv4/GTP tunnel"
	function (End.M.GTP4.E for short) is used in the downlink when doing		function (End.M.GTP4.E for short) is used in the downlink when doing
	interworking with legacy gNB using IPv4/GTP.		interworking with legacy gNB using IPv4/GTP.
	When the SR Gateway node N receives a packet destined to S and S is a		When the SR Gateway node N receives a packet destined to S and S is a
	local End.M.GTP4.E SID, N does:		local End.M.GTP4.E SID, N does:
	1. IF NH=SRH & SL = 0 THEN		1. IF (NH=SRH and SL = 0) or ENH=4 THEN
	2. store SRH[0] in buffer S		2. store IPv6 DA in buffer S
	3. pop the IPv6 header and its extension headers		3. store IPv6 SA in buffer S'
	4. push UDP/GTP headers with GTP TEID from S		4. pop the IPv6 header and its extension headers
	5. push outer IPv4 header with SA, DA from S		5. push UDP/GTP headers with GTP TEID from S
	6. ELSE		6. push outer IPv4 header with SA, DA from S' and S
	7. Drop the packet		7. ELSE
			8. Drop the packet
	S has the following format:		The End.M.GTP4.E SID in S has the following format:
	+----------------------+-------+-------+-------+		0 127
	| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |		+-----------------------+-------+----------------+---------+
	+----------------------+-------+-------+-------+		| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
	128-a-b-c a b c		+-----------------------+-------+----------------+---------+
			128-a-b-c a b c
	End.M.GTP4.E SID Encoding		End.M.GTP4.E SID Encoding
	6.6. T.M.Tmap		S' has the following format:
			0 127
			+----------------------+--------+--------------------------+
			| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
			+----------------------+--------+--------------------------+
			128-a-b a b
			IPv6 SA Encoding for End.M.GTP4.E
			6.6. T.M.GTP4.D
	The "Transit with tunnel decapsulation and map to an SRv6 policy"		The "Transit with tunnel decapsulation and map to an SRv6 policy"
	function (T.M.Tmap for short) is used in the direction from legacy		function (T.M.GTP4.D for short) is used in the direction from legacy
	user-plane to SRv6 user-plane network.		user-plane to SRv6 user-plane network.
	When the SR Gateway node N receives a packet destined to a IW-		When the SR Gateway node N receives a packet destined to a IW-
	IPv4-Prefix, N does:		IPv4-Prefix, N does:
	1. IF Payload == UDP/GTP THEN		1. IF Payload == UDP/GTP THEN
	2. pop the outer IPv4 header and UDP/GTP headers		2. pop the outer IPv4 header and UDP/GTP headers
	3. copy IPv4 DA, SA, TUN-ID to form SID B		3. copy IPv4 DA, TEID to form SID B
	4. encapsulate the packet into a new IPv6 header		4. copy IPv4 SA to form IPv6 SA B'
	5. set the IPv6 DA = B		5. encapsulate the packet into a new IPv6 header ;;Ref1
	6. forward along the shortest path to B		6. set the IPv6 DA = B
	7. ELSE		7. forward along the shortest path to B
	8. Drop the packet		8. ELSE
			9. Drop the packet
	B has the following format:		Ref1: The NH value is identified by inspecting the first nibble of
			the inner payload.
	+----------------------+-------+-------+-------+		The SID B has the following format:
	| SRGW-IPv6-LOC-FUNC |IPv4DA |IPv4SA |TUN-ID |
	+----------------------+-------+-------+-------+
	128-a-b-c a b c
	End.M.GTP4.E SID Encoding		0 127
			+-----------------------+-------+----------------+---------+
			|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
			+-----------------------+-------+----------------+---------+
			128-a-b-c a b c
	The SID B is an SRv6 BindingSID instantiated at the first UPF (U1).		T.M.GTP4.D SID Encoding
	A static format is used for this Binding SIDs in order to remove
	state from the SRGW.		The SID B MAY be an SRv6 Binding SID instantiated at the first UPF
			(U1) to bind a SR policy [I-D.ietf-spring-segment-routing-policy].
			The prefix of B' SHOULD be an End.M.GTP4.E SID with its format
			instantiated at an SR gateway with the IPv4 SA of the receiving
			packet.
	6.7. End.Limit: Rate Limiting function		6.7. End.Limit: Rate Limiting function
	The mobile user-plane requires a rate-limit feature. For this		The mobile user-plane requires a rate-limit feature. For this
	purpose, we define a new function "End.Limit". The "End.Limit"		purpose, we define a new function "End.Limit". The "End.Limit"
	function encodes in its arguments the rate limiting parameter that		function encodes in its arguments the rate limiting parameter that
	should be applied to this packet. Multiple flows of packets should		should be applied to this packet. Multiple flows of packets should
	have the same group identifier in the SID when those flows are in an		have the same group identifier in the SID when those flows are in an
	same AMBR group. The encoding format of the rate limit segment SID		same AMBR group. The encoding format of the rate limit segment SID
	is as follows:		is as follows:
	skipping to change at page 22, line 27 ¶		skipping to change at page 23, line 16 ¶
	for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;		for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
	End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions;		End.DT46 for IPv4v6 PDU sessions; End.DX2 for L2 PDU sessions;
	End.DX2 for Unstructured PDU sessions).		End.DX2 for Unstructured PDU sessions).
	8. Network Slicing Considerations		8. Network Slicing Considerations
	A mobile network may be required to implement "network slices", which		A mobile network may be required to implement "network slices", which
	logically separate network resources. User-plane functions		logically separate network resources. User-plane functions
	represented as SRv6 segments would be part of a slice.		represented as SRv6 segments would be part of a slice.
	[I-D.filsfils-spring-segment-routing-policy] describes a solution to		[I-D.ietf-spring-segment-routing-policy] describes a solution to
	build basic network slices with SR. Depending on the requirements,		build basic network slices with SR. Depending on the requirements,
	these slices can be further refined by adopting the mechanisms from:		these slices can be further refined by adopting the mechanisms from:
	o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo]		o IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo]
	o Inter-Domain policies		o Inter-Domain policies
	[I-D.ietf-spring-segment-routing-central-epe]		[I-D.ietf-spring-segment-routing-central-epe]
	Furthermore, these can be combined with ODN/AS		Furthermore, these can be combined with ODN/AS
	[I-D.filsfils-spring-segment-routing-policy] for automated slice		[I-D.ietf-spring-segment-routing-policy] for automated slice
	provisioning and traffic steering.		provisioning and traffic steering.
	Further details on how these tools can be used to create end to end		Further details on how these tools can be used to create end to end
	network slices are documented in		network slices are documented in
	[I-D.ali-spring-network-slicing-building-blocks].		[I-D.ali-spring-network-slicing-building-blocks].
	9. Control Plane Considerations		9. Control Plane Considerations
	This document focuses on user-plane behavior and its independence		This document focuses on user-plane behavior and its independence
	from the control plane.		from the control plane.
	skipping to change at page 23, line 25 ¶		skipping to change at page 24, line 17 ¶
	10. Security Considerations		10. Security Considerations
	TBD		TBD
	11. IANA Considerations		11. IANA Considerations
	IANA is requested to allocate, within the "SRv6 Endpoint Types" sub-		IANA is requested to allocate, within the "SRv6 Endpoint Types" sub-
	registry belonging to the top-level "Segment-routing with IPv6		registry belonging to the top-level "Segment-routing with IPv6
	dataplane (SRv6) Parameters" registry		dataplane (SRv6) Parameters" registry
	[I-D.filsfils-spring-srv6-network-programming], the following values:		[I-D.ietf-spring-srv6-network-programming], the following values:
	+-------------+-----+-------------------+-----------+		+-------------+-----+-------------------+-----------+
	| Value/Range | Hex | Endpoint function | Reference |		| Value/Range | Hex | Endpoint function | Reference |
	+-------------+-----+-------------------+-----------+		+-------------+-----+-------------------+-----------+
	| TBA | TBA | End.MAP | [This.ID] |		| TBA | TBA | End.MAP | [This.ID] |
	| TBA | TBA | End.M.GTP6.D | [This.ID] |		| TBA | TBA | End.M.GTP6.D | [This.ID] |
	| TBA | TBA | End.M.GTP6.E | [This.ID] |		| TBA | TBA | End.M.GTP6.E | [This.ID] |
	| TBA | TBA | End.M.GTP4.E | [This.ID] |		| TBA | TBA | End.M.GTP4.E | [This.ID] |
	| TBA | TBA | End.Limit | [This.ID] |		| TBA | TBA | End.Limit | [This.ID] |
	+-------------+-----+-------------------+-----------+		+-------------+-----+-------------------+-----------+
	skipping to change at page 23, line 49 ¶		skipping to change at page 24, line 41 ¶
	12. Acknowledgements		12. Acknowledgements
	The authors would like to thank Daisuke Yokota, Bart Peirens,		The authors would like to thank Daisuke Yokota, Bart Peirens,
	Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois		Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
	Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi		Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi
	Shekhar and Aeneas Dodd-Noble for their useful comments of this work.		Shekhar and Aeneas Dodd-Noble for their useful comments of this work.
	13. Contributors		13. Contributors
	Kentaro Ebisawa		Kentaro Ebisawa
	Ponto Networks		Toyota Motor Corporation
	Japan		Japan
	Email: ebiken@pontonetworks.com
			Email: ebisawa@toyota-tokyo.tech
	14. References		14. References
	14.1. Normative References		14.1. Normative References
	[I-D.filsfils-spring-segment-routing-policy]		[I-D.ietf-6man-segment-routing-header]
	Filsfils, C., Sivabalan, S., Hegde, S.,		Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
	daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,		Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment
	b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,		Routing Header (SRH)", draft-ietf-6man-segment-routing-
	Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,		header-21 (work in progress), June 2019.
	J., Clad, F., and K. Raza, "Segment Routing Policy
	Architecture", draft-filsfils-spring-segment-routing-
	policy-06 (work in progress), May 2018.
	[I-D.filsfils-spring-srv6-network-programming]		[I-D.ietf-spring-segment-routing-policy]
			Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
			bogdanov@google.com, b., and P. Mattes, "Segment Routing
			Policy Architecture", draft-ietf-spring-segment-routing-
			policy-03 (work in progress), May 2019.
			[I-D.ietf-spring-srv6-network-programming]
	Filsfils, C., Camarillo, P., Leddy, J.,		Filsfils, C., Camarillo, P., Leddy, J.,
	daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6		daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
	Network Programming", draft-filsfils-spring-srv6-network-		Network Programming", draft-ietf-spring-srv6-network-
	programming-07 (work in progress), February 2019.		programming-01 (work in progress), July 2019.
	[I-D.ietf-6man-segment-routing-header]
	Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
	d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
	(SRH)", draft-ietf-6man-segment-routing-header-16 (work in
	progress), February 2019.
	[I-D.voyer-6man-extension-header-insertion]
	daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes,
	D., Previdi, S., and S. Matsushima, "Insertion of IPv6
	Segment Routing Headers in a Controlled Domain", draft-
	voyer-6man-extension-header-insertion-05 (work in
	progress), January 2019.
	[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-
	<https://www.rfc-editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,		[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
	Decraene, B., Litkowski, S., and R. Shakir, "Segment		Decraene, B., Litkowski, S., and R. Shakir, "Segment
	Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,		Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
	July 2018, <https://www.rfc-editor.org/info/rfc8402>.		July 2018, <https://www.rfc-editor.org/info/rfc8402>.
	14.2. Informative References		14.2. Informative References
	[I-D.ali-spring-network-slicing-building-blocks]		[I-D.ali-spring-network-slicing-building-blocks]
	Ali, Z., Filsfils, C., Camarillo, P., and d.		Ali, Z., Filsfils, C., Camarillo, P., and d.
	daniel.voyer@bell.ca, "Building blocks for Slicing in		daniel.voyer@bell.ca, "Building blocks for Slicing in
	Segment Routing Network", draft-ali-spring-network-		Segment Routing Network", draft-ali-spring-network-
	slicing-building-blocks-01 (work in progress), March 2019.		slicing-building-blocks-01 (work in progress), March 2019.
	[I-D.auge-dmm-hicn-mobility-deployment-options]		[I-D.auge-dmm-hicn-mobility-deployment-options]
	Auge, J., Carofiglio, G., Muscariello, L., and M.		Auge, J., Carofiglio, G., Muscariello, L., and M.
	Papalini, "Anchorless mobility management through hICN		Papalini, "Anchorless mobility management through hICN
	(hICN-AMM): Deployment options", draft-auge-dmm-hicn-		(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
	mobility-deployment-options-01 (work in progress),		mobility-deployment-options-02 (work in progress), July
	December 2018.		2019.
	[I-D.camarillo-dmm-srv6-mobile-pocs]		[I-D.camarillo-dmm-srv6-mobile-pocs]
	Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,		Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,
	Matsushima, S., and d. daniel.voyer@bell.ca, "Segment		Matsushima, S., and d. daniel.voyer@bell.ca, "Segment
	Routing IPv6 for mobile user-plane PoCs", draft-camarillo-		Routing IPv6 for mobile user-plane PoCs", draft-camarillo-
	dmm-srv6-mobile-pocs-01 (work in progress), October 2018.		dmm-srv6-mobile-pocs-02 (work in progress), April 2019.
	[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]		[I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
	Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S.,		Camarillo, P., Filsfils, C., Elmalky, H., Matsushima, S.,
	daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6		daniel.voyer@bell.ca, d., Cui, A., and B. Peirens, "SRv6
	Mobility Use-Cases", draft-camarilloelmalky-springdmm-		Mobility Use-Cases", draft-camarilloelmalky-springdmm-
	srv6-mob-usecases-01 (work in progress), January 2019.		srv6-mob-usecases-01 (work in progress), January 2019.
	[I-D.gundavelli-dmm-mfa]		[I-D.gundavelli-dmm-mfa]
	Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-		Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
	aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01		aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-01
	skipping to change at page 26, line 16 ¶		skipping to change at page 26, line 44 ¶
	Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,		Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
	Camarillo, P., and C. Filsfils, "LISP Control Plane for		Camarillo, P., and C. Filsfils, "LISP Control Plane for
	SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-01		SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-01
	(work in progress), January 2019.		(work in progress), January 2019.
	[I-D.xuclad-spring-sr-service-programming]		[I-D.xuclad-spring-sr-service-programming]
	Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,		Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
	d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,		d., Li, C., Decraene, B., Ma, S., Yadlapalli, C.,
	Henderickx, W., and S. Salsano, "Service Programming with		Henderickx, W., and S. Salsano, "Service Programming with
	Segment Routing", draft-xuclad-spring-sr-service-		Segment Routing", draft-xuclad-spring-sr-service-
	programming-01 (work in progress), October 2018.		programming-02 (work in progress), April 2019.
	[TS.23501]		[TS.23501]
	3GPP, "System Architecture for the 5G System", 3GPP TS		3GPP, , "System Architecture for the 5G System", 3GPP TS
	23.501 15.0.0, November 2017.		23.501 15.0.0, November 2017.
	[TS.29244]		[TS.29244]
	3GPP, "Interface between the Control Plane and the User		3GPP, , "Interface between the Control Plane and the User
	Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.		Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.
	[TS.29281]		[TS.29281]
	3GPP, "General Packet Radio System (GPRS) Tunnelling		3GPP, , "General Packet Radio System (GPRS) Tunnelling
	Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,		Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
	December 2017.		December 2017.
	[TS.38415]		[TS.38415]
	3GPP, "Draft Specification for 5GS container (TS 38.415)",		3GPP, , "Draft Specification for 5GS container (TS
	3GPP R3-174510 0.0.0, August 2017.		38.415)", 3GPP R3-174510 0.0.0, August 2017.
	Appendix A. Implementations		Appendix A. Implementations
	This document introduces new SRv6 functions. These functions have an		This document introduces new SRv6 functions. These functions have an
	open-source P4 implementation available in		open-source P4 implementation available in
	<https://github.com/ebiken/p4srv6>.		<https://github.com/ebiken/p4srv6>.
	There are also implementations in M-CORD NGIC and Open Air Interface		There are also implementations in M-CORD NGIC and Open Air Interface
	(OAI). Further details can be found in		(OAI). Further details can be found in
	[I-D.camarillo-dmm-srv6-mobile-pocs].		[I-D.camarillo-dmm-srv6-mobile-pocs].
	Appendix B. Changes from revision 02 to revision 03
	This section lists the changes between draft-ietf-dmm-srv6-mobile-
	uplane revisions ...-02 and ...-03.
	o Added new terminology section for abbreviations.
	o Added new terminology section for predefined SRv6 functions.
	o Made terminology section for conventions used in the document.
	o Renamed "Basic" mode to be called "Traditional" mode.
	o Renamed "Aggregate" mode to be called "Enhanced" mode.
	o Added new Args.Mob.Session format to supply QFI, RQI indication
	and PDU Session ID.
	o Modified End.MAP function to define the SID argument format and
	support more than one SID
	o Added missing references.
	o Editorial updates to improve readability.
	Authors' Addresses		Authors' Addresses
	Satoru Matsushima		Satoru Matsushima
	SoftBank		SoftBank
	Tokyo		Tokyo
	Japan		Japan
	Email: satoru.matsushima@g.softbank.co.jp		Email: satoru.matsushima@g.softbank.co.jp
	Clarence Filsfils		Clarence Filsfils
End of changes. 57 change blocks.
	161 lines changed or deleted		168 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/