rfc9895v1.txt		rfc9895.txt
	skipping to change at line 79 ¶		skipping to change at line 79 ¶
	The DLEP specification does not define any flow control mechanisms.		The DLEP specification does not define any flow control mechanisms.
	While in theory various flow control techniques could be implemented		While in theory various flow control techniques could be implemented
	with DLEP, this document specifies a DLEP extension that introduces		with DLEP, this document specifies a DLEP extension that introduces
	an Ethernet-based flow control mechanism for traffic transmitted from		an Ethernet-based flow control mechanism for traffic transmitted from
	a router to a modem. This mechanism utilizes one or more logical		a router to a modem. This mechanism utilizes one or more logical
	"Credit Windows", each of which is typically associated with a		"Credit Windows", each of which is typically associated with a
	virtual or physical queue. The router leverages traffic flow		virtual or physical queue. The router leverages traffic flow
	classification information provided by the modem to determine the		classification information provided by the modem to determine the
	appropriate credit window for a given traffic flow. Credit windows		appropriate credit window for a given traffic flow. Credit windows
	may be allocated on either a shared or a per-flow basis. For a		may be shared across multiple flows or used on a per-flow basis. For
	Diffserv-based approach to credit window flow control, refer to		a Diffserv-based approach to credit window flow control, refer to
	[RFC9894]. As specified in Section 2.3.1 of [RFC9892], when both		[RFC9894]. As specified in Section 2.3.1 of [RFC9892], when both
	Diffserv and Ethernet traffic classification are applied to a flow,		Diffserv and Ethernet traffic classification are applied to a flow,
	Ethernet-based classification takes precedence.		Ethernet-based classification takes precedence.
	This document leverages the traffic classification and credit window		This document leverages the traffic classification and credit window
	control mechanisms defined in [RFC9892] and [RFC9893] to enable		control mechanisms defined in [RFC9892] and [RFC9893] to enable
	credit-window-based flow control based on DLEP destinations, Ethernet		credit-window-based flow control based on DLEP destinations, Ethernet
	Virtual Local Area Networks (VLANs), and Priority Code Points (PCPs).		Virtual Local Area Networks (VLANs), and Priority Code Points (PCPs).
	Ethernet PCP support is specified as part of the IEEE 802.1Q tag		Ethernet PCP support is specified as part of the IEEE 802.1Q tag
	format [IEEE8021Q], which includes a 3-bit "PCP" field. The tag		format [IEEE8021Q], which includes a 3-bit "PCP" field. The tag
	skipping to change at line 118 ¶		skipping to change at line 118 ¶
	1.1. Key Words		1.1. Key Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Extension Usage and Identification		2. Extension Usage and Identification
	The extension defined in this document is composed of the mechanisms		The extension defined in this document is built on the mechanisms and
	and processing defined in [RFC9892] and [RFC9893]. To indicate that		processing defined in [RFC9892] and [RFC9893]. To indicate that the
	the IEEE 802.1Q Aware Credit Window Extension is to be used, an		IEEE 802.1Q Aware Credit Window Extension is to be used, an
	implementation MUST include the IEEE 802.1Q Aware Credit Window Type		implementation MUST include the IEEE 802.1Q Aware Credit Window
	Value in the Extensions Supported Data Item (see Section 13.6 of		Extension Type Value in the Extensions Supported Data Item (see
	[RFC8175]). The Extensions Supported Data Item is sent and processed		Section 13.6 of [RFC8175]). The Extensions Supported Data Item is
	according to [RFC8175]. Any implementation that indicates the use of		sent and processed according to [RFC8175]. Any implementation that
	the IEEE 802.1Q Aware Credit Window Extension MUST support all		indicates the use of the IEEE 802.1Q Aware Credit Window Extension
	message types, Data Items, the Ethernet Traffic Classification Sub-		MUST support all message types, Data Items, the Ethernet Traffic
	Data Item, and all related processing defined in [RFC9892] and		Classification Sub-Data Item, and all related processing defined in
	[RFC9893].		[RFC9892] and [RFC9893].
	The IEEE 802.1Q Aware Credit Window Extension Type Value is 5. See		The IEEE 802.1Q Aware Credit Window Extension Type Value is 5. See
	Section 5.		Section 5.
	3. Management Considerations		3. Management Considerations
	This section provides several network management guidelines for		This section provides several network management guidelines for
	implementations supporting the IEEE 802.1Q Aware Credit Window		implementations supporting the IEEE 802.1Q Aware Credit Window
	Extension.		Extension.
	skipping to change at line 151 ¶		skipping to change at line 151 ¶
	which is configurable on both modems and routers. Diffserv Aware		which is configurable on both modems and routers. Diffserv Aware
	Credit Window Extension Data Items MUST NOT be emitted by a DLEP		Credit Window Extension Data Items MUST NOT be emitted by a DLEP
	participant unless such support was specified in the initialization		participant unless such support was specified in the initialization
	message received from its peer. The use of the extension defined in		message received from its peer. The use of the extension defined in
	this document SHOULD be configurable on both modems and routers.		this document SHOULD be configurable on both modems and routers.
	Modems SHOULD support the configuration of mapping a PCP to a credit		Modems SHOULD support the configuration of mapping a PCP to a credit
	window (queue).		window (queue).
	Modems MAY support the configuration of mapping a PCP to a credit		Modems MAY support the configuration of mapping a PCP to a credit
	window (queue) on a per-VLAN basis. VID value zero (0) is used by		window (queue) on a per-VLAN basis. VID value zero (0x0000) is used
	[RFC9892] to indicate that the VID is ignored and any VID value is		by [RFC9892] to indicate that the VID is ignored and VID 0xFFFF is
	used in traffic classification.		reserved. Any other VID value from 0x0001 through 0xFFFE can be used
			in traffic classification.
	When VLANs are supported by a modem without support from PCPs, the		When VLANs are supported by a modem without support from PCPs, the
	modem SHOULD support the configuration of mapping a VLAN to a credit		modem SHOULD support the configuration of mapping a VLAN to a credit
	window (queue).		window (queue).
	Modems MAY support the configuration of the number of credit windows		Modems MAY support the configuration of the number of credit windows
	(queues) that they advertise to a router.		(queues) that they advertise to a router.
	Routers may impose limitations on the number of queues they can		Routers may impose limitations on the number of queues they can
	support and on the allowable credit window configurations. In some		support and on the allowable credit window configurations. In some
End of changes. 3 change blocks.
	16 lines changed or deleted		17 lines changed or added
This html diff was produced by rfcdiff 1.48.