draft-ietf-dmm-5g-uplane-analysis-01.txt		draft-ietf-dmm-5g-uplane-analysis-02.txt
	DMM Working Group S. Homma		DMM Working Group S. Homma
	Internet-Draft NTT		Internet-Draft NTT
	Intended status: Informational T. Miyasaka		Intended status: Informational T. Miyasaka
	Expires: September 12, 2019 KDDI Research		Expires: January 9, 2020 KDDI Research
	S. Matsushima		S. Matsushima
	SoftBank		SoftBank
	D. Voyer		D. Voyer
	Bell Canada		Bell Canada
	March 11, 2019		July 8, 2019
	User Plane Protocol and Architectural Analysis on 3GPP 5G System		User Plane Protocol and Architectural Analysis on 3GPP 5G System
	draft-ietf-dmm-5g-uplane-analysis-01		draft-ietf-dmm-5g-uplane-analysis-02
	Abstract		Abstract
	This document analyzes the mobile user plane protocol and the		This document analyzes the mobile user plane protocol and the
	architecture specified in 3GPP 5G documents. The analysis work is to		architecture specified in 3GPP 5G documents. The analysis work is to
	clarify those specifications, extract protocol and architectural		clarify those specifications, extract protocol and architectural
	requirements and derive evaluation aspects for user plane protocols		requirements and derive evaluation aspects for user plane protocols
	on IETF side. This work is corresponding to the User Plane Protocol		on IETF side. This work is corresponding to the User Plane Protocol
	Study work on 3GPP side.		Study work on 3GPP side.
	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 http://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 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
	(http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3		1.1. Current Status of Mobile User Plane for 5G . . . . . . . 3
	1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 3		1.2. Our Way of Analysis Work . . . . . . . . . . . . . . . . 4
	2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4		2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4
	3. GTP-U Specification and Observation . . . . . . . . . . . . . 6		3. GTP-U Specification and Observation . . . . . . . . . . . . . 6
	3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6		3.1. GTP-U Tunnel . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10		3.2. GTP-U Header Format . . . . . . . . . . . . . . . . . . . 10
	3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12		3.3. Control Plane Protocol for GTP-U . . . . . . . . . . . . 12
	3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13		3.4. GTP-U message . . . . . . . . . . . . . . . . . . . . . . 13
	3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14		3.5. Packet Format . . . . . . . . . . . . . . . . . . . . . . 14
	3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16		3.6. Observations Summary . . . . . . . . . . . . . . . . . . 16
	4. 5GS Architectural Requirements for User Plane Protocols . . . 16		4. 5GS Architectural Requirements for User Plane Protocols . . . 16
	4.1. Overview of 5G System Architecture . . . . . . . . . . . 16		4.1. Overview of 5G System Architecture . . . . . . . . . . . 16
	4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18		4.1.1. UPF Functionalities . . . . . . . . . . . . . . . . . 18
	4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 18		4.1.2. UP Traffic Detection . . . . . . . . . . . . . . . . 19
	4.2. Architectural Requirements for User Plane Protocols . 20		4.1.3. User Plane Configuration . . . . . . . . . . . . . . 21
	5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 24		4.2. Architectural Requirements for User Plane Protocols . 22
	5.1. Supporting PDU Session Type Variations . . . . . . . . . 25		5. Evaluation Aspects . . . . . . . . . . . . . . . . . . . . . 28
	5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 25		5.1. Supporting PDU Session Type Variations . . . . . . . . . 29
	5.3. Supporting Transport Variations . . . . . . . . . . . . . 25		5.2. Nature of Data Path . . . . . . . . . . . . . . . . . . . 29
	5.4. Data Path Management . . . . . . . . . . . . . . . . . . 26		5.3. Supporting Transport Variations . . . . . . . . . . . . . 30
	5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 27		5.4. Data Path Management . . . . . . . . . . . . . . . . . . 30
	5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 27		5.5. QoS Control . . . . . . . . . . . . . . . . . . . . . . . 31
	5.7. Supporting Network Slicing Diversity . . . . . . . . . . 28		5.6. Traffic Detection and Flow Handling . . . . . . . . . . . 32
	6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 29		5.7. Supporting Network Slicing Diversity . . . . . . . . . . 32
	7. Security Consideration . . . . . . . . . . . . . . . . . . . 29		5.8. Reliable Communication support . . . . . . . . . . . . . 33
	8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 29		6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 33
	9. Informative References . . . . . . . . . . . . . . . . . . . 29		7. Security Consideration . . . . . . . . . . . . . . . . . . . 34
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34		8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 34
			9. Informative References . . . . . . . . . . . . . . . . . . . 34
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	This document analyzes the mobile user plane protocol and the		This document analyzes the mobile user plane protocol and the
	architecture specified by 3GPP 5G documents. The background of the		architecture specified by 3GPP 5G documents. The background of the
	work is that 3GPP requests through a liaison statement that the IETF		work is that 3GPP requests through a liaison statement that the IETF
	to provide any information for the User Plane Protocol Study work in		to provide any information for the User Plane Protocol Study work in
	3GPP [CP-180116-3GPP]. Justification and the objectives of the study		3GPP [CP-180116-3GPP]. Justification and the objectives of the study
	can be found from [CP-173160-3GPP].		can be found from [CP-173160-3GPP].
	skipping to change at page 17, line 16 ¶		skipping to change at page 17, line 16 ¶
	separated from the Control Plane (CP) functions for allowing		separated from the Control Plane (CP) functions for allowing
	independent scalability, evolution and flexible deployments.		independent scalability, evolution and flexible deployments.
	Network slicing is also one of the fundamental concepts of the 5G		Network slicing is also one of the fundamental concepts of the 5G
	system, and it provides logical network separation. In terms of user		system, and it provides logical network separation. In terms of user
	plane, multiple network slices can be comprised of UPFs on top of		plane, multiple network slices can be comprised of UPFs on top of
	same physical network resources. Allocated resources and structures		same physical network resources. Allocated resources and structures
	may be differentiated among the slices by which the required features		may be differentiated among the slices by which the required features
	or capabilities.		or capabilities.
			The 3GPP 5G architecture [TS.23.501-3GPP] defines slice types which
			are eMBB, URLLC and MIoT from Rel-15. In addition to that, V2X slice
			type is defined from Rel-16.
	The architecture overview is shown in Figure 5. The details of		The architecture overview is shown in Figure 5. The details of
	functions are described in [TS.23.501-3GPP]. A UPF handles UP paths		functions are described in [TS.23.501-3GPP]. A UPF handles UP paths
	on N3, N9 and N6 interface, and the setup is controlled by SMF via N4		on N3, N9 and N6 interface, and the setup is controlled by SMF via N4
	interface. A UP path will be manipulated based on application		interface. A UP path will be manipulated based on application
	requirements for the PDU session corresponding to the path. An SMF		requirements for the PDU session corresponding to the path. An SMF
	is also capable to receive information regarding routing path with		is also capable to receive information regarding routing path with
	API from AF via NEF, PCF, and SMF.		API from AF via NEF, PCF, and SMF.
	+-----+ +-----+ +-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
	|NSSF | | NEF | | NRF | | PCF | | UDM | | AF |		|NSSF | | NEF | | NRF | | PCF | | UDM | | AF |
	skipping to change at page 18, line 48 ¶		skipping to change at page 19, line 28 ¶
	o Downlink packet buffering and downlink data notification		o Downlink packet buffering and downlink data notification
	triggering.		triggering.
	o Sending and forwarding of one or more "end marker" to the source		o Sending and forwarding of one or more "end marker" to the source
	NG-RAN node.		NG-RAN node.
	o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the		o ARP proxying and / or IPv6 Neighbour Solicitation Proxying for the
	Ethernet PDUs.		Ethernet PDUs.
			o Packet duplication in downlink direction and elimination in uplink
			direction in UP protocol layer.
			o TSN Translator functionality to hold and forward user plane
			packets for de-jittering when 5G System is integrated as a bridge
			with the TSN network.
	4.1.2. UP Traffic Detection		4.1.2. UP Traffic Detection
	The traffic detection is described in the section 5.8.2.4 of		The traffic detection is described in the section 5.8.2.4 of
	[TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP		[TS.23.501-3GPP]. In 3GPP UP packet forwarding model, UPF detects UP
	traffic flow which belong to a N4 session configured by SMF.		traffic flow which belong to a N4 session configured by SMF.
	The protocol of N4 interface, PFCP, brings a set of traffic detection		The protocol of N4 interface, PFCP, brings a set of traffic detection
	information from SMF to UPF as Packet Detection Information (PDI) in		information from SMF to UPF as Packet Detection Information (PDI) in
	a PDR to establish/modify the N4 PFCP session. It is defined in		a PDR to establish/modify the N4 PFCP session. It is defined in
	section 7.5.2.2 of [TS.29.244-3GPP].		section 7.5.2.2 of [TS.29.244-3GPP].
	skipping to change at page 20, line 33 ¶		skipping to change at page 21, line 20 ¶
	fields as defined in IEEE 802.1Q		fields as defined in IEEE 802.1Q
	* Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI		* Customer-VLAN tag(C-TAG) and/or Service-VLAN tag(S-TAG) PCP/DEI
	fields as defined in IEEE 802.1Q		fields as defined in IEEE 802.1Q
	* IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6		* IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6
	payload		payload
	* Packet filter direction		* Packet filter direction
			4.1.3. User Plane Configuration
			User Plane configuration on a UPF is managed by an SMF through PFCP
			[TS.29.244-3GPP]. The SMF establishes PFCP sessions on the UPF per
			PDU session basis. The UPF maintains each configured PFCP session
			states during the sessions exist.
			A PFCP session consists of the rules of packet detection, forwarding
			action, QoS enforcement, usage reporting and buffering action.
			Figure 6 depicts overview of the PFCP session state structure.
			The listed information in Section 4.1.2 indicates packet detection
			information of packet detection rule for that the rest of related
			rules within the PFCP session to be derived. All rules are per
			session unique and no rules are shared with other sessions.
			PFCP-Session* [F-SEID]
			+- F-SEID(Full Qualified Session Endpoint ID) uint64
			+- PDU-Session-Type [IPv4|IPv6|IPv4v6|Ether|Unstrct]
			+- DNN(Data Network Name)
			+- PDR(Packet Detection Rule)* [PDR-ID]
			| +- PDR-ID uint16
			| +- PDI (Packet Detection Information)
			| | +- Traffic-Endpoint-ID? -> Traffic-Endpoint-ID reference
			| | +- ....
			| +- FAR/URR/QER-ID -> FAR/URR/QER-ID references
			+- FAR(Forwarding Action Rule)* [FAR-ID]
			| +- FAR-ID uint32
			| +- Forwarding-Parameters
			| | +- Network-Instance? Octet String
			| | +- Outer-Header-Creation
			| | | +- Outer-Hdr-Creation-Desc [GTPoUDP/IPv4|IPv6, etc.,]
			| | | +- TEID, outer IP-Address for N3/N9
			| | | +- C/S-TAG, UDP Port-number for N6
			| | +- Forwarding-Policy-ID? Octet String
			| | +- ....
			| +- Duplicating-Parameters
			| | +- ....
			| +- BAR-ID? -> BAR-ID reference
			+- QER(QoS Enforcement Rule)* [QER-ID]
			| +- QER-ID uint32
			| +- MBR(Maximum Bit Rate)
			| | +- UL/DL-MBR? bitrate_in_kbps (0..10000000)
			| +- GBR(Guaranteed Bit Rate)
			| | +- UL/DL-GBR? bitrate_in_kbps (0..10000000)
			| +- QoS-flow-identifier? QFI value(6-bits)
			| +- Reflective-QoS? boolean
			| +- Paging-Policy-Indicator? PPI value(3-bits)
			| +- ....
			+- URR(Usage Reporting Rule)* [URR-ID]
			| +- URR-ID uint32
			| +- Measurement-Method, Period, Reporting-Triggers?
			| +- Volume/Event/Time Threshold, Quota?
			| +- Quota-Holding-Time?
			| +- FAR-ID for Quota action? -> FAR-ID reference
			| +- ....
			+- BAR(Buffering Action Rule)* [BAR-ID]
			| +- BAR-ID uint8
			| +- Suggested-Buffering-Packets-Count
			+- Traffic-Endpoint* [Traffic-Endpoint-ID]
			+- Traffic-Endpoint-ID uint8
			+- TEID, Tunnle IP Address, UE Address...?
			Figure 6: User Plane Configuration Model
	4.2. Architectural Requirements for User Plane Protocols		4.2. Architectural Requirements for User Plane Protocols
	This section lists the requirements for the UP protocol on the 5G		This section lists the requirements for the UP protocol on the 5G
	system. The requirements are picked up from [TS.23.501-3GPP]. In		system. The requirements are picked up from [TS.23.501-3GPP]. In
	addition, some of service requirements described in [TS.22.261-3GPP]		addition, some of service requirements described in [TS.22.261-3GPP]
	are referred to clarify the originations of architectural		are referred to clarify the originations of architectural
	requirements.		requirements.
	According to [TS.23.501-3GPP], the specifications potentially have		According to [TS.23.501-3GPP], the specifications potentially have
	assumptions that the UP protocol is a tunnel representing a single		assumptions that the UP protocol is a tunnel representing a single
	skipping to change at page 21, line 40 ¶		skipping to change at page 23, line 45 ¶
	ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a		ARCH-Req-3: Supporting deployment of multiple UPFs as anchors for a
	single PDU session		single PDU session
	The 5G system allows to deploy multiple UPFs as anchors for a single		The 5G system allows to deploy multiple UPFs as anchors for a single
	PDU session, and supports multihoming of a single PDU session for		PDU session, and supports multihoming of a single PDU session for
	such anchor UPFs.		such anchor UPFs.
	Multihoming is provided with Branching Point (BP). BP provides		Multihoming is provided with Branching Point (BP). BP provides
	forwarding of UL traffic towards the different PDU Session Anchors		forwarding of UL traffic towards the different PDU Session Anchors
	based on the source IPv6 prefixes and merge of DL traffic to the UE.		based on the source IPv6 prefixes and merge of DL traffic to the UE.
	UL CL provides destination based multihoming for load balancing.		IPv6 multihoming only means multiple source IPv6 prefixes are used
			for a PDU session. It is identical to one classified as scenario 1
			in [RFC7157].
	Noted that, in 3GPP definition, IPv6 multihoming indicates only cases		Up link classifier (UL CL) is to forward uplink packets to multiple
	where "multiple" source IPv6 prefixes are used, and it is different		anchor UPFs based on the destination IP of the T-PDU regardless of
	from IETF definition. Actually, in the 5GS, Up link classifier (UL		the source IP address. Noted that single source IP address/prefix
	CL) is capable to provide forwarding to multiple anchor for a PDU		PDU session is not defined as multihoming PDU session in 5GCS even
	session with a single source IPv6 prefix, but it is distinguished		though a PDU session has multiple anchor UPFs.
	from IPv6 multihoming.
	On UL side, multihoming of a single PDU session is achieved by a		On UL side, P2P tunnels are established per destination anchor UPFs
	point-to-point (P2P) tunnel per anchor UPF. It means that multiple		basis from one UL CL UPF to the anchor UPFs for the PDU session.
	P2P paths are established from one source gNB or UPF to the multiple
	destination anchor UPFs for the PDU session.
	On DL side, one single multipoint-to-point (MP2P) path exists from		On DL side, one single multipoint-to-point (MP2P) tunnel exists from
	the anchor UPFs to the destination gNB or UPF for the PDU session in		the source anchor UPFs to the destination BP UPF for the PDU session.
	this multihoming case. It means that the paths from the anchor UPFs		It means that the paths from the anchor UPFs are merged into just one
	are merged into just one tunnel state at the source gNB or UPF for		tunnel state at the destination BP UPF.
	the PDU session.
	Multiple P2P paths on DL could also be used for multihoming. However		Multiple P2P paths on DL could also be used for multihoming. However
	it should be the multiple PDU sessions multihoming case where the		it should be the multiple PDU sessions multihoming case where the
	destination gNB or UPF needs to maintain multiple tunnel states under		destination gNB or UPF needs to maintain multiple tunnel states under
	the one PDU session to one UP tunnel architectural principle. It		the one PDU session to one UP tunnel architectural principle. It
	causes increase of load on tunnel states management in UPF due to		causes increase of load on tunnel states management in UPF due to
	increment of the anchor UPF for the PDU session.		increment of the anchor UPF for the PDU session.
	However, P2P tunneling could increase explosively the number of		However, P2P tunneling could increase explosively the number of
	states in UPF as the anchor UPF/DN incremented to the PDU session.		states in UPF as the anchor UPF/DN incremented to the PDU session.
	skipping to change at page 24, line 41 ¶		skipping to change at page 26, line 46 ¶
	ARCH-Req-8: End Marker support		ARCH-Req-8: End Marker support
	The construction of End Marker packets specified in [TS.23.501-3GPP]		The construction of End Marker packets specified in [TS.23.501-3GPP]
	may either be done in the CP/UP functions for indicating the end of		may either be done in the CP/UP functions for indicating the end of
	the payload stream on a given UP tunnel. PDU packets arrive after an		the payload stream on a given UP tunnel. PDU packets arrive after an
	End Marker message on the tunnel may be silently discarded. For		End Marker message on the tunnel may be silently discarded. For
	example, End Maker is used for handover procedures, and it can		example, End Maker is used for handover procedures, and it can
	prevent reordering of arriving packets due to switch of anchor UPFs.		prevent reordering of arriving packets due to switch of anchor UPFs.
			ARCHI-Req-9: Supporting URLLC
			The 5G is expected to support services which are latency sensitive
			and require high reliability. Communication to realize such services
			is called Ultra-Reliable and Low-Latency Communication or URLLC. In
			URLLC, redundancy of QoS flows is required for providing highly
			reliable communication. For instance, a set of UP NFs (e.g., UPF or
			gNB) and interfaces between UE and DN are redundant, and packets are
			replicated and forwarded via each route. UEs and DN support dual
			connectivity and drop duplicated received packets. The scheme of
			packet dropping at UE is out of responsibility of 3GPP. The overview
			is shown in Figure 7.
			---+-----------+----------+---
			Namf| Nsmf| Nsmf|
			+--+--+ +--+--+ +--+--+
			| AMF | | SMF1| | SMF3|
			+-+---+ +--+--+ +-+---+
			/ / /
			N2/ N4/ N4/
			/ / /
			+----++ N3 +--+---+ / N6 +----+
			|M-RAN+--------+ UPF1 +--------------+ |
			++-+--+ +-+--+-+ / | |
			/ | | | / | |
			+----+ / | +--+ / | |
			| UE +< |Xn N9 / | DN |
			+----+ \ | / | |
			\ | / | |
			++-+--+ N3 +----+-+ N6 | |
			|S-RAN+--------+ UPF2 +--------------+ |
			+-----+ +-+--+-+ +----+
			| |
			+--+
			N9
			*Legends
			M-RAN: Master RAN
			S-RAN: Secondary RAN
			Figure 7: Redundant UP paths using dual connectivity
			Otherwise, in case that RAN nodes and UPFs have enough reliability
			and they are not redundant by dual devices, reliable connectivity of
			QoS flows is provided by dual N3 tunnels between RAN and UPFs. Such
			tunnels are treated as individual ones, but they have the same
			sequence number. UP NFs identifies the duplication of PDU packets
			based on sequence number content in the UP tunnel headers. For
			uplink packets, a RAN node replicates each packet from a UE. An
			anchor UPF receives the duplicated packets, and drops ones which
			reach later in each duplicated packet pare. On the other hand, for
			downlink packets, a UPF replicates packets received from DN, and a
			RAN node drops the duplicated packets as well. The overviews of the
			ways are shown in Figure 8.
			----+-----------+-----------+---
			Namf| Nsmf| Npcf|
			+--+--+ +--+--+ +--+--+
			| AMF | | SMF | | PCF |
			+-+---+ +--+--+ +-----+
			/ |
			N2/ N4|
			/ N3 Tunnel1 |
			+----+ +--+--+__________+--+--+ N6 +----+
			| UE +----+ RAN |__________| UPF |-----+ DN |
			+----+ +-----+ +-----+ +----+
			N3 Tunnel2
			Figure 8: Redundant UP transmission with two N3 tunnels
			In addition, there is a case that two intermediate UPFs (I-UPFs)
			between anchor UPF and RAN are used to support the redundant
			transmission based on two N3 and N9 tunnels between single anchor UPF
			and RAN node. The RAN node and anchor UPF support the packet
			replication and dropping of duplicated packets as described above.
			As described above, anchor UPF and RAN node detect packet duplication
			with sequence number of UP tunnels, and thus I-UPFs would forward the
			packets with the same sequence number on N3 and N9 tunnels. The
			overview is shown in Figure 9.
			----+-------------+--------------+---
			Namf| Nsmf| Npcf|
			+--+--+ +---+---+ +--+--+
			| AMF | | SMF + | PCF |
			+--+--+ +-+-+-+-+ +-----+
			/ | | |
			N2 / N4| | +----------------+
			/ | | |
			/ N3 Tunnel1 +-+-+---+ N9 Tunnel1 |
			/ +-----+I-UPF1 +----+ |
			+----+ +--+--+______| +-------+ |______+--+--+ N6 +----+
			| UE +---+ RAN |______ | ______| UPF +-----+ DN |
			+----+ +-----+ N3 | +---+---+ | N9 +-----+ +----+
			+-----+I-UPF2 +----+
			N3 Tunnel2 +-------+ N9 Tunnel2
			Figure 9: Redundant UP transmission with two I-UPF and N3/N9 tunnels
	5. Evaluation Aspects		5. Evaluation Aspects
	This section provides UP protocol evaluation aspects that are mainly		This section provides UP protocol evaluation aspects that are mainly
	we derived from the architectural requirements described in		we derived from the architectural requirements described in
	Section 4. Those aspects are not prioritized by the order here.		Section 4. Those aspects are not prioritized by the order here.
	Expected deployment scenarios explain the evaluations purpose in the		Expected deployment scenarios explain the evaluations purpose in the
	corresponding aspects.		corresponding aspects.
	As we were noticed that the gaps between GTP-U specifications and 5G		As we were noticed that the gaps between GTP-U specifications and 5G
	architectural requirements through the analysis, those each gap are		architectural requirements through the analysis, those each gap are
	briefly described in the evaluation aspect associated to it.		briefly described in the evaluation aspect associated to it.
	Since it is obvious that 5G system should be able to interwork with		Since it is obvious that 5G system should be able to interwork with
	existing previous generation based systems, any aspects from		existing previous generation based systems, any aspects from
	coexisting and interworking point of view are not particularly		coexisting and interworking point of view are not particularly
	skipping to change at page 29, line 15 ¶		skipping to change at page 33, line 22 ¶
	Option 2 and 3 are expected as IP domain separation, but it is hard		Option 2 and 3 are expected as IP domain separation, but it is hard
	to see that it is able to indicate transport slice in addition to the		to see that it is able to indicate transport slice in addition to the
	IP domain. Other L2 and tunneling solutions should be same with		IP domain. Other L2 and tunneling solutions should be same with
	those options.		those options.
	The expected evaluation points from this aspect should be whether the		The expected evaluation points from this aspect should be whether the
	candidate protocols can contain forwarding information associated to		candidate protocols can contain forwarding information associated to
	the assigned IP domain and transport slice for all possible		the assigned IP domain and transport slice for all possible
	deployment cases.		deployment cases.
			5.8. Reliable Communication support
			As Section 4.2 described, more than two UP paths are required for a
			QoS flow of a PDU session between the anchor UPF and gNB. Those UP
			paths are to convey redundant duplicated packets.
			To support reliable communication with above requirements, UPF and
			gNB must replicate the sending UP packets and eliminate the received
			duplicated UP packets. Not to mention that UP protocol should be
			able to make sure that the paths are not in fate sharing, the UP
			packet must have sequence number to indicate duplicate packets per
			QoS flow basis.
			The expected evaluation points from this aspect should be whether the
			candidate protocols can indicate packet sequence and diversed paths
			in the context of QoS flow, not in UP tunnel context. The packet
			sequence information should be transparent through I-UPF(s) exist in
			the middle of the path even in case that the UP tunnels are
			terminated at the I-UPF(s).
	6. Conclusion		6. Conclusion
	We analyzed the 3GPP specifications of the 5G architecture in terms		We analyzed the 3GPP specifications of the 5G architecture in terms
	of user plane and the current protocol adopted to the user plane.		of user plane and the current protocol adopted to the user plane.
	After the analysis work, we believe that the results described in		After the analysis work, we believe that the results described in
	this document shows that we reach at certain level of understanding		this document shows that we reach at certain level of understanding
	on the 5G systems and ready to provide our inputs to 3GPP.		on the 5G systems and ready to provide our inputs to 3GPP.
	We clarified GTP-U through the analysis and listed observed		We clarified GTP-U through the analysis and listed observed
	characteristics in Section 3.6. We also clarified the architectural		characteristics in Section 3.6. We also clarified the architectural
	skipping to change at page 30, line 25 ¶		skipping to change at page 34, line 48 ¶
	Docs/CP-173160.zip>.		Docs/CP-173160.zip>.
	[CP-180116-3GPP]		[CP-180116-3GPP]
	3rd Generation Partnership Project (3GPP), "LS on user		3rd Generation Partnership Project (3GPP), "LS on user
	plane protocol study", March 2018,		plane protocol study", March 2018,
	<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/		<http://www.3gpp.org/ftp/tsg_ct/TSG_CT/TSGC_79_Chennai/
	Docs/CP-180116.zip>.		Docs/CP-180116.zip>.
	[IAB-Statement]		[IAB-Statement]
	Internet Architecture Board (IAB), "IAB Statement on		Internet Architecture Board (IAB), "IAB Statement on
	IPv6", November 2016, <https://www.iab.org/2016/11/07/iab-		IPv6", November 2016,
	statement-on-ipv6/>.		<https://www.iab.org/2016/11/07/iab-statement-on-ipv6/>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <https://www.rfc-editor.org/info/rfc2460>.		December 1998, <https://www.rfc-editor.org/info/rfc2460>.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	2006, <https://www.rfc-editor.org/info/rfc4364>.		2006, <https://www.rfc-editor.org/info/rfc4364>.
	[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer		[RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer
	2 Virtual Private Networks (L2VPNs)", RFC 4664,		2 Virtual Private Networks (L2VPNs)", RFC 4664,
	DOI 10.17487/RFC4664, September 2006, <https://www.rfc-		DOI 10.17487/RFC4664, September 2006,
	editor.org/info/rfc4664>.		<https://www.rfc-editor.org/info/rfc4664>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007, <https://www.rfc-		DOI 10.17487/RFC4861, September 2007,
	editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification", RFC 6437,		"IPv6 Flow Label Specification", RFC 6437,
	DOI 10.17487/RFC6437, November 2011, <https://www.rfc-		DOI 10.17487/RFC6437, November 2011,
	editor.org/info/rfc6437>.		<https://www.rfc-editor.org/info/rfc6437>.
	[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label		[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
	for Equal Cost Multipath Routing and Link Aggregation in		for Equal Cost Multipath Routing and Link Aggregation in
	Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,		Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
	<https://www.rfc-editor.org/info/rfc6438>.		<https://www.rfc-editor.org/info/rfc6438>.
	[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and		[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and
	UDP Checksums for Tunneled Packets", RFC 6935,		UDP Checksums for Tunneled Packets", RFC 6935,
	DOI 10.17487/RFC6935, April 2013, <https://www.rfc-		DOI 10.17487/RFC6935, April 2013,
	editor.org/info/rfc6935>.		<https://www.rfc-editor.org/info/rfc6935>.
			[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T.,
			and D. Wing, "IPv6 Multihoming without Network Address
			Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014,
			<https://www.rfc-editor.org/info/rfc7157>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017, <https://www.rfc-		DOI 10.17487/RFC8200, July 2017,
	editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	[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>.
	[TR.29.891-3GPP]		[TR.29.891-3GPP]
	3rd Generation Partnership Project (3GPP), "3GPP TR 29.891		3rd Generation Partnership Project (3GPP), "3GPP TR 29.891
	(V15.0.0): 5G System Phase 1, CT WG4 Aspects", December		(V15.0.0): 5G System Phase 1, CT WG4 Aspects", December
	2017, <http://www.3gpp.org/FTP/Specs/2017-12/		2017, <http://www.3gpp.org/FTP/Specs/2017-12/
	skipping to change at page 31, line 46 ¶		skipping to change at page 36, line 26 ¶
	[TS.23.060-3GPP]		[TS.23.060-3GPP]
	3rd Generation Partnership Project (3GPP), "3GPP TS 23.060		3rd Generation Partnership Project (3GPP), "3GPP TS 23.060
	(V15.3.0): General Packet Radio Service (GPRS); Service		(V15.3.0): General Packet Radio Service (GPRS); Service
	description; Stage 2", June 2018,		description; Stage 2", June 2018,
	<http://www.3gpp.org/ftp//Specs/		<http://www.3gpp.org/ftp//Specs/
	archive/23_series/23.060/23060-f30.zip>.		archive/23_series/23.060/23060-f30.zip>.
	[TS.23.501-3GPP]		[TS.23.501-3GPP]
	3rd Generation Partnership Project (3GPP), "3GPP TS 23.501		3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
	(V15.4.0): System Architecture for 5G System; Stage 2",		(V16.1.0): System Architecture for 5G System; Stage 2",
	December 2018, <http://www.3gpp.org/ftp//Specs/		June 2019, <http://www.3gpp.org/ftp//Specs/
	archive/23_series/23.501/23501-f40.zip>.		archive/23_series/23.501/23501-g10.zip>.
	[TS.23.502-3GPP]		[TS.23.502-3GPP]
	3rd Generation Partnership Project (3GPP), "3GPP TS 23.502		3rd Generation Partnership Project (3GPP), "3GPP TS 23.502
	(V15.4.0): Procedures for 5G System; Stage 2", December		(V15.4.0): Procedures for 5G System; Stage 2", December
	2018, <http://www.3gpp.org/FTP/Specs/2018-03/		2018, <http://www.3gpp.org/FTP/Specs/2018-03/
	Rel-15/23_series/23502-f40.zip>.		Rel-15/23_series/23502-f40.zip>.
	[TS.23.503-3GPP]		[TS.23.503-3GPP]
	3rd Generation Partnership Project (3GPP), "3GPP TS 23.503		3rd Generation Partnership Project (3GPP), "3GPP TS 23.503
	(V15.4.0): Policy and Charging Control System for 5G		(V15.4.0): Policy and Charging Control System for 5G
End of changes. 25 change blocks.
	53 lines changed or deleted		252 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/