rfc9895v1.txt		rfc9895.txt
	skipping to change at line 16 ¶		skipping to change at line 16 ¶
	D. Eastlake 3rd, Ed.		D. Eastlake 3rd, Ed.
	Independent		Independent
	November 2025		November 2025
	Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window		Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window
	Extension		Extension
	Abstract		Abstract
	This document defines an extension to the Dynamic Link Exchange		This document defines an extension to the Dynamic Link Exchange
	Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit-		Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit
	window scheme for destination-specific and shared flow control.		window scheme for destination-specific and shared flow control.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	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		flow 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
	format also incorporates a 12-bit "VLAN Identifier (VID)" field.		format also incorporates a 12-bit "VLAN Identifier (VID)" field.
	The defined mechanism allows credit windows to be shared across		The defined mechanism allows credit windows to be shared across
	traffic destined for multiple DLEP destinations, VLANs, and PCPs, or		traffic destined for multiple DLEP destinations, VLANs, and PCPs, or
	to be dedicated exclusively to traffic associated with a specific		to be dedicated exclusively to traffic associated with a specific
	destination, VLAN, and/or PCP. Additionally, this extension supports		destination, VLAN, and/or PCP. Additionally, this extension supports
	"wildcard" matching for any PCP or VID.		"wildcard" matching for any PCP or VID.
	The extension defined in this document is referred to as the "IEEE		The extension defined in this document is referred to as the "IEEE
	802.1Q Aware Credit Window" or, more simply, the "Ethernet Credit"		802.1Q Aware Credit Window" or, more simply, the "Ethernet Credit"
	extension. The reader should be familiar with both the traffic		extension. The reader should be familiar with both the traffic
	classification and credit window control mechanisms defined in		classification and credit window flow control mechanisms defined in
	[RFC9892] and [RFC9893].		[RFC9892] and [RFC9893].
	This document defines a new DLEP Extension Type Value that is used to		This document defines a new DLEP Extension Type value that is used to
	indicate support for the extension. See Section 2.		indicate support for the extension. See Section 2.
	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.
	If this extension is supported, that support MUST be declared using		If this extension is supported, that support MUST be declared using
	the Extensions Supported Data Item (see Section 13.6 of [RFC8175]),		the Extensions Supported Data Item (see Section 13.6 of [RFC8175]),
	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. 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
	skipping to change at line 180 ¶		skipping to change at line 181 ¶
	standard network management mechanisms, such as user interface		standard network management mechanisms, such as user interface
	notifications or error logging.		notifications or error logging.
	Regardless of implementation, if credit windows are in use, the		Regardless of implementation, if credit windows are in use, the
	router MUST NOT send traffic to the modem unless sufficient credits		router MUST NOT send traffic to the modem unless sufficient credits
	are available.		are available.
	4. Security Considerations		4. Security Considerations
	This document defines a DLEP extension that uses DLEP mechanisms and		This document defines a DLEP extension that uses DLEP mechanisms and
	the credit window control and flow mechanisms defined in [RFC9892]		the credit window flow control mechanisms defined in [RFC9892] and
	and [RFC9893]. See also the Security Considerations sections of		[RFC9893]. See also the Security Considerations sections of those
	those documents.		documents.
	The defined extension is exposed to vulnerabilities similar to		The defined extension is exposed to vulnerabilities similar to
	existing DLEP messages and discussed in the Security Considerations		existing DLEP messages and discussed in the Security Considerations
	section of [RFC8175], such as an injected message resizing a credit		section of [RFC8175], such as an injected message resizing a credit
	window to a value that results in a denial of service. The security		window to a value that results in a denial of service. The security
	mechanisms documented in [RFC8175] can be applied equally to the		mechanisms documented in [RFC8175] can be applied equally to the
	mechanism defined in this document.		mechanism defined in this document.
	Wildcards for matching PCP and VID fields are provided. Note that		Wildcards for matching PCP and VID fields are provided. Note that
	wildcards may be convenient for matching a number of packet flows but		wildcards may be convenient for matching a number of packet flows but
End of changes. 9 change blocks.
	24 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.48.