<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" docName="draft-ietf-manet-dlep-traffic-classification-17" number="9892" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.19.4 -->

  <front>
    <title abbrev="DLEP Traffic Classification">
  Dynamic Classification">Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-manet-dlep-traffic-classification-17"/> name="RFC" value="9892"/>
    <author initials="B." surname="Cheng" fullname="Bow-Nan Cheng">
      <organization>MIT Lincoln Laboratory</organization>
      <address>
        <postal>
          <street>Massachusetts Institute of Technology</street>
          <street>244 Wood Street</street>
          <city>Lexington</city>
          <region>MA</region>
          <code>02421-6426</code>
          <country>United States of America</country>
        </postal>
        <email>bcheng@ll.mit.edu</email>
      </address>
    </author>
    <author initials="D." surname="Wiggins" fullname="David Wiggins">
      <address>
        <email>david@none.org</email>
      </address>
    </author>
    <author initials="L." surname="Berger" fullname="Lou Berger">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
	<email>lberger@labn.net</email>
      </address>
    </author>
    <author role="editor" initials="D." surname="Fedyk" fullname="Don Fedyk">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
        <email>dfedyk@labn.net</email>
      </address>
    </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>
      <t>
      This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP)
      to support traffic classification.  Traffic classification
      information identifies traffic flows based on
      frame/packet content such as a destination address.  The Data Item
      is defined in an extensible and reusable fashion. Its use will be
      mandated in other documents defining specific DLEP extensions.
      This document also introduces DLEP Sub-Data Items, and Items; Sub-Data
      Items are defined to support DiffServ Diffserv and Ethernet traffic
      classification.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
      The Dynamic Link Exchange Protocol (DLEP) is defined in <xref target="RFC8175" format="default"/>.  This protocol provides the exchange of link related link-related
      control information between DLEP peers.  DLEP peers are comprised
      of a modem and a router.  DLEP defines a base set of mechanisms as
      well as support for possible extensions.  DLEP defines Data Items Items,
      which are sets of information that can be reused in DLEP
      messaging.  The DLEP specification does not include any flow
      identification beyond DLEP endpoints, i.e., flows are identified
      based on their DLEP endpoint.
      </t>
      <t>This document defines DLEP
      Data Item formats which that provide flow identification on a more
      granular basis.  Specifically, it enables a router
      to use traffic flow classification information provided by the
      modem to identify traffic flows based on a combination of
      information found in a data plane header.
      (For general background on traffic classification classification, see
      <xref target="RFC2475" format="default"/> Section 2.3.) sectionFormat="of" section="2.3"/>.)
      The Data Item is structured to
      allow for the use of the defined traffic classification information
      with applications such as credit window control as specified in
      <xref target="I-D.ietf-manet-dlep-credit-flow-control" target="RFC9893" format="default"/>.
      The credit window control document <xref target="RFC9893" format="default"/> provides an
      example of combining traffic classification
      and credit window flow control.
       </t>
       <t>
      This document defines traffic classification based on a DLEP
      destination and flows identified by either DiffServ
      <xref target="RFC2475" format="default"/> Differentiated Services Codepoints Code Points (DSCPs) <xref target="RFC2475" format="default"/>
      or IEEE
      802.1Q <xref target="IEEE8021Q" format="default"/> Ethernet
       Priority Code Points (PCPs). (PCPs) <xref target="IEEE8021Q" format="default"/>.
      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.
      The extension also supports the "wildcard" matching of any flow (DSCP
      or PCP).  Traffic classification information is provided such that it
      can be readily extended to support other traffic classification
      techniques,
      techniques or can be used by non-credit window extensions that are not related extensions, to credit windows, such
      as the extension defined in <xref target="RFC8651" format="default"/> or even
      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>
      This document defines support for traffic classification using a
      single new Data Item in (see <xref target="sec-di-tc" format="default"/> format="default"/>) for general
      support and two
      support. Two new Sub-Data Items are defined to support
      identification of flows based on DSCPs and PCPs.
      </t>
      <section anchor="sec-1.1" numbered="true" toc="default">
        <name>Key Words</name>
        <t>
        The
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
        "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
        "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in
        BCP 14 BCP&nbsp;14
        <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.
        </t> here.</t>
      </section>
    </section>
    <section anchor="sec-tc" numbered="true" toc="default">
      <name>Traffic Classification</name>
      <t>
    The Traffic Classification Data Item represents a list of
    flows that may be used at the same time to provide
    different service classes
    for traffic sent from a
    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
    Sub-Data Item structure is structures are intended to be independent of any
    specific usage of the flow identification, e.g., flow control.  The
    Sub-Data Item structure is also intended to allow for future traffic
    classification types, e.g., 5-tuple flows.  While the structure of
    the Data Items is extensible, actual flow information is expected to
    be used in an extension dependent extension-dependent manner. Support for DSCP and
    PCP-based flows are is defined via individual Sub-Data Items Items; see
    below. Other types of flow identification, e.g., based on IP
    protocol and ports, may be defined in the future via new Sub-Data
    Items.  Note that when extensions supporting multiple Sub-Data Item
    types are negotiated, these types MAY <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>
    Each list of flows is identified
    using a "Traffic Classification Identifier" or "TID" and is expected
    to represent a valid combination of data plane identifiers that may
    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 that
    carries the data plane identifier or identifiers used to associate
    traffic with the flow.  A DLEP destination address is also needed to
    complete traffic classification information used in extensions such
    as flow control.  This information is expected to be provided in an
    extension specific
    extension-specific manner.  For example, this address can be provided
    by a modem when it identifies the traffic classification set in a
    Destination Up Message using the Credit Window Associate Association Data Item
    defined in <xref target="I-D.ietf-manet-dlep-credit-flow-control" target="RFC9893" format="default"/>.
    TID and FID values have modem-local scope.
      </t>
      <section anchor="sec-di-tc" numbered="true" toc="default">
        <name>Traffic Classification Data Item</name>
        <t>
      This section defines the Traffic Classification Data Item.  This
      Data Item is used by a modem to provide a router with traffic
      classification information.  When an extension requires the use of
      any Data Item, the Data Items, including this Traffic Classification Data Item SHOULD Item, <bcp14>SHOULD</bcp14> be
      included by a modem in any Session Initialization Response Message, e.g., Message (e.g., see
      <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>. target="RFC9893" format="default"/>).
                Updates to
      previously provided traffic classifications or new traffic
      classifications MAY <bcp14>MAY</bcp14> be sent by a modem by including the Data Item
      in Session Update Messages.  More than one Data Item MAY <bcp14>MAY</bcp14> be
      included in a message to provide information on multiple traffic
      classifiers.
        </t>
        <t>
      The set of traffic classification information provided in the data
      item Data
      Item is identified using a Traffic Classification Identifier, or
      TID.  The actual data plane related information related to data planes that is used in traffic
      classification is provided in a variable list of Traffic
      Classification Sub-Data Items.
        </t>
        <t>
      The format of the Traffic Classification Data Item is: is as follows:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Data Item Type                | Length                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Traffic Class. Identifier (TID)|   Num SDIs    |   Reserved    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~           Traffic Classification Sub-Data Item 1              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                              ...                              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~           Traffic Classification Sub-Data Item n              ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>

        <dl newline="true" spacing="normal">
          <dt>Data Item Type:</dt>
          <dd>TBA1</dd>
          <dd>29</dd>
          <dt>Length:</dt>
          <dd>
            <t>Variable
            </t>
            <t>
        Per <xref target="RFC8175" format="default"/> format="default"/>, Length
        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
        supported.  For example example, if the Packet packet is limited to 1400 bytes bytes, then the
        length MUST NOT <bcp14>MUST NOT</bcp14> exceed this value. If larger packets are supported supported,
        the maximum MUST <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 fits will fit in a single 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>
          </dd>
          <dt> Traffic Classification Identifier (TID):</dt>
          <dd>
          A 16-bit unsigned integer identifying a traffic classification
          set.  There is no restriction on values used by a modem, and there
          is no requirement for sequential or ordered values.
        </dd>
          <dt>Num SDIs:</dt>
          <dd>
          An 8-bit unsigned integer indicating the number of Traffic
          Classification Sub-Data Items included in the Data Item.  A value
          of zero (0) is allowed and indicates that no traffic should be
          matched against this TID.
        </dd>
          <dt>Reserved:</dt>
          <dd>
           For the Traffic Classification Data Item Item, this reserved field is currently unused.
		       It MUST <bcp14>MUST</bcp14> be set to all zeros for this version of the Data Item and it is currently ignored on reception.
		       This allows for future extensions of the Data Item if needed.
          </dd>
          <dt>Traffic Classification Sub-Data Item:</dt>
          <dd>
          Zero or more Traffic Classification Sub-Data Items of the format
          defined below MAY in <xref target="sec-di-tc-sub"/> <bcp14>MAY</bcp14> be included.  The number MUST <bcp14>MUST</bcp14> match the value
          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>
        </dl>
        <t>
      A router receiving the Traffic Classification Data Item MUST <bcp14>MUST</bcp14>
      locate the traffic classification information that is associated
      with the TID indicated in each received Data Item.  If no
      associated traffic classification information is found, the router
      MUST
      <bcp14>MUST</bcp14> initialize a new information set using the values carried in
      the Data Item.  If the associated traffic classification information
      is found, the router MUST <bcp14>MUST</bcp14> replace the corresponding information using the values
      carried in the Data Item.  In both cases, a router MUST <bcp14>MUST</bcp14> also
      ensure that any data plane state, e.g., state (e.g., see <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>, target="RFC9893" format="default"/>) that is
      associated with the TID is updated as needed.

        </t>
        <section anchor="sec-di-tc-sub" numbered="true" toc="default">
          <name>Traffic Classification Sub-Data Item</name>
          <t>
        All Traffic Classification Sub-Data Items share a common format
        that is patterned after the standard DLEP Data Item format, see format.  See
        <xref target="RFC8175" format="default"/> Section 11.3. sectionFormat="of" section="11.3"/>.  There is no requirement
        on, or meaning to to, Sub-Data Item ordering.
        Any errors or inconsistencies encountered in parsing Sub-Data Items
        are handled in the same fashion as any other Data Item parsing error
        encountered in DLEP, see DLEP. See <xref target="RFC8175" format="default"/>.
          </t>
          <t>
        The format of the Traffic Classification Sub-Data Item is: is as follows:
          </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-Data Item Type            | Length                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                           Value...                            ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Sub-Data Item Type:</dt>
            <dd>
            A 16-bit unsigned integer that indicates the type and
            corresponding format of the Sub-Data Item's Value field.
            Sub-Data Item Types are scoped within the Data Item in which
            they are carried, i.e., the Sub-Data Item Type field MUST <bcp14>MUST</bcp14> be
            used together with the Traffic Classification Data Item Type to identify the format
            of the Sub-Data Item.  Traffic Classification Sub-Data
            Item Types are managed according to the
            IANA registry described
            in <xref target="sec-iana-sdi" format="default"/>.
          </dd>
            <dt>Length:</dt>
            <dd>
              <t>Variable
              </t>
              <t>
          Copying
          Per <xref target="RFC8175" format="default"/>, Length is a 16-bit unsigned
          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
          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>
            </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>
        </section>
      </section>
      <section anchor="sec-di-tc-ds-sub" numbered="true" toc="default">
        <name>DiffServ
        <name>Diffserv Traffic Classification Sub-Data Item</name>
        <t>
      The DiffServ Diffserv Traffic Classification Sub-Data Item identifies
      the set of DSCPs that should be treated as a
      single flow, i.e., receive the same traffic treatment.  DSCPs are
      identified in a list of DiffServ Diffserv fields.  An implementation that
      does not support DSCPs and wants the same traffic treatment for
      all traffic to a destination or destinations would indicate
      0 DSCPs.
        </t>
        <t>
      The format of the DiffServ Diffserv Traffic Classification Sub-Data Item
      is:
      is as follows:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-Data Item Type (1)        |  Length                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Flow Identifier (FID)         |   Num DSCPs   |   DS Field 1  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   DS Field 2  |      ...      |   DS Field n  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <dl newline="true" spacing="normal">
          <dt>Sub-Data Item Type:</dt>
          <dd>
            <t>
             Sub-Data Item Type with value one (1) identifies the DiffServ Diffserv
             Traffic Classification Sub-Data Item Type in the format
             defined in <xref target="sec-di-tc-sub"/>.
            </t>
          </dd>
          <dt>Length:</dt>
          <dd>
            <t>Variable
            </t>
            <t>
             Length is defined above.  For this Sub-Data Item, it is
                    equal to three (3) octets plus the value of the Num DSCPs field.
                    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.
                    The definition can be in multiple Sub-Data Items that are much 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>
          </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>
          <dd>
          A 16-bit unsigned integer representing the data plane
          information carried in the Sub-Data Item that is to be used in
          identifying a flow.  The value of 0xFFFF is reserved and MUST
          NOT <bcp14>MUST
          NOT</bcp14> be used in this field.
        </dd>
        <dt>Num DSCPs:</dt>
          <dd>
          An 8-bit unsigned integer indicating the number of DSCPs
          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
          use of this is mapping any DSCPs that are not explicitly mapped to a default queue.
        </dd>
          <dt>DS Field:</dt>
          <dd>
            <t>
          Each DS Field is an 8-bit that 8 bits long and carries the DSCP field as defined
          in <xref target="RFC2474" format="default"/>.

<!-- [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[
            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          |         DSCP          |  MBZ  |
          +---+---+---+---+---+---+---+---+

          DSCP: Differentiated
]]></artwork>
	    <dl spacing="compact" newline="false">
	      <dt>DSCP:</dt><dd>Differentiated Services Codepoint (RFC 2474).
                MBZ:  Must Code Point <xref target="RFC2474"/></dd>
              <dt>MBZ:</dt><dd>Must Be Zero - set to zero when transmitted.
          ]]></artwork> transmitted</dd>
	    </dl>
          </dd>
        </dl>
        <section anchor="sec-di-tc-rrp" numbered="true" toc="default">
          <name>Router Receive Processing</name>
          <t>
        A router receiving the Traffic Classification Sub-Data
        Item MUST <bcp14>MUST</bcp14> validate the information on receipt, prior to using
        the carried information, including potentially updating the data
        behavior as determined by the extension requiring the use of the
        Sub-Data Item.  Validation failures MUST <bcp14>MUST</bcp14> be treated as an error as
        described above in <xref target="sec-di-tc-sub" format="default"/>.
          </t>
          <t>
        Once validated, the receiver MUST <bcp14>MUST</bcp14> ensure that each DS Field
        value is listed only once across the whole Traffic
        Classification Data Item.  Note,  Note that this check is across the Data
        Item and not the individual Sub-Data Item.  If the same DS Field
        value is listed more than once within the same Traffic
        Classification Data Item, the Data Item MUST <bcp14>MUST</bcp14> be treated as an
        error as described above in
        <xref target="sec-di-tc-sub" format="default"/>.
          </t>
        </section>
      </section>
      <section anchor="sec-di-tc-e-sub" numbered="true" toc="default">
        <name>Ethernet Traffic Classification Sub-Data Item</name>
        <t>
      The Ethernet Traffic Classification Sub-Data Item
      identifies the VLAN and PCPs that should be treated as a single
      flow, i.e., receive the same traffic treatment.  Ethernet Priority
                Code Point PCP
                support is defined as part of the IEEE 802.1Q
                tag format <xref target="IEEE8021Q" format="default"/> tag format and includes a 3 bit 3-bit "PCP"
      field.  The tag format also includes a 12 bit VLAN identifier
      (VID) 12-bit "VLAN Identifier
      (VID)" field. PCPs are identified in a list of priority fields.  An
      implementation that does not support PCPs and wants the same
      traffic treatment for all traffic to a destination or destinations
      would indicate 0 PCPs.  Such an implementation could identify a
      VLAN to use per destination.
        </t>
        <t>
      The format of the Ethernet Traffic Classification
      Sub-Data Item is: is as follows:
        </t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Sub-Data Item Type (2)        | Length                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Flow Identifier (FID)         |NumPCPs| VLAN Identifier (VID) |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Pri. 1| Pri. 2| ..... | ..... | ..... |  Pad  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <dl newline="true" spacing="normal">
          <dt>Sub-Data Item Type:</dt>
          <dd>
            <t>
             Sub-Data Item Type with value two (2) identifies the Ethernet
             Traffic Classification Sub-Data Item Type in the format
             defined in <xref target="sec-di-tc-sub"/>.
            </t>
          </dd>
          <dt>Length:</dt>
          <dd>
            <t>Variable
            </t>
            <t>
          Length is defined above.  For this Sub-Data Item, it is equal
          to four (4) plus the number of octets needed to accommodate
          the number of Priority fields indicated by the NumPCPs
          field. Note that as the length is in octets and each Priority
          field is 4 bits, the additional length is the value carried in
          the NumPCPs field divided by 2 and rounded up to the next
          higher integer quantity.
          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>
          </dd>
          <dt>Flow Identifier (FID):</dt>
          <dd>
          A 16-bit unsigned integer representing the data plane
          information carried in the Sub-Data Item that is to be used in
          identifying a flow.  The value of 0xFFFF is reserved and MUST
          NOT <bcp14>MUST
          NOT</bcp14> be used in this field.
        </dd>
          <dt>Num PCPs:</dt>
          <dd>
          A 4-bit unsigned integer indicating the number of Priority
          fields carried in the Sub-Data Item.  A zero (0) indicates a
          (wildcard) 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 are not explicitly mapped to a default queue.
          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>
          <dt>VLAN identifier Identifier (VID):</dt>
          <dd>
          A 12-bit unsigned integer field indicating the VLAN to be
          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
          traffic classification. Any explicitly mapped VLANs are match first and
          then any matched first.
          Any VLANs that do not have a mapping will then map to this default mapping.
        </dd>
          <dt>Priority:</dt>
          <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>
          Each Priority Field is 4-bits 4 bits long and indicates a
          PCP field as defined in <xref target="IEEE8021Q" format="default"/>. Note
          that zero (0) is a valid value for either PCP.
            </t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
          0   1   2   3
        +---+---+---+---+
        |    PCP    |MBZ|
        +---+---+---+---+

        PCP: Priority
]]></artwork>
	    <dl spacing="compact" newline="false">
              <dt>PCP:</dt><dd>Priority Code Point (IEEE8021Q)
             MBZ:  Must <xref target="IEEE8021Q" format="default"/></dd>
              <dt>MBZ:</dt><dd>Must Be Zero - set to zero when transmitted.

            ]]></artwork> transmitted</dd>
	    </dl>
          </dd>
          <dt>Pad:</dt>
          <dd>
          A 4-bit long field that is 4 bits long and is included when NumPCPs is an odd number.
          This field MUST <bcp14>MUST</bcp14> be set to zero by the sender, sender and MUST <bcp14>MUST</bcp14> be ignored
          on receipt.
        </dd>
        </dl>
        <section anchor="sec-di-tc-q-rrp" numbered="true" toc="default">
          <name>Router Receive Processing</name>
          <t>
        A router receiving the Traffic Classification Sub-Data
        Item MUST <bcp14>MUST</bcp14> validate the information on receipt, prior to the using
        the carried information, including potentially updating the data
        behavior as determined by the extension requiring the use of the
                  Sub-Data Item.

        Note that validation can include usage specific usage-specific semantics such as those found in
        <xref target="I-D.ietf-manet-dlep-credit-flow-control" target="RFC9893" format="default"/>.
        Any failures MUST <bcp14>MUST</bcp14> be treated as an error as
        described above in <xref target="sec-di-tc-sub" format="default"/>.
          </t>
          <t>
        After successful validation, the receiver MUST <bcp14>MUST</bcp14> ensure that each Priority
        Field value is listed only once across the whole Traffic
        Classification Data Item.  Note,  Note that this check is across the Data
        Item and not the individual Sub-Data Items.  If the same Priority
        Field value is listed more than once within the same Traffic
        Classification Data Item, the Data Item MUST <bcp14>MUST</bcp14> be treated as an
        error as
        described above in <xref target="sec-di-tc-sub" format="default"/>.
          </t>
          <t>
        In cases where both Traffic Classification Sub-Data Item types are defined, matching on
        Ethernet information takes precedence. More specifically, when a packet
        matches both a DSCP indicated in a DiffServ Diffserv Traffic Classification Sub-Data
        Item (<xref target="sec-di-tc-ds-sub" format="default"/>) and a VID/PCP
        identified in an Ethernet Traffic Classification  Sub-Data Item (<xref
        target="sec-di-tc-e-sub" format="default"/>),  then the TID associated with the
        matching VLAN/PCP MUST <bcp14>MUST</bcp14> be used.

          </t>
        </section>
      </section>
    </section>
    <section anchor="sec-compat" numbered="true" toc="default">
      <name>Compatibility</name>
      <t>
    The formats defined in this document will only be used when
    extensions require their use.
      </t>
      <t>
    The DLEP specification <xref target="RFC8175" format="default"/> defines the handling of unexpected
    appearances of any Data Items, including those defined in this
    document.
      </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,
      DLEP Traffic Classification, and DLEP Credit Flow Control,
      <xref target="I-D.ietf-manet-dlep-credit-flow-control" format="default"/>.
      </t-->
    </section>
    <section anchor="sec-sec" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
    This document introduces finer grained finer-grained flow identification mechanisms
    to
    for DLEP. These mechanisms expose vulnerabilities similar to existing
    DLEP messages.
    An example of a threat to which traffic classification might be susceptible is
    where a malicious actor masquerading as a DLEP peer could inject an alternate
    Traffic Classification Data Item, changing the mapping of traffic to queues that queues; this would
    in turn causes cause delay, congestion congestion,
    or loss to in one or more service classes.
    Other possible threats are given discussed in the Security Considerations section of
    <xref target="RFC8175" format="default"/> and are also applicable to, applicable,
    but not specific to, specific, to traffic classification.
    </t>
    <t>
    The transport layer transport-layer security mechanisms documented in
    <xref target="RFC8175" format="default"/>, with some updated
    references to external documents listed below, can be applied to
    this document.
    Implementations following the "networked deployment" model described
    in the "Implementation Scenarios" Section&nbsp;<xref target="RFC8175" section="4" sectionFormat="bare">"Implementation Scenarios"</xref> of <xref target="RFC8175" format="default"/> SHOULD target="RFC8175"/> <bcp14>SHOULD</bcp14> refer to
    <xref target="BCP195" format="default"/> for additional details.
    The Layer 2 security mechanisms documented in
    <xref target="RFC8175" format="default"/> can also, with some updates,
    be applied to the mechanism mechanisms defined in this document.
    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"/>.

<!-- [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>
    </section>
    <section anchor="sec-iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <!--t>
       <This document requests the assignment of several values by IANA.  All
      assignments are to registries defined by <xref target="RFC8175" format="default"/>.
      </t-->
      <section anchor="sec-iana-di" numbered="true" toc="default">
        <name>Data

<!-- [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 Values</name>
        <t>
      This Type Values" registry
prior to publication.

Link to registry:
https://www.iana.org/assignments/dlep-parameters/dlep-parameters.xhtml#traffic-classification-sub-data-item-type-values>

c) Related to the question above, the first two sentences below do not
directly indicate that this document requests defines the following two new assignments 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
      Registry named "Data (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" from Values registry for the range
   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.  The requested 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>
      IANA has assigned the following value is as follows: from the "Specification
      Required" range <xref target="RFC8126" format="default"></xref> in the DLEP
      "Data Item Type Values" registry:
        </t>
        <t keepWithNext="true"/>

        <table anchor="table_di" align="center">
          <name>Requested
          <name>New Data Item Values</name> Type Value</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA1</td> align="left">29</td>
              <td align="left">Traffic Classification</td>
            </tr>
          </tbody>
        </table>
        <t keepWithPrevious="true"/>

      </section>
      <section anchor="sec-iana-sdi" numbered="true" toc="default">
              <name>DLEP Traffic
              <name>Traffic Classification Sub-Data Item Registry</name> Type Values</name>
        <t>
      Upon approval of this document,
      IANA is requested to create has created a new
      DLEP registry, registry named "Traffic Classification Sub-Data Item Type Values".
	</t>
	<t>
      The following table provides initial registry values and
<xref target="table_tc_reg-proc" format="default"></xref> shows the registration policies <xref target="RFC8126" format="default"/> defined policies that should apply to format="default"></xref> for the registry:
        </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 contents of the registry:</t>

        <table anchor="table_tc_sdi" align="center">
          <name>Initial Registry Values</name> Contents</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">Reserved</td>
              <td align="left"></td> align="left">RFC 9892</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">DiffServ align="left">Diffserv Traffic Classification</td>
              <td align="left"><xref target="RFC2474"/></td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">Ethernet Traffic Classification</td>
              <td align="left"><xref target="IEEE8021Q"/></td>
            </tr>
            <tr>
              <td align="left">3-65407</td>
              <td align="left">Specification Required</td> align="left">Unassigned</td>
              <td align="left"></td>
            </tr>
            <tr>
              <td align="left">65408-65534</td>
              <td align="left">Private align="left">Reserved for Private Use</td>
              <td align="left"></td> align="left">RFC 9892</td>
            </tr>
            <tr>
              <td align="left">65535</td>
              <td align="left">Reserved</td>
              <td align="left"></td> align="left">RFC 9892</td>
            </tr>
          </tbody>
        </table>
        <t keepWithPrevious="true"/>

	<t>
         This section provides guidance to the Internet Assigned Numbers
         Authority (IANA) regarding registration of values related to for registrations in the
         Traffic "Traffic
         Classification Sub-Data Item Type Values registry for
         the DLEP protocol, in accordance with BCP 26 and [RFC8126]. Values" registry.
        </t>

        <t>
         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. Reserved values are
         set aside for similar future identifiers that may emerge to
         denote QoS treatment. However, requests for new entries are not
         expected to be frequent.
	</t>

        <t>
   Allocations within the registry are subject to the following requirements:
        </t>
        <ol>
        <li>
         Documentation of the intended use of the requested value, in
         compliance with the "Specification Required" policy defined in
         <xref target="RFC8126" format="default"/>. format="default"></xref>.
        </li>
        <li>
        <t> Approval by the Designated Expert designated expert (DE) appointed by the IESG.
        The DE must: must do the following: </t>
        <ul spacing="compact"> spacing="normal">
        <li>
         Verify that the requested value is clearly documented and its
         purpose and usage are unambiguous.
        </li>
        <li>
         Ensure that the proposed value does not conflict with existing work
         or ongoing efforts within the IETF.
        </li>
        <li>
         Confirm that any specification requesting a code point has
        undergone review by the MANET working group Working Group (or a successor mailing
        list designated by the IESG).
        </li>
        <li>
         Validate that external specifications requesting code points are
         publicly available, are permanently archived, and do not conflict
         with active or published IETF work.
        </li>
        <li>
         Ensure that the review process is conducted in a timely manner, with
         any disputes resolved through consultation with the appropriate
         working groups.
        </li>
        </ul>
        </li>
        </ol>
        <t>
   To simplify future registrations, registrations in DLEP-related registries, it is recommended that this guidance serves as a standard reference for
   apply to all DLEP-related
         registries. registries within the "Dynamic Link Exchange Protocol (DLEP)
   Parameters" registry group.  Future specifications may include a header note pointing
   point to this the guidance in this document.
        </t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8175.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-dlep-credit-flow-control.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-dlep-da-credit-extension.xml"/>

<!-- draft-ietf-manet-dlep-credit-flow-control (RFC 9893) -->
        <reference anchor="RFC9893" target="https://www.rfc-editor.org/info/rfc9893">
          <front>
            <title>Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control 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.2474.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8651.xml"/>

      <reference anchor="IEEE8021Q" target="https://ieeexplore.ieee.org/document/8403927" target="https://ieeexplore.ieee.org/document/10004498" quoteTitle="true" derivedAnchor="IEEE8021Q">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks</title>
          <author>
            <organization showOnFrontPage="true">IEEE</organization>
            <organization>IEEE</organization>
          </author>
          <date month="July" month="December" year="2022"/>
        </front>
        <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.10004498"/>
        <seriesInfo name="IEEE" name="IEEE Std" value="802.1Q-2022"/>
      </reference>
        <referencegroup anchor="BCP195" target="https://www.rfc-editor.org/info/bcp195">
          <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml"/>
        </referencegroup> href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0195.xml"/>

        <reference anchor="IEEE-802.1AE" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
              <title>802.1AE-2018 - IEEE
            <title>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security</title>
              <author/>
              <author>
                <organization>IEEE</organization>
              </author>
          <date month="December" year="2018"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8585421"/>
          <seriesInfo name="IEEE Std" value="802.1AE-2018"/>
        </reference>

        <reference anchor="IEEE-8802-1X" target="https://ieeexplore.ieee.org/document/9650828">
          <front>
              <title>8802-1X-2021 - IEEE/ISO/IEC
              <title>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</title>
              <author/>
              <author>
                <organization>IEEE</organization>
              </author>
          <date month="December" year="2021"/>
          </front>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9650828"/>
          <seriesInfo name="IEEE Std" value="8802-1X-2021"/>
        </reference>
    </references>
    </references>
    <section numbered="true" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>
     The
      <t>The Sub-Data Item format was inspired by Rick Taylor's <contact
      fullname="Rick Taylor"/>'s "Data Item Containers".  He also
      proposed the separation of credit windows from traffic
      classification at IETF98. Many useful comments were
     received from contributors to the MANET working group. IETF 98. This document was
      derived from <xref target="I-D.ietf-manet-dlep-da-credit-extension"
      target="RFC9894"
      format="default"/> as a result of discussions at IETF 101. Many
      useful comments were received from contributors to the MANET working group,
      Working Group, notably
     Ronald in't Velt <contact fullname="Ronald in 't Velt"/> and David Black.
      </t>
      <t>
        We
      <contact fullname="David Black"/>.</t>
      <t>We had the honor of working too briefly with David Wiggins <contact
      fullname="David Wiggins"/> on this and related DLEP work. His
      contribution to the IETF and publication of the first and
      definitive open source open-source DLEP implementation have been critical to
      the acceptance of DLEP. We mourn his passing on November 23, 26, 2023.
      We wish to recognize his guidance, leadership leadership, and professional
      excellence.  We were fortunate to benefit from his leadership and
      friendship. He shall be missed.
      </t> missed.</t>
    </section>
  </back>
</rfc>

<!-- Local Variables: -->
<!-- fill-column:72 [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. -->

<!-- End: [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>
</rfc>