rfc9892v4.txt		rfc9892.txt
	Internet Engineering Task Force (IETF) B. Cheng		Internet Engineering Task Force (IETF) B. Cheng
	Request for Comments: 9892 MIT Lincoln Laboratory		Request for Comments: 9892 MIT Lincoln Laboratory
	Category: Standards Track D. Wiggins		Category: Standards Track D. Wiggins
	ISSN: 2070-1721		ISSN: 2070-1721
	L. Berger		L. Berger
	D. Fedyk, Ed.		D. Fedyk, Ed.
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
	November 2025		December 2025
	Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item		Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item
	Abstract		Abstract
	This document defines a new Data Item for the Dynamic Link Exchange		This document defines a new Data Item for the Dynamic Link Exchange
	Protocol (DLEP) to support traffic classification. Traffic		Protocol (DLEP) to support traffic classification. Traffic
	classification information identifies traffic flows based on frame/		classification information identifies traffic flows based on frame/
	packet content such as a destination address. The Data Item is		packet content such as a destination address. The Data Item is
	defined in an extensible and reusable fashion. Its use will be		defined in an extensible and reusable fashion. Its use will be
	skipping to change at line 369 ¶		skipping to change at line 369 ¶
	within the same Traffic Classification Data Item, the Data Item MUST		within the same Traffic Classification Data Item, the Data Item MUST
	be treated as an error as described in Section 2.1.1.		be treated as an error as described in Section 2.1.1.
	2.3. Ethernet Traffic Classification Sub-Data Item		2.3. Ethernet Traffic Classification Sub-Data Item
	The Ethernet Traffic Classification Sub-Data Item identifies the VLAN		The Ethernet Traffic Classification Sub-Data Item identifies the VLAN
	and PCPs that should be treated as a single flow, i.e., receive the		and PCPs that should be treated as a single flow, i.e., receive the
	same traffic treatment. Ethernet PCP support is defined as part of		same traffic treatment. Ethernet PCP support is defined as part of
	the IEEE 802.1Q tag format [IEEE8021Q] and includes a 3-bit "PCP"		the IEEE 802.1Q tag format [IEEE8021Q] and includes a 3-bit "PCP"
	field. The tag format also includes a 12-bit "VLAN Identifier (VID)"		field. The tag format also includes a 12-bit "VLAN Identifier (VID)"
	field. PCPs are identified in a list of priority fields. An		field. PCPs are identified in a list of Priority Fields. An
	implementation that does not support PCPs and wants the same traffic		implementation that does not support PCPs and wants the same traffic
	treatment for all traffic to a destination or destinations would		treatment for all traffic to a destination or destinations would
	indicate 0 PCPs. Such an implementation could identify a VLAN to use		indicate 0 PCPs. Such an implementation could identify a VLAN to use
	per destination.		per destination.
	The format of the Ethernet Traffic Classification Sub-Data Item is as		The format of the Ethernet Traffic Classification Sub-Data Item is as
	follows:		follows:
	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
	skipping to change at line 398 ¶		skipping to change at line 398 ¶
	Sub-Data Item Type:		Sub-Data Item Type:
	Sub-Data Item Type with value two (2) identifies the Ethernet		Sub-Data Item Type with value two (2) identifies the Ethernet
	Traffic Classification Sub-Data Item Type in the format defined in		Traffic Classification Sub-Data Item Type in the format defined in
	Section 2.1.1.		Section 2.1.1.
	Length:		Length:
	Variable		Variable
	Length is defined above. For this Sub-Data Item, it is equal to		Length is defined above. For this Sub-Data Item, it is equal to
	four (4) plus the number of octets needed to accommodate the		four (4) plus the number of octets needed to accommodate the
	number of Priority fields indicated by the NumPCPs field. Note		number of Priority Fields indicated by the NumPCPs field. Note
	that as the length is in octets and each Priority field is 4 bits,		that as the length is in octets and each Priority Field is 4 bits,
	the total length of this Sub-Data Item is the 2 octets of Flow		the total length of this Sub-Data Item is the 2 octets of Flow
	Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus		Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus
	the number of octets for PCPs. The number of octets for the PCPs		the number of octets for PCPs. The number of octets for the PCPs
	is computed by rounding up NumPCPs to the nearest even value and		is computed by rounding up NumPCPs to the nearest even value and
	dividing by 2. This TLV has maximum length of 4 plus 8 divided by		dividing by 2. This TLV has maximum length of 4 plus 8 divided by
	2 or 8 octets.		2 or 8 octets.
	Flow Identifier (FID):		Flow Identifier (FID):
	A 16-bit unsigned integer representing the data plane information		A 16-bit unsigned integer representing the data plane information
	carried in the Sub-Data Item that is to be used in identifying a		carried in the Sub-Data Item that is to be used in identifying a
	flow. The value 0xFFFF is reserved and MUST NOT be used in this		flow. The value 0xFFFF is reserved and MUST NOT be used in this
	field.		field.
	Num PCPs:		NumPCPs:
	A 4-bit unsigned integer indicating the number of Priority fields		A 4-bit unsigned integer indicating the number of Priority Fields
	carried in the Sub-Data Item. A zero (0) indicates a (wildcard)		carried in the Sub-Data Item. A zero (0) indicates a (wildcard)
	match against any PCP value that does not have an explicit match		match against any PCP value that does not have an explicit match
	to a FID. A typical use of a wildcard is mapping any PCPs that		to a FID. A typical use of a wildcard is mapping any PCPs that
	are not explicitly mapped to a default queue. The maximum number		are not explicitly mapped to a default queue. The maximum number
	of PCPs is 8.		of PCPs is 8.
	VLAN Identifier (VID):		VLAN Identifier (VID):
	A 12-bit unsigned integer field indicating the VLAN to be used in		A 12-bit unsigned integer field indicating the VLAN to be used in
	traffic classification. A value of zero (0) indicates that the		traffic classification. VID value zero (0x000) is used to
	VID is to be ignored and any VID is to be accepted during traffic		indicate that the VID is to be ignored. VID 0xFFF is reserved.
	classification. Any explicitly mapped VLANs are matched first.		Any other VID value from 0x001 through 0xFFE can be used in
	Any VLANs that do not have a mapping will then map to this default		traffic classification. Any explicitly mapped VLANs are matched
	mapping.		first. Any VLANs that do not have a mapping will then map to this
			default mapping.
	Priority:		Priority:
	Each Priority Field is 4 bits long and indicates a PCP field as		Each Priority Field is 4 bits long and indicates a PCP field as
	defined in [IEEE8021Q]. Note that zero (0) is a valid value for		defined in [IEEE8021Q]. Note that zero (0) is a valid value for
	PCP.		PCP.
	0 1 2 3		0 1 2 3
	+---+---+---+---+		+---+---+---+---+
	| PCP |MBZ|		| PCP |MBZ|
	+---+---+---+---+		+---+---+---+---+
	skipping to change at line 465 ¶		skipping to change at line 466 ¶
	as described in Section 2.1.1.		as described in Section 2.1.1.
	After successful validation, the receiver MUST ensure that each		After successful validation, the receiver MUST ensure that each
	Priority Field value is listed only once across the whole Traffic		Priority Field value is listed only once across the whole Traffic
	Classification Data Item. Note that this check is across the Data		Classification Data Item. Note that this check is across the Data
	Item and not the individual Sub-Data Items. If the same Priority		Item and not the individual Sub-Data Items. If the same Priority
	Field value is listed more than once within the same Traffic		Field value is listed more than once within the same Traffic
	Classification Data Item, the Data Item MUST be treated as an error		Classification Data Item, the Data Item MUST be treated as an error
	as described in Section 2.1.1.		as described in Section 2.1.1.
	In cases where both Traffic Classification Sub-Data Item types are		In cases where both Traffic Classification Sub-Data Item Types are
	defined, matching on Ethernet information takes precedence. More		defined, matching on Ethernet information takes precedence. More
	specifically, when a packet matches both a DSCP indicated in a		specifically, when a packet matches both a DSCP indicated in a
	Diffserv Traffic Classification Sub-Data Item (Section 2.2) and a		Diffserv Traffic Classification Sub-Data Item (Section 2.2) and a
	VID/PCP identified in an Ethernet Traffic Classification Sub-Data		VID/PCP identified in an Ethernet Traffic Classification Sub-Data
	Item (Section 2.3), the TID associated with the matching VLAN/PCP		Item (Section 2.3), the TID associated with the matching VLAN/PCP
	MUST be used.		MUST be used.
	3. Compatibility		3. Compatibility
	The formats defined in this document will only be used when		The formats defined in this document will only be used when
	skipping to change at line 684 ¶		skipping to change at line 685 ¶
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link		[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link
	Exchange Protocol (DLEP) Control-Plane-Based Pause		Exchange Protocol (DLEP) Control-Plane-Based Pause
	Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,		Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,
	<https://www.rfc-editor.org/info/rfc8651>.		<https://www.rfc-editor.org/info/rfc8651>.
	[RFC9893] Cheng, B., Wiggins, D., Ratliff, S., Berger, L., and E.		[RFC9893] Cheng, B., Wiggins, D., Ratliff, S., Berger, L., and E.
	Kinzie, Ed., "Dynamic Link Exchange Protocol (DLEP)		Kinzie, Ed., "Dynamic Link Exchange Protocol (DLEP)
	Credit-Based Flow Control Messages and Data Items",		Credit-Based Flow Control Messages and Data Items",
	RFC 9893, DOI 10.17487/RFC9893, November 2025,		RFC 9893, DOI 10.17487/RFC9893, December 2025,
	<https://www.rfc-editor.org/info/rfc9893>.		<https://www.rfc-editor.org/info/rfc9893>.
	[RFC9894] Cheng, B., Wiggins, D., Berger, L., and D. Eastlake 3rd,		[RFC9894] Cheng, B., Wiggins, D., Berger, L., and D. Eastlake 3rd,
	Ed., "Dynamic Link Exchange Protocol (DLEP) Diffserv Aware		Ed., "Dynamic Link Exchange Protocol (DLEP) Diffserv Aware
	Credit Window Extension", RFC 9894, DOI 10.17487/RFC9894,		Credit Window Extension", RFC 9894, DOI 10.17487/RFC9894,
	November 2025, <https://www.rfc-editor.org/info/rfc9894>.		December 2025, <https://www.rfc-editor.org/info/rfc9894>.
	Acknowledgments		Acknowledgments
	The Sub-Data Item format was inspired by Rick Taylor's "Data Item		The Sub-Data Item format was inspired by Rick Taylor's "Data Item
	Containers". He also proposed the separation of credit windows from		Containers". He also proposed the separation of credit windows from
	traffic classification at IETF 98. This document was derived from		traffic classification at IETF 98. This document was derived from
	[RFC9894] as a result of discussions at IETF 101. Many useful		[RFC9894] as a result of discussions at IETF 101. Many useful
	comments were received from contributors to the MANET Working Group,		comments were received from contributors to the MANET Working Group,
	notably Ronald in 't Velt and David Black.		notably Ronald in 't Velt and David Black.
End of changes. 8 change blocks.
	14 lines changed or deleted		15 lines changed or added
This html diff was produced by rfcdiff 1.48.