Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control Messages and Data Items
Extracted elements (31)
Credit-based flow control is proactive: a transmitter does not send packets until the receiver indicates sufficient buffer space, making packet loss from buffer exhaustion less likely compared to a pause-based mechanism.
Credit windows are defined per FID (one-to-one mapping) rather than per destination, allowing modems to share or dedicate resources flexibly to match their implementation and attached transmission technology.
Unlike the prior Credit-Window-Extension draft, credits in this specification are never provided by the router to the modem — flow control is unidirectional from modem to router.
The messages and Data Items defined in this document are only used when extensions explicitly require their use; the DLEP base specification handles unexpected Data Items, ensuring backward compatibility with DLEP peers that do not implement this extension.
When credit window information provided by a modem exceeds a router's queue capacity, the router SHOULD use a subset of the provided credit windows or MAY reset the session and indicate the extension is not supported; capability mismatches SHOULD be reported via network management.
A Credit Control Message sent by a modem MUST contain one or more Credit Window Grant Data Items, and 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 and SHOULD contain a Credit Window Status Data Item corresponding to each credit window request.
A Credit Control Response Message sent by a router MUST contain one or more Credit Window Status Data Items. Credit Control Response Messages sent by modems MUST contain one or more Credit Window Grant Data Items, with a Data Item for every Credit Window Request Data Item in the corresponding Credit Control Message.
A modem receiving a Credit Window Request 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.
A node parsing a Data Item that encounters errors or inconsistencies MUST terminate the session with a Status Data Item indicating 'Invalid Data', consistent with DLEP base error handling in RFC 8175.
A router MUST ensure that sufficient credits are available in the associated credit window for the current data packet before sending that data packet to the modem. The count of octets includes MAC overhead (framing, header, and trailer).
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.
A router receiving a Credit Window Initialization Data Item MUST locate or initialize the credit window for the indicated FID. If an associated credit window is found, the router MUST update it; if the resultant credit value exceeds the Credit Window Max Size, the max size is used as the new window size.
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, ensuring only one outstanding message per sender at a time.
A single Credit Window Association Data Item MUST be included in every Destination Up and Destination Update Message sent by a modem when credit window flow control is in use.
For each Credit Window Grant Data Item received in message types other than Credit Control Response, the receiving router MUST send a Credit Window Status Data Item reflecting the resultant credit window value. When received in a Destination Up Message, the status MUST be sent in the Destination Up Response; otherwise, a Credit Control Message MUST be sent.
If a router determines that a newly received Credit Window Association Data Item results in credit windows with overlapping TIDs, the Data Item MUST be treated as an error.
The Credit Window Initialization Data Item SHOULD be included in any Session Initialization Response Message that indicates support for a credit-window extension, to avoid errors from undefined FIDs or uninitialized credit windows.
When receiving a Credit Window Grant Data Item, the router MUST identify the credit window indicated by the FID and MUST increase the credit window size by the value in the Additional Credits field. If overflow results, the credit window is set to its maximum.
Credits are denominated in octets and include per-frame MAC headers. A router decrements the credit window by the number of sent octets (including MAC framing) for each packet forwarded to the modem.
The Credit Control Message (Type 17) is sent by both modems and routers. Modems use it to provide credit window increases via Credit Window Grant Data Items; routers use it to request credits via Credit Window Request Data Items.
The Credit Control Response Message (Type 18) is sent in reply to a Credit Control Message. Routers send Credit Window Status Data Items; modems send Credit Window Grant Data Items covering every Credit Window Request in the triggering message.
The Scale field in the Credit Window Initialization Data Item encodes the unit for Credit Window Max Size: 0=Bytes, 1=Kilobytes (B/1024), 2=Megabytes (KB/1024), 3=Gigabytes (MB/1024).
IANA assigned five new values in the DLEP 'Data Item Type Values' registry: 30 (Credit Window Initialization), 31 (Credit Window Association), 32 (Credit Window Grant), 33 (Credit Window Status), and 34 (Credit Window Request), all in the Specification Required range.
IANA assigned two new values in the DLEP 'Message Type Values' registry: Type 17 (Credit Control) and Type 18 (Credit Control Response), both in the Specification Required range.
A malicious actor masquerading as a DLEP peer could inject a Credit Window Initialization Data Item that resizes a credit window to cause a denial of service. Transport-layer security per RFC 8175 and BCP 195, as well as Layer 2 security (IEEE 802.1AE, IEEE 8802-1X), should be applied to mitigate such threats.
The Credit Window Association Data Item (Type 31) is 2 octets: a single 16-bit unsigned Traffic Classification Identifier (TID) field.
The Credit Window Grant Data Item (Type 32) is 12 octets: 2-octet FID, 2-octet Reserved (must be zero), and 8-octet Additional Credits (64-bit unsigned integer in octets including MAC headers; zero means no additional credits).
The Credit Window Initialization Data Item (Type 30) is 16 octets: 2-octet FID, 2-octet Reserved (must be zero), 8-octet Credit Value (64-bit unsigned integer in octets including MAC headers), 1-octet Scale, and 3-octet Credit Window Max Size.
The Credit Window Request Data Item (Type 34) has a variable-length format containing one or more 2-octet FID fields; Length MUST be at least 2. The special FID value 0xFFFF requests credits across all queues.
The Credit Window Status Data Item (Type 33) is 12 octets: 2-octet FID, 2-octet Reserved (must be zero), and 8-octet Current Credit Window Size (64-bit unsigned integer in octets).