RFC 9893

RFC 9893: Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items 🎀

Okay bestie, here are the deets 💅. This one is an IETF Standards Track document, so it's a real Internet standard in the making, and it was published in January 2026 as RFC 9893 ✨. It's by B. Cheng (MIT Lincoln Laboratory), D. Wiggins, S. Ratliff, L. Berger, and E. Kinzie (Editor, LabN Consulting, L.L.C.) 👑. The ISSN is 2070-1721. It doesn't list any RFCs it obsoletes or updates, so it's not replacing or patching anything else 🦋.

Abstract 🌸

This document defines new Dynamic Link Exchange Protocol (DLEP) Data Items that support credit-based flow control. Credit window flow control is how you regulate when data is allowed to be sent to an associated virtual or physical queue 🫶. The Data Items are extensible and reusable, which is very much the vibe ✨.

This document also defines new messages that support credit window flow control 💖.

Status of This Memo 📜

This is an Internet Standards Track document 🔥.

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🙌. If you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9893 💜.

Copyright Notice 🌈

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 📚. Code Components pulled out of this document must include the Revised BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Revised BSD License describes 🫶.

Table of Contents 🗺️

1.  Introduction
  1.1.  Key Words
2.  Credit Window Flow Control
  2.1.  Data Plane Considerations
  2.2.  Credit Window Messages
    2.2.1.  Credit Control Message
    2.2.2.  Credit Control Response Message
  2.3.  Data Items for the Control of Credit Windows
    2.3.1.  Credit Window Initialization
    2.3.2.  Credit Window Association
    2.3.3.  Credit Window Grant
    2.3.4.  Credit Window Status
    2.3.5.  Credit Window Request
  2.4.  Management Considerations
3.  Compatibility
4.  Security Considerations
5.  IANA Considerations
  5.1.  Message Type Values
  5.2.  Data Item Values
6.  References
  6.1.  Normative References
  6.2.  Informative References
Appendix A.  Example DLEP Credit Flow Control and Traffic
        Classification Data Item Exchange
Acknowledgments
Authors' Addresses

1. Introduction 🦋

Okay so the Dynamic Link Exchange Protocol (DLEP), defined in [RFC8175], is how DLEP peers swap link-related control information 🔗. A DLEP peer is made of a modem and a router. DLEP has a base set of mechanisms and is built to take future extensions 🧩. It also has Data Items, which are bundles of info that can be reused across DLEP messages ✨.

Here's the tea: DLEP doesn't do any flow identification beyond the DLEP endpoints, and it doesn't address flow control either 🙈. Flow control techniques are theoretically possible with DLEP, though 💅. For example, a credit window scheme for destination-specific flow control that gives aggregate flow control for both modems and routers has been proposed in [Credit-Window-Extension], and there's a mechanism called the Control-Plane-Based Pause Extension, defined in [RFC8651]. Using other flow control mechanisms at the same time as credit-based flow control is not in scope for this document 🚫.

Credit-based flow control is proactive, so it can have some real advantages over a pause mechanism 🌸. Packet loss from not having enough buffer space is less likely, because a transmitter doesn't send packets until the receiver has said there's enough buffer space available 🫶.

Figure 1 shows a local node with a router and a modem running DLEP. DLEP messages can optionally contain a bunch of Data Items and Sub-Data Items 🍓. The Traffic Classification Data Item from the modem is defined in [RFC9892]. In this case, a flow is identified from info in a data plane header, and one or more matches are tied to a single flow 🎯. As stated in [RFC9892], more than one Data Item MAY be included in a message to give info about multiple traffic classifiers. For general background on traffic classification, check out Section 2.3 of [RFC2475] 📚.

|--------------------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

              Figure 1: Router and Modem DLEP Exchange

This document defines DLEP Data Items that provide a flow control mechanism for traffic sent from a router to a modem 🚀. Flow control happens through one or more logical "credit windows", and each one typically has an associated virtual or physical queue behind it 🧚. Credit windows can be shared or dedicated on a per-flow basis 💜. The Data Items are structured so the defined credit-window flow control can be reused with different traffic classification techniques ♻️. A router logically consumes credits for each credit window that matches a packet it sends 🌈.

Note that this document defines common messages, Data Items, and mechanisms that are reusable. They're expected to be needed by DLEP extensions defined in other documents, like the extension defined in [RFC9894] 🤝.

This document brings in support for credit window flow control with two new DLEP messages (Section 2.2) and five new DLEP Data Items (Section 2.3) ⭐.

Some conditions described here cause a message to be logged. In every case, the log message comes from the contents of a received Data Item defined in this document. Nothing gets logged in response to activity in the data plane 🙈.

1.1. Key Words 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💖.

---

Part 1 of 6 is done, bestie! Section 2 is where the credit windows get real 🦋✨

2. Credit Window Flow Control ✨

Okay bestie, section 2 is where the credit window magic happens 🎀. This part adds DLEP stuff so the router can control credits, and then the router uses that info to decide when it's allowed to send data to a modem 💖.

The credit window flow control mechanisms in this document cover traffic sent from a router to a modem 🦋. Flows get mapped to a particular credit window using the Traffic Classification Data Item from [RFC9892] 💅. When a session starts, both DLEP peers, the router and the modem, negotiate whether they'll use an extension that works this way, and this is required as needed. For example, check [RFC9894] 🧚. Once credit windows are in play, the router is only allowed to send data traffic to the modem when there are credits available 🔥.

Credits are managed on a 'per logical "credit window"' basis ⭐. You can think of each credit window as a queue inside a modem 🌸. Credit windows can be shared across destinations and data plane identifiers (like DSCPs), or dedicated to them. The granularity is up to the modem's implementation and the transmission technology it's attached to 💜. As Section 2.3.1 explains, there's a direct one-to-one mapping between credit windows and flows, identified by Flow Identifiers (FIDs) carried in the Traffic Classification Data Item 👑. Before a router can send any data when an extension requiring credit window flow control is in use, modems pass along information about their credit windows and FIDs 🫶. Also, Traffic Classification Identifier (TID) values and FID values only matter to the modem that issued them. If two modems happen to issue the same TID or FID value, that does not imply any relationship between them 🙈. Along with the traffic classification info tied to a FID, modems also give an initial credit window size, plus the maximum size of the logical queue for each credit window. That maximum size is included for informative and potential future uses 🍓.

Modems give an initial credit window size when the credit window gets initialized. That can happen during session initiation or any point after, and it can also happen when rate information changes 🌈. An increment to a credit window size, carried in a Credit Window Grant Data Item, shows up in a Destination Up Message (Section 2.3.2) or a Credit Control Message (Section 2.2.1) 💖. Routers share their view of the credit window, called "Status", in Destination Up Response Messages (Section 2.3.3) and Credit Control Response Messages (Section 2.2.2) ✨. Routers can also ask for credits by using the Credit Control Message 🦋.

When modems hand out credits, they have to account for any overhead from their attached transmission technology and map it into the credit semantics defined in this document 💅. The credit window here includes per-frame (per-packet) Media Access Control (MAC) headers, and that might not match the actual overhead of the modem's transmission technology 😭. If it doesn't match, the modem has to make a direct mapping or an approximation so it can provide appropriate credit values 🧠.

Real traffic gets mapped to credit windows based on the flow identification info modems provide in the Traffic Classification Data Item from [RFC9892] 🎀. That Data Item can classify traffic per destination or at a more fine-grained level 🌸. Routers use the combination of the DLEP-identified destination and the flow info tied to a credit window to match the traffic they send to specific credit windows 💜. In some cases, the Traffic Classification Data Item lets the modem specify a wildcard that matches any packets that don't match other Data Items. For example, see [RFC9895] 🌈. Without a wildcard, a packet might not match any Data Item at all, and in that case, it MUST be dropped by the router 🚫.

When a destination becomes reachable, the modem "associates" (identifies) the right traffic classification info through the TID, which will be used for traffic the router sends to that destination ⭐. The Credit Window Association Data Item does this job, and it's carried in Destination Up and Destination Update Messages. See Section 2.3.2 👑. The TID gives the info the router needs for traffic classification, based on the FIDs inside the TID. See [RFC9892] 🫶. Each credit window has a corresponding FID, so traffic gets mapped to a credit window by finding a matching FID in the TID associated with the traffic's destination 🧚. So FIDs, TIDs, and the link between a TID and a DLEP destination are what let a modem share or dedicate resources in a way that fits its implementation and its attached transmission technology 🍓.

Credit window flow control in this document has goals similar to the control technique described in [Credit-Window-Extension] 💅. One big difference, though: in this document, credits are never provided by the router to the modem 🙅‍♀️.

2.1. Data Plane Considerations

When credit windowing is in use, a router MUST NOT send data traffic to a modem for forwarding if there is no matching classifier 💀. If a matching classifier is found, a router MUST NOT send data traffic to a modem when there are no credits available in the associated credit window 🚫. Section 2 describes how classifiers are associated with destinations and how credit windows are associated with classifiers 🌸. On top of that, a router MUST ensure that sufficient credits are available in the associated credit window for the current data packet before sending that packet to the modem 🔥. The count of octets in the packet includes MAC overhead. With Ethernet, for example, framing, header, and trailer are all included in this count 🧾. This document defines credit windows in octets, and the credit window is decremented by the number of octets sent 💜.

A router MUST 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 👑.

2.2. Credit Window Messages

This document defines two new messages that support credit window flow control: Credit Control Messages and Credit Control Response Messages 🦋. Sending and receiving both message types is REQUIRED to support the credit window flow control mechanisms defined here 💖.

2.2.1. Credit Control Message

Credit Control Messages are sent by modems and routers 🫶. Each sender is only permitted to have one message outstanding at a time. In other words, a sender (either modem or router) MUST NOT send a subsequent Credit Control Message until a Credit Control Response Message has been received from its peer 🙈.

Modems send Credit Control Messages to provide credit window increases ✨. They send credit increases when their transmission or local queue availability exceeds the credit window value they previously gave the router 🌈. Modems have to balance the load from sending and processing credit window increases against a router that has data traffic ready to go but no available credits 🧠.

Routers MAY send Credit Control Messages to request credits and provide window status 🎀. Routers have to balance the load from sending and processing credit window requests against having data traffic available to send but no available credits 🌸.

The Message Type value in the DLEP Message Header is set to 17 🔢.

A Credit Control Message sent by a modem MUST contain one or more Credit Window Grant Data Items, as defined in Section 2.3.3. A router receiving this message MUST respond with a Credit Control Response Message 💅.

A Credit Control Message sent by a router MUST contain one or more Credit Window Request Data Items, as defined in Section 2.3.5, and SHOULD contain a Credit Window Status Data Item, defined in Section 2.3.4, for each credit window request 🍓. A modem receiving this message MUST respond with a Credit Control Response Message, based on the received message and Data Item and the processing defined in Section 2.2.2. That response will typically result in credit window increments being provided 💜.

Specific processing for each Credit Data Item is provided in Section 2.3 ⭐.

2.2.2. Credit Control Response Message

Credit Control Response Messages are sent by routers to report the current credit window for a destination 🧚. A Credit Control Response Message sent by a router MUST contain one or more Credit Window Status Data Items, as defined in Section 2.3.4. The specific receive processing for the Credit Window Status Data Item is in Section 2.3.4 👑.

Credit Control Response Messages sent by modems MUST contain one or more Credit Window Grant Data Items 🦋. A Data Item MUST be included for every Credit Window Request Data Item contained in the corresponding Credit Control Message the modem received 🫶. Each Credit Window Grant Data Item MAY provide zero or more additional credits, based on the modem's transmission or local queue availability ✨. The specific receive processing for each Credit Window Grant Data Item is in Section 2.3.3 🌈.

The Message Type value in the DLEP Message Header is set to 18 🔢.

2.3. Data Items for the Control of Credit Windows

Five new Data Items are defined to support the control of credit windows 🎀:

• The Credit Window Initialization Data Item (Section 2.3.1) is used by a modem to identify a credit window and set its size 🌸.
• The Credit Window Association Data Item (Section 2.3.2) is used by a modem to identify which TIDs (flows) should be used when sending traffic to a particular DLEP-identified destination 💜.
• The Credit Window Grant Data Item (Section 2.3.3) is used by a modem to provide additional credits to a router 💖.
• The Credit Window Status Data Item (Section 2.3.4) is used to advertise the sender's view of the number of available credits, for state synchronization purposes 🌈.
• The Credit Window Request Data Item (Section 2.3.5) is used by a router to request additional credits 🦋.

Any errors or inconsistencies found while parsing Data Items are handled the same way as any other Data Item parsing error in DLEP. See [RFC8175] 🧾. In particular, the node parsing the Data Item MUST terminate the session with a Status Data Item [RFC8175] indicating Invalid Data 🚨.

2.3.1. Credit Window Initialization ✨

okay so bestie, the Credit Window Initialization Data Item is how a modem identifies a credit window and sets its size 💖 to avoid errors from undefined FIDs or uninitialized credit windows, this Data Item SHOULD be included in any Session Initialization Response Message that indicates support for any such extension 🎀 updates to previously identified credit windows or brand new ones MAY be sent by a modem by including the Data Item in Session Update Messages ✨ and more than one Data Item MAY be included in a message to cover multiple credit windows 🦋

so the Data Item identifies a credit window using a FID and gives its size 🌸 to be used, a FID must be defined within a Traffic Classification Data Item, and the associated TID must be provided via a Credit Window Association Data Item 💅

here's the layout:

        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                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 30

Length: 16

As specified in [RFC8175], Length is the number of octets in the Data Item. It MUST be equal to sixteen (16). If it is some other value, the Data Item is corrupt, so the message in which it appears cannot be reliably parsed and is ignored. 🙈

Flow Identifier (FID): A 2-octet flow identifier as defined by the Traffic Classification Data Item [RFC9892]. The FID also uniquely identifies a credit window for a specific DLEP session. 🧚

Reserved: For the Credit Window Initialization Data Item, this reserved field is currently unused. It MUST be set to all zeros for this version of the Data Item and is currently ignored on reception. This allows for future extensions of the Data Item if needed. 🍓

Credit Value: A 64-bit unsigned integer representing the credits, in octets, to be added to the credit window. This value includes MAC headers as seen on the link between the modem and router. 💜

Scale: An 8-bit unsigned integer indicating the scale used in the Credit Window Max Size field. The valid values are as follows:

+=======+=========================+
| Value |          Scale          |
+=======+=========================+
| 0     | B: Bytes (Octets)       |
+-------+-------------------------+
| 1     | KB: Kilobytes (B/1024)  |
+-------+-------------------------+
| 2     | MB: Megabytes (KB/1024) |
+-------+-------------------------+
| 3     | GB: Gigabytes (MB/1024) |
+-------+-------------------------+

Table 1: Valid Scale Field Values

Credit Window Max Size: A 24-bit unsigned integer representing the maximum size, in the octet scale indicated by the Scale field, of the associated credit window. 🌈

A router that receives a Credit Window Initialization Data Item MUST 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, the router SHOULD 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 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 initialize a new credit window using the values carried in the Data Item. When an associated credit window is found, the router MUST update the credit window and associated data plane state using the values carried in the Data Item. If the 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. 👑

It is worth noting that such updates can result in a credit window size being 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 continue processing received packets that match the indicated FIDs, fit within the window for the unmodified Credit Window Max Size, and arrive before the modem receives the corresponding Session Update Response Message. The modem SHOULD NOT issue additional credits for any affected FID until that FID's associated window has drained to be less than the new Credit Window Max Size, regardless of when the corresponding Session Update Response Message is received. ⭐

---

2.3.2. Credit Window Association 🦋

the Credit Window Association Data Item is how a modem links traffic classification info to a destination 🌸 the info is identified by a TID value that the modem already sent, or that's listed in a Traffic Classification Data Item in the same message 💅 and TIDs in different credit windows MUST NOT overlap 🙅

a single Credit Window Association Data Item MUST be included in every Destination Up and Destination Update Message sent by a modem when a credit window flow control mechanism defined in this document is used 🎀 and note that a TID won't be used unless it's listed in a Credit Window Association Data Item 🫶

here's the layout:

        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)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 31

Length: 2

As specified in [RFC8175], Length is the number of octets in the Data Item. It MUST be equal to two (2). If it is some other value, the Data Item is corrupt, so the message in which it appears cannot be reliably parsed and is ignored. 🙈

Traffic Classification Identifier (TID): A 16-bit unsigned integer identifying a traffic classification set that has been identified in a Traffic Classification Data Item; see [RFC9892]. 🧚

A router that receives a Credit Window Association Data Item MUST locate the traffic classification information indicated by the received TID. If no corresponding information is found, the Credit Window Association Data Item MUST be treated as an error as described above. If the traffic classification information is located, the router MUST ensure that any data plane state that is associated with the TID and its corresponding FIDs is updated as needed (per Section 2.1). If a router determines that a newly received Data Item results in credit windows with overlapping TIDs, the Data Item MUST be treated as an error as described above. 💖

2.3.3. Credit Window Grant

Okay bestie, the Credit Window Grant Data Item is how a modem hands a router more credits 🎀✨ One or more of these MAY show up in a Destination Up, Destination Announce Response, Destination Update, Credit Control, or Credit Control Response Message 💖 You can fit several into one message, and each one gives credits to a different credit window, so each one has its own FID 🦋 In every message type, the item adds some extra octets onto the window it points at. Windows are identified by FID values the modem sent earlier, or by ones listed in a Credit Window Initialization Data Item in the same message 🧚

The format of the Credit Window Grant Data Item is as follows:

       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                        |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 32

Length: 12

As specified in [RFC8175], Length is the number of octets in the Data Item. It MUST be equal to twelve (12). If it is some other value, the Data Item is corrupt, so the message in which it appears cannot be reliably parsed and is ignored. 🙈

Flow Identifier (FID): A 2-octet flow identifier as defined by the Traffic Classification Data Item. The FID also uniquely indicates a credit window. 🌸

Reserved: For the Credit Window Grant Data Item, this reserved field is currently unused. It MUST be set to all zeros for this version of the Data Item and is currently ignored on reception. This allows for future extensions of the Data Item if needed. 🍓

Additional Credits: A 64-bit unsigned integer representing the credits, in octets, to be added to the 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. 💜

When receiving this Data Item, a router MUST identify the credit window indicated by the FID. If the FID is not known to the router, it SHOULD log this information and discard the Data Item. The method of logging is left to the router implementation. It is so important to note that while this Data Item can be received in a destination-specific message, credit windows are managed independently of the destination identified in the message carrying this Data Item, and the indicated FID MAY even be disjoint from the identified destination. 👀✨

Once the credit window is identified, the credit window size MUST be increased by the value contained in the Additional Credits field. If the increase results in a window overflow, the credit window must be set to its maximum as defined by the Credit Window Max Size carried in the Credit Window Initialization Data Item. 🔥

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. For each Credit Window Grant Data Item received in other message types, the receiving router MUST send a Credit Window Status Data Item reflecting the resultant credit window value of the updated credit windows. When the Credit Window Grant Data Item is received in a Destination Up Message, the Credit Window Status Data Item(s) MUST be sent in the corresponding Destination Up Response Message. Otherwise, a Credit Control Message MUST be sent. 💅

---

2.3.4. Credit Window Status

The Credit Window Status Data Item is how a router reports its current credit window size back to its modem bestie 🫶 One or more of these MAY be carried in a Destination Up Response Message or a Credit Control Response Message. As discussed in Section 2.3.3, 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. You can send multiple Credit Window Status Data Items in one message to show different sizes for different credit windows. Just like the Credit Window Grant Data Item, windows are identified using FID values the modem already sent. 🦋

The format of the Credit Window Status Data Item is as follows:

       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                   |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 33

Length: 12

As specified in [RFC8175], Length is the number of octets in the Data Item. It MUST be equal to twelve (12). If it is some other value, the Data Item is corrupt, so the message in which it appears cannot be reliably parsed and is ignored. 🙈

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

Reserved: For the Credit Window Status Data Item, this reserved field is currently unused. It MUST be set to all zeros for this version of the Data Item and is currently ignored on reception. This allows for future extensions of the Data Item if needed. 🍓

Current Credit Window Size: A 64-bit unsigned 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 [Credit-Window-Extension]. 💖

When receiving this Data Item, a modem MUST identify the credit window indicated by the FID. If the FID is not known to the modem, it SHOULD 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 be unrelated to the destination indicated in the message carrying the Data Item. 🧚

Once the credit window is identified, the modem SHOULD 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 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 specified in Section 2.3.1, Credit Window Initialization Data Items are sent in Session Update Messages. When multiple Data Items need to be sent, they SHOULD be combined into a single message when possible. Alternatively, and also in cases where there are small differences, the modem MAY adjust the values sent in Credit Window Grant Data Items to account for the reported credit window. ✨

---

2.3.5. Credit Window Request

The Credit Window Request Data Item is how a router asks for extra credits on particular credit windows 🙏 These are carried in Credit Control Messages, and one or more Credit Window Request Data Items MAY be present in a message. 💌

Credit windows are identified using a FID as defined in Section 2.3.1. Multiple FIDs MAY be present to allow for the case where the router 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. 👑

The format of the Credit Window Request Data Item is as follows:

       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]     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type: 34

Length: Variable

As specified in [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 be at least 2. If it is less than 2, the Data Item is corrupt, so the message in which it appears cannot be reliably parsed and is ignored. 🫠

Flow Identifier (FID): A 2-octet flow identifier as defined by the Traffic Classification Data Item. The FID also uniquely identifies a credit window. The special value 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, as the special value indicates all FIDs. 🌈

A modem receiving this Data Item MUST provide a 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 be combined into a single Credit Control Message when possible. Unknown FID values SHOULD be logged and then ignored by the modem. The method of logging is left to the modem implementation. 🥹💜

2.4. Management Considerations ✨

okay bestie, this section is all about the management side of things 🎀 it's basically the "how do we keep the peace on the network" section, and honestly it's giving responsible adult energy 🧚

Modems MAY support the configuration of the number of credit windows (queues) to advertise to a router. 💖 so a modem is allowed to let you pick how many credit windows (aka queues) it tells the router about. totally optional, but a nice touch 🌸

Routers may have limits on the number of queues that they can support. 😭 routers are not infinite, bestie. they may even have limits on which credit window combinations they're willing to handle. for example, per-destination queues may not be supported at all 💀 like, sorry, that's just not happening on this router 🙈

When credit window information provided by a modem exceeds the capabilities of a router, the router SHOULD use a subset of the provided credit windows. 🫶 so if the modem is overachieving, the router should just pick a smaller group of the windows it was given. Alternatively, a router MAY reset the session and indicate that the extension is not supported 🔥 that's the nuclear option, and the router is allowed to do it if it wants. In either case, any mismatch in capabilities SHOULD be reported to the user via normal network management mechanisms, such as the user interface or error logging ✨ so the mismatch should get flagged to the user through the usual stuff, like a UI message or error logs. no hiding the tea 🍓

In all cases, if credit windows are in use, traffic for which credits are not available MUST NOT be sent to the modem by the router. 👑 this one is a hard rule, no exceptions, no cap. if there are no credits for the traffic, the router must NOT send it to the modem. period 💅

---

3. Compatibility 🦋

okay so the messages and Data Items defined in this document will only be used when extensions require their use. 💜 they only show up when an extension actually needs them, so nothing weird happens otherwise 🌈

The DLEP specification [RFC8175] defines the handling of unexpected appearances of any Data Items, including those defined in this document. 🧚 so if one of these Data Items shows up somewhere it isn't expected, the DLEP spec in [RFC8175] is the one that tells you what to do about it 📖

---

4. Security Considerations 🔐

This document introduces credit window flow control mechanisms for DLEP. 🎀 these mechanisms expose vulnerabilities similar to existing DLEP messages, so this is a whole serious vibe now 😭

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 that resizes a credit window to a value that results in a denial of service. 💀 okay this is the scary part bestie. imagine some sketchy impostor pretending to be a DLEP peer and sneaking in a Credit Window Initialization Data Item that resizes a credit window to a value that causes a denial of service. the network just goes down, and that's a whole disaster 🙈

Other possible threats are discussed in the Security Considerations section of [RFC8175] and are also applicable, but not specific, to flow control. 📚 there are more threats covered in the Security Considerations section of [RFC8175]. they apply here too, they just aren't specific to flow control.

The transport-layer security mechanisms documented in [RFC8175], along with the latest version of [BCP195] at the time of this writing, can be applied to this document. 🔒 so you can use the transport-layer security stuff from [RFC8175], plus the latest [BCP195] as of when this was written, to protect this document's mechanisms.

Implementations following the "networked deployment" model described in Section 4 ("Implementation Scenarios") of [RFC8175] SHOULD refer to [BCP195] for additional details. 🌸 if you're doing the "networked deployment" model from Section 4 ("Implementation Scenarios") of [RFC8175], you SHOULD check out [BCP195] for more details.

The Layer 2 security mechanisms documented in [RFC8175] can also, with some updates, be applied to the mechanisms defined in this document. 🍓 the Layer 2 security stuff in [RFC8175] can also be applied here, though it needs a few updates first.

Examples of technologies that can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-8802-1X]. 🦋 some examples of tech you can use to lock down the Layer 2 link are [IEEE-802.1AE] and [IEEE-8802-1X].

---

5. IANA Considerations 🧾

5.1. Message Type Values 💌

IANA has assigned two new values from the "Specification Required" range [RFC8126] in the DLEP "Message Type Values" registry: 🎀 IANA added two new values to the DLEP "Message Type Values" registry, taken from the "Specification Required" range in [RFC8126].

+===========+=========================+
| Type Code | Description             |
+===========+=========================+
| 17        | Credit Control          |
+-----------+-------------------------+
| 18        | Credit Control Response |
+-----------+-------------------------+

            Table 2: Message Type Values

5.2. Data Item Values 🌈

IANA has assigned the following values from the "Specification Required" range [RFC8126] in the DLEP "Data Item Type Values" registry: 🧚 these values were assigned from the "Specification Required" range in [RFC8126] for the DLEP "Data Item Type Values" registry.

+===========+==============================+
| Type Code | Description                  |
+===========+==============================+
| 30        | Credit Window Initialization |
+-----------+------------------------------+
| 31        | Credit Window Association    |
+-----------+------------------------------+
| 32        | Credit Window Grant          |
+-----------+------------------------------+
| 33        | Credit Window Status         |
+-----------+------------------------------+
| 34        | Credit Window Request        |
+-----------+------------------------------+

            Table 3: Data Item Values

---

6. References 📚

6.1. Normative References 💜

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, June 2017, <https://www.rfc-editor.org/info/rfc8175>.

[RFC9892] Cheng, B., Wiggins, D., Berger, L., and D. Fedyk, Ed., "Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data Item", RFC 9892, DOI 10.17487/RFC9892, January 2026, <https://www.rfc-editor.org/info/rfc9892>.

6.2. Informative References 🌸

[BCP195] Best Current Practice 195, <https://www.rfc-editor.org/info/bcp195>. At the time of writing, this BCP comprises the following:

Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.

Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November 2022, <https://www.rfc-editor.org/info/rfc9325>.

[Credit-Window-Extension] Ratliff, S., "Credit Windowing extension for DLEP", Work in Progress, Internet-Draft, draft-ietf-manet-credit- window-07, 13 November 2016, <https://datatracker.ietf.org/doc/html/draft-ietf-manet- credit-window-07>.

[IEEE-802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018, December 2018, <https://ieeexplore.ieee.org/document/8585421>.

[IEEE-8802-1X] IEEE, "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", DOI 10.1109/IEEESTD.2021.9650828, IEEE Std 8802-1X-2021, December 2021, <https://ieeexplore.ieee.org/document/9650828>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019, <https://www.rfc-editor.org/info/rfc8651>.

[RFC9894] Cheng, B., Wiggins, D., Berger, L., and D. Eastlake 3rd, Ed., "Dynamic Link Exchange Protocol (DLEP) Diffserv Aware Credit Window Extension", RFC 9894, DOI 10.17487/RFC9894, January 2026, <https://www.rfc-editor.org/info/rfc9894>.

[RFC9895] Wiggins, D., Berger, L., and D. Eastlake 3rd, Ed., "Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window Extension", RFC 9895, DOI 10.17487/RFC9895, January 2026, <https://www.rfc-editor.org/info/rfc9895>.

Appendix A. Example DLEP Credit Flow Control and Traffic Classification Data Item Exchange 🦋

Figure 2 illustrates a credit flow control and traffic classification exchange between a router and a modem. 🎀 this figure shows the whole credit flow control and traffic classification exchange between a router and a modem. the modem will initialize a number of queues with Credit Window Initialization Data Items, Credit Window Association Data Item(s), and Traffic Classification Data Item(s) included in DLEP messages as outlined in this document. 💖 the modem sets up a bunch of queues using those Data Items, all sent in DLEP messages the way this document describes.

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. 🌸 if everything validates, traffic gets mapped to its matching credit window on the router, and it only gets forwarded when there are enough credits.

Routers can periodically report the status of the credit window. 🧚 routers can check in now and then to report the credit window status.

Modems will send periodic updates with more credits as packets are transmitted. ✨ modems keep topping up the credits as packets go out.

If a router requires more credits for a particular window, it may request them. 🍓 if a router needs more credits for a certain window, it's allowed to ask for them.

This document defines credit window flow information for FIDs that map to the queues. 💜 this doc defines the credit window flow info for the FIDs that map to those queues.

[RFC9892] defines the Traffic Classification Sub-Data Items, such as DSCPs, that map to the FIDs. 👑 [RFC9892] is where the Traffic Classification Sub-Data Items live, like DSCPs, and those are what map to the FIDs.

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                                   |
  |                                             |

Figure 2: Example DLEP Traffic Classification / Credit Flow Exchange 🌈

Acknowledgments 🫶

okay bestie, this part is a little bittersweet 🥺 we have to remember some incredible people. we are mourning 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 🕊️

we also had the honor of working with David Wiggins, even though it was only briefly 💜 his contribution to the IETF and the publication of the first and definitive open-source DLEP implementation were 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 🌸

many useful comments came from contributors to the MANET Working Group, especially Rick Taylor, Ronald in 't Velt, David Black, and Donald E. Eastlake 🙌 this document was derived from [RFC9894] as a result of discussions at IETF 101 🎀

---

Authors' Addresses 🧚

Bow-Nan Cheng

Bow-Nan Cheng
MIT Lincoln Laboratory
Massachusetts Institute of Technology
244 Wood Street
Lexington, MA 02421-6426
United States of America
Email: bcheng@ll.mit.edu

David Wiggins 🕊️

Stan Ratliff 🕊️

Lou Berger

Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net

Eric Kinzie (editor)

Eric Kinzie (editor)
LabN Consulting, L.L.C.
Email: ekinzie@labn.net