DLEP 802.1Q credits: Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window Extension
How DLEP modems and routers can meter Ethernet traffic with credit windows tied to VLANs and priority bits.
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>.
@misc{rfc9895,
series = {Request for Comments},
number = 9895,
howpublished = {RFC 9895},
publisher = {RFC Editor},
doi = {10.17487/RFC9895},
url = {https://www.rfc-editor.org/info/rfc9895},
author = {D. Wiggins and L. Berger and D. Eastlake 3rd},
title = {{Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window Extension}},
pagetotal = 6,
year = 2026,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) D. Wiggins
Request for Comments: 9895
Category: Standards Track L. Berger
ISSN: 2070-1721 LabN Consulting, L.L.C.
D. Eastlake 3rd, Ed.
Independent
January 2026
Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window
Extension
Abstract
This document defines an extension to the Dynamic Link Exchange
Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit
window scheme for destination-specific and shared flow control.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9895.
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) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
1.1. Key Words
2. Extension Usage and Identification
3. Management Considerations
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
The protocol provides the exchange of link-related control
information between DLEP peers. DLEP peers consist of a modem and a
router. DLEP defines a base set of mechanisms as well as support for
possible extensions. This document defines one such extension.
The DLEP specification does not define any flow control mechanisms.
While in theory various flow control techniques could be implemented
with DLEP, this document specifies a DLEP extension that introduces
an Ethernet-based flow control mechanism for traffic transmitted from
a router to a modem. This mechanism utilizes one or more logical
"credit windows", each of which is typically associated with a
virtual or physical queue. The router leverages traffic flow
classification information provided by the modem to determine the
appropriate credit window for a given traffic flow. Credit windows
may be shared across multiple flows or used on a per-flow basis. For
a Diffserv-based approach to credit window flow control, refer to
[RFC9894]. As specified in Section 2.3.1 of [RFC9892], when both
Diffserv and Ethernet traffic classification are applied to a flow,
Ethernet-based classification takes precedence.
This document leverages the traffic classification and credit window
flow control mechanisms defined in [RFC9892] and [RFC9893] to enable
credit-window-based flow control based on DLEP destinations, Ethernet
Virtual Local Area Networks (VLANs), and Priority Code Points (PCPs).
Ethernet PCP support is specified as part of the IEEE 802.1Q tag
format [IEEE8021Q], which includes a 3-bit "PCP" field. The tag
format also incorporates a 12-bit "VLAN Identifier (VID)" field.
The defined mechanism allows credit windows to be shared across
traffic destined for multiple DLEP destinations, VLANs, and PCPs, or
to be dedicated exclusively to traffic associated with a specific
destination, VLAN, and/or PCP. Additionally, this extension supports
"wildcard" matching for any PCP or VID.
The extension defined in this document is referred to as the "IEEE
802.1Q Aware Credit Window" or, more simply, the "Ethernet Credit"
extension. The reader should be familiar with both the traffic
classification and credit window flow control mechanisms defined in
[RFC9892] and [RFC9893].
This document defines a new DLEP Extension Type value that is used to
indicate support for the extension. See Section 2.
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.
2. Extension Usage and Identification
The extension defined in this document is built on the mechanisms and
processing defined in [RFC9892] and [RFC9893]. To indicate that the
IEEE 802.1Q Aware Credit Window Extension is to be used, an
implementation MUST include the IEEE 802.1Q Aware Credit Window
Extension Type value in the Extensions Supported Data Item (see
Section 13.6 of [RFC8175]). The Extensions Supported Data Item is
sent and processed according to [RFC8175]. Any implementation that
indicates the use of the IEEE 802.1Q Aware Credit Window Extension
MUST support all message types, Data Items, the Ethernet Traffic
Classification Sub-Data Item, and all related processing defined in
[RFC9892] and [RFC9893].
The IEEE 802.1Q Aware Credit Window Extension Type value is 5. See
Section 5.
3. Management Considerations
This section provides several network management guidelines for
implementations supporting the IEEE 802.1Q Aware Credit Window
Extension.
If this extension is supported, that support MUST be declared using
the Extensions Supported Data Item (see Section 13.6 of [RFC8175]),
which is configurable on both modems and routers. Diffserv Aware
Credit Window Extension Data Items MUST NOT be emitted by a DLEP
participant unless such support was specified in the initialization
message received from its peer. The use of the extension defined in
this document SHOULD be configurable on both modems and routers.
Modems SHOULD support the configuration of mapping a PCP to a credit
window (queue).
Modems MAY support the configuration of mapping a PCP to a credit
window (queue) on a per-VLAN basis. VID value zero (0x0000) is used
by [RFC9892] to indicate that the VID is ignored. VID 0xFFFF is
reserved. Any other VID value from 0x0001 through 0xFFFE can be used
in traffic classification.
When VLANs are supported by a modem without support from PCPs, the
modem SHOULD support the configuration of mapping a VLAN to a credit
window (queue).
Modems MAY support the configuration of the number of credit windows
(queues) that they advertise to a router.
Routers may impose limitations on the number of queues they can
support and on the allowable credit window configurations. In some
cases, per-destination queues may not be supported. If the credit
window information provided by the modem exceeds the router's
capabilities, the router SHOULD utilize a subset of the advertised
credit windows. Alternatively, the router MAY reset the session and
indicate that the extension is not supported. In either case, any
mismatch in capabilities SHOULD be reported to the user through
standard network management mechanisms, such as user interface
notifications or error logging.
Regardless of implementation, if credit windows are in use, the
router MUST NOT send traffic to the modem unless sufficient credits
are available.
4. Security Considerations
This document defines a DLEP extension that uses DLEP mechanisms and
the credit window flow control mechanisms defined in [RFC9892] and
[RFC9893]. See also the Security Considerations sections of those
documents.
The defined extension is exposed to vulnerabilities similar to
existing DLEP messages and discussed in the Security Considerations
section of [RFC8175], such as an injected message resizing a credit
window to a value that results in a denial of service. The security
mechanisms documented in [RFC8175] can be applied equally to the
mechanism defined in this document.
Wildcards for matching PCP and VID fields are provided. Note that
wildcards may be convenient for matching a number of packet flows but
could inadvertently match unexpected flows or new flows that appear
after the wildcard matching has been set up. It is therefore
RECOMMENDED that wildcards not be used unless clearly needed.
5. IANA Considerations
IANA has assigned the following code point in the "Extension Type
Values" registry in the "Dynamic Link Exchange Protocol (DLEP)
Parameters" registry group:
+======+=================================+
| Code | Description |
+======+=================================+
| 5 | IEEE 802.1Q Aware Credit Window |
+------+---------------------------------+
Table 1: Extension Type Value
6. References
6.1. Normative References
[IEEE8021Q]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks",
DOI 10.1109/IEEESTD.2022.10004498, IEEE Std 802.1Q-2022,
December 2022,
<https://ieeexplore.ieee.org/document/10004498>.
[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>.
[RFC9893] Cheng, B., Wiggins, D., Ratliff, S., Berger, L., and E.
Kinzie, Ed., "Dynamic Link Exchange Protocol (DLEP)
Credit-Based Flow Control Messages and Data Items",
RFC 9893, DOI 10.17487/RFC9893, January 2026,
<https://www.rfc-editor.org/info/rfc9893>.
6.2. Informative References
[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>.
Acknowledgments
This document was motivated by discussions in the MANET Working
Group. Many useful comments were received from contributors to the
MANET Working Group, notably Ronald in 't Velt.
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 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.
Authors' Addresses
David Wiggins
Lou Berger
LabN Consulting, L.L.C.
Email: lberger@labn.net
Donald E. Eastlake 3rd (editor)
Independent
2386 Panoramic Circle
Apopka, FL 32703
United States of America
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com
AI ELI5
On this page
§1Introduction
The Dynamic Link Exchange Protocol (DLEP, RFC 8175) carries link-related control information between two peers, a modem and a router. DLEP defines a base set of mechanisms plus support for extensions. It does not define any flow control, and this document adds one as an extension.
The extension introduces an Ethernet-based flow control mechanism for traffic sent from the router to the modem. It uses one or more logical credit windows, each typically tied to a virtual or physical queue. The router uses traffic classification information supplied by the modem to pick the right credit window for a flow.
The extension is called the IEEE 802.1Q Aware Credit Window extension, or more simply the Ethernet Credit extension. Readers are expected to know the classification and credit mechanisms of RFC 9892 and RFC 9893.
A router and a radio box talk to each other. This document gives them a ticket system so the router only sends as much as the box can take.
§2Credit Windows, VLANs and Priorities
The extension builds on RFC 9892 and RFC 9893 to give credit-window flow control based on DLEP destinations, Ethernet Virtual Local Area Networks (VLANs) and Priority Code Points (PCPs). The IEEE 802.1Q tag format carries a 3-bit PCP field and a 12-bit VLAN Identifier (VID) field.
A credit window can be shared across traffic for several DLEP destinations, VLANs and PCPs, or dedicated to the traffic of one destination, VLAN and/or PCP. The extension also supports wildcard matching for any PCP or VID.
For a Diffserv-based approach to credit windows, the RFC points to RFC 9894. When both Diffserv and Ethernet classification apply to a flow, Ethernet-based classification takes precedence, as set out in Section 2.3.1 of RFC 9892.
Each kind of Ethernet label can get its own pile of tickets, or several labels can share one pile. A special wildcard label means any label at all.
- DLEP destinationTraffic for one destination or for several.
- VLAN (VID)A 12-bit VLAN Identifier; a wildcard can match any VID.
- Priority (PCP)A 3-bit Priority Code Point; a wildcard can match any PCP.
- Shared or dedicatedOne window for many flows, or one window per flow.
§3Announcing the Extension
To use the extension, an implementation MUST include the IEEE 802.1Q Aware Credit Window Extension Type value in the Extensions Supported Data Item defined in Section 13.6 of RFC 8175. That item is sent and processed as RFC 8175 describes. The Extension Type value is 5.
An implementation that signals the extension MUST support all message types, Data Items, the Ethernet Traffic Classification Sub-Data Item and the related processing defined in RFC 9892 and RFC 9893.
Before using the ticket system, each side says so out loud, using the number 5. If you say you play, you must know all the rules.
§4Management Considerations
Support for the extension MUST be declared with the Extensions Supported Data Item, which is configurable on both modems and routers. Use of the extension SHOULD be configurable on both sides. The extension's Data Items MUST NOT be emitted unless support was specified in the initialization message received from the peer.
Modems SHOULD support mapping a PCP to a credit window (queue) and MAY support doing so per VLAN. In traffic classification, VID 0x0000 means the VID is ignored, 0xFFFF is reserved, and values 0x0001 through 0xFFFE can be used. A modem that supports VLANs without PCPs SHOULD support mapping a VLAN to a credit window. Modems MAY let the operator configure how many credit windows they advertise.
Routers may be limited in the queues they can support, and per-destination queues may not be available. If the modem advertises more than the router can handle, the router SHOULD use a subset of the advertised windows, or MAY reset the session and indicate that the extension is not supported. Either way, the mismatch SHOULD be reported through standard network management means such as a user interface notice or an error log.
Whatever the implementation, when credit windows are in use the router MUST NOT send traffic to the modem unless sufficient credits are available.
The modem decides how many piles of tickets there are. If the router cannot handle that many, it uses only some of them, or starts over, and tells a person about it. It never sends without a ticket.
§5Security Considerations
The extension relies on DLEP and on the credit window mechanisms of RFC 9892 and RFC 9893, whose security sections also apply. It is exposed to threats like those against existing DLEP messages, for example an injected message that resizes a credit window to a value causing denial of service. The security mechanisms of RFC 8175 can be applied equally here.
Wildcards for PCP and VID fields can be convenient, but they could inadvertently match unexpected flows, or new flows that appear after the wildcard was set up. The RFC therefore RECOMMENDS that wildcards not be used unless clearly needed.
A trickster could send a fake message that shrinks the pile of tickets. Also, a wildcard label can grab more traffic than you meant, so use it only when you must.
§6IANA Code Point
IANA has assigned code 5, described as "IEEE 802.1Q Aware Credit Window", in the Extension Type Values registry within the Dynamic Link Exchange Protocol (DLEP) Parameters registry group. No other registrations are made.
The official list of extension numbers now has an entry, number 5, for this one.