<?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>
<keyword>Diffserv Code Points</keyword>
<keyword>Ethernet Priority Code Points</keyword>

    <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, Items and defines two new 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 and, when combined with applications such as
      credit window control, allows credit windows to be shared (1)&nbsp;shared
      across traffic sent to multiple DLEP destinations and as part of
      multiple flows, flows or used (2)&nbsp;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.
      </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 defines two new Sub-Data Items are defined to support
      identification of flows based on DSCPs and PCPs. PCPs (see Sections <xref target="sec-di-tc-ds-sub" format="counter"/> and <xref target="sec-di-tc-e-sub" format="counter"/>).
      </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
    transport-layer 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.
      </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"/> sectionFormat="of" section="11.3"/>, Length
        is the number of octets in the Data Item, excluding the Data Item 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.
            </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.
        </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"/>, sectionFormat="of" section="11.3"/>, 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. The maximum length is limited on a per Each Sub-Data Item Type. has its own Length field.
              </t>
            </dd>
           <dt>Value:</dt>
           <dd>
             <t>
             A field of &lt;Length&gt; octets that contains data specific to a particular Data Item.
             </t>
           </dd>
          </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.
            </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 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"/>.
  </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 total length of this Sub-Data Item is the value carried in 2 octets
          of Flow Identifier, plus the 2 octets for NumPCPs field divided by two and rounded VLAN Identifier
          plus the number of octets for PCPs.  The number of octets for the PCPs
          is computed by rounding up NumPCPs to the next
          higher integer quantity. nearest even value and
          dividing by 2. This TLV has maximum length of 4 plus 8 divided by 2 or 16 8
          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.
        </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>
            <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>
      <!--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"/>, along with some updated
    references to external documents listed below, the latest versions of
    <xref target="BCP195" format="default"/>, <xref target="IEEE-802.1AE"/>, and <xref target="IEEE-802.1X"/> at the time of this writing, 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"/>. target="IEEE-802.1X"/>.
    </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 Item Type Values</name>

        <t>
      This document requests
      IANA has assigned the following new assignments to value from the "Specification
      Required" range <xref target="RFC8126" format="default"></xref> in the DLEP Data Item
      Registry named
      "Data Item Type Values" from the range with the "Specification
      Required" policy.  The requested value is as follows: 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 the
         Traffic Classification Sub-Data Item Type Values registry for
         the DLEP protocol, in accordance with BCP 26 and [RFC8126].
        </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 entries 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>

      </section>

      <section anchor="sec-reg-guidance" numbered="true" toc="default">
      <name>Registration Guidance</name>
	<t>
         This section provides guidance for registrations in the "Traffic
         Classification Sub-Data Item Type Values" registry. To simplify future registrations,
         registrations in DLEP-related registries, it is recommended that this the
         guidance serves as a standard reference for in this section apply to all DLEP-related
         registries. registries within the "Dynamic Link
         Exchange Protocol (DLEP) Parameters" registry group that use the
         "Specification Required" policy <xref target="RFC8126"/>. 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" anchor="IEEE-802.1X" target="https://ieeexplore.ieee.org/document/9650828">
          <front>
              <title>8802-1X-2021 - 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="IEEE-802.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 -->
<!-- End: [rfced] The following terms appear to be used inconsistently
in this document.  Please let us know which forms are 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>