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

<!DOCTYPE rfc [
  <!ENTITY filename "draft-ietf-manet-dlep-credit-flow-control-19">
  <!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="&filename;" docName="draft-ietf-manet-dlep-credit-flow-control-19" number="9893" 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 Credit-Based Flow Control">
  Dynamic Control">Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-manet-dlep-credit-flow-control-19"/> name="RFC" value="9893"/>
    <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 fullname="Stan Ratliff" initials="S." surname="Ratliff">
      <address>
        <email>stan@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="E." surname="Kinzie" fullname="Eric Kinzie">
      <organization>LabN Consulting, L.L.C.</organization>
      <address>
        <email>ekinzie@labn.net</email>
      </address>
    </author>

   <date/>

   <date month="December" year="2025"/>

   <area>RTG</area>
   <workgroup>manet</workgroup>
   <abstract>
     <t>
     This document defines new Dynamic Link Exchange Protocol (DLEP)
     Data Items that are used to support credit-based flow control.
     Credit window flow control is used to regulate when data may be sent to
     an associated virtual or physical queue.  The  These Data Items are
     extensible and reusable.
     </t>
     <t>
     This document also defines new messages that support credit window
     flow control.
     </t>
   </abstract>
</front>

<middle>
    <section anchor="sec-1" numbered="true">
      <name>Introduction</name>
      <t>
      The Dynamic Link Exchange Protocol (DLEP), defined in <xref target="RFC8175" format="default"/>, 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 future 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 endpoints, nor does it address flow control capability.
      There are various
      Various flow control techniques are theoretically possible
      with DLEP.  For example, a credit-window credit window scheme for
      destination-specific flow control which that provides aggregate flow
      control for both modem modems and routers has been proposed in <xref target="I-D.ietf-manet-credit-window" format="default"/>, and a control plane pause
      based mechanism referred to as the Control-Plane-Based Pause Extension is defined in <xref target="RFC8651" format="default"/>.
      The use of other flow control mechanisms simultaneously with
      Credit-Based Flow Control
      credit-based flow control is not within the scope of this document.
      </t>
      <t>
      Credit-Based Flow Control,
      Credit-based flow control, as a result of its proactive nature,
      may offer some advantages over a pause mechanism.
      Packet loss resulting from insufficient buffer space is less
      likely, as a transmitter does not send packets until the receiver
      has indicated that there is sufficient buffer space available.
      </t>
      <t>
      <xref target="router-modem" format="default"/>  illustrates
      a local node consisting of a router and a modem with a implementing
      DLEP.
      DLEP messages optionally contain a number of Data Items and
      Sub-data
      Sub-Data Items.
      Traffic flow classification Classification Data Items provided by the modem, modem
      are defined in <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>.
      In this case, a flow is identified based on
      information found in a data plane header header, and one or more matches
      are associated with a single flow.
      Refer to Section 2.3 of <xref target="RFC2475" format="default"/> section="2.3"/>
      for general background on traffic classification.
      </t>
      <figure anchor="router-modem" align="left" suppress-title="false">
      <name slugifiedName="router_to_modem">Router align="left">
      <name>Router and Modem DLEP Exchange</name>
      <artwork name="" type="" align="left" alt=""><![CDATA[
|--------------------Local Node--------------------|
|                                                  |
+-----------------------------+            +-------+
| Router                      |            |Modem  |
|                             |            |Device |{~~~~~~~~} Remote
|                             |            |       | Link      Nodes
| Traffic Classification:     |            |       | Protocol
| Per TID:                    |            |       | (e.g.,
| DSCPs to FID / PCPs to FID  |            |       | 802.11)
|                             | Data Items |       |
| Per Modem: (list of TIDs)   |<---------->|       |
| FID to Credit Window Queues |============|       |
|                             |            |       |
+-----------------------------+            +-------+
                              |            |
                              |----DLEP--- |

DSCP:  Differentiated Services Code Point
FID:  Flow Identifier
PCP:  Priority Code Point
TID:  Traffic Classification Identifier
]]></artwork>
      </figure>
      <t>
      This document defines DLEP Data Items which that provide
      a flow control mechanism for traffic sent
      from a router to a modem. Flow control is provided using one or
      more logical "Credit Windows", "credit windows", each of which will typically be
      supported by an associated virtual or physical queue.
      Credit windows may be shared or dedicated on a per flow per-flow basis. The
      Data Items are structured to allow for the reuse of the defined
      credit window based
      credit-window-based flow control
      with different traffic classification techniques.
      A router logically consumes credits for each credit window
      matching packet sent.
      </t>
      <t>
      Note that this document defines common Messages, messages, Data Items Items, and
      mechanisms that are reusable.  They are expected to be required by
      DLEP extensions defined in other documents documents, such as found the extension defined in <xref target="I-D.ietf-manet-dlep-da-credit-extension" target="RFC9894" format="default"/>.
      </t>
      <t>
      This document
      introduces support for credit window flow control by defining two new DLEP
      messages in <xref (<xref target="sec-msgs" format="default"/>, format="default"/>) and five new DLEP Data
      Items in <xref (<xref target="sec-data-items" format="default"/>. format="default"/>).
      </t>
      <t>
      Various conditions described in this document cause a message to
      be logged.
      In all cases, the log message results from the contents of a
      received Data Item defined here.
      No messages are logged in response to activity in the data plane.
      </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-cw-control" numbered="true" toc="default">
      <name>Credit Window Flow Control</name>
      <t>
    This section defines additions to DLEP used in credit based credit-based flow
    control.
    The use of credit window control impacts additions provide the DLEP mechanisms to control credits. Routers then use this information to regulate when data plane. is sent to a modem.
      </t>
      <t>
    The credit window flow control mechanisms defined in this document
    support credit based credit-based flow control of traffic sent from a router to a
    modem.  The mapping of specific flows to a particular
    credit window is based on the Traffic Classification Data Item
    defined in <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>.
    Both types of DLEP peers, peers -- router and modem, modem -- negotiate the use of an
    extension employing this mechanism during session initialization as
    required,
    required; for example, by see
    <xref target="I-D.ietf-manet-dlep-da-credit-extension" target="RFC9894" format="default"/>.
    When using
    credit windows, data traffic is only allowed to be sent by the
    router to the modem when there are credits available.
      </t>
      <t>
    Credits are managed on a per 'per logical "Credit Window" "credit window"' basis.  Each
    credit window can be thought of as corresponding to a queue within a
    modem.  Credit windows may be shared across, or dedicated to,
    destinations and data plane identifiers, identifiers -- for example, DSCPs, DSCPs -- at a
    granularity that is appropriate for a modem's implementation and its
    attached transmission technology.  As defined below specified in
    <xref target="sec-di-cwi" format="default"/>, there is a
    direct one-for-one one-to-one mapping of credit windows to flows as identified
    by Flow Identifiers (FIDs) carried within the Traffic Classification Data Item.  Modems
    pass to the router information on their credit windows and FIDs
    prior to a router being able to send data when an extension
    requiring the use of credit window flow control is used.
    Note that TID Traffic Classification Identifier (TID) values and FID values are significant only to the issuing modem.
    There is no relationship implied by the same TID or FID value being
    issued by more than one modem.
    In addition to
    the traffic classification information associated with a FID,
    modems provide an initial credit window size, as well as the
    maximum size of the logical queue associated with each credit
    window.  The maximum size is included for informative and potential
    future uses.
      </t>
      <t>
    Modems provide an initial credit window size at the time of "Credit
    Window Initialization". credit
    window initialization.  Such initialization can take place during
    session initiation or any point thereafter.  It can also take place
    when rate information changes.
    An increment to a Credit Window credit window size, specified in a Credit Window Grant
    Data Item, is provided in a Destination Up Message (<xref target="sec-di-cwa"/>) or the new "Credit Control"
    Message. Credit Control
    Message (<xref target="sec-cc-msg"/>).
    A router provides its view
    of the Credit Window, credit window, which is known as "Status", in Destination Up
    Response Messages (<xref target="sec-di-grant"/>) and the new "Credit Credit Control Response" Messages. Response Messages (<xref target="sec-ccr-msg"/>).  Routers
    can also request credits using the new "Credit Control" Message.
      </t> Credit Control Message.</t>
      <t>
    When modems provide credits to a router, they will need to take into
    account any overhead of their attached transmission technology and
    map it into the credit semantics defined in this document.  In
    particular, the credit window is defined below to include per frame
    (packet) MAC per-frame
    (per-packet) Media Access Control (MAC) headers, and this may not match the actual overhead of
    the modem modems' attached transmission technology.  In that case case, a direct
    mapping,
    mapping or an approximation will need to be made by the modem to
    provide appropriate credit values.
      </t>
      <t>
    Actual flows of traffic are mapped to credit windows based on flow
    identification information provided by modems in the Traffic
    Classification Data Item defined in <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>. This
    data item
    Data Item supports traffic classification on a per destination per-destination or
    more fine grain fine-grained level.  Routers use the combination of the DLEP
    identified
    DLEP-identified destination and flow information associated with a credit
    window in order to match traffic they send to specific credit
    windows.
    In some cases, the Traffic Classification Data Item allows
    the modem to specify a wildcard to match any packets that do not
    match other data items, Data Items; for example example, see <xref target
    ="I-D.ietf-manet-dlep-ether-credit-extension"/>. target="RFC9895"/>.
    In the absence of a wildcard, a packet may not match any of the data
    items Data
    Items and, in this case, MUST <bcp14>MUST</bcp14> be dropped by the router.
      </t>
      <t>
    When a destination becomes reachable, a modem "associates"
    (identifies) the appropriate traffic classification information via
    the Traffic Class Identifier (TID) TID to be used for traffic sent by the router to that
    destination.
    This is supported by the Credit Window
    Association Data Item Item, which is carried in Destination Up and Destination Update
    messages,
    Messages; see <xref target="sec-di-cwa" format="default"/>.
    The TID provides the information to support router traffic
    classification, based on the FIDs contained in the TID, TID; see <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>.
    As defined,
    each credit window has a corresponding FID, so traffic is
    mapped to a credit window by locating a matching FID that is
    contained in the TID that is associated with the traffic's
    destination.
    This means that the use of FIDs, TIDs FIDs and TIDs, and the association of a
    TID to a DLEP destination enables destination, enable a modem to share or dedicate
    resources as needed to match the specifics of its implementation and
    its attached transmission technology.
      </t>
      <t>
      The defined credit
      Credit window flow control as defined in this document has similar objectives as similar to the
      control found technique described in <xref target="I-D.ietf-manet-credit-window" format="default"/>.
      One notable difference from that type of credit control is that in this
      document, credits are never provided by the router to the modem.
      </t>

      <section anchor="data-plane" numbered="true">
        <name>Data Plane Considerations</name>
        <t>
      When credit windowing is used, a router MUST NOT <bcp14>MUST NOT</bcp14> send data traffic
      to a modem for forwarding if there is no matching classifier.
      If a matching classifier is found, a router MUST NOT <bcp14>MUST NOT</bcp14> send data
      traffic to a modem when there are no credits available in the
      associated Credit Window. credit window.
      <xref target="sec-cw-control" format="default"/> describes
      how classifiers are associated with destinations and how credit
      windows are associated with classifiers.
      Additionally, a router MUST <bcp14>MUST</bcp14> ensure that sufficient credits are available in the associated
      Credit Window
      credit window for the current data packet before sending that data packet to the modem.
      The count of octets in the packet includes MAC overhead.
      In the example of Ethernet,
      Taking Ethernet as an example, framing, header header, and trailer are all
      included in this count.
      This document defines credit windows in octets octets, and the credit
      window is decremented by the number of sent octets.
        </t>
        <t>
      A router MUST <bcp14>MUST</bcp14> identify the credit window associated with traffic
      to be
      sent to a modem based on the traffic classification information
      provided in the Data Items defined in this document.
        </t>
      </section>

      <section anchor="sec-msgs" numbered="true">
        <name>Credit Window Messages</name>
        <t>
      Two
      This document defines two new messages are defined in that support for credit window flow control:
      the
      Credit Control Messages and the Credit Control Response Messages.  Sending
      and receiving both message types is REQUIRED <bcp14>REQUIRED</bcp14> to support the credit
      window flow control mechanisms defined in this document.
        </t>

        <section anchor="sec-cc-msg" numbered="true">
          <name>Credit Control Message</name>
          <t>
        Credit Control Messages are sent by modems and routers. Each
        sender is only permitted to have one message outstanding at one
        time.  That is, a sender (either modem or router) MUST NOT <bcp14>MUST NOT</bcp14> send
        any
        a subsequent Credit Control Message until a Credit
        Control Response Message is has been received from its peer.
          </t>
          <t>
        Credit Control Messages are sent by modems to provide credit
        window increases.  Modems send credit increases when there is their
        transmission or local queue availability that exceeds the credit
        window value previously provided to the router. Modems will need to
        balance the load generated by sending and processing credit
        window increases against a router having data traffic available to send, send
        but no credits available. available credits.
          </t>
          <t>
        Credit Control Messages MAY <bcp14>MAY</bcp14> be sent by routers to request
        credits and provide window status. Routers will need to
        balance the load generated by sending and processing credit
        window requests against having data traffic available to send, send
        but no credits available. available credits.
          </t>

          <t>
        The Message Type value in the DLEP Message Header is set to TBA2. 17.
          </t>
          <t>
        A Credit Control message Message sent by a modem, MUST modem <bcp14>MUST</bcp14> contain one or more
        Credit Window Grant Data Items as defined in <xref target="sec-di-grant" format="default"/>.  A router receiving this message MUST <bcp14>MUST</bcp14>
        respond with a Credit Control Response Message.
          </t>
          <t>
        A Credit Control message Message sent by a router, MUST router <bcp14>MUST</bcp14> contain one or more Credit Window
        Request Data Items as defined in <xref target="sec-di-request" format="default"/> and SHOULD <bcp14>SHOULD</bcp14> contain a Credit Window
        Status Data Item, defined in <xref target="sec-di-status" format="default"/>,
        corresponding to each credit window request. A modem receiving
        this message MUST <bcp14>MUST</bcp14> respond with a Credit Control Response
        Message based on the received message and Data Item and the
        processing defined in
        <xref target="sec-ccr-msg" format="default"/>,
        which will typically result in credit
        window increments being provided.
          </t>
          <t>
        Specific processing associated with each Credit Data Item is
        provided in
        <xref target="sec-data-items" format="default"/>.
          </t>
        </section>

        <section anchor="sec-ccr-msg" numbered="true">
          <name>Credit Control Response Message</name>
          <t>
        Credit Control Response Messages are sent by routers to report
        the current Credit Window credit window for a destination.  A Credit Control
        Response message Message sent by
        a router, MUST router <bcp14>MUST</bcp14> contain one or more Credit Window Status Data
        Items as defined below in <xref target="sec-di-status" format="default"/>.
        Specific receive processing associated with the Credit Window
        Status Data Item is provided in <xref target="sec-di-status" format="default"/>.
          </t>
          <t>
        Credit Control Response Messages sent by modems MUST <bcp14>MUST</bcp14> contain one
        or more Credit Window Grant Data Items. A Data Item for every
        Credit Window Request Data Item contained in the corresponding
        Credit Control Message received by the modem MUST <bcp14>MUST</bcp14> be
        included.  Each Credit Window Grant Data Item MAY <bcp14>MAY</bcp14> provide zero or more
        additional credits based on the modem's transmission or local
        queue availability.  Specific receive processing associated with
        each Credit Window Grant Data Item is provided in <xref target="sec-di-grant" format="default"/>.
          </t>
          <t>
        The Message Type value in the DLEP Message Header is set to TBA3. 18.
          </t>
        </section>
      </section>

      <section anchor="sec-data-items" numbered="true">
        <name>Credit Window
        <name>Data Items for the Control Data Items</name> of Credit Windows</name>
        <t>
      Five new Data Items are defined to support the control of credit window control.
      The windows:</t>
      <ul spacing="normal">
      <li>The Credit Window Initialization
      Data Item (<xref target="sec-di-cwi"/>) is used by a modem to identify a credit window and set its
      size.
      The
      size.</li>
      <li>The Credit Window Association
      Data Item (<xref target="sec-di-cwa"/>) is used by a modem to identify which traffic classification
      identifiers TIDs
      (flows) should be used when sending traffic to a particular DLEP
      identified destination.
      The
      DLEP-identified destination.</li>
      <li>The Credit Window Grant Data Item (<xref target="sec-di-grant"/>) is used by a modem to provide additional
      credits to a router.
      The Credit Window Request Data Item is used by a router to request additional
      credits.
      The router.</li>
      <li>The Credit Window Status Data Item (<xref target="sec-di-status"/>) is used to advertise the sender's view of the
      number of available credits for state synchronization purposes.
        </t> purposes.</li>
      <li>The Credit Window Request Data Item (<xref target="sec-di-request"/>) is used by a router to request additional
      credits.</li>
      </ul>
        <t>
      Any errors or inconsistencies encountered in parsing Data Items
      are handled in the same fashion as any other data item Data Item parsing error
      encountered in DLEP, DLEP; see <xref target="RFC8175" format="default"/>. In particular, the
      node parsing the Data Item MUST <bcp14>MUST</bcp14> terminate the session with a
      Status Data Item <xref target="RFC8175" format="default"/> indicating Invalid Data. "Invalid Data".
        </t>

        <section anchor="sec-di-cwi" numbered="true">
          <name>Credit Window Initialization</name>
          <t>
        The
        As noted above, the Credit Window Initialization Data Item is used by a modem to
        identify a credit window and set its size.
        In order to avoid errors caused by the use of undefined FIDs or
        uninitialized credit windows, this Data Item SHOULD <bcp14>SHOULD</bcp14> be included
        in any Session Initialization Response Message that indicates
        support for any such extension.
        Updates to
        previously identified credit windows or new credit windows MAY <bcp14>MAY</bcp14>
        be sent by a modem by including the Data Item in Session Update
        Messages.  More than one data item MAY Data Item <bcp14>MAY</bcp14> be included in a message
        to provide information on multiple credit windows.
          </t>
          <t>
        The Credit Window Initialization Data Item identifies a credit
        window using a Flow Identifier, or FID.  It also provides the
        size of the identified credit window.  To be used, a FID must be
        defined within a Traffic Classification Data Item Item, and the
        associated TID must be provided via a Credit Window Association
        Data Item.
          </t>
          <t>
        The format of the Credit Window Initialization 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 (16)                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Flow Identifier (FID)         |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Credit Value                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Scale      |         Credit Window Max Size                |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Data Item Type:</dt>
            <dd>Data Item Type (TBA4)</dd>
            <dd>30</dd>

            <dt>Length:</dt>
            <dd>
              <t>16</t>
              <t>
          As specified in <xref target="RFC8175"/>, Length is the number
          of octets in the Data Item.  It MUST <bcp14>MUST</bcp14> be equal to sixteen
          (16). If it is some other value, the Data Item is corrupt corrupt, so
          the message in which it appears cannot be reliably parsed and
          is ignored.
              </t>
            </dd>

            <dt>Flow Identifier (FID):</dt>
            <dd>
            A two-octet 2-octet flow identifier as defined by the Traffic
            Classification Data Item <xref
            target="I-D.ietf-manet-dlep-traffic-classification" />. target="RFC9892"/>.  The
            FID also uniquely identifies a credit window for a specific
            DLEP session.
            </dd>

            <dt>Reserved:</dt>
            <dd>
            For the Credit Window Initialization 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>Credit Value:</dt>
            <dd>
            A 64-bit unsigned integer representing the credits, in octets, to
            be added to the Credit Window. credit window.  This value includes MAC
            headers as seen on the link between the modem and router.
          </dd>
            <dt>Scale:</dt>
            <dd>
              <t>
            An 8-bit unsigned integer indicating the scale used in the Credit Window
            Max Size field.  The valid values are: are as follows:
              </t>
              <artwork name="" type="" align="left" alt=""><![CDATA[
      Value
<table anchor="table_scale" align="left">
  <name>Valid Scale
      ------------
          0   B - Field Values</name>
  <thead><tr><th>Value</th><th align="center">Scale</th></tr></thead>
  <tbody>
    <tr><td>0</td><td>B: Bytes     (Octets)
          1  KB - (Octets)</td></tr>
    <tr><td>1</td><td>KB: Kilobytes (B/1024)
          2  MB - (B/1024)</td></tr>
    <tr><td>2</td><td>MB: Megabytes (KB/1024)
          3  GB - (KB/1024)</td></tr>
    <tr><td>3</td><td>GB: Gigabytes (MB/1024)
              ]]></artwork> (MB/1024)</td></tr>
  </tbody>
</table>
            </dd>
            <dt>Credit Window Max Size:</dt>
            <dd>
            A 24-bit unsigned integer representing the maximum size, in the
            octet scale indicated by the Scale field, of the associated credit
            window.
            </dd>
          </dl>
          <t>
        A router that receives a Credit Window Initialization Data Item
        MUST
        <bcp14>MUST</bcp14> ensure that the FID field value has been provided by the
        modem in a Traffic Classification Data Item carried in either
        the current message or a previous message.  If the FID cannot be found found, the
        router SHOULD <bcp14>SHOULD</bcp14> log this information.
        The method of logging is left to the router implementation.
        Note that
        no traffic will be associated with the credit window in this
        case.  After FID validation, the router MUST <bcp14>MUST</bcp14> locate the credit
        window that is associated with the FID indicated in each
        received Data Item.  If no associated credit window is found,
        the router MUST <bcp14>MUST</bcp14> initialize a new credit window using the values
        carried in the Data Item.  When an associated credit window is
        found, the router MUST <bcp14>MUST</bcp14> update the credit window and associated
        data plane state using the values carried in the Data Item.
        If the resulting Credit Value resultant credit value results in the credit window
        exceeding the represented Credit Window Max Size, the Credit
        Window Max Size field value is used as the new credit window size.
          </t>
          <t>
        It is worth noting, noting that such updates can result in a credit window
        size being reduced, reduced -- for example, due to a transmission rate
        change on the modem.
        After sending the Session Update Message with one or more Credit
        Window Initialization Data Items that decrease the Credit Window
        Max Size, the modem SHOULD <bcp14>SHOULD</bcp14> continue processing received packets
        that match the indicated FIDs, fit within the window for the
        unmodified Credit Window Max Size Size, and arrive before the modem
        receives the corresponding Session Update Response Message.
        The modem SHOULD NOT <bcp14>SHOULD NOT</bcp14> issue additional credits for any affected
        FID until that FID's associated Window window has drained to be
        less than the new Credit Window Max Size, regardless of when
        the corresponding Session Update Response Message is received.
          </t>
        </section>

        <section anchor="sec-di-cwa" numbered="true">
          <name>Credit Window Association</name>
          <t>
        The Credit Window Association Data Item is used by a modem to
        associate traffic classification information with a destination.
        The traffic classification information is identified using a TID
        value that has previously been previously sent by the modem or is listed
        in a Traffic Classification Data Item carried in the same message
        as the
        Credit Window Association
        Data Item.  TIDs in different Credit credit windows must not
        overlap.
          </t>
          <t>
        A single Credit Window Association Data Item MUST <bcp14>MUST</bcp14> be included in every
        Destination Up and Destination Update Message sent by a modem when
        the a
        credit window flow control mechanism defined in this document is used. Note
        that a TID will not be used unless it is listed in a Credit Window
        Association Data Item.
          </t>
          <t>
        The format of the Credit Window Association 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 (2)                    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Traffic Class. Identifier (TID)|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Data Item Type:</dt>
            <dd>Data Item Type (TBA5)</dd>
            <dd>31</dd>

            <dt>Length:</dt>
            <dd>
              <t>2</t>
              <t>
          As specified in <xref target="RFC8175"/>, Length is the number
          of octets in the Data Item. It MUST <bcp14>MUST</bcp14> be equal to two (2). If it
          is some other value, the Data Item is corrupt corrupt, so the message
          in which it appears cannot be reliably parsed and is ignored.
              </t>
            </dd>
            <dt> Traffic Classification Identifier (TID):</dt>
            <dd>
            A 16-bit unsigned integer identifying a traffic
            classification set that has been identified in a Traffic
            Classification Data Item, Item; see <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>.
          </dd>
          </dl>
          <t>
        A router that receives a Credit Window Association Data Item MUST <bcp14>MUST</bcp14>
        locate the traffic classification information indicated by the
        received TID.  If no corresponding information is found, the
        Credit Window Association
        Data Item MUST <bcp14>MUST</bcp14> be treated as an error as described above.
        If the traffic classification information is located, the
        router MUST <bcp14>MUST</bcp14> ensure that any data plane state that is associated
        with the TID and its corresponding FIDs are is updated as needed
        (per <xref target="data-plane" format="default"/>).
        If a
        router determines that a newly received Data Item results in
        credit windows with overlapping TIDs, the Data Item MUST <bcp14>MUST</bcp14> be
        treated as an error as described above.
          </t>
        </section>

        <section anchor="sec-di-grant" numbered="true">
          <name>Credit Window Grant</name>
          <t>
        The Credit Window Grant Data Item is used by a modem to
        provide credits to a router.  One or more Credit Window Grant Data
        Items MAY <bcp14>MAY</bcp14> be carried in the DLEP Destination Up, Destination Announce
        Response, Destination Update, Credit Control Messages, Control, and Credit
        Control Response Messages.
        Multiple Credit Window Grant Data Items may be present in a
        single message.
        Each item grants credits to a different credit window and,
        therefor, and
        therefore references a different FID.
        In all
        message types, this Data Item provides an additional number of octets
        to be added to the indicated credit window.  Credit windows are
        identified using FID values that have been previously been
        sent by the modem or are listed in a Credit Window Initialization
        Data Item carried in the same message as the Data Item.
          </t>
          <t>
        The format of the Credit Window Grant 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 (12)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flow Identifier (FID)         |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Additional Credits                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Data Item Type:</dt>
            <dd>Data Item Type (TBA6)</dd>
            <dd>32</dd>

            <dt>Length:</dt>
            <dd>
              <t>12</t>
              <t>
          As specified in <xref target="RFC8175"/>, Length is the number
          of octets in the Data Item.  It MUST <bcp14>MUST</bcp14> be equal to twelve
          (12). If it is some other value, the Data Item is corrupt corrupt, so
          the message in which it appears cannot be reliably parsed and
          is ignored.
              </t>
            </dd>
            <dt>Flow Identifier (FID):</dt>
            <dd>
            A two-octet 2-octet flow identifier as defined by the Traffic
            Classification Data Item.  The FID also uniquely indicates a
            credit window.
            </dd>

            <dt>Reserved:</dt>
            <dd>
            For the Credit Window Grant 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>Additional Credit:</dt> Credits:</dt>
            <dd>
            A 64-bit unsigned integer representing the credits, in octets, to
            be added to the Credit Window. credit window.  This value includes MAC
            headers as seen on the link between the modem and router. A value
          of zero indicates that no additional credits are being provided.</dd>
          </dl>
          <t>
        When receiving this Data Item, a router MUST <bcp14>MUST</bcp14> identify the credit
        window indicated by the FID.  If the FID is not known to the router,
        it SHOULD <bcp14>SHOULD</bcp14> log this information and discard the Data Item.
        The method of logging is left to the router implementation.
        It is important to note that while this Data Item can be received in a
        destination specific
        destination-specific message, credit windows are managed independently
        from
        of the destination identified in the message carrying this Data
        Item, and the indicated FID MAY <bcp14>MAY</bcp14> even be disjoint from the identified
        destination.
          </t>
          <t>
        Once the credit window is identified, the credit window size MUST <bcp14>MUST</bcp14> be
        increased by the value contained in the Additional Credits field.  If
        the increase results in a window overflow, the Credit Window credit window
        must be set to its maximum as defined by the Credit Window Max
        Size carried in the Credit Window Initialization Data Item.
          </t>
          <t>
        No response is sent by the router to a modem after processing a Credit
        Window Grant Data Item received in a Credit Control Response Message.
        When a
        For each Credit Window Grant Data Item is received in other message types,
        the receiving router MUST <bcp14>MUST</bcp14> send a
        Credit Window Status Data Item or items reflecting the
        resulting Credit Window
        resultant credit window value of the updated credit window. windows.  When the
        Credit Window Grant Data Item is received in a Destination Up Message, the
        Credit Window Status Data Item(s) MUST <bcp14>MUST</bcp14> be sent in the
        corresponding Destination Up Response Message.  Otherwise, a
        Credit Control Message MUST <bcp14>MUST</bcp14> be sent.
          </t>
        </section>

        <section anchor="sec-di-status" numbered="true">
          <name>Credit Window Status</name>
          <t>
        The Credit Window Status Data Item is used by
        a router to report the current credit window size to its peer modem.  One
        or more Credit Window Status Data Items MAY <bcp14>MAY</bcp14> be carried in a
        Destination Up Response Message or a Credit Control Response Message.
        As discussed in
        <xref target="sec-di-grant" format="default"/>,
        the Destination Up Response Message is used when
        the Data Item is sent in response to a Destination Up Message, and
        the Credit Control Response Message is sent in response to a Credit
        Control Message.  Multiple Credit Window Status Data Items in a
        single message are used to indicate different sizes of different
        credit windows.  Similar to the Credit Window Grant, Grant Data Item, credit windows
        are identified using FID values that have been previously been sent
        by the modem.
          </t>
          <t>
        The format of the Credit Window Status 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 (12)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flow Identifier (FID)         |            Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Current Credit Window Size                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Data Item Type:</dt>
            <dd>Data Item Type (TBA7)</dd>
            <dd>33</dd>

            <dt>Length:</dt>
            <dd>
              <t>12</t>
              <t>
          As specified in <xref target="RFC8175"/>, Length is the number
          of octets in the Data Item. It MUST <bcp14>MUST</bcp14> be equal to twelve
          (12). If it is some other value, the Data Item is corrupt corrupt, so
          the message in which it appears cannot be reliably parsed and
          is ignored.
              </t>
            </dd>

            <dt>Flow Identifier (FID):</dt>
            <dd>
            A two-octet 2-octet flow identifier as defined by the Traffic
            Classification Data Item.  The FID also uniquely identifies
            a credit window.
            </dd>

            <dt>Reserved:</dt>
            <dd>
            For the Credit Window Status 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>Current Credit Window Size:</dt>
            <dd>
            A 64-bit unsigned integer, integer indicating
            the current number of credits, in octets, available for the
                    router to send to the modem.
                    This is referred to as the Modem Receive Window in
        <xref target="I-D.ietf-manet-credit-window" format="default"/>.
          </dd>
          </dl>
          <t>
        When receiving this Data Item, a modem MUST <bcp14>MUST</bcp14> identify the credit
        window indicated by the FID.  If the FID is not known to the modem,
        it SHOULD <bcp14>SHOULD</bcp14> log this information and discard the Data Item.
        The method of logging is left to the modem implementation.
        As with the Credit Window Grant Data Item, the FID MAY <bcp14>MAY</bcp14> be unrelated to
        the Destination destination indicated in the message carrying the Data Item.
          </t>
          <t>
        Once the credit window is identified, the modem SHOULD <bcp14>SHOULD</bcp14> check the
        received Current Credit Window Size field value against the outstanding credit
        window's available credits at the time the most recent Credit Window
        Initialization or Credit Window Grant Data Item associated with the indicated FID
        was sent.  If the difference in values is greater than what can
        be accounted for based on observed data frames, then the modem SHOULD <bcp14>SHOULD</bcp14>
        send a Credit Window Initialization Data Item to reset the associated
        credit window size to the modem's current view of the available
        credits.  As defined specified in
        <xref target="sec-di-cwi" format="default"/>,
        Credit Window Initialization Data Items are
        sent in Session Update Messages.  When multiple Data Items need to be
        sent, they SHOULD <bcp14>SHOULD</bcp14> be combined into a single message when possible.
        Alternatively, and also in cases where there are small differences,
        the modem MAY <bcp14>MAY</bcp14> adjust the values sent in Credit Window Grant Data Items
        to account for the reported Credit Window. credit window.
          </t>
        </section>

        <section anchor="sec-di-request" numbered="true">
          <name>Credit Window Request</name>
          <t>
        The Credit Window Request Data Item is used by a router to
        request additional credits for particular credit windows.  Credit
        Window Request Data Items are carried in Credit Control Messages, and
        one or more Credit Window Request Data Items MAY <bcp14>MAY</bcp14> be present in a
        message.
          </t>
          <t>
        Credit windows are identified using a FID as defined in <xref target="sec-di-cwi" format="default"/>.  Multiple FIDs MAY <bcp14>MAY</bcp14> be present to allow for the
        case where the router identifies determines that credits are needed in multiple
        credit windows.  A special FID value, as defined below, is used to
        indicate that a credit window request is being made across all queues.
          </t>
          <t>
        The format of the Credit Window Request 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Flow Identifier (FID) [1]     | Flow Identifier (FID) [2]     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               ...             | Flow Identifier (FID) [n]     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
          <dl newline="true" spacing="normal">
            <dt>Data Item Type:</dt>
            <dd>Data Item Type (TBA8)</dd>
            <dd>34</dd>

            <dt>Length:</dt>
            <dd>
              <t>Variable</t>
              <t>
          As specified in <xref target="RFC8175"/>, Length is the number
          of octets in the Data Item, excluding the Data Item Type and Length
          fields.  It is equal to the number of FID fields carried in
          the Data Item times 2 and MUST <bcp14>MUST</bcp14> be at least 2. If it is less
          than 2, the Data Item is corrupt corrupt, so the message in which it
          appears cannot be reliably parsed and is ignored.
              </t>
            </dd>
            <dt>Flow Identifier (FID):</dt>
            <dd>
            A two-octet 2-octet flow identifier as defined by the Traffic
            Classification Data Item.  The FID also uniquely identifies
            a credit window.  The special value of 0xFFFF indicates that
            the request applies to all FIDs.  When this special value is
            included, all other FID values included in the Data Item are
            redundant
            redundant, as the special value indicates all FIDs.
          </dd>
          </dl>
          <t>
        A modem receiving this Data Item MUST <bcp14>MUST</bcp14> provide a Credit Increment credit window increment for
        the indicated credit windows via Credit Window Grant Data Items
        carried in a new Credit Control Message.  Multiple values and queue
        indexes SHOULD <bcp14>SHOULD</bcp14> be combined into a single Credit Control Message when
        possible.  Unknown FID values SHOULD <bcp14>SHOULD</bcp14> be logged and then
        ignored by the modem.
        The method of logging is left to the modem implementation.
          </t>
        </section>
      </section>

      <section anchor="sec-mgmnt" numbered="true">
        <name>Management Considerations</name>
        <t>
      This section provides several network management guidelines
      to
      for implementations supporting the credit window flow control mechanisms defined
      in this document.
        </t>
        <t>
      Modems MAY <bcp14>MAY</bcp14> support the configuration of the number of credit
      windows (queues) to advertise to a router.
        </t>
        <t>
      Routers may have limits on the number of queues that they can
      support.  They may even have limits on supported credit window
      combinations.  For example, per destination per-destination queues may not be
      supported at all.  When modem-provided credit window information provided by a
      modem exceeds the capabilities of a router, the router SHOULD <bcp14>SHOULD</bcp14> use a subset of
      the provided credit windows.  Alternatively, a router MAY <bcp14>MAY</bcp14> reset the
      session and indicate that the extension is not supported.  In either
      case, the any mismatch of in capabilities SHOULD <bcp14>SHOULD</bcp14> be reported to the user via
      normal network management mechanisms, such as the user interface
      or error logging.
        </t>
        <t>
      In all cases, if credit windows are in use, traffic for which credits are not
      available MUST NOT <bcp14>MUST NOT</bcp14> be sent to the modem by the router.
        </t>
      </section>
    </section>

    <section anchor="sec-compat" numbered="true">
      <name>Compatibility</name>
      <t>
    The messages and Data Items 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>
    </section>

    <section anchor="sec-sec" numbered="true">
      <name>Security Considerations</name>
      <t>
    This document introduces credit window control and flow control mechanisms
    to
    for DLEP.  These mechanisms expose vulnerabilities similar to existing
    DLEP messages.
    An example of a threat to which flow control might be susceptible is where
    a malicious actor masquerading as a DLEP peer could inject a Credit
    Window Initialization Data Item, which Item that resizes a credit window to
    a value that results in a denial of service.
    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 flow control.
    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 version of <xref target="BCP195" format="default"/> 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"/>.
      </t>
    </section>

    <section anchor="sec-iana" numbered="true">
      <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-msg" numbered="true">
        <name>Message Type Values</name>

        <t>
      This document requests 2
      IANA has assigned two new assignments to values from the "Specification Required" range <xref target="RFC8126"/> in the DLEP Message Registry
      named "Message Type Values" in the range with the "Specification Required"
      policy.  The requested values are as follows: registry:
        </t>
        <t keepWithNext="true"/>

        <table anchor="table_msg" align="center">
          <name>Requested Message
          <name>Message Type Values</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA2</td> align="left">17</td>
              <td align="left">Credit Control</td>
            </tr>
            <tr>
              <td align="left">TBA3</td> align="left">18</td>
              <td align="left">Credit Control Response</td>
            </tr>
          </tbody>
        </table>
        <t keepWithPrevious="true"/>

      </section>
      <section anchor="sec-iana-di" numbered="true" toc="default">
        <name>Data Item Values</name>
        <t>
      This document requests
      IANA has assigned the following new assignments to values from the "Specification Required" range <xref target="RFC8126"/> in the DLEP Data Item
      Registry named "Data Item Type Values" in the range with the "Specification
      Required" policy.  The requested values are as follows: registry:
        </t>
        <t keepWithNext="true"/>

        <table anchor="table_di" align="center">
          <name>Requested Data
          <name>Data Item Values</name>
          <thead>
            <tr>
              <th align="left">Type Code</th>
              <th align="left">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">TBA4</td> align="left">30</td>
              <td align="left">Credit Window Initialization</td>
            </tr>
            <tr>
              <td align="left">TBA5</td> align="left">31</td>
              <td align="left">Credit Window Association</td>
            </tr>
            <tr>
              <td align="left">TBA6</td> align="left">32</td>
              <td align="left">Credit Window Grant</td>
            </tr>
            <tr>
              <td align="left">TBA7</td> align="left">33</td>
              <td align="left">Credit Window Status</td>
            </tr>
            <tr>
              <td align="left">TBA8</td> align="left">34</td>
              <td align="left">Credit Window Request</td>
            </tr>
          </tbody>
        </table>
        <t keepWithPrevious="true"/>

      </section>
    </section>
</middle>

<back>

<displayreference target="I-D.ietf-manet-credit-window" to="Credit-Window-Extension"/>
    <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"/>

<!-- draft-ietf-manet-dlep-traffic-classification (RFC 9892) -->
        <reference anchor="I-D.ietf-manet-dlep-traffic-classification"
                   target="https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-traffic-classification"> anchor="RFC9892" target="https://www.rfc-editor.org/info/rfc9892">
          <front>
            <title>Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item</title>
            <author fullname="Bow-Nan Cheng" initials="B."
	  	    surname="Cheng"> surname="Cheng" fullname="Bow-Nan Cheng">
              <organization>MIT Lincoln Laboratory</organization>
            </author>
            <author fullname="David Wiggins" initials="D."
		    surname="Wiggins"/> surname="Wiggins" fullname="David Wiggins">
            </author>
            <author fullname="Lou Berger" initials="L." surname="Berger"> surname="Berger" fullname="Lou Berger">
              <organization>LabN Consulting, L.L.C.</organization>
            </author>
            <author initials="D." surname="Fedyk" fullname="Don Fedyk" initials="D." surname="Fedyk"> role="editor">
              <organization>LabN Consulting, L.L.C.</organization>
            </author>
            <date day="19" month="November" year="2024"/> month='December' year='2025'/>
          </front>
          <seriesInfo name="Internet-Draft"
		      value="draft-ietf-manet-dlep-traffic-classification"/> name="RFC" value="9892"/>
          <seriesInfo name="DOI" value="10.17487/RFC9892"/>
        </reference>

      </references>

      <references>
        <name>Informative References</name>

<!-- draft-ietf-manet-dlep-da-credit-extension-21 (RFC 9894) -->
 <reference anchor="I-D.ietf-manet-dlep-da-credit-extension"
		   target="https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-da-credit-extension/"> anchor="RFC9894" target="https://www.rfc-editor.org/info/rfc9894">
   <front>
	    <title>DLEP DiffServ
      <title>Dynamic Link Exchange Protocol (DLEP) Diffserv Aware Credit Window Extension</title>
      <author fullname="Bow-Nan Cheng" initials="B."
		    surname="Cheng"> surname="Cheng" fullname="Bow-Nan Cheng">
         <organization>MIT Lincoln Laboratory</organization>
      </author>
      <author fullname="David Wiggins" initials="D."
		    surname="Wiggins"/> surname="Wiggins" fullname="David Wiggins">
         </author>
      <author fullname="Lou Berger" initials="L."
		    surname="Berger"> surname="Berger" fullname="Lou Berger">
         <organization>LabN Consulting, L.L.C.</organization>
      </author>
      <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3rd" initials="D. E."
		    surname="Eastlake"> role="editor">
         <organization>Independent</organization>
      </author>
      <date day="15" month="December" year="2024"/> year="2025" />
   </front>
  <seriesInfo name="Internet-Draft"
	    value="draft-ietf-manet-dlep-da-credit-extension"/> name="RFC" value="9894"/>
  <seriesInfo name="DOI" value="10.17487/RFC9894"/>
</reference>

<!-- draft-ietf-manet-dlep-ether-credit-extension-09 (RFC 9895) -->
<reference anchor="I-D.ietf-manet-dlep-ether-credit-extension"
		   target="https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-ether-credit-extension/"> anchor="RFC9895" target="https://www.rfc-editor.org/info/rfc9895">
   <front>
	    <title>DLEP
      <title>Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window Extension</title>
      <author fullname="David Wiggins" initials="D."
		    surname="Wiggins"/> surname="Wiggins" fullname="David Wiggins">
         </author>
      <author fullname="Lou Berger" initials="L."
		    surname="Berger"> surname="Berger" fullname="Lou Berger">
         <organization>LabN Consulting, L.L.C.</organization>
      </author>
      <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3rd" initials="D. E."
		    surname="Eastlake"> role="editor">
         <organization>Independent</organization>
      </author>
      <date day="15" month="December" year="2024"/> year="2025" />
   </front>
   <seriesInfo name="Internet-Draft"
		      value="draft-ietf-manet-dlep-ether-credit-extension"/> name="RFC" value="9895"/>
   <seriesInfo name="DOI" value="10.17487/RFC9895"/>
</reference>

<!-- draft-ietf-manet-credit-window-07 (Expired) -->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-manet-credit-window.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.8651.xml"/>
	<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"/> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.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>IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security Amendment 4: MAC Privacy protection</title>
	      <author/> Security</title>
              <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">
      <name>Acknowledgments</name>
      <t>
     We mourn the loss of Stan Ratliff who passed away on October 22,
     2019. His guidance, leadership and personal contributions were
     critical in the development of this work and DLEP as a whole. His
     leadership and friendship shall be missed.
      </t>
      <t>
     We had the honor of working too briefly with David Wiggins on this
     and related DLEP work. His contribution to the IETF and publication
     of the first and definitive open source DLEP implementation have
     been critical to the acceptance of DLEP. We morn his passing on
     November 23, 2023.  We wish to recognize his guidance, leadership
     and professional excellence.  We were fortunate to benefit from his
     leadership and friendship. He shall be missed.
      </t>
      <t>
     Many useful comments were
     received from contributors to the MANET working group, notably Rick
     Taylor, Ronald in't Velt, David Black and Donald E. Eastlake.
     This
     document was derived from <xref target="I-D.ietf-manet-dlep-da-credit-extension" format="default"/> as a result of
     discussions at IETF 101.
      </t>
    </section>

    <section anchor="Tree" numbered="true" toc="default">
      <name>Example DLEP Credit Flow Control and Traffic Classification Data Item Exchange</name>
      <t>
        Below
        <xref target="dlep-exchange" format="default"/> illustrates
        a credit flow control and traffic classification exchange between
        a Router router and a Modem. modem.
        The Modem modem will initialize a number of queues with Credit Window
        Initialization Data Items, Credit Window Association Data Item(s) Item(s),
        and Traffic Classification Data Item(s) included in DLEP messages as
        outlined in this document.
        If the Data Items are successfully validated, traffic is mapped
        to the corresponding credit window on the router and forwarded
        when there are sufficient credits.
        Routers can periodically report the status of the credit window.
        Modems will send periodic updates with more credits as packets are
        transmitted.  Routers may request  If a router requires more credits for a particular
        window if the router requires more credits. window, it may request them.

        This document defines window credit window flow information for flow
        Identifiers (FIDs) FIDs
        that map to the queues.
        <xref target="I-D.ietf-manet-dlep-traffic-classification" target="RFC9892" format="default"/>
        defines the traffic classification data sub items Traffic Classification Sub-Data Items, such as DiffServ
        code points DSCPs,
        that map to the FIDs.
      </t>
       <figure anchor="dlep-exchange" align="left" suppress-title="false">
         <name slugifiedName="dlep_exchange">Example align="left">
         <name>Example DLEP Traffic Classification/Credit Classification / Credit Flow Exchange</name>
         <artwork name="" type="" align="center" align="left" alt=""><![CDATA[
Router                                        Modem

  |<----------------DLEP Messages---------------|
  |   Traffic Classification Data Item(s)       |
  |   Credit Window Association Data Item(s)    |
  |   Credit Window Initialization Data Item(s) |
  |                                             |
  |============================================>|
  |   Traffic                                   |
  |                                             |
  |<----------------DLEP Messages---------------|
  |   Credit Window Grant Data Item(s)          | T
  |============================================>| i
  |   Traffic                                   | m
  |                                             | e
  |----------------DLEP Messages--------------->|
  |   Credit Window Status Data Item(s)         | |
  |                                             | V
  |============================================>|
  |   Traffic                                   |
  |                                             |
  |----------------DLEP Messages--------------->|
  |   Credit Window Request Data Item(s)        |
  |                                             |
  |<------------------------------------------- |
  |   Credit Window Grant Data Item(s)          |
  |                                             |
  |============================================>|
  |   Traffic                                   |
  |                                             |
]]></artwork>
       </figure>
    </section>

    <section numbered="false">
      <name>Acknowledgments</name>
      <t>
     We mourn the loss of <contact fullname="Stan Ratliff"/>, who passed away on October 22,
     2019. His guidance, leadership, and personal contributions were
     critical in the development of this work and DLEP as a whole. His
     leadership and friendship shall be missed.
      </t>
      <t>
     We had the honor of working too briefly with <contact fullname="David Wiggins"/> on this
     and related DLEP work. His contribution to the IETF and publication
     of the first and definitive open-source DLEP implementation have
     been critical to the acceptance of DLEP. We mourn his passing on
     November 26, 2023.  We wish to recognize his guidance, leadership,
     and professional excellence.  We were fortunate to benefit from his
     leadership and friendship. He shall be missed.
      </t>
      <t>
     Many useful comments were
     received from contributors to the MANET Working Group, notably <contact fullname="Rick
     Taylor"/>, <contact fullname="Ronald in 't Velt"/>, <contact fullname="David Black"/>, and <contact fullname="Donald E.&nbsp;Eastlake"/>.
     This
     document was derived from <xref target="RFC9894" format="default"/> as a result of
     discussions at IETF 101.
      </t>
    </section>

</back>
</rfc>