< draft-ietf-tsvwg-ecn-encap-guidelines-13.txt		draft-ietf-tsvwg-ecn-encap-guidelines-14-COULD-NOT-SUBMIT.txt >
	Transport Area Working Group B. Briscoe		Transport Area Working Group B. Briscoe
	Internet-Draft Independent		Internet-Draft Independent
	Updates: 3819 (if approved) J. Kaippallimalil		Updates: 3819 (if approved) J. Kaippallimalil
	Intended status: Best Current Practice Huawei		Intended status: Best Current Practice Futurewei
	Expires: November 21, 2019 P. Thaler		Expires: September 10, 2020 P. Thaler
	Broadcom Corporation (retired)		Broadcom Corporation (retired)
	May 20, 2019		March 9, 2020
	Guidelines for Adding Congestion Notification to Protocols that		Guidelines for Adding Congestion Notification to Protocols that
	Encapsulate IP		Encapsulate IP
	draft-ietf-tsvwg-ecn-encap-guidelines-13		draft-ietf-tsvwg-ecn-encap-guidelines-14
	Abstract		Abstract
	The purpose of this document is to guide the design of congestion		The purpose of this document is to guide the design of congestion
	notification in any lower layer or tunnelling protocol that		notification in any lower layer or tunnelling protocol that
	encapsulates IP. The aim is for explicit congestion signals to		encapsulates IP. The aim is for explicit congestion signals to
	propagate consistently from lower layer protocols into IP. Then the		propagate consistently from lower layer protocols into IP. Then the
	IP internetwork layer can act as a portability layer to carry		IP internetwork layer can act as a portability layer to carry
	congestion notification from non-IP-aware congested nodes up to the		congestion notification from non-IP-aware congested nodes up to the
	transport layer (L4). Following these guidelines should assure		transport layer (L4). Following these guidelines should assure
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 21, 2019.		This Internet-Draft will expire on September 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	4.2. Wire Protocol Design: Indication of ECN Support . . . . . 16		4.2. Wire Protocol Design: Indication of ECN Support . . . . . 16
	4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 18		4.3. Encapsulation Guidelines . . . . . . . . . . . . . . . . 18
	4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 20		4.4. Decapsulation Guidelines . . . . . . . . . . . . . . . . 20
	4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 22		4.5. Sequences of Similar Tunnels or Subnets . . . . . . . . . 22
	4.6. Reframing and Congestion Markings . . . . . . . . . . . . 22		4.6. Reframing and Congestion Markings . . . . . . . . . . . . 22
	5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion		5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
	Notification . . . . . . . . . . . . . . . . . . . . . . . . 23		Notification . . . . . . . . . . . . . . . . . . . . . . . . 23
	6. Feed-Backward Mode: Guidelines for Adding Congestion		6. Feed-Backward Mode: Guidelines for Adding Congestion
	Notification . . . . . . . . . . . . . . . . . . . . . . . . 24		Notification . . . . . . . . . . . . . . . . . . . . . . . . 24
	7. IANA Considerations (to be removed by RFC Editor) . . . . . . 25		7. IANA Considerations (to be removed by RFC Editor) . . . . . . 25
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 26		8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26		9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 27		11. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 27
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	12.1. Normative References . . . . . . . . . . . . . . . . . . 27		12.1. Normative References . . . . . . . . . . . . . . . . . . 27
	12.2. Informative References . . . . . . . . . . . . . . . . . 28		12.2. Informative References . . . . . . . . . . . . . . . . . 28
	Appendix A. Changes in This Version (to be removed by RFC		Appendix A. Changes in This Version (to be removed by RFC
	Editor) . . . . . . . . . . . . . . . . . . . . . . 33		Editor) . . . . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	skipping to change at page 23, line 5 ¶		skipping to change at page 23, line 5 ¶
	The guidance in this section is only applicable where an ECN		The guidance in this section is only applicable where an ECN
	capability is being added to a layer-2 protocol so that layer-2		capability is being added to a layer-2 protocol so that layer-2
	frames can be ECN-marked by an AQM at layer-2. This would only be		frames can be ECN-marked by an AQM at layer-2. This would only be
	necessary where AQM will be applied at pure layer-2 nodes (without		necessary where AQM will be applied at pure layer-2 nodes (without
	IP-awareness). Where framing boundaries do not necessarily align		IP-awareness). Where framing boundaries do not necessarily align
	with packet boundaries, the following guidance will be needed. It		with packet boundaries, the following guidance will be needed. It
	explains how to propagate ECN markings from layer-2 frame headers		explains how to propagate ECN markings from layer-2 frame headers
	when they are stripped off and IP PDUs with different boundaries are		when they are stripped off and IP PDUs with different boundaries are
	reassembled for forwarding.		reassembled for forwarding.
	Congestion indications SHOULD be propagated on the basis that a		Congestion indications SHOULD be propagated on the basis that an
	congestion indication on a PDU applies to all the octets in the PDU.		encapsulator or decapsulator SHOULD approximately preserve the
	On average, an encapsulator or decapsulator SHOULD approximately		proportion of PDUs with congestion indications arriving and leaving.
	preserve the number of marked octets arriving and leaving (counting
	the size of inner headers, but not encapsulating headers that are
	being added or stripped).
	The next departing frame SHOULD be immediately marked even if only
	enough incoming marked octets have arrived for part of the departing
	frame. This ensures that any outstanding congestion marked octets
	are propagated immediately, rather than held back waiting for a frame
	no bigger than the outstanding marked octets--which might involve a
	long wait.
	For instance, an algorithm for marking departing frames could		The mechanism for propagating congestion indications SHOULD ensure
	maintain a counter representing the balance of arriving marked octets		that any incoming congestion indication is propagated immediately,
	minus departing marked octets. It adds the size of every marked		not held awaiting the possibility of further congestion indications
	frame that arrives and if the counter is positive it marks the next		to be sufficient to indicate congestion on an outgoing PDU.
	frame to depart and subtracts its size from the counter. This will
	often leave a negative remainder in the counter, which is deliberate.
	5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion		5. Feed-Up-and-Forward Mode: Guidelines for Adding Congestion
	Notification		Notification
	The guidance in this section is applicable, for example, when IP		The guidance in this section is applicable, for example, when IP
	packets:		packets:
	o are encapsulated in Ethernet headers, which have no support for		o are encapsulated in Ethernet headers, which have no support for
	ECN;		ECN;
	skipping to change at page 29, line 7 ¶		skipping to change at page 28, line 38 ¶
	[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling		[GTPv1-U] 3GPP, "General Packet Radio System (GPRS) Tunnelling
	Protocol User Plane (GTPv1-U)", Technical Specification TS		Protocol User Plane (GTPv1-U)", Technical Specification TS
	29.281.		29.281.
	[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)		[GTPv2-C] 3GPP, "Evolved General Packet Radio Service (GPRS)
	Tunnelling Protocol for Control plane (GTPv2-C)",		Tunnelling Protocol for Control plane (GTPv2-C)",
	Technical Specification TS 29.274.		Technical Specification TS 29.274.
	[I-D.ietf-intarea-gue]		[I-D.ietf-intarea-gue]
	Herbert, T., Yong, L., and O. Zia, "Generic UDP		Herbert, T., Yong, L., and O. Zia, "Generic UDP
	Encapsulation", draft-ietf-intarea-gue-07 (work in		Encapsulation", draft-ietf-intarea-gue-09 (work in
	progress), March 2019.		progress), October 2019.
	[I-D.ietf-nvo3-geneve]		[I-D.ietf-nvo3-geneve]
	Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic		Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
	Network Virtualization Encapsulation", draft-ietf-		Network Virtualization Encapsulation", draft-ietf-
	nvo3-geneve-13 (work in progress), March 2019.		nvo3-geneve-16 (work in progress), March 2020.
	[I-D.ietf-trill-ecn-support]		[I-D.ietf-trill-ecn-support]
	Eastlake, D. and B. Briscoe, "TRILL (TRansparent		Eastlake, D. and B. Briscoe, "TRILL (TRansparent
	Interconnection of Lots of Links): ECN (Explicit		Interconnection of Lots of Links): ECN (Explicit
	Congestion Notification) Support", draft-ietf-trill-ecn-		Congestion Notification) Support", draft-ietf-trill-ecn-
	support-07 (work in progress), February 2018.		support-07 (work in progress), February 2018.
	[I-D.ietf-tsvwg-ecn-l4s-id]		[I-D.ietf-tsvwg-ecn-l4s-id]
	Schepper, K. and B. Briscoe, "Identifying Modified		Schepper, K. and B. Briscoe, "Identifying Modified
	Explicit Congestion Notification (ECN) Semantics for		Explicit Congestion Notification (ECN) Semantics for
	Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-		Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
	id-06 (work in progress), March 2019.		id-09 (work in progress), February 2020.
	[I-D.ietf-tsvwg-rfc6040update-shim]		[I-D.ietf-tsvwg-rfc6040update-shim]
	Briscoe, B., "Propagating Explicit Congestion Notification		Briscoe, B., "Propagating Explicit Congestion Notification
	Across IP Tunnel Headers Separated by a Shim", draft-ietf-		Across IP Tunnel Headers Separated by a Shim", draft-ietf-
	tsvwg-rfc6040update-shim-08 (work in progress), March		tsvwg-rfc6040update-shim-09 (work in progress), July 2019.
	2019.
	[IEEE802.1Q]		[IEEE802.1Q]
	IEEE, "IEEE Standard for Local and Metropolitan Area		IEEE, "IEEE Standard for Local and Metropolitan Area
	Networks--Virtual Bridged Local Area Networks--Amendment		Networks--Virtual Bridged Local Area Networks--Amendment
	6: Provider Backbone Bridges", IEEE Std 802.1Q-2018, July		6: Provider Backbone Bridges", IEEE Std 802.1Q-2018, July
	2018, <https://ieeexplore.ieee.org/document/8403927>.		2018, <https://ieeexplore.ieee.org/document/8403927>.
	[ITU-T.I.371]		[ITU-T.I.371]
	ITU-T, "Traffic Control and Congestion Control in B-ISDN",		ITU-T, "Traffic Control and Congestion Control in B-ISDN",
	ITU-T Rec. I.371 (03/04), March 2004,		ITU-T Rec. I.371 (03/04), March 2004,
	skipping to change at page 38, line 16 ¶		skipping to change at page 38, line 16 ¶
	Authors' Addresses		Authors' Addresses
	Bob Briscoe		Bob Briscoe
	Independent		Independent
	UK		UK
	EMail: ietf@bobbriscoe.net		EMail: ietf@bobbriscoe.net
	URI: http://bobbriscoe.net/		URI: http://bobbriscoe.net/
	John Kaippallimalil		John Kaippallimalil
	Huawei		Futurewei
	5340 Legacy Drive, Suite 175		5700 Tennyson Parkway, Suite 600
	Plano, Texas 75024		Plano, Texas 75024
	USA		USA
	EMail: john.kaippallimalil@huawei.com		EMail: kjohn@futurewei.com
	Pat Thaler		Pat Thaler
	Broadcom Corporation (retired)		Broadcom Corporation (retired)
	CA		CA
	USA		USA
End of changes. 15 change blocks.
	36 lines changed or deleted		23 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/