< draft-ietf-sfc-nsh-ecn-support-02.txt		draft-ietf-sfc-nsh-ecn-support-03.txt >
	INTERNET-DRAFT Donald Eastlake		INTERNET-DRAFT Donald Eastlake
	Intended status: Proposed Standard Futurewei Technologies		Intended status: Proposed Standard Futurewei Technologies
	Bob Briscoe		Bob Briscoe
	Independent		Independent
	Andrew Malis		Andrew Malis
	Futurewei Technologies		Independent
	Expires: June 31, 2020 January 1, 2020		Expires: January 1, 2021 July 2, 2020
	Explicit Congestion Notification (ECN) and Congestion Feedback		Explicit Congestion Notification (ECN) and Congestion Feedback
	Using the Network Service Header (NSH)		Using the Network Service Header (NSH)
	<draft-ietf-sfc-nsh-ecn-support-02.txt>		<draft-ietf-sfc-nsh-ecn-support-03.txt>
	Abstract		Abstract
	Explicit congestion notification (ECN) allows a forwarding element to		Explicit congestion notification (ECN) allows a forwarding element to
	notify downstream devices of the onset of congestion without having		notify downstream devices of the onset of congestion without having
	to drop packets. Coupled with a means to feed back information about		to drop packets. Coupled with a means to feed back information about
	congestion to upstream nodes, this can improve network efficiency		congestion to upstream nodes, this can improve network efficiency
	through better congestion control, frequently without packet drops.		through better congestion control, frequently without packet drops.
	This document specifies ECN and congestion feedback support within a		This document specifies ECN and congestion feedback support within a
	Service Function Chaining (SFC) domain through use of the Network		Service Function Chaining (SFC) domain through use of the Network
	skipping to change at page 3, line 5 ¶		skipping to change at page 2, line 35 ¶
	4. Tunnel Congestion Feedback Support.....................15		4. Tunnel Congestion Feedback Support.....................15
	5. IANA Considerations....................................16		5. IANA Considerations....................................16
	6. Security Considerations................................17		6. Security Considerations................................17
	7. Acknowledgements.......................................17		7. Acknowledgements.......................................17
	Normative References......................................18		Normative References......................................18
	Informative References....................................19		Informative References....................................19
			Authors' Addresses........................................20
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	1. Introduction		1. Introduction
	Explicit congestion notification (ECN [RFC3168]) allows a forwarding		Explicit congestion notification (ECN [RFC3168]) allows a forwarding
	element to notify downstream devices of the onset of congestion		element to notify downstream devices of the onset of congestion
	without having to drop packets. Coupled with a means to feed back		without having to drop packets. Coupled with a means to feed back
	information about congestion to upstream nodes, this can improve		information about congestion to upstream nodes, this can improve
	network efficiency through better congestion control, frequently		network efficiency through better congestion control, frequently
	without packet drops. This document specifies ECN and congestion		without packet drops. This document specifies ECN and congestion
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	domain through use of the Network Service Header (NSH [RFC8300]) and		domain through use of the Network Service Header (NSH [RFC8300]) and
	IP Flow Information Export (IPFIX [TunnelCongFeedback]).		IP Flow Information Export (IPFIX [TunnelCongFeedback]).
	It requires that all ingress and egress nodes of the SFC domain		It requires that all ingress and egress nodes of the SFC domain
	implement ECN. While congestion management will be the most effective		implement ECN. While congestion management will be the most effective
	if all interior nodes of the SFC domain implement ECN, some benefit		if all interior nodes of the SFC domain implement ECN, some benefit
	is obtained even if some interior nodes do not implement ECN. In		is obtained even if some interior nodes do not implement ECN. In
	particular, congestion at any bottleneck where ECN marking is not		particular, congestion at any bottleneck where ECN marking is not
	implemented will be unmanaged.		implemented will be unmanaged.
	The subsections below in this is section provide background		The subsections below in this section provide background information
	information on NSH, ECN, congestion feedback, and terminology used in		on NSH, ECN, congestion feedback, and terminology used in this
	this document.		document.
	1.1 NSH Background		1.1 NSH Background
	The Service Function Chaining (SFC [RFC7665]) architecture calls for		The Service Function Chaining (SFC [RFC7665]) architecture calls for
	the encapsulation of traffic within a service function chaining		the encapsulation of traffic within a service function chaining
	domain with a Network Service Header (NSH [RFC8300]) added by the		domain with a Network Service Header (NSH [RFC8300]) added by the
	"Classifier" (ingress node) on entry to the domain and the NSH being		"Classifier" (ingress node) on entry to the domain and the NSH being
	removed on exit from the domain at the egress node. The NSH is used		removed on exit from the domain at the egress node. The NSH is used
	to control the path of a packet in an SFC domain. The NSH is a		to control the path of a packet in an SFC domain. The NSH is a
	natural place, in a domain where traffic is NSH encapsulated, to note		natural place, in a domain where traffic is NSH encapsulated, to note
	skipping to change at page 4, line 46 ¶		skipping to change at page 4, line 46 ¶
	. v +----+ .		. v +----+ .
	. +------+ .		. +------+ .
	. . .| Exit |. . . . . . . . . . . . . . .		. . .| Exit |. . . . . . . . . . . . . . .
	+------+		+------+
	|		|
	v		v
	Figure 1. Example SFC Path Forwarding Nodes		Figure 1. Example SFC Path Forwarding Nodes
	Figure 1 shows an SFC domain for the purpose of illustrating the use		Figure 1 shows an SFC domain for the purpose of illustrating the use
	of NSH. Traffic passes through a sequence of Service Function		of the NSH. Traffic passes through a sequence of Service Function
	Forwarders (SFFs) each of which sends the traffic to one or more		Forwarders (SFFs) each of which sends the traffic to one or more
	Service Functions (SFs). Each SF performs some operation on the		Service Functions (SFs). Each SF performs some operation on the
	traffic, for example firewall or Network Address Translation (NAT),		traffic, for example firewall or Network Address Translation (NAT),
	and then returns it to the SFF from which it was received.		and then returns it to the SFF from which it was received.
	Logically, during the transit of each SFF, the outer transport header		Logically, during the transit of each SFF, the outer transport header
	that got the packet to the SFF is stripped, the SFF decides on the		that got the packet to the SFF is stripped, the SFF decides on the
	next forwarding step, either adding a transport header or, if the SFF		next forwarding step, either adding a transport header or, if the SFF
	is the exit/egress, removing the NSH header. The transport headers		is the exit/egress, removing the NSH header. The transport headers
	skipping to change at page 5, line 48 ¶		skipping to change at page 5, line 48 ¶
	(1) Traffic throttling (policing), where the downstream traffic		(1) Traffic throttling (policing), where the downstream traffic
	flowing out of the ingress node is limited to reduce or eliminate		flowing out of the ingress node is limited to reduce or eliminate
	congestion.		congestion.
	(2) Upstream congestion feedback, where the ingress node sends		(2) Upstream congestion feedback, where the ingress node sends
	messages upstream to or towards the ultimate traffic source, a		messages upstream to or towards the ultimate traffic source, a
	function that can throttle traffic generation/transmission.		function that can throttle traffic generation/transmission.
	(3) Traffic re-direction, where the ingress node configures the NSH		(3) Traffic re-direction, where the ingress node configures the NSH
	of some future traffic so that it avoids congested paths. Great		of some future traffic so that it avoids congested paths. Great
	care must be taken to avoid (a) significant re-ordering of		care must be taken with this option to avoid (a) significant re-
	traffic in flows that it is desirable to keep in order and (b)		ordering of traffic in flows that it is desirable to keep in
	oscillation/instability in traffic paths due to alternate		order and (b) oscillation/instability in traffic paths due to
	congestion of previously idle paths and the idling of previously		alternate congestion of previously idle paths and the idling of
	congested paths. For example, it is preferable to classify		previously congested paths. For example, it is preferable to
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	traffic into flows of a sufficiently coarse granularity that the		classify traffic into flows of a sufficiently coarse granularity
	flows are long lived and use a stable path per flow, then send		that the flows are long lived and then use a stable path per
	only newly appearing flows on apparently uncongested paths.		flow, sending only newly appearing flows on apparently
			uncongested paths.
	Figure 2 shows an example path from an origin sender to a final		Figure 2 shows an example path from an origin sender to a final
	receiver passing through an example chain of service functions		receiver passing through an example chain of service functions
	between the ingress and egress of an SFC domain. The path is also		between the ingress and egress of an SFC domain. The path is also
	likely to pass through other network nodes outside the SFC domain		likely to pass through other network nodes outside the SFC domain
	(not shown). The figure shows typical congestion feedback that would		(not shown). The figure shows typical congestion feedback that would
	be expected from the final receiver to the origin sender, which		be expected from the final receiver to the origin sender, which
	controls the load the origin sender applies to all elements on the		controls the load the origin sender applies to all elements on the
	path. The figure also shows the congestion feedback from the egress		path. The figure also shows the congestion feedback from the egress
	to the ingress of the SFC domain that is described in this document,		to the ingress of the SFC domain that is described in this document,
	to control or balance load within the SFC domain.		to control or balance load within the SFC domain.
	.:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :.		.:= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = :.
	_||_ End-to-End Congestion Feedback ||		_||_ End-to-End Congestion Feedback ||
	\ / ||		\ / ||
	\/ ||		\/ ||
	Inner Transport Header and Payload __		__ Inner Transport Header and Payload __
	| | - - - - - - - - - - - - - - - ->- - - - - -- - - - - - - - | |		| | ->- - - - - - - - - - - - - - ->- - - - - -- - - - - - ->- | |
	| | | |		| | | |
	| | .:= = = = = = = = = = = = = = = = = = = = = =:. | |		| | .:= = = = = = = = = = = = = = = = = = = = = =:. | |
	| | _||_ Tunnel Congestion Feedback || | |		| | _||_ Tunnel Congestion Feedback || | |
	| | \ / || | |		| | \ / || | |
	| | \/ || | |		| | \/ || | |
	| | __ NSH __ | |		| | __ NSH __ | |
	| | | |-------------------------->--------------| | | |		| | | |-------------------------->--------------| | | |
	| |. . . | | ___ ___ ___ | |. . .| |		| |. . . | | ___ ___ ___ | |. . .| |
	| | | | OT1 | | OT4 | | . . . | | OTn | | | |		| | | | OT1 | | OT4 | | . . . | | OTn | | | |
	| | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | |		| | | |-->--|SFF|--->---|SFF| |SFF|-->--| | | |
	skipping to change at page 11, line 17 ¶		skipping to change at page 11, line 17 ¶
	3.1 At The Ingress		3.1 At The Ingress
	When the ingress/Classifier encapsulates an incoming IP packet with		When the ingress/Classifier encapsulates an incoming IP packet with
	an NSH, it MUST set the NSH ECN field using the "Normal mode"		an NSH, it MUST set the NSH ECN field using the "Normal mode"
	specified in [RFC6040] (i.e., copied from the incoming IP header).		specified in [RFC6040] (i.e., copied from the incoming IP header).
	Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD		Then, if the resulting NSH ECN field is Not-ECT, the ingress SHOULD
	set it to ECT(0). This indicates that, even though the end-to-end		set it to ECT(0). This indicates that, even though the end-to-end
	transport is not ECN-capable, the egress and ingress of the SFC		transport is not ECN-capable, the egress and ingress of the SFC
	domain are acting as an ECN-capable transport. This approach will		domain are acting as an ECN-capable transport. This approach will
	inherently support all known variatns of ECN, including the		inherently support all known variants of ECN, including the
	experimental L4S capability [RFC8311], [ecnL4S].		experimental L4S capability [RFC8311] [ecnL4S].
	Packets arriving at the ingress might not use IP. If the protocol of		Packets arriving at the ingress might not use IP. If the protocol of
	arriving packets supports an ECN field similar to IP, the procedures		arriving packets supports an ECN field similar to IP, the procedures
	for IP packets can be used. If arriving packets do not support an ECN		for IP packets can be used. If arriving packets do not support an ECN
	field similar to IP, they MUST be treated as if they are Not-ECT IP		field similar to IP, they MUST be treated as if they are Not-ECT IP
	packets.		packets.
	Then, as the NSH encapsulated packet is further encapsulated with a		Then, as the NSH encapsulated packet is further encapsulated with a
	transport header, if ECN marking is available for that transport (as		transport header, if ECN marking is available for that transport (as
	it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the		it is for IP [RFC3168] and MPLS [RFC5129]), the ECN field of the
	skipping to change at page 13, line 26 ¶		skipping to change at page 13, line 26 ¶
	If the SF is not NSH-aware, then an NSH proxy will be between the SFF		If the SF is not NSH-aware, then an NSH proxy will be between the SFF
	and the SF to avoid exposure of the NSH at the SF that does not		and the SF to avoid exposure of the NSH at the SF that does not
	understand NSHs. This is described in Section 4.6 of [RFC7665]. The		understand NSHs. This is described in Section 4.6 of [RFC7665]. The
	SF and proxy together look to the SFF like an NSH-aware SF. The		SF and proxy together look to the SFF like an NSH-aware SF. The
	behavior at the proxy and SF in this case is as below:		behavior at the proxy and SF in this case is as below:
	If such a proxy is not ECN-aware then congestion in the entire		If such a proxy is not ECN-aware then congestion in the entire
	path from SFF to proxy to SF back to proxy to SFF will be		path from SFF to proxy to SF back to proxy to SFF will be
	unmanaged.		unmanaged.
	If the proxy is ECN-aware the proxy uses an AQM to indicate		If the proxy is ECN-aware, the proxy uses an AQM to indicate
	congestion in the proxy itself in the NSH that it returns to the		congestion within the proxy in the NSH that it returns to the SFF.
	SFF. The outer header used for the proxy to SF path uses Normal		The outer header used for the proxy to SF path uses Normal Mode.
	Mode. The outer head used for the proxy return to SFF path uses		The outer head used for the proxy return to SFF path uses Normal
	Normal Mode based copying the NSH ECN field to the outer header.		Mode based copying the NSH ECN field to the outer header. Thus
	Thus congestion in the proxy will be managed. Congestion in the SF		congestion in the proxy will be managed. Congestion in the SF will
	will be managed only if the SF is ECN-aware implementing an AQM.		be managed only if the SF is ECN-aware implementing an AQM.
	3.2.3 At Other Forwarding Nodes		3.2.3 At Other Forwarding Nodes
	Other forwarding nodes, that is non-NSH forwarding nodes between NSH		Other forwarding nodes, that is non-NSH forwarding nodes between NSH
	forwarding nodes, such as IP routers, might also contain potential		forwarding nodes, such as IP routers, might also contain potential
	bottlenecks. If so, they SHOULD implement an AQM algorithm to update		bottlenecks. If so, they SHOULD implement an AQM algorithm to update
	the ECN marking in the outer transport header as specified in		the ECN marking in the outer transport header as specified in
	[RFC3168].		[RFC3168].
	3.3 At Exit/Egress		3.3 At Exit/Egress
	skipping to change at page 20, line 25 ¶		skipping to change at page 20, line 25 ¶
	Email: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	Bob Briscoe		Bob Briscoe
	Independent		Independent
	UK		UK
	Email: ietf@bobbriscoe.net		Email: ietf@bobbriscoe.net
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	Andrew G. Malis		Andrew G. Malis
	Futurewei Technologies		Independent
	Email: agmalis@gmail.com		Email: agmalis@gmail.com
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	Copyright and IPR Provisions		Copyright and IPR Provisions
	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.
End of changes. 11 change blocks.
	27 lines changed or deleted		30 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/