< draft-ietf-sfc-nsh-ecn-support-03.txt		draft-ietf-sfc-nsh-ecn-support-04.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
	Independent		Independent
	Expires: January 1, 2021 July 2, 2020		Expires: June 5, 2021 December 6, 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-03.txt>		<draft-ietf-sfc-nsh-ecn-support-04.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 information about
	congestion to upstream nodes, this can improve network efficiency		congestion back to upstream nodes, this can improve network
	through better congestion control, frequently without packet drops.		efficiency through better congestion control, frequently without
	This document specifies ECN and congestion feedback support within a		packet drops. This document specifies ECN and congestion feedback
	Service Function Chaining (SFC) domain through use of the Network		support within a Service Function Chaining (SFC) architecture domain
	Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX,		through use of the Network Service Header (NSH, RFC 8300) and IP Flow
			Information Export (IPFIX,
	draft-ietf-tsvwg-tunnel-congestion-feedback).		draft-ietf-tsvwg-tunnel-congestion-feedback).
	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.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the SFC Working Group mailing list <sfc@ietf.org> or to the		to the SFC Working Group mailing list <sfc@ietf.org> or to the
	authors.		authors.
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3.2 At Transit Nodes......................................12		3.2 At Transit Nodes......................................12
	3.2.1 At NSH Transit Nodes................................12		3.2.1 At NSH Transit Nodes................................12
	3.2.2 At an SF/Proxy......................................13		3.2.2 At an SF/Proxy......................................13
	3.2.3 At Other Forwarding Nodes...........................13		3.2.3 At Other Forwarding Nodes...........................13
	3.3 At Exit/Egress........................................13		3.3 At Exit/Egress........................................13
	3.4 Conservation of Packets...............................14		3.4 Conservation of Packets...............................14
	4. Tunnel Congestion Feedback Support.....................15		4. Tunnel Congestion Feedback Support.....................15
	5. IANA Considerations....................................16		5. IANA Considerations....................................16
			5.1 SFC NSH Header ECN Bits...............................16
			5.2 IPFIX Information Element ID..........................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....................................18
	Authors' Addresses........................................20		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
	information about congestion to upstream nodes, this can improve		information about congestion back 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
	feedback support within a Service Function Chaining (SFC [RFC7665])		feedback support within a Service Function Chaining (SFC [RFC7665])
	domain through use of the Network Service Header (NSH [RFC8300]) and		architecture domain through use of the Network Service Header (NSH
	IP Flow Information Export (IPFIX [TunnelCongFeedback]).		[RFC8300]) and 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.
	particular, congestion at any bottleneck where ECN marking is not		Congestion at any interior bottleneck where ECN marking is not
	implemented will be unmanaged.		implemented will be unmanaged.
	The subsections below in this section provide background information		The subsections below in this section provide background information
	on NSH, ECN, congestion feedback, and terminology used in this		on NSH, ECN, congestion feedback, and terminology used in 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
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 49 ¶
	+------+		+------+
	|		|
	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 the 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) or
	and then returns it to the SFF from which it was received.		load balancer, 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 (see Figure 3), the SFF
	next forwarding step, either adding a transport header or, if the SFF		decides on the next forwarding step, either adding a new transport
	is the exit/egress, removing the NSH header. The transport headers
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	added may be different in different regions of the SFC domain. For		header or, if the SFF is the exit/egress, removing the NSH header.
	example, IP could be used for some SFF-to-SFF communication and MPLS		The transport headers added may be different in different regions of
	used for other such communication.		the SFC domain. For example, IP could be used for some SFF-to-SFF
			communication and MPLS used for other such communication.
	1.2 ECN Background		1.2 ECN Background
	Explicit congestion notification (ECN [RFC3168]) allows a forwarding		Explicit congestion notification (ECN [RFC3168]) allows a forwarding
	element (such as a router or a Service Function Forwarder (SFF) or		element (such as a router or a Service Function Forwarder (SFF) or
	Service Function (SF)) to notify downstream devices of the onset of		Service Function (SF)) to notify downstream devices of the onset of
	congestion without having to drop packets. This can be used as an		congestion without having to drop packets. This can be used as an
	element in active queue management (AQM) [RFC7567] to improve network		element in active queue management (AQM) [RFC7567] to improve network
	efficiency through better traffic control without packet drops. The		efficiency through better traffic control without packet drops. The
	forwarding element can explicitly mark some packets in an ECN field		forwarding element can explicitly mark some packets in an ECN field
	instead of dropping the packet. For example, a two-bit field is		instead of dropping the packet. For example, a two-bit field is
	available for ECN marking in IP headers [RFC3168].		available for ECN marking in IP headers [RFC3168].
	1.3 Tunnel Congestion Feedback Background		1.3 Tunnel Congestion Feedback Background
	Tunnel Congestion Feedback [TunnelCongFeedback] is a building block		Tunnel Congestion Feedback [TunnelCongFeedback] is a building block
	for various congestion mitigation methods. It supports feedback of		for various congestion mitigation methods. It supports feedback of
	congestion information from an egress node to an ingress node.		congestion information from an egress node to an ingress node. This
			document treats the SFC domain as a tunnel with the initial
			Classifier node being the ingress.
	Examples of actions that can be taken by an ingress node when it has		Examples of actions that can be taken by an ingress node when it has
	knowledge of downstream congestion include those listed below.		knowledge of downstream congestion include those listed below.
	Details of implementing these traffic control methods, beyond those		Details of implementing these traffic control methods, beyond those
	given here, are outside the scope of this document.		given here, are outside the scope of this document.
	Any action by the ingress to reduce congestion needs to allow		Any action by a tunnel ingress to reduce congestion needs to allow
	sufficient time for the end-to-end congestion control loop to respond		sufficient time for the end-to-end congestion control loop to respond
	first, for instance by the ingress taking a smoothed average of the		first, for instance by the ingress taking a smoothed average of the
	level of congestion signalled by feedback from the tunnel egress.		level of congestion signalled by feedback from the tunnel egress.
	(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 with this option to avoid (a) significant re-		care must be taken with this option to avoid (a) significant re-
			INTERNET-DRAFT NSH ECN & Congestion Feedback
	ordering of traffic in flows that it is desirable to keep in		ordering of traffic in flows that it is desirable to keep in
	order and (b) oscillation/instability in traffic paths due to		order and (b) oscillation/instability in traffic paths due to
	alternate congestion of previously idle paths and the idling of		alternate congestion of previously idle paths and the idling of
	previously congested paths. For example, it is preferable to		previously congested paths. For example, it is preferable to
	INTERNET-DRAFT NSH ECN & Congestion Feedback
	classify traffic into flows of a sufficiently coarse granularity		classify traffic into flows of a sufficiently coarse granularity
	that the flows are long lived and then use a stable path per		that the flows are long lived and then use a stable path per
	flow, sending only newly appearing flows on apparently		flow, sending only newly appearing flows on apparently
	uncongested paths.		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) before entering the SFC domain and after leaving the SFC
	be expected from the final receiver to the origin sender, which		domain.
	controls the load the origin sender applies to all elements on the
	path. The figure also shows the congestion feedback from the egress		The figure shows typical congestion feedback that would be expected
	to the ingress of the SFC domain that is described in this document,		from the final receiver to the origin sender, which controls the load
	to control or balance load within the SFC domain.		the origin sender applies to all elements on the 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 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 || | |
	skipping to change at page 6, line 49 ¶		skipping to change at page 7, line 5 ¶
	|__| |__| |___| |___| |___| |__| |__|		|__| |__| |___| |___| |___| |__| |__|
	origin SFC | ^ | ^ SFC final		origin SFC | ^ | ^ SFC final
	sender domain OT2| |OT3 OT6| |OT7 domain rcvr		sender domain OT2| |OT3 OT6| |OT7 domain rcvr
	ingress v | v | egress		ingress v | v | egress
	+---+ +---+		+---+ +---+
	|SF | |SF |		|SF | |SF |
	+---+ +---+		+---+ +---+
	Figure 2: Congestion Feedback across an SFC Domain		Figure 2: Congestion Feedback across an SFC Domain
			INTERNET-DRAFT NSH ECN & Congestion Feedback
	SFC Domain congestion feedback in Figure 2 is shown within the		SFC Domain congestion feedback in Figure 2 is shown within the
	context of an end-to-end congestion feedback loop. Also shown is the		context of an end-to-end congestion feedback loop. Also shown is the
	encapsulated layering of NSH headers within a series of outer		encapsulated layering of NSH headers within a series of outer
	transport headers (OT1, OT2, ... OTn).		transport headers (OT1, OT2, ... OTn).
	INTERNET-DRAFT NSH ECN & Congestion Feedback
	1.4 Conventions Used in This Document		1.4 Conventions Used in This Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119] [RFC8174]		document are to be interpreted as described in [RFC2119] [RFC8174]
	when, and only when, they appear in all capitals, as shown here.		when, and only when, they appear in all capitals, as shown here.
	Acronyms:		Acronyms:
	AQM - Active Queue Management [RFC7567]		AQM - Active Queue Management [RFC7567]
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	TLV - Type Length Value		TLV - Type Length Value
	upstream - The direction from egress to ingress		upstream - The direction from egress to ingress
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	2. The NSH ECN Field		2. The NSH ECN Field
	The NSH header is used to encapsulate and control the subsequent path		The NSH header is used to encapsulate and control the subsequent path
	of traffic (see Section 2 of [RFC8300]). The NSH also provides for		of traffic (see Section 2 of [RFC8300]). The NSH also provides for
	metadata inclusion, as shown in Figure 3.		optional metadata inclusion, as shown in Figure 3.
	+-----------------------------------+		+-----------------------------------+
	| Transport Encapsulation |		| Outer Transport Header |
	+-----------------------------------+		+-----------------------------------+
	| Network Service Header (NSH) |		| Network Service Header (NSH) |
	| +------------------------------+ |		| +------------------------------+ |
	| | Base Header | |		| | Base Header | |
	| +------------------------------+ |		| +------------------------------+ |
	| | Service Path Header | |		| | Service Path Header | |
	| +------------------------------+ |		| +------------------------------+ |
	| | Metadata (Context Header(s)) | |		| | Metadata (Context Header(s)) | |
	| +------------------------------+ |		| +------------------------------+ |
	+-----------------------------------+		+-----------------------------------+
	| Original Packet / Frame |		| Original Packet / Frame / Payload |
	+-----------------------------------+		+-----------------------------------+
	Figure 3. Data Encapsulation with the NSH		Figure 3. Data Encapsulation with the NSH
	Two currently unused bits (indicated by "U") in the NSH Base Header		Two currently unused bits (indicated by "U") in the NSH Base Header
	(Section 2.2 of [RFC8300]) are allocated for ECN as shown in Figure		(Section 2.2 of [RFC8300]) are allocated for ECN indication as shown
	4.		in Figure 4.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |		|Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	^ ^		^ ^
	| |		| |
	+-------+		+-------+
	|NSH ECN|		|NSH ECN|
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 14 ¶
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	3. ECN Support in the NSH		3. ECN Support in the NSH
	This section describes the required behavior to support ECN using the		This section describes the required behavior to support ECN using the
	NSH. There are two aspects to ECN support:		NSH. There are two aspects to ECN support:
	1. ECN propagation during encapsulation or decapsulation		1. ECN propagation during encapsulation or decapsulation
	2. ECN marking during congestion at bottlenecks.		2. ECN marking during congestion at bottlenecks.
	While this section covers all combinations of ECN-aware and not ECN-		While this section covers all combinations of ECN-aware and ECN-
	aware, it is expected that in most cases the NSH domain will be		unaware, it is expected that in most cases the NSH domain will be
	uniform so that, if this document is applicable, all SFFs will		uniform so that, if this document is applicable, all SFFs will
	support ECN; however, some legacy SFs might not support ECN.		support ECN; however, some legacy SFs might not support ECN.
	ECN Propagation:		ECN Propagation:
	The specification of ECN tunneling [RFC6040] explains that an		The specification of ECN tunneling [RFC6040] explains that an
	ingress must not propagate ECN support into an encapsulating		ingress must not propagate ECN support into an encapsulating
	header unless the egress supports correct onward propagation of		header unless the egress supports correct onward propagation of
	the ECN field during decapsulation. We define Compliant ECN		the ECN field during decapsulation. We define Compliant ECN
	Decapsulation here as decapsulation compliant with either		Decapsulation here as decapsulation compliant with either
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 27 ¶
	+-----------------+		+-----------------+
	| Inner Header |		| Inner Header |
	+-----------------+		+-----------------+
	| Payload |		| Payload |
	+-----------------+		+-----------------+
	Figure 5. Packet in Transit		Figure 5. Packet in Transit
	3.2.1 At NSH Transit Nodes		3.2.1 At NSH Transit Nodes
	When a packet is received at an NSH based forwarding node N1, such as		When a packet is received at an NSH based forwarding node such as an
	an SFF, the outer transport encapsulation is removed and its ECN		SFF, say N1, the outer transport encapsulation is removed and its ECN
	marking SHOULD be combined into the NSH ECN marking as specified in		marking SHOULD be combined into the NSH ECN marking as specified in
	[RFC6040]. If this is not done, any congestion encountered at non-NSH		[RFC6040]. If this is not done, any congestion encountered at non-NSH
	transit nodes between N1 and the next upstream NSH based forwarding		transit nodes between N1 and the next upstream NSH based forwarding
	node will be lost and not transmitted downstream.		node will be lost and not transmitted downstream.
	The NSH forwarding node SHOULD use a recognized AQM algorithm		The NSH forwarding node SHOULD use a recognized AQM algorithm
	[RFC7567] to detect congestion. If the NSH ECN field indicates ECT,		[RFC7567] to detect congestion. If the NSH ECN field indicates ECT,
	it will probabilistically set the NSH ECN field to the Congestion		it will probabilistically set the NSH ECN field to the Congestion
	Experienced (CE) value or, in cases of extreme congestion, drop the		Experienced (CE) value or, in cases of extreme congestion, drop the
	packet.		packet.
	When the NSH encapsulated packet is further encapsulated for		When the NSH encapsulated packet is further encapsulated for
	transmission to the next SFF or SF, ECN marking behavior depends on		transmission to the next SFF or SF, ECN marking behavior depends on
	whether or not the node that will decapsulate the outer header		whether or not the node that will decapsulate the outer header
	supports Compliant ECN Decapsulation (see Section 3). If it does,		supports Compliant ECN Decapsulation (see Section 3). If it does,
	then the ingress node propagates the NSH ECN field to this outer		then the encapsulating node propagates the NSH ECN field to this
	encapsulation using the "Normal Mode" of ECN encapsulation [RFC6040]		outer encapsulation using the "Normal Mode" of ECN encapsulation
	(it copies the ECN field). If it does not, then the ingress MUST		[RFC6040] (the ECN field is copied). If it does not, then the
	clear ECN in the outer encapsulation to non-ECT (the "Compatibility		encapsulating node MUST clear ECN in the outer encapsulation to non-
	Mode" of [RFC6040]).		ECT (the "Compatibility Mode" of [RFC6040]).
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	3.2.2 At an SF/Proxy		3.2.2 At an SF/Proxy
	If the SF is NSH and ECN-aware, the processing is essentially the		If the SF is NSH and ECN-aware, the processing is essentially the
	same at the SF as at an SFF as discussed in Section 3.2.1.		same at the SF as at an SFF as discussed in Section 3.2.1.
	If the SF is NSH-aware but not ECN-aware, then the SFF transmitting		If the SF is NSH-aware but ECN-unaware, then the SFF transmitting the
	the packet to the SF will use Compatibility Mode. Congestion		packet to the SF will use Compatibility Mode. Congestion encountered
	encountered in the SFF to SF and SF to SFF paths will be unmanaged.		in the SFF to SF and SF to SFF paths will be unmanaged.
	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 to 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 within the proxy in the NSH that it returns to the SFF.		congestion within the proxy in the NSH that it returns to the SFF.
	The outer header used for the proxy to SF path uses Normal Mode.		The outer header used for the proxy to SF path uses Normal Mode.
	The outer head used for the proxy return to SFF path uses Normal		The outer head used for the proxy return to SFF path uses Normal
	Mode based copying the NSH ECN field to the outer header. Thus		Mode based copying of the NSH ECN field to the outer header. Thus
	congestion in the proxy will be managed. Congestion in the SF will		congestion in the proxy will be managed. Congestion in the SF 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 or label switched routers, might also
	bottlenecks. If so, they SHOULD implement an AQM algorithm to update		contain potential bottlenecks. If so, they SHOULD implement an AQM
	the ECN marking in the outer transport header as specified in		algorithm to update the ECN marking in the outer transport header as
	[RFC3168].		specified in [RFC3168].
	3.3 At Exit/Egress		3.3 At Exit/Egress
	First, any actions are taken based on Congestion Experienced, such as		First, any actions are taken based on Congestion Experienced or other
	forwarding statistics back to the ingress (see Section 4). If the		values of ECN marking, such as accumulating statistics to forward
	packet being carried inside the NSH is IP, when the NSH is removed		back to the ingress (see Section 4). If the packet being carried
	the NSH ECN field MUST be combined with IP ECN field as specified in		inside the NSH is IP, when the NSH is removed the NSH ECN field MUST
	Table 3 that was extracted from [RFC6040]. This requirement applies		be combined with the IP ECN field as specified in Table 3 that was
	to all egress nodes for the domain in which NSH is being used to		extracted from [RFC6040]. This requirement applies to all egress
	route traffic.		nodes for the domain in which NSH is being used to route traffic.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	+---------+---------------------------------------------+		+---------+---------------------------------------------+
	|Arriving | Arriving Outer Header |		|Arriving | Arriving Outer Header |
	| Inner +---------+-----------+-----------+-----------+		| Inner +---------+-----------+-----------+-----------+
	| Header | Not-ECT | ECT(0) | ECT(1) | CE |		| Header | Not-ECT | ECT(0) | ECT(1) | CE |
	+---------+---------+-----------+-----------+-----------+		+---------+---------+-----------+-----------+-----------+
	| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |		| Not-ECT | Not-ECT |Not-ECT |Not-ECT | <drop> |
	| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |		| ECT(0) | ECT(0) | ECT(0) | ECT(0) | CE |
	skipping to change at page 14, line 28 ¶		skipping to change at page 14, line 28 ¶
	Table 3. Exit ECN Fields Merger		Table 3. Exit ECN Fields Merger
	All the egress nodes of the SFC domain MUST support Compliant ECN		All the egress nodes of the SFC domain MUST support Compliant ECN
	Decapsulation as specified in this section. If this is not the case,		Decapsulation as specified in this section. If this is not the case,
	the scheme described in this document will not work, and cannot be		the scheme described in this document will not work, and cannot be
	used.		used.
	3.4 Conservation of Packets		3.4 Conservation of Packets
	The SFC specification permits an SF to absorb packets and to generate		The SFC specification permits an SF to absorb packets and to generate
	new packets as well as to process and forward the packets it		new packets as well as simply processing and forwarding the packets
	receives. Such actions might appear to be packet loss due to		it receives. Such actions might appear to be packet loss due to
	congestion or might mask the loss of packets by generating additional		congestion or might mask the loss of packets by generating additional
	packets.		packets.
	The tunnel congestion feedback approach [TunnelCongFeedback] detects		The tunnel congestion feedback approach [TunnelCongFeedback] detects
	loss by counting payload bytes in at the ingress and counting them		loss by counting payload bytes in at the ingress and counting them
	out at the egress. This does not work unless nodes conserve the		out at the egress. This does not work unless nodes conserve the
	amount of payload bytes. Therefore, it will not be possible to detect		amount of payload bytes. Therefore, it will not be possible to detect
	loss using this technique if they are not conserved.		loss using this technique if they are not conserved.
	Nonetheless, if a bottleneck supports ECN marking, it will be		Nonetheless, if a bottleneck supports ECN marking, it will be
	possible to detect the very high level of CE markings that are		possible to detect the very high level of CE markings that are
	associated with congestion that is so excessive that it leads to		associated with congestion that is so excessive that it leads to
	loss. However, it will not be possible for the tunnel congestion		loss. However, it will not be possible for the tunnel congestion
	feedback approach to detect any congestion, whether slight or severe,		feedback approach to detect any congestion, whether slight or severe,
	if it occurs at a bottleneck that does not support ECN marking.		if it occurs at a bottleneck that does not support ECN marking.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	4. Tunnel Congestion Feedback Support		4. Tunnel Congestion Feedback Support
	The collection and storage of congestion information may be useful		The collection and storage of congestion information at the egress
	for later analysis but, unless it can be fed back to a point which		may be useful for later analysis but, unless it can be fed back to a
	can take action to reduce congestion, it will not be useful in real		point which can take action to reduce congestion, it will not be
	time. Such congestion feedback to the ingress enables it to take		useful in real time. Such congestion feedback to the ingress enables
	actions such as those listed in Section 1.3.		it to take actions such as those listed in Section 1.3.
	IP Flow Information Export (IPFIX [RFC7011]) provides a standard for		IP Flow Information Export (IPFIX [RFC7011]) provides a standard for
	communicating traffic flow statistics. As extended by		communicating traffic flow statistics. As extended by
	[TunnelCongFeedback], IPFIX can be used to determine the extent of		[TunnelCongFeedback] and herein, IPFIX messages from the egress to
	congestion between an ingress and egress.		the ingress are used to communicate the extent of congestion between
			an ingress and egress based on ECN marking in the NSH. For example,
			the tunnelEcnCEMarkedRatio field, specified in [TunnelCongFeedback],
			indicates tha fraction of traffic that has been marked in the ECN
			field of the NSH as Congestion Experienced (CE).
	IPFIX recommends use of SCTP [RFC4960] in partial reliability mode.		In order to identify SFC flows, so that congestion can be measured
	This mode allows loss of some packets, which is tolerable because		and reported at that granularity, it is necessary for IPFIX to be
	IPFIX communicates cumulative statistics. IPFIX over SCTP SHOULD be		able to classify traffic based on the Service Path Identifier field
	used directly where there is IP connectivity between the ingress and		of the NSH [RFC8300]. Thus an NSH Service Path Identifier
			(nshServicePathID) IPFIX Information Element [RFC7012] is specified
			as follows for use in this application of IPFIX:
			Name: nshServicePathID
			Description: Network Service Header [RFC8300] Service Path
			Identifier. This is a 24-bit value which is left justified in
			the Information Element. The low order byte MUST be sent as
			zero and ignored on receipt.
			Abstract Data Type: unsigned32
			Data Type Semantics: identifier
			ElementID: tbd
			Status: current
			IPFIX recommends, but does not require, use of SCTP [RFC4960] in
			partial reliability mode for the transport of its messages. This mode
			allows loss of some packets, which is tolerable because IPFIX
			communicates cumulative statistics. IPFIX over SCTP SHOULD be used
			directly where there is IP connectivity between the ingress and
	egress; however, there might be different transport protocols or		egress; however, there might be different transport protocols or
	address spaces used in different regions of an SFC domain that make		address spaces used in different regions of an SFC domain that make
	such direct IP connectivity problematic. The NSH provides the general		such direct IP connectivity problematic. The NSH provides the general
	method of routing of traffic within such domain so the IPFIX over		method of routing traffic within such an SFC domain so the IPFIX
	SCTP over IP traffic should be encapsulated in NSH when necessary.		traffic MUST be encapsulated in NSH when IP connectivity is not
			available.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	5. IANA Considerations		5. IANA Considerations
			5.1 SFC NSH Header ECN Bits
	IANA is requested to assign two contiguous bits in the NSH Base		IANA is requested to assign two contiguous bits in the NSH Base
	Header Bits registry for ECN (bits 16 and 17 suggested) and note this		Header Bits registry for ECN (bits 16 and 17 suggested) and note this
	assignment as follows:		assignment as follows:
	Bit Description Reference		Bit Description Reference
	---------- ----------- ---------------		---------- ----------- ---------------
	tbd(16-17) NSH ECN [this document]		tbd(16-17) NSH ECN [this document]
			5.2 IPFIX Information Element ID
			IANA is request to assign an IPFIX Information Element ID as follows:
			ElementID: tbd
			Name: nshServicePathID
			Data Type: unsigned32
			Data Type Semantics: identifier
			Status: current
			Description: The Network Service Header [RFC8300] Service Path
			Identifier.
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	6. Security Considerations		6. Security Considerations
	For general NSH security considerations, see [RFC8300].		For general NSH security considerations, see [RFC8300].
	For security considerations concerning tampering with ECN signaling,		For security considerations concerning tampering with ECN signaling,
	see [RFC3168]. For security considerations concerning ECN		see [RFC3168]. For security considerations concerning ECN and
	encapsulation, see [RFC6040].		encapsulation, see [RFC6040].
	For general IPFIX security considerations, see [RFC7011]. If deployed		For general IPFIX security considerations, see [RFC7011]. If deployed
	in an untrusted environment, the signaling traffic between ingress		in an untrusted environment, the signaling traffic between ingress
	and egress can be protected utilizing the security mechanisms		and egress can be protected utilizing the security mechanisms
	provided by IPFIX (see Section 11 in [RFC7011]).		provided by IPFIX (see Section 11 in [RFC7011]).
	The solution in this document does not introduce any greater		The solution in this document does not introduce any greater
	potential to invade privacy than would have been possible without the		potential to invade privacy than would have been available without
	solution.		the solution.
	7. Acknowledgements		7. Acknowledgements
	The authors wish to thank the following for their comments and		The authors wish to thank the following for their comments and
	suggestion:		suggestion:
	Joel Halpern, Tal Mizrahi, Xinpeng Wei		Joel Halpern, Tal Mizrahi, Xinpeng Wei
	INTERNET-DRAFT NSH ECN & Congestion Feedback		INTERNET-DRAFT NSH ECN & Congestion Feedback
	skipping to change at page 19, line 5 ¶		skipping to change at page 18, line 49 ¶
	2017, <http://www.rfc-editor.org/info/rfc8174>		2017, <http://www.rfc-editor.org/info/rfc8174>
	[RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,		[RFC8300] - Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
	"Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,		"Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300,
	January 2018, <https://www.rfc-editor.org/info/rfc8300>.		January 2018, <https://www.rfc-editor.org/info/rfc8300>.
	[TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng,		[TunnelCongFeedback] - Wei, X., Li, Y., Boutros, S., and L. Deng,
	"Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel-		"Tunnel Congestion Feedback", draft-ietf-tsvwg-tunnel-
	congestion-feedback, work in progress.		congestion-feedback, work in progress.
	INTERNET-DRAFT NSH ECN & Congestion Feedback
	Informative References		Informative References
	[RFC4301] - Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] - Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December
	2005, <https://www.rfc-editor.org/info/rfc4301>.		2005, <https://www.rfc-editor.org/info/rfc4301>.
			INTERNET-DRAFT NSH ECN & Congestion Feedback
	[RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] - Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<https://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
	[RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service		[RFC7665] - Halpern, J., Ed., and C. Pignataro, Ed., "Service
	Function Chaining (SFC) Architecture", RFC 7665, DOI		Function Chaining (SFC) Architecture", RFC 7665, DOI
	10.17487/RFC7665, October 2015, <https://www.rfc-		10.17487/RFC7665, October 2015, <https://www.rfc-
	editor.org/info/rfc7665>.		editor.org/info/rfc7665>.
			[RFC7012] - Claise, B., Ed., and B. Trammell, Ed., "Information Model
			for IP Flow Information Export (IPFIX)", RFC 7012, DOI
			10.17487/RFC7012, September 2013, <https://www.rfc-
			editor.org/info/rfc7012>.
	[RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion		[RFC8311] - Black, D., "Relaxing Restrictions on Explicit Congestion
	Notification (ECN) Experimentation", RFC 8311, DOI		Notification (ECN) Experimentation", RFC 8311, DOI
	10.17487/RFC8311, January 2018, <https://www.rfc-		10.17487/RFC8311, January 2018, <https://www.rfc-
	editor.org/info/rfc8311>.		editor.org/info/rfc8311>.
	[ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified		[ecnL4S] - De Schepper, K., and B. Briscoe, "Identifying Modified
	Explicit Congestion Notification (ECN) Semantics for Ultra-Low		Explicit Congestion Notification (ECN) Semantics for Ultra-Low
	Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in		Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-id, work in
	progress.		progress.
End of changes. 43 change blocks.
	86 lines changed or deleted		146 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/