rfc9892.original.xml   rfc9892.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<?rfc symrefs="yes" ?> docName="draft-ietf-manet-dlep-traffic-classification-17" number="9892" consens
<?rfc sortrefs="yes"?> us="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude
<?rfc iprnotified="no" ?> ="true" symRefs="true" sortRefs="true" version="3">
<?rfc strict="yes" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
docName="draft-ietf-manet-dlep-traffic-classification-17" obsoletes="" updates=
"" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs
="true" version="3">
<!-- xml2rfc v2v3 conversion 3.19.4 -->
<front> <front>
<title abbrev="DLEP Traffic Classification"> <title abbrev="DLEP Traffic Classification">Dynamic Link Exchange Protocol (
Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item</title> DLEP) Traffic Classification Data Item</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-manet-dlep-traffic-class <seriesInfo name="RFC" value="9892"/>
ification-17"/>
<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng"> <author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
<organization>MIT Lincoln Laboratory</organization> <organization>MIT Lincoln Laboratory</organization>
<address> <address>
<postal> <postal>
<street>Massachusetts Institute of Technology</street> <street>Massachusetts Institute of Technology</street>
<street>244 Wood Street</street> <street>244 Wood Street</street>
<city>Lexington</city> <city>Lexington</city>
<region>MA</region> <region>MA</region>
<code>02421-6426</code> <code>02421-6426</code>
<country>United States of America</country>
</postal> </postal>
<email>bcheng@ll.mit.edu</email> <email>bcheng@ll.mit.edu</email>
</address> </address>
</author> </author>
<author initials="D." surname="Wiggins" fullname="David Wiggins"> <author initials="D." surname="Wiggins" fullname="David Wiggins">
<address>
<email>david@none.org</email>
</address>
</author> </author>
<author initials="L." surname="Berger" fullname="Lou Berger"> <author initials="L." surname="Berger" fullname="Lou Berger">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>lberger@labn.net</email> <email>lberger@labn.net</email>
</address> </address>
</author> </author>
<author role="editor" initials="D." surname="Fedyk" fullname="Don Fedyk"> <author role="editor" initials="D." surname="Fedyk" fullname="Don Fedyk">
<organization>LabN Consulting, L.L.C.</organization> <organization>LabN Consulting, L.L.C.</organization>
<address> <address>
<email>dfedyk@labn.net</email> <email>dfedyk@labn.net</email>
</address> </address>
</author> </author>
<date/> <date month="November" year="2025"/>
<area>RTG</area>
<workgroup>manet</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<abstract> <abstract>
<t> <t>
This document defines a new Data Item for the Dynamic Link Exchange Protoc ol (DLEP) This document defines a new Data Item for the Dynamic Link Exchange Protoc ol (DLEP)
to support traffic classification. Traffic classification to support traffic classification. Traffic classification
information identifies traffic flows based on information identifies traffic flows based on
frame/packet content such as destination address. The Data Item frame/packet content such as a destination address. The Data Item
is defined in an extensible and reusable fashion. Its use will be is defined in an extensible and reusable fashion. Its use will be
mandated in other documents defining specific DLEP extensions. mandated in other documents defining specific DLEP extensions.
This document also introduces DLEP Sub-Data Items, and Sub-Data This document also introduces DLEP Sub-Data Items; Sub-Data
Items are defined to support DiffServ and Ethernet traffic Items are defined to support Diffserv and Ethernet traffic
classification. classification.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sec-1" numbered="true" toc="default"> <section anchor="sec-1" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
The Dynamic Link Exchange Protocol (DLEP) is defined in <xref target="RFC8 175" format="default"/>. This protocol provides the exchange of link related The Dynamic Link Exchange Protocol (DLEP) is defined in <xref target="RFC8 175" format="default"/>. This protocol provides the exchange of link-related
control information between DLEP peers. DLEP peers are comprised control information between DLEP peers. DLEP peers are comprised
of a modem and a router. DLEP defines a base set of mechanisms as of a modem and a router. DLEP defines a base set of mechanisms as
well as support for possible extensions. DLEP defines Data Items well as support for possible extensions. DLEP defines Data Items,
which are sets of information that can be reused in DLEP which are sets of information that can be reused in DLEP
messaging. The DLEP specification does not include any flow messaging. The DLEP specification does not include any flow
identification beyond DLEP endpoints, i.e., flows are identified identification beyond DLEP endpoints, i.e., flows are identified
based on their DLEP endpoint. based on their DLEP endpoint.
</t> </t>
<t>This document defines DLEP <t>This document defines DLEP
Data Item formats which provide flow identification on a more Data Item formats that provide flow identification on a more
granular basis. Specifically, it enables a router granular basis. Specifically, it enables a router
to use traffic flow classification information provided by the to use traffic flow classification information provided by the
modem to identify traffic flows based on a combination of modem to identify traffic flows based on a combination of
information found in a data plane header. information found in a data plane header.
(For general background on traffic classification see (For general background on traffic classification, see
<xref target="RFC2475" format="default"/> Section 2.3.) <xref target="RFC2475" sectionFormat="of" section="2.3"/>.)
The Data Item is structured to The Data Item is structured to
allow for use of the defined traffic classification information allow for the use of the defined traffic classification information
with applications such as credit window control as specified in with applications such as credit window control as specified in
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>. <xref target="RFC9893" format="default"/>. <xref target="RFC9893" format="
The credit window control document provides an default"/> provides an
example of combining traffic classification example of combining traffic classification
and credit window flow control. and credit window flow control.
</t> </t>
<t> <t>
This document defines traffic classification based on a DLEP This document defines traffic classification based on a DLEP
destination and flows identified by either DiffServ destination and flows identified by either Differentiated Services Code Po
<xref target="RFC2475" format="default"/> ints (DSCPs) <xref target="RFC2475" format="default"/>
Differentiated Services Codepoints (DSCPs) or IEEE or IEEE
802.1Q <xref target="IEEE8021Q" format="default"/> Ethernet 802.1Q Ethernet
Priority Code Points (PCPs). Priority Code Points (PCPs) <xref target="IEEE8021Q" format="default"/>.
The defined mechanism allows for flows to be described in The defined mechanism allows for flows to be described in
a flexible fashion and when combined with applications such as a flexible fashion and when combined with applications such as
credit window control, allows credit windows to be shared credit window control, allows credit windows to be shared
across traffic sent to multiple DLEP destinations and as part of across traffic sent to multiple DLEP destinations and as part of
multiple flows, or used multiple flows, or used
exclusively for traffic sent to a particular destination and/or exclusively for traffic sent to a particular destination and/or
belonging to a particular flow. belonging to a particular flow.
The extension also supports the "wildcard" matching of any flow (DSCP The extension also supports the "wildcard" matching of any flow (DSCP
or PCP). Traffic classification information is provided such that it or PCP). Traffic classification information is provided such that it
can be readily extended to support other traffic classification can be readily extended to support other traffic classification
techniques, or be used by non-credit window related extensions, such techniques or can be used by extensions that are not related to credit win
as <xref target="RFC8651" format="default"/> or even dows, such
as the extension defined in <xref target="RFC8651" format="default"/> or e
ven
5-tuple IP flows. 5-tuple IP flows.
<!-- [rfced] Section 1: We had trouble following the "and", "or", and
"and/or" relationships in this sentence. If the suggested text is not
correct, please clarify.
Original:
The defined mechanism allows
for flows to be described in a flexible fashion and when combined
with applications such as credit window control, allows credit
windows to be shared across traffic sent to multiple DLEP
destinations and as part of multiple flows, or used exclusively for
traffic sent to a particular destination and/or belonging to a
particular flow.
Suggested:
The defined mechanism allows
for flows to be described in a flexible fashion and, when combined
with applications such as credit window control, allows credit
windows to be (1) shared across traffic sent to multiple DLEP
destinations and as part of multiple flows or (2) used exclusively
for traffic sent to a particular destination and/or belonging to a
particular flow. -->
</t> </t>
<t> <t>
This document defines support for traffic classification using a This document defines support for traffic classification using a
single new Data Item in <xref target="sec-di-tc" format="default"/> for ge single new Data Item (see <xref target="sec-di-tc" format="default"/>) for
neral general
support and two new Sub-Data Items are defined to support support. Two new Sub-Data Items are defined to support
identification of flows based on DSCPs and PCPs. identification of flows based on DSCPs and PCPs.
</t> </t>
<section anchor="sec-1.1" numbered="true" toc="default"> <section anchor="sec-1.1" numbered="true" toc="default">
<name>Key Words</name> <name>Key Words</name>
<t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in "<bcp14>SHOULD NOT</bcp14>",
BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
format="default"/> when, and "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
only when, they appear in all capitals, as shown here. are to be interpreted as described in BCP&nbsp;14
</t> <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
when, they appear in all capitals, as shown here.</t>
</section> </section>
</section> </section>
<section anchor="sec-tc" numbered="true" toc="default"> <section anchor="sec-tc" numbered="true" toc="default">
<name>Traffic Classification</name> <name>Traffic Classification</name>
<t> <t>
The Traffic Classification Data Item represents a list of The Traffic Classification Data Item represents a list of
flows that may be used at the same time to provide flows that may be used at the same time to provide
different service classes different service classes
for traffic sent from a for traffic sent from a
router to a modem. The data plane information used to identify each router to a modem. The data plane information used to identify each
flow is represented in a separate Sub-Data Item. The Data Item and flow is represented in a separate Sub-Data Item. The Data Item and
Sub-Data Item structure is intended to be independent of any Sub-Data Item structures are intended to be independent of any
specific usage of the flow identification, e.g., flow control. The specific usage of the flow identification, e.g., flow control. The
Sub-Data Item structure is also intended to allow for future traffic Sub-Data Item structure is also intended to allow for future traffic
classification types, e.g., 5-tuple flows. While the structure of classification types, e.g., 5-tuple flows. While the structure of
the Data Items is extensible, actual flow information is expected to the Data Items is extensible, actual flow information is expected to
be used in an extension dependent manner. Support for DSCP and be used in an extension-dependent manner. Support for DSCP and
PCP-based flows are defined via individual Sub-Data Items PCP-based flows is defined via individual Sub-Data Items; see
below. Other types of flow identification, e.g., based on IP below. Other types of flow identification, e.g., based on IP
protocol and ports, may be defined in the future via new Sub-Data protocol and ports, may be defined in the future via new Sub-Data
Items. Note that when extensions supporting multiple Sub-Data Item Items. Note that when extensions supporting multiple Sub-Data Item
types are negotiated, these types MAY be combined in a single Data Item. types are negotiated, these types <bcp14>MAY</bcp14> be combined in a single
Data Item.
<!-- [rfced] Section 2: Does "based on IP protocol and" (which looks
like "based on Internet Protocol protocol and") mean "based on IP
protocol type and" or something else?
Original:
Other types of flow identification, e.g., based on
IP protocol and ports, may be defined in the future via new Sub-Data
Items. -->
</t> </t>
<t> <t>
Each list of flows is identified Each list of flows is identified
using a "Traffic Classification Identifier" or "TID" and is expected using a "Traffic Classification Identifier" or "TID" and is expected
to represent a valid combination of data plane identifiers that may to represent a valid combination of data plane identifiers that may
be used at the same time. Each flow is identified via a "Flow be used at the same time. Each flow is identified via a "Flow
Identifier" or "FID". Each FID is defined in a Sub-Data Item which Identifier" or "FID". Each FID is defined in a Sub-Data Item that
carries the data plane identifier or identifiers used to associate carries the data plane identifier or identifiers used to associate
traffic with the flow. A DLEP destination address is also needed to traffic with the flow. A DLEP destination address is also needed to
complete traffic classification information used in extensions such complete traffic classification information used in extensions such
as flow control. This information is expected to be provided in an as flow control. This information is expected to be provided in an
extension specific manner. For example, this address can be provided extension-specific manner. For example, this address can be provided
by a modem when it identifies the traffic classification set in a by a modem when it identifies the traffic classification set in a
Destination Up Message using the Credit Window Associate Data Item Destination Up Message using the Credit Window Association Data Item
defined in <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="de defined in <xref target="RFC9893" format="default"/>.
fault"/>.
TID and FID values have modem-local scope. TID and FID values have modem-local scope.
</t> </t>
<section anchor="sec-di-tc" numbered="true" toc="default"> <section anchor="sec-di-tc" numbered="true" toc="default">
<name>Traffic Classification Data Item</name> <name>Traffic Classification Data Item</name>
<t> <t>
This section defines the Traffic Classification Data Item. This This section defines the Traffic Classification Data Item. This
Data Item is used by a modem to provide a router with traffic Data Item is used by a modem to provide a router with traffic
classification information. When an extension requires use of classification information. When an extension requires the use of
any Data Item, the Data Items, including this Traffic Classification Data any Data Item, the Data Items, including this Traffic Classification Data
Item SHOULD be Item, <bcp14>SHOULD</bcp14> be
included by a modem in any Session Initialization Response Message, e.g., included by a modem in any Session Initialization Response Message (e.g.,
see see
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>. <xref target="RFC9893" format="default"/>).
Updates to Updates to
previously provided traffic classifications or new traffic previously provided traffic classifications or new traffic
classifications MAY be sent by a modem by including the Data Item classifications <bcp14>MAY</bcp14> be sent by a modem by including the Dat
in Session Update Messages. More than one Data Item MAY be a Item
in Session Update Messages. More than one Data Item <bcp14>MAY</bcp14> be
included in a message to provide information on multiple traffic included in a message to provide information on multiple traffic
classifiers. classifiers.
</t> </t>
<t> <t>
The set of traffic classification information provided in the data The set of traffic classification information provided in the Data
item is identified using a Traffic Classification Identifier, or Item is identified using a
TID. The actual data plane related information used in traffic TID. The actual information related to data planes that is used in traffi
c
classification is provided in a variable list of Traffic classification is provided in a variable list of Traffic
Classification Sub-Data Items. Classification Sub-Data Items.
</t> </t>
<t> <t>
The format of the Traffic Classification Data Item is: The format of the Traffic Classification Data Item is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length | | Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Traffic Class. Identifier (TID)| Num SDIs | Reserved | |Traffic Class. Identifier (TID)| Num SDIs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item 1 ~ ~ Traffic Classification Sub-Data Item 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~ ~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item n ~ ~ Traffic Classification Sub-Data Item n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Data Item Type:</dt> <dt>Data Item Type:</dt>
<dd>TBA1</dd> <dd>29</dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
<t>Variable <t>Variable
</t> </t>
<t> <t>
Per <xref target="RFC8175" format="default"/> Length Per <xref target="RFC8175" format="default"/>, Length
is the number of octets in the Data Item, excluding the Type and is the number of octets in the Data Item, excluding the Type and
Length fields. The length here is limited by the packet data unit (PDU) length Length fields. The length here is limited by the packet data unit (PDU) length
supported. For example if the Packet is limited to 1400 bytes then the supported. For example, if the packet is limited to 1400 bytes, then th
length MUST NOT exceed this value. If larger packets are supported e
the maximum MUST be adjusted to be smaller or equal to the maximum PDU. length <bcp14>MUST NOT</bcp14> exceed this value. If larger packets are
Multiple messages can be used if there is more than fits in a single TLV supported,
. the maximum <bcp14>MUST</bcp14> be adjusted to be smaller than or equal
to the maximum PDU.
Multiple messages can be used if there is more data than will fit in a s
ingle TLV.
<!-- [rfced] Sections 2.1 and 2.1.1: We do not see a Type field in
RFC 8175, but we see a "Data Item Type" field. May we update as
suggested (per Section 11.3 ("DLEP Generic Data Item") of RFC 8175),
to distinguish this definition from the definitions of Length in
Sections 11.1 ("DLEP Signal Header") and 11.2 ("DLEP Message Header")
of RFC 8175, which do not mention excluding a "Type" field?
Original:
Per [RFC8175] Length is the number of octets in the Data Item,
excluding the Type and Length fields.
...
Copying [RFC8175], Length is a 16-bit unsigned integer that is the
number of octets in the Sub-Data Item, excluding the Type and
Length fields.
Suggested:
Per Section 11.3 of [RFC8175], Length is the number of octets in the
Data Item, excluding the Data Item Type and Length fields.
...
Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer
that is the number of octets in the Sub-Data Item, excluding the
Data Item Type and Length fields. -->
</t> </t>
</dd> </dd>
<dt> Traffic Classification Identifier (TID):</dt> <dt> Traffic Classification Identifier (TID):</dt>
<dd> <dd>
A 16-bit unsigned integer identifying a traffic classification A 16-bit unsigned integer identifying a traffic classification
set. There is no restriction on values used by a modem, and there set. There is no restriction on values used by a modem, and there
is no requirement for sequential or ordered values. is no requirement for sequential or ordered values.
</dd> </dd>
<dt>Num SDIs:</dt> <dt>Num SDIs:</dt>
<dd> <dd>
An 8-bit unsigned integer indicating the number of Traffic An 8-bit unsigned integer indicating the number of Traffic
Classification Sub-Data Items included in the Data Item. A value Classification Sub-Data Items included in the Data Item. A value
of zero (0) is allowed and indicates that no traffic should be of zero (0) is allowed and indicates that no traffic should be
matched against this TID. matched against this TID.
</dd> </dd>
<dt>Reserved:</dt> <dt>Reserved:</dt>
<dd> <dd>
For the Traffic Classification Data Item this reserved field is curre For the Traffic Classification Data Item, this reserved field is curr
ntly unused. ently unused.
It MUST be set to all zeros for this version of the Data I It <bcp14>MUST</bcp14> be set to all zeros for this versio
tem and it is currently ignored on reception. n of the Data Item and is currently ignored on reception.
This allows for future extensions of the Data Item if need ed. This allows for future extensions of the Data Item if need ed.
</dd> </dd>
<dt>Traffic Classification Sub-Data Item:</dt> <dt>Traffic Classification Sub-Data Item:</dt>
<dd> <dd>
Zero or more Traffic Classification Sub-Data Items of the format Zero or more Traffic Classification Sub-Data Items of the format
defined below MAY be included. The number MUST match the value defined in <xref target="sec-di-tc-sub"/> <bcp14>MAY</bcp14> be includ ed. The number <bcp14>MUST</bcp14> match the value
carried in the Num SDIs field. carried in the Num SDIs field.
<!-- [rfced] Section 2.1: For ease of the reader, we changed "below"
to "in Section 2.1.1". If this is incorrect, please clarify what
"below" refers to.
Original:
Traffic Classification Sub-Data Item:
Zero or more Traffic Classification Sub-Data Items of the format
defined below MAY be included.
Currently:
Traffic Classification Sub-Data Item:
Zero or more Traffic Classification Sub-Data Items of the format
defined in Section 2.1.1 MAY be included. -->
</dd> </dd>
</dl> </dl>
<t> <t>
A router receiving the Traffic Classification Data Item MUST A router receiving the Traffic Classification Data Item <bcp14>MUST</bcp14 >
locate the traffic classification information that is associated locate the traffic classification information that is associated
with the TID indicated in each received Data Item. If no with the TID indicated in each received Data Item. If no
associated traffic classification information is found, the router associated traffic classification information is found, the router
MUST initialize a new information set using the values carried in <bcp14>MUST</bcp14> initialize a new information set using the values carr ied in
the Data Item. If the associated traffic classification information the Data Item. If the associated traffic classification information
is found, the router MUST replace the corresponding information using the is found, the router <bcp14>MUST</bcp14> replace the corresponding informa
values tion using the values
carried in the Data Item. In both cases, a router MUST also carried in the Data Item. In both cases, a router <bcp14>MUST</bcp14> als
ensure that any data plane state, e.g., <xref target="I-D.ietf-manet-dlep- o
credit-flow-control" format="default"/>, that is ensure that any data plane state (e.g., see <xref target="RFC9893" format=
"default"/>) that is
associated with the TID is updated as needed. associated with the TID is updated as needed.
</t> </t>
<section anchor="sec-di-tc-sub" numbered="true" toc="default"> <section anchor="sec-di-tc-sub" numbered="true" toc="default">
<name>Traffic Classification Sub-Data Item</name> <name>Traffic Classification Sub-Data Item</name>
<t> <t>
All Traffic Classification Sub-Data Items share a common format All Traffic Classification Sub-Data Items share a common format
that is patterned after the standard DLEP Data Item format, see that is patterned after the standard DLEP Data Item format. See
<xref target="RFC8175" format="default"/> Section 11.3. There is no req <xref target="RFC8175" sectionFormat="of" section="11.3"/>. There is no
uirement requirement
on, or meaning to Sub-Data Item ordering. on, or meaning to, Sub-Data Item ordering.
Any errors or inconsistencies encountered in parsing Sub-Data Items Any errors or inconsistencies encountered in parsing Sub-Data Items
are handled in the same fashion as any other Data Item parsing error are handled in the same fashion as any other Data Item parsing error
encountered in DLEP, see <xref target="RFC8175" format="default"/>. encountered in DLEP. See <xref target="RFC8175" format="default"/>.
</t> </t>
<t> <t>
The format of the Traffic Classification Sub-Data Item is: The format of the Traffic Classification Sub-Data Item is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type | Length | | Sub-Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value... ~ ~ Value... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Sub-Data Item Type:</dt> <dt>Sub-Data Item Type:</dt>
<dd> <dd>
A 16-bit unsigned integer that indicates the type and A 16-bit unsigned integer that indicates the type and
corresponding format of the Sub-Data Item's Value field. corresponding format of the Sub-Data Item's Value field.
Sub-Data Item Types are scoped within the Data Item in which Sub-Data Item Types are scoped within the Data Item in which
they are carried, i.e., the Sub-Data Item Type field MUST be they are carried, i.e., the Sub-Data Item Type field <bcp14>MUST</bc p14> be
used together with the Traffic Classification Data Item Type to iden tify the format used together with the Traffic Classification Data Item Type to iden tify the format
of the Sub-Data Item. Traffic Classification Sub-Data of the Sub-Data Item. Traffic Classification Sub-Data
Item Types are managed according to the IANA registry described Item Types are managed according to the
IANA registry described
in <xref target="sec-iana-sdi" format="default"/>. in <xref target="sec-iana-sdi" format="default"/>.
</dd> </dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
<t>Variable <t>Variable
</t> </t>
<t> <t>
Copying <xref target="RFC8175" format="default"/>, Length is a 16-bit unsigned Per <xref target="RFC8175" format="default"/>, Length is a 16-bit unsi gned
integer that is the number of octets in the Sub-Data Item, integer that is the number of octets in the Sub-Data Item,
excluding the Type and Length fields. The maximum length is limited on a per excluding the Type and Length fields. The maximum length is limited on a per
Sub-Data Item Type. Sub-Data Item Type.
<!-- [rfced] Section 2.1.1: We had trouble following the meaning of
"on a per Sub-Data Item Type". Are some words missing?
Original:
The maximum length is limited on a per Sub-Data
Item Type. -->
</t> </t>
</dd> </dd>
<!-- [rfced] Section 2.1.1: We see that the Value field is mentioned
under "Sub-Data Item Type:" but is not otherwise defined. Would you
like to add a list item and explanation of the Value field?
For example, Section 11.3 of RFC 8175 provides this definition of the
Value field:
Value: A field of <Length> octets that contains data specific to a
particular Data Item.
Original:
~ Value... ~
...
Sub-Data Item Type:
A 16-bit unsigned integer that indicates the type and
corresponding format of the Sub-Data Item's Value field. ... -->
</dl> </dl>
</section> </section>
</section> </section>
<section anchor="sec-di-tc-ds-sub" numbered="true" toc="default"> <section anchor="sec-di-tc-ds-sub" numbered="true" toc="default">
<name>DiffServ Traffic Classification Sub-Data Item</name> <name>Diffserv Traffic Classification Sub-Data Item</name>
<t> <t>
The DiffServ Traffic Classification Sub-Data Item identifies The Diffserv Traffic Classification Sub-Data Item identifies
the set of DSCPs that should be treated as a the set of DSCPs that should be treated as a
single flow, i.e., receive the same traffic treatment. DSCPs are single flow, i.e., receive the same traffic treatment. DSCPs are
identified in a list of DiffServ fields. An implementation that identified in a list of Diffserv fields. An implementation that
does not support DSCPs and wants the same traffic treatment for does not support DSCPs and wants the same traffic treatment for
all traffic to a destination or destinations would indicate all traffic to a destination or destinations would indicate
0 DSCPs. 0 DSCPs.
</t> </t>
<t> <t>
The format of the DiffServ Traffic Classification Sub-Data Item The format of the Diffserv Traffic Classification Sub-Data Item
is: is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type (1) | Length | | Sub-Data Item Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Identifier (FID) | Num DSCPs | DS Field 1 | | Flow Identifier (FID) | Num DSCPs | DS Field 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Field 2 | ... | DS Field n | | DS Field 2 | ... | DS Field n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Sub-Data Item Type:</dt> <dt>Sub-Data Item Type:</dt>
<dd> <dd>
<t> <t>
Sub-Data Item Type with value one (1) identifies the DiffServ Sub-Data Item Type with value one (1) identifies the Diffserv
Traffic Classification Sub-Data Item Type in the format Traffic Classification Sub-Data Item Type in the format
defined in <xref target="sec-di-tc-sub"/>. defined in <xref target="sec-di-tc-sub"/>.
</t> </t>
</dd> </dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
<t>Variable <t>Variable
</t> </t>
<t> <t>
Length is defined above. For this Sub-Data Item, it is Length is defined above. For this Sub-Data Item, it is
equal to three (3) octets plus the value of the Num DSCPs fi eld. equal to three (3) octets plus the value of the Num DSCPs fi eld.
This means that the maximum Length base on a FID per DSCP fo r this TLV could be This means that the maximum Length base on a FID per DSCP fo r this TLV could be
64 times 3 plus one for Num DSCPs plus one DSCPs or 320 octe ts. 64 times 3 plus one for Num DSCPs plus one DSCPs or 320 octe ts.
The definition can be in multiple Sub-Data Items that are mu ch smaller than this. The definition can be in multiple Sub-Data Items that are mu ch smaller than this.
<!-- [rfced] Section 2.2: Please clarify "one DSCPs". There appears
to be a singular-versus-plural issue (i.e., perhaps either "one DSCP"
or "one or more DSCPs" would be correct here).
Original:
This
means that the maximum Length base on a FID per DSCP for this TLV
could be 64 times 3 plus one for Num DSCPs plus one DSCPs or 320
octets. -->
</t> </t>
</dd> </dd>
<!-- [rfced] Section 2.2: Please confirm that there is no IANA registration
associated with the value "0xFFFF" in this sentence.
Original:
The value of 0xFFFF is reserved and MUST NOT be used in
this field.
-->
<dt>Flow Identifier (FID):</dt> <dt>Flow Identifier (FID):</dt>
<dd> <dd>
A 16-bit unsigned integer representing the data plane A 16-bit unsigned integer representing the data plane
information carried in the Sub-Data Item that is to be used in information carried in the Sub-Data Item that is to be used in
identifying a flow. The value of 0xFFFF is reserved and MUST identifying a flow. The value 0xFFFF is reserved and <bcp14>MUST
NOT be used in this field. NOT</bcp14> be used in this field.
</dd> </dd>
<dt>Num DSCPs:</dt> <dt>Num DSCPs:</dt>
<dd> <dd>
An 8-bit unsigned integer indicating the number of DSCPs An 8-bit unsigned integer indicating the number of DSCPs
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 DSCP value that does not have an explicit match to a FID. A typical match against any DSCP value that does not have an explicit match to a FID. A typical
use of this is mapping any DSCPs that are not explicitly mapped to a d efault queue. use of this is mapping any DSCPs that are not explicitly mapped to a d efault queue.
</dd> </dd>
<dt>DS Field:</dt> <dt>DS Field:</dt>
<dd> <dd>
<t> <t>
Each DS Field is an 8-bit that carries the DSCP field defined Each DS Field is 8 bits long and carries the DSCP field as defined
in <xref target="RFC2474" format="default"/>. in <xref target="RFC2474" format="default"/>.
</t>
<!-- [rfced] Section 2.2: We changed "is an 8-bit that carries" to
"is 8 bits long and carries". If this update is incorrect, please
clarify the meaning of "an 8-bit that carries".
Original:
DS Field:
Each DS Field is an 8-bit that carries the DSCP field defined in
[RFC2474].
Currently:
DS Field:
Each DS Field is 8 bits long and carries the DSCP field as
defined in [RFC2474]. -->
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| DSCP | MBZ | | DSCP | MBZ |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
]]></artwork>
DSCP: Differentiated Services Codepoint (RFC 2474). <dl spacing="compact" newline="false">
MBZ: Must Be Zero - set to zero when transmitted. <dt>DSCP:</dt><dd>Differentiated Services Code Point <xref target="
]]></artwork> RFC2474"/></dd>
<dt>MBZ:</dt><dd>Must Be Zero - set to zero when transmitted</dd>
</dl>
</dd> </dd>
</dl> </dl>
<section anchor="sec-di-tc-rrp" numbered="true" toc="default"> <section anchor="sec-di-tc-rrp" numbered="true" toc="default">
<name>Router Receive Processing</name> <name>Router Receive Processing</name>
<t> <t>
A router receiving the Traffic Classification Sub-Data A router receiving the Traffic Classification Sub-Data
Item MUST validate the information on receipt, prior to using Item <bcp14>MUST</bcp14> validate the information on receipt, prior to u sing
the carried information, including potentially updating the data the carried information, including potentially updating the data
behavior as determined by the extension requiring the use of the behavior as determined by the extension requiring the use of the
Sub-Data Item. Validation failures MUST be treated as an error as Sub-Data Item. Validation failures <bcp14>MUST</bcp14> be treated as an
described above in <xref target="sec-di-tc-sub" format="default"/>. error as
described in <xref target="sec-di-tc-sub" format="default"/>.
</t> </t>
<t> <t>
Once validated, the receiver MUST ensure that each DS Field Once validated, the receiver <bcp14>MUST</bcp14> ensure that each DS Fie ld
value is listed only once across the whole Traffic value is listed only once across the whole Traffic
Classification Data Item. Note, this check is across the Data Classification Data Item. Note that this check is across the Data
Item and not the individual Sub-Data Item. If the same DS Field Item and not the individual Sub-Data Item. If the same DS Field
value is listed more than once within the same Traffic value is listed more than once within the same Traffic
Classification Data Item, the Data Item MUST be treated as an Classification Data Item, the Data Item <bcp14>MUST</bcp14> be treated a
error as described above in s an
error as described in
<xref target="sec-di-tc-sub" format="default"/>. <xref target="sec-di-tc-sub" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="sec-di-tc-e-sub" numbered="true" toc="default"> <section anchor="sec-di-tc-e-sub" numbered="true" toc="default">
<name>Ethernet Traffic Classification Sub-Data Item</name> <name>Ethernet Traffic Classification Sub-Data Item</name>
<t> <t>
The Ethernet Traffic Classification Sub-Data Item The Ethernet Traffic Classification Sub-Data Item
identifies the VLAN and PCPs that should be treated as a single identifies the VLAN and PCPs that should be treated as a single
flow, i.e., receive the same traffic treatment. Ethernet Priority flow, i.e., receive the same traffic treatment. Ethernet PCP
Code Point support is defined as part of the IEEE 802.1Q support is defined as part of the IEEE 802.1Q
<xref target="IEEE8021Q" format="default"/> tag format and inclu tag format <xref target="IEEE8021Q" format="default"/> and inclu
des a 3 bit "PCP" des a 3-bit "PCP"
field. The tag format also includes a 12 bit VLAN identifier field. The tag format also includes a 12-bit "VLAN Identifier
(VID) field. PCPs are identified in a list of priority fields. An (VID)" field. PCPs are identified in a list of priority fields. An
implementation that does not support PCPs and wants the same implementation that does not support PCPs and wants the same
traffic treatment for all traffic to a destination or destinations traffic treatment for all traffic to a destination or destinations
would indicate 0 PCPs. Such an implementation could identify a would indicate 0 PCPs. Such an implementation could identify a
VLAN to use per destination. VLAN to use per destination.
</t> </t>
<t> <t>
The format of the Ethernet Traffic Classification The format of the Ethernet Traffic Classification
Sub-Data Item is: Sub-Data Item is as follows:
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type (2) | Length | | Sub-Data Item Type (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) | | Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri. 1| Pri. 2| ..... | ..... | ..... | Pad | | Pri. 1| Pri. 2| ..... | ..... | ..... | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Sub-Data Item Type:</dt> <dt>Sub-Data Item Type:</dt>
<dd> <dd>
<t> <t>
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 Traffic Classification Sub-Data Item Type in the format
defined in <xref target="sec-di-tc-sub"/>. defined in <xref target="sec-di-tc-sub"/>.
</t> </t>
</dd> </dd>
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
<t>Variable <t>Variable
</t> </t>
<t> <t>
Length is defined above. For this Sub-Data Item, it is equal Length is defined above. For this Sub-Data Item, it is equal
to four (4) plus the number of octets needed to accommodate to four (4) plus the number of octets needed to accommodate
the number of Priority fields indicated by the NumPCPs the number of Priority fields indicated by the NumPCPs
field. Note that as length is in octets and each Priority field. Note that as the length is in octets and each Priority
field is 4 bits, the additional length is the value carried in field is 4 bits, the additional length is the value carried in
the NumPCPs field divided by two and rounded up to the next the NumPCPs field divided by 2 and rounded up to the next
higher integer quantity. higher integer quantity.
This TLV has maximum length of 4 plus 8 divided by 2 or 16 octets. This TLV has a maximum length of 4 plus 8 divided by 2 or 16 octets.
<!-- [rfced] Section 2.3: We had trouble following these sentences.
Does "the next higher integer quantity" refer to a higher integer
quantity that comes next, or does it mean "the next-higher integer
quantity" or "the next-highest integer quantity"? In the equation,
does "divided by 2 or 16 octets" mean "divided by either 2 octets or
16 octets", or something else?
Original:
Note
that as length is in octets and each Priority field is 4 bits, the
additional length is the value carried in the NumPCPs field
divided by two and rounded up to the next higher integer quantity.
This TLV has maximum length of 4 plus 8 divided by 2 or 16 octets. -->
</t> </t>
</dd> </dd>
<dt>Flow Identifier (FID):</dt> <dt>Flow Identifier (FID):</dt>
<dd> <dd>
A 16-bit unsigned integer representing the data plane A 16-bit unsigned integer representing the data plane
information carried in the Sub-Data Item that is to be used in information carried in the Sub-Data Item that is to be used in
identifying a flow. The value of 0xFFFF is reserved and MUST identifying a flow. The value 0xFFFF is reserved and <bcp14>MUST
NOT be used in this field. NOT</bcp14> be used in this field.
</dd> </dd>
<dt>Num PCPs:</dt> <dt>Num PCPs:</dt>
<dd> <dd>
A 4-bit unsigned integer indicating the number of Priority A 4-bit unsigned integer indicating the number of Priority
fields carried in the Sub-Data Item. A zero (0) indicates a fields carried in the Sub-Data Item. A zero (0) indicates a
(wildcard) match against any PCP value (wildcard) match against any PCP value
that does not have an explicit match to a FID. A typical that does not have an explicit match to a FID. A typical
use of a wildcard is mapping any PCPs that are not explicitly mapped t o a default queue. use of a wildcard is mapping any PCPs that are not explicitly mapped t o a default queue.
The maximum number of PCPs 8. The maximum number of PCPs is 8.
<!-- [rfced] Section 2.3: We changed "The maximum number of PCPs 8"
to "The maximum number of PCPs is 8". If this is incorrect, please
clarify the text.
Original:
The maximum number of PCPs 8.
Currently:
The maximum number of PCPs is 8. -->
</dd> </dd>
<dt>VLAN identifier (VID):</dt> <dt>VLAN Identifier (VID):</dt>
<dd> <dd>
A 12-bit unsigned integer field indicating the VLAN to be A 12-bit unsigned integer field indicating the VLAN to be
used in traffic classification. A value of zero (0) indicates used in traffic classification. A value of zero (0) indicates
that the VID is to be ignored and any VID is to be accepted during that the VID is to be ignored and any VID is to be accepted during
traffic classification. Any explicitly mapped VLANs are match first an traffic classification. Any explicitly mapped VLANs are matched first.
d Any VLANs that do not have a mapping will then map to this default map
then any VLANs that do not have a mapping map to this default mapping. ping.
</dd> </dd>
<dt>Priority:</dt> <dt>Priority:</dt>
<dd> <dd>
<!-- [rfced] Section 2.3: Is "either PCP" correct here? Earlier text indicates
that there can be up to 8 PCPs.
Original:
Note that zero (0) is a valid value for either PCP.
Perhaps:
Note that zero (0) is a valid value for PCP.
-->
<t> <t>
Each Priority Field is 4-bits long and indicates a Each Priority Field is 4 bits long and indicates a
PCP field defined in <xref target="IEEE8021Q" format="default"/>. Note PCP field as defined in <xref target="IEEE8021Q" format="default"/>. N
ote
that zero (0) is a valid value for either PCP. that zero (0) is a valid value for either PCP.
</t> </t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
+---+---+---+---+ +---+---+---+---+
| PCP |MBZ| | PCP |MBZ|
+---+---+---+---+ +---+---+---+---+
]]></artwork>
PCP: Priority Code Point (IEEE8021Q) <dl spacing="compact" newline="false">
MBZ: Must Be Zero - set to zero when transmitted. <dt>PCP:</dt><dd>Priority Code Point <xref target="IEEE8021Q" form
at="default"/></dd>
]]></artwork> <dt>MBZ:</dt><dd>Must Be Zero - set to zero when transmitted</dd>
</dl>
</dd> </dd>
<dt>Pad:</dt> <dt>Pad:</dt>
<dd> <dd>
A 4-bit long field included when NumPCPs is an odd number. A field that is 4 bits long and is included when NumPCPs is an odd num
This field MUST be set to zero by the sender, and MUST be ignored ber.
This field <bcp14>MUST</bcp14> be set to zero by the sender and <bcp14
>MUST</bcp14> be ignored
on receipt. on receipt.
</dd> </dd>
</dl> </dl>
<section anchor="sec-di-tc-q-rrp" numbered="true" toc="default"> <section anchor="sec-di-tc-q-rrp" numbered="true" toc="default">
<name>Router Receive Processing</name> <name>Router Receive Processing</name>
<t> <t>
A router receiving the Traffic Classification Sub-Data A router receiving the Traffic Classification Sub-Data
Item MUST validate the information on receipt, prior to the using Item <bcp14>MUST</bcp14> validate the information on receipt, prior to u sing
the carried information, including potentially updating the data the carried information, including potentially updating the data
behavior as determined by the extension requiring the use of the behavior as determined by the extension requiring the use of the
Sub-Data Item. Sub-Data Item.
Note that validation can include usage specific semantics such as those Note that validation can include usage-specific semantics such as those
found in found in
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/ <xref target="RFC9893" format="default"/>.
>. Any failures <bcp14>MUST</bcp14> be treated as an error as
Any failures MUST be treated as an error as described in <xref target="sec-di-tc-sub" format="default"/>.
described above in <xref target="sec-di-tc-sub" format="default"/>.
</t> </t>
<t> <t>
After successful validation, the receiver MUST ensure that each Priority After successful validation, the receiver <bcp14>MUST</bcp14> ensure tha t each Priority
Field value is listed only once across the whole Traffic Field value is listed only once across the whole Traffic
Classification Data Item. Note, 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 Classification Data Item, the Data Item <bcp14>MUST</bcp14> be treated a s an
error as error as
described above in <xref target="sec-di-tc-sub" format="default"/>. described in <xref target="sec-di-tc-sub" format="default"/>.
</t> </t>
<t> <t>
In cases where both Traffic Classification Sub-Data Item types are defin ed, matching on In cases where both Traffic Classification Sub-Data Item types are defin ed, matching on
Ethernet information takes precedence. More specifically, when a packet Ethernet information takes precedence. More specifically, when a packet
matches both a DSCP indicated in a DiffServ Traffic Classification Sub-D ata matches both a DSCP indicated in a Diffserv Traffic Classification Sub-D ata
Item (<xref target="sec-di-tc-ds-sub" format="default"/>) and a VID/PCP Item (<xref target="sec-di-tc-ds-sub" format="default"/>) and a VID/PCP
identified in an Ethernet Traffic Classification Sub-Data Item (<xref identified in an Ethernet Traffic Classification Sub-Data Item (<xref
target="sec-di-tc-e-sub" format="default"/>), then the TID associated w target="sec-di-tc-e-sub" format="default"/>), the TID associated with th
ith the e
matching VLAN/PCP MUST be used. matching VLAN/PCP <bcp14>MUST</bcp14> be used.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="sec-compat" numbered="true" toc="default"> <section anchor="sec-compat" numbered="true" toc="default">
<name>Compatibility</name> <name>Compatibility</name>
<t> <t>
The formats defined in this document will only be used when The formats defined in this document will only be used when
extensions require their use. extensions require their use.
</t> </t>
<t> <t>
The DLEP specification <xref target="RFC8175" format="default"/> defines han dling of unexpected The DLEP specification <xref target="RFC8175" format="default"/> defines the handling of unexpected
appearances of any Data Items, including those defined in this appearances of any Data Items, including those defined in this
document. document.
</t> </t>
<!-- [rfced] We found the following two comments in the XML file.
May we remove them?
First comment:
Both the router and the modem need to support this document,
DLEP Traffic Classification, and DLEP Credit Flow Control,
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>.
Second comment:
This document requests the assignment of several values by IANA. All
assignments are to registries defined by <xref target="RFC8175"
format="default"/>. -->
<!--t> Both the router and the modem need to support this document, <!--t> Both the router and the modem need to support this document,
DLEP Traffic Classification, and DLEP Credit Flow Control, DLEP Traffic Classification, and DLEP Credit Flow Control,
<xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>. <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>.
</t--> </t-->
</section> </section>
<section anchor="sec-sec" numbered="true" toc="default"> <section anchor="sec-sec" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
This document introduces finer grained flow identification mechanisms This document introduces finer-grained flow identification mechanisms
to DLEP. These mechanisms expose vulnerabilities similar to existing for DLEP. These mechanisms expose vulnerabilities similar to existing
DLEP messages. DLEP messages.
An example of a threat to which traffic classification might be susceptible is An example of a threat to which traffic classification might be susceptible is
a malicious actor masquerading as a DLEP peer could inject an alternate where a malicious actor masquerading as a DLEP peer could inject an alternat
Traffic Classification Data Item, changing the mapping of traffic to queues e
that Traffic Classification Data Item, changing the mapping of traffic to queues;
in turn causes delay, congestion this would
or loss to one or more service classes. in turn cause delay, congestion,
Other possible threats are given in the Security Considerations of or loss in one or more service classes.
<xref target="RFC8175" format="default"/> and are also applicable to, Other possible threats are discussed in the Security Considerations section
but not specific to, traffic classification. of
<xref target="RFC8175" format="default"/> and are also applicable,
but not specific, to traffic classification.
</t> </t>
<t> <t>
The transport layer security mechanisms documented in The transport-layer security mechanisms documented in
<xref target="RFC8175" format="default"/>, with some updated <xref target="RFC8175" format="default"/>, with some updated
references to external documents listed below, can be applied to references to external documents listed below, can be applied to
this document. this document.
Implementations following the "networked deployment" model described Implementations following the "networked deployment" model described
in the "Implementation Scenarios" of in Section&nbsp;<xref target="RFC8175" section="4" sectionFormat="bare">"Imp
<xref target="RFC8175" format="default"/> SHOULD refer to lementation Scenarios"</xref> of <xref target="RFC8175"/> <bcp14>SHOULD</bcp14>
refer to
<xref target="BCP195" format="default"/> for additional details. <xref target="BCP195" format="default"/> for additional details.
The Layer 2 security mechanisms documented in The Layer 2 security mechanisms documented in
<xref target="RFC8175" format="default"/> can also, with some updates, <xref target="RFC8175" format="default"/> can also, with some updates,
be applied to the mechanism defined in this document. be applied to the mechanisms defined in this document.
Examples of technologies that can be deployed to secure the Layer 2 Examples of technologies that can be deployed to secure the Layer 2
link include <xref target="IEEE-802.1AE"/> and <xref target="IEEE-8802-1X"/> . link include <xref target="IEEE-802.1AE"/> and <xref target="IEEE-8802-1X"/> .
<!-- [rfced] Section 4: We had trouble following "some updated
references to external documents listed below" in this paragraph.
It appears that "external documents" is intended to refer to
[BCP195], [IEEE-802.1AE], and [IEEE-8802-1X].
However, we see that [RFC8175] cites [IEEE-802.1X] ("IEEE Standards
for Local and metropolitan area networks-Port-Based Network Access
Control"), but this document cites [IEEE-8802-1X] ("IEEE/ISO/IEC
International Standard-Telecommunications and exchange between
information technology systems-Requirements for local and
metropolitan area networks-Part 1X:Port-based network access
control").
May we update as suggested? If not, please clarify the text.
Original:
The transport layer security mechanisms documented in [RFC8175], with
some updated references to external documents listed below, can be
applied to this document.
Suggested:
The transport layer security mechanisms documented in [RFC8175],
along with the latest versions of [BCP195], [IEEE-802.1AE], and
[IEEE-8802-1X] at the time of this writing, can be applied to this
document. -->
</t> </t>
</section> </section>
<section anchor="sec-iana" numbered="true" toc="default"> <section anchor="sec-iana" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<!--t> <!--t>
<This document requests the assignment of several values by IANA. All <This document requests the assignment of several values by IANA. All
assignments are to registries defined by <xref target="RFC8175" format="de fault"/>. assignments are to registries defined by <xref target="RFC8175" format="de fault"/>.
</t--> </t-->
<section anchor="sec-iana-di" numbered="true" toc="default">
<name>Data Item Values</name> <!-- [rfced] Below are some specific questions relating to IANA text in
Section 5.2 of the document.
a) FYI - To improve clarity, we added a new table (current Table 2) to show
the registration policies and adjusted the original table (current Table 3) to
show only the initial contents of the registry.
b) In the current Table 3, which shows the initial values of the new registry,
[RFC2474] and [IEEE8021Q] are listed as references. Should this document be
listed as a reference instead of or in addition to [RFC2474] and [IEEE8021Q]?
It seems that this document defines the Diffserv Traffic Classification in
Section 2.2 and the Ethernet Traffic Classification in Section 2.3. Please
review and let us know if any updates are needed. If needed, we will ask IANA
to update the "Traffic Classification Sub-Data Item Type Values" registry
prior to publication.
Link to registry:
https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-c
lassification-sub-data-item-type-values>
c) Related to the question above, the first two sentences below do not
directly indicate that this document defines the two new Sub-Data Items in
Sections 2.2 and 2.3, but the third sentence does. Should any of these
sentences be updated?
Original:
This document also introduces DLEP Sub-Data Items, and Sub-Data Items are
defined to support DiffServ and Ethernet traffic classification.
...
This document defines support for traffic classification using a
single new Data Item in Section 2.1 for general support and two new
Sub-Data Items are defined to support identification of flows based
on DSCPs and PCPs.
...
This document defines traffic classification based on a DLEP
destination and flows identified by either DiffServ [RFC2475]
Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q]
Ethernet Priority Code Points (PCPs).
Perhaps (updates to first two sentences to indicate that this document defines
the two Sub-Data Items; not changes to third sentence):
This document also introduces DLEP Sub-Data Items and defines two new
Sub-Data Items to support Diffserv and Ethernet traffic classification.
...
This document defines support for traffic classification using a
single new Data Item (see Section 2.1) for general support and defines two new
Sub-Data Items to support identification of flows based
on DSCPs and PCPs (see Sections 2.2 and 2.3).
...
This document defines traffic classification based on a DLEP
destination and flows identified by either Diffserv [RFC2475]
Differentiated Services Codepoints (DSCPs) or IEEE 802.1Q [IEEE8021Q]
Ethernet Priority Code Points (PCPs).
d) May we combine the first paragraph after the current Table 3 and the last
paragraph of Section 5.2 as follows? Also, would it be helpful to separate the
text after the current Table 3 into a new section so future documents can
easily refer to the guidance? Last, we suggest including "Specification Required
"
in this text as the guidance only applies to registrations with that policy.
Original:
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
Traffic Classification Sub-Data Item Type Values registry for the
DLEP protocol, in accordance with BCP 26 and [RFC8126].
...
To simplify future registrations, it is recommended that this
guidance serves as a standard reference for all DLEP-related
registries. Future specifications may include a header note pointing
to this guidance document.
Perhaps:
5.3. Registration Guidance
This section provides guidance for registrations in the "Traffic
Classification Sub-Data Item Type Values" registry. To simplify future
registrations in DLEP-related registries, it is recommended that the
guidance in this section apply to all registries within the "Dynamic Link
Exchange Protocol (DLEP) Parameters" registry group that use the
"Specification Required" policy [RFC8126]. Future specifications
may point to the guidance in this document.
e) Please clarify "two specific registries" here. Is the intent "two specific
entries" (i.e., 1 for Diffserv Traffic Classification and 2 for Ethernet
Traffic Classification)?
Original (the previous sentence included for context):
This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific
registries for widely recognized identifiers used in QoS management
for IP and Ethernet networks.
Perhaps:
This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames indicate
Quality of Service (QoS) treatment. It includes two specific
entries for widely recognized identifiers used in QoS management
for IP and Ethernet networks.
-->
<section anchor="sec-iana-di" numbered="true" toc="default">
<name>Data Item Type Values</name>
<t> <t>
This document requests the following new assignments to the DLEP Data Item IANA has assigned the following value from the "Specification
Registry named "Data Item Type Values" from the range with the "Specificat Required" range <xref target="RFC8126" format="default"></xref> in the DLE
ion P
Required" policy. The requested value is as follows: "Data Item Type Values" registry:
</t> </t>
<t keepWithNext="true"/>
<table anchor="table_di" align="center"> <table anchor="table_di" align="center">
<name>Requested Data Item Values</name> <name>New Data Item Type Value</name>
<thead> <thead>
<tr> <tr>
<th align="left">Type Code</th> <th align="left">Type Code</th>
<th align="left">Description</th> <th align="left">Description</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBA1</td> <td align="left">29</td>
<td align="left">Traffic Classification</td> <td align="left">Traffic Classification</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t keepWithPrevious="true"/>
</section> </section>
<section anchor="sec-iana-sdi" numbered="true" toc="default"> <section anchor="sec-iana-sdi" numbered="true" toc="default">
<name>DLEP Traffic Classification Sub-Data Item Registry</name> <name>Traffic Classification Sub-Data Item Type Values</name>
<t>
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Traffic Classification Sub-Data Item Type Values".
</t>
<t> <t>
The following table provides initial registry values and the IANA has created a new
<xref target="RFC8126" format="default"/> defined policies that should app DLEP registry named "Traffic Classification Sub-Data Item Type Values".
ly to the registry: </t>
<t>
<xref target="table_tc_reg-proc" format="default"></xref> shows the registration
policies <xref target="RFC8126" format="default"></xref> for the registry:
</t> </t>
<t keepWithNext="true"/>
<table anchor="table_tc_reg-proc">
<name>Registration Policies</name>
<thead>
<tr>
<th align="left">Range</th>
<th align="left">Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1-65407</td>
<td align="left">Specification Required</td>
</tr>
<tr>
<td align="left">65408-65534</td>
<td align="left">Private Use</td>
</tr>
</tbody>
</table>
<t><xref target="table_tc_sdi" format="default"></xref> shows the initial conten
ts of the registry:</t>
<table anchor="table_tc_sdi" align="center"> <table anchor="table_tc_sdi" align="center">
<name>Initial Registry Values</name> <name>Initial Registry Contents</name>
<thead> <thead>
<tr> <tr>
<th align="left">Type Code</th> <th align="left">Type Code</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left"></td> <td align="left">RFC 9892</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">DiffServ Traffic Classification</td> <td align="left">Diffserv Traffic Classification</td>
<td align="left"><xref target="RFC2474"/></td> <td align="left"><xref target="RFC2474"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">Ethernet Traffic Classification</td> <td align="left">Ethernet Traffic Classification</td>
<td align="left"><xref target="IEEE8021Q"/></td> <td align="left"><xref target="IEEE8021Q"/></td>
</tr> </tr>
<tr> <tr>
<td align="left">3-65407</td> <td align="left">3-65407</td>
<td align="left">Specification Required</td> <td align="left">Unassigned</td>
<td align="left"></td> <td align="left"></td>
</tr> </tr>
<tr> <tr>
<td align="left">65408-65534</td> <td align="left">65408-65534</td>
<td align="left">Private Use</td> <td align="left">Reserved for Private Use</td>
<td align="left"></td> <td align="left">RFC 9892</td>
</tr> </tr>
<tr> <tr>
<td align="left">65535</td> <td align="left">65535</td>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="left"></td> <td align="left">RFC 9892</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t keepWithPrevious="true"/>
<t> <t>
This section provides guidance to the Internet Assigned Numbers This section provides guidance for registrations in the "Traffic
Authority (IANA) regarding registration of values related to the Classification Sub-Data Item Type Values" registry.
Traffic Classification Sub-Data Item Type Values registry for
the DLEP protocol, in accordance with BCP 26 and [RFC8126].
</t> </t>
<t> <t>
This registry encompasses packet traffic classification, where This registry encompasses packet traffic classification, where
standard packet header identifiers in packets or data frames standard packet header identifiers in packets or data frames
indicate Quality of Service (QoS) treatment. It includes two indicate Quality of Service (QoS) treatment. It includes two
specific registries for widely recognized identifiers used in specific registries for widely recognized identifiers used in
QoS management for IP and Ethernet networks. Reserved values are QoS management for IP and Ethernet networks. Reserved values are
set aside for similar future identifiers that may emerge to set aside for similar future identifiers that may emerge to
denote QoS treatment. However, requests for new entries are not denote QoS treatment. However, requests for new entries are not
expected to be frequent. expected to be frequent.
</t> </t>
<t> <t>
Allocations within the registry are subject to the following Allocations within the registry are subject to the following requirements:
requirements:
</t> </t>
<ol> <ol>
<li> <li>
Documentation of the intended use of the requested value, in Documentation of the intended use of the requested value, in
compliance with the "Specification Required" policy defined in compliance with the "Specification Required" policy defined in
<xref target="RFC8126" format="default"/>. <xref target="RFC8126" format="default"></xref>.
</li> </li>
<li> <li>
<t> Approval by the Designated Expert (DE) appointed by the IESG. <t> Approval by the designated expert (DE) appointed by the IESG.
The DE must: </t> The DE must do the following: </t>
<ul spacing="compact"> <ul spacing="normal">
<li> <li>
Verify that the requested value is clearly documented and its Verify that the requested value is clearly documented and its
purpose and usage are unambiguous. purpose and usage are unambiguous.
</li> </li>
<li> <li>
Ensure the proposed value does not conflict with existing work Ensure that the proposed value does not conflict with existing work
or ongoing efforts within the IETF. or ongoing efforts within the IETF.
</li> </li>
<li> <li>
Confirm that any specification requesting a code point has Confirm that any specification requesting a code point has
undergone review by the MANET working group (or a successor mailing undergone review by the MANET Working Group (or a successor mailing
list designated by the IESG). list designated by the IESG).
</li> </li>
<li> <li>
Validate that external specifications requesting code points are Validate that external specifications requesting code points are
publicly available, permanently archived, and do not conflict publicly available, are permanently archived, and do not conflict
with active or published IETF work. with active or published IETF work.
</li> </li>
<li> <li>
Ensure the review process is conducted in a timely manner, with Ensure that the review process is conducted in a timely manner, with
any disputes resolved through consultation with the appropriate any disputes resolved through consultation with the appropriate
working groups. working groups.
</li> </li>
</ul> </ul>
</li> </li>
</ol> </ol>
<t> <t>
To simplify future registrations, it is recommended that this To simplify future registrations in DLEP-related registries, it is recommende
guidance serves as a standard reference for all DLEP-related d that this guidance
registries. Future specifications may include a header note pointing to apply to all registries within the "Dynamic Link Exchange Protocol (DLEP)
this Parameters" registry group. Future specifications may
guidance document. point to the guidance in this document.
</t> </t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 175.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 175.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
ietf-manet-dlep-credit-flow-control.xml"/> <!-- draft-ietf-manet-dlep-credit-flow-control (RFC 9893) -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. <reference anchor="RFC9893" target="https://www.rfc-editor.org/info/rfc9
ietf-manet-dlep-da-credit-extension.xml"/> 893">
<front>
<title>Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Contr
ol Messages and Data Items</title>
<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
<organization>MIT Lincoln Laboratory</organization>
</author>
<author initials="D." surname="Wiggins" fullname="David Wiggins">
</author>
<author initials="S." surname="Ratliff" fullname="Stan Ratliff">
</author>
<author initials="L." surname="Berger" fullname="Lou Berger">
<organization>LabN Consulting, L.L.C.</organization>
</author>
<author initials="E." surname="Kinzie" fullname="Eric Kinzie" role="
editor">
<organization>LabN Consulting, L.L.C.</organization>
</author>
<date month="November" year="2025" />
</front>
<seriesInfo name="RFC" value="9893"/>
<seriesInfo name="DOI" value="10.17487/RFC9893"/>
</reference>
<!-- draft-ietf-manet-dlep-da-credit-extension (RFC 9894) -->
<reference anchor="RFC9894" target="https://www.rfc-editor.org/info/rfc9894">
<front>
<title>Dynamic Link Exchange Protocol (DLEP) Diffserv Aware Credit Window
Extension</title>
<author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
<organization>MIT Lincoln Laboratory</organization>
</author>
<author initials="D." surname="Wiggins" fullname="David Wiggins">
</author>
<author initials="L." surname="Berger" fullname="Lou Berger">
<organization>LabN Consulting, L.L.C.</organization>
</author>
<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake
3rd" role="editor">
<organization>Independent</organization>
</author>
<date month="November" year="2025" />
</front>
<seriesInfo name="RFC" value="9894"/>
<seriesInfo name="DOI" value="10.17487/RFC9894"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 474.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 474.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 475.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 475.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 651.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 651.xml"/>
<reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document
/8403927" quoteTitle="true" derivedAnchor="IEEE8021Q"> <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document
/10004498" quoteTitle="true" derivedAnchor="IEEE8021Q">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title> <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title>
<author> <author>
<organization showOnFrontPage="true">IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date month="July" year="2022"/> <date month="December" year="2022"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2022.10004498"/> <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.10004498"/>
<seriesInfo name="IEEE" value="802.1Q-2022"/> <seriesInfo name="IEEE Std" value="802.1Q-2022"/>
</reference> </reference>
<referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/
bcp195"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.01
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC 95.xml"/>
.9325.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
.8996.xml"/>
</referencegroup>
<reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/doc ument/8585421"> <reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/doc ument/8585421">
<front> <front>
<title>802.1AE-2018 - IEEE Standard for Local and metropolitan are <title>IEEE Standard for Local and metropolitan area networks-Media
a networks-Media Access Control (MAC) Security</title> Access Control (MAC) Security</title>
<author/> <author>
<organization>IEEE</organization>
</author>
<date month="December" year="2018"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
<seriesInfo name="IEEE Std" value="802.1AE-2018"/>
</reference> </reference>
<reference anchor="IEEE-8802-1X" target="https://ieeexplore.ieee.org/doc ument/9650828"> <reference anchor="IEEE-8802-1X" target="https://ieeexplore.ieee.org/doc ument/9650828">
<front> <front>
<title>8802-1X-2021 - IEEE/ISO/IEC International Standard-Telecomm <title>IEEE/ISO/IEC International Standard-Telecommunications and
unications and exchange between information technology systems--Requirements for exchange between information technology systems--Requirements for local and metr
local and metropolitan area networks--Part 1X:Port-based network access control opolitan area networks--Part 1X:Port-based network access control</title>
</title> <author>
<author/> <organization>IEEE</organization>
</author>
<date month="December" year="2021"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9650828"/>
<seriesInfo name="IEEE Std" value="8802-1X-2021"/>
</reference> </reference>
</references> </references>
</references> </references>
<section numbered="true" toc="default"> <section numbered="false" toc="default">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> <t>The Sub-Data Item format was inspired by <contact
The Sub-Data Item format was inspired by Rick Taylor's "Data Item fullname="Rick Taylor"/>'s "Data Item Containers". He also
Containers". He also proposed the separation of credit windows proposed the separation of credit windows from traffic
from traffic classification at IETF98. Many useful comments were classification at IETF 98. This document was
received from contributors to the MANET working group. This derived from <xref
document was derived from <xref target="I-D.ietf-manet-dlep-da-credit-exten target="RFC9894"
sion" format="default"/> as a result of format="default"/> as a result of discussions at IETF 101. Many
discussions at IETF 101. Many useful comments were useful comments were received from contributors to the MANET
received from contributors to the MANET working group, notably Working Group, notably <contact fullname="Ronald in 't Velt"/> and
Ronald in't Velt and David Black. <contact fullname="David Black"/>.</t>
</t> <t>We had the honor of working too briefly with <contact
<t> fullname="David Wiggins"/> on this and related DLEP work. His
We had the honor of working too briefly with David Wiggins on contribution to the IETF and publication of the first and
this and related DLEP work. His contribution to the IETF and definitive open-source DLEP implementation have been critical to
publication of the first and definitive open source DLEP the acceptance of DLEP. We mourn his passing on November 26, 2023.
implementation have been critical to the acceptance of DLEP. We We wish to recognize his guidance, leadership, and professional
mourn his passing on November 23, 2023. We wish to recognize his excellence. We were fortunate to benefit from his leadership and
guidance, leadership and professional excellence. We were friendship. He shall be missed.</t>
fortunate to benefit from his leadership and friendship. He
shall be missed.
</t>
</section> </section>
<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
Note that our script did not flag any words in particular, but this
should still be reviewed as a best practice. -->
<!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following term was used inconsistently in this document.
We chose to use the latter form. Please let us know any objections.
data item (1 instance) / Data Item (e.g., "the data item",
"the Data Item") (per the rest of this document and per this
group (cluster) of documents)
b) The following terms appear to be used inconsistently in this
document. Please let us know which form is preferred.
priority field / Priority field / Priority Field
(e.g., "priority fields", "Priority fields",
"Each Priority Field is", "each Priority field is")
Item Types / Item types (e.g., "Traffic Classification Sub-Data Item
Types", "Traffic Classification Sub-Data Item types")
Num PCPs (1 instance) / NumPCPs (4 instances)
(We also see "Num DSCPs" and "Num SDIs".)
the individual Sub-Data Item / the individual Sub-Data Items -->
</back> </back>
</rfc> </rfc>
<!-- Local Variables: -->
<!-- fill-column:72 -->
<!-- End: -->
 End of changes. 139 change blocks. 
276 lines changed or deleted 716 lines changed or added

This html diff was produced by rfcdiff 1.48.