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
ISO Plain Language
On this page
§1Introduction
The Dynamic Link Exchange Protocol is defined in RFC 8175 and 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, and 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 uses the 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, the reader is referred to RFC 9894. As specified in Section 2.3.1 of RFC 9892, 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 RFC 9892 and RFC 9893 to enable credit-window-based flow control based on DLEP destinations, Ethernet Virtual Local Area Networks, and Priority Code Points. Ethernet PCP support is specified as part of the IEEE 802.1Q tag format, which includes a 3-bit PCP field, and the tag format also incorporates a 12-bit VLAN Identifier 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 or priority code point. The extension also supports wildcard matching for any PCP or VID. The extension is referred to as the IEEE 802.1Q Aware Credit Window, or more simply the Ethernet Credit extension.
A credit window is an allowance to send a certain amount of data. The modem decides how many windows it has, the router decides which window each flow belongs to, and the router sends only while an allowance remains. This document decides that the flow is identified by the fields in the Ethernet frame's tag: the three-bit priority code point that says how urgent the frame is, and the twelve-bit identifier that says which virtual network it belongs to.
- Credit windowAn allowance to send a certain amount of data, usually tied to one queue.
- Traffic classificationInformation the modem provides so the router can tell which credit window a flow belongs to.
- Priority Code PointThe three-bit field in the IEEE 802.1Q tag that carries the priority of an Ethernet frame.
- VLAN IdentifierThe twelve-bit field in the IEEE 802.1Q tag that names the virtual network the frame belongs to.
- WildcardA setting that matches any priority code point or any VLAN identifier.
§2Extension Usage and Identification
The extension defined in this document is built on the mechanisms and processing defined in RFC 9892 and RFC 9893. To indicate that the IEEE 802.1Q Aware Credit Window Extension is to be used, an implementation must include the extension type value in the Extensions Supported Data Item of RFC 8175. The Extensions Supported Data Item is sent and processed according to RFC 8175. Any implementation that indicates the use of the extension must support all message types, Data Items, the Ethernet Traffic Classification Sub-Data Item, and all related processing defined in RFC 9892 and RFC 9893.
The IEEE 802.1Q Aware Credit Window Extension Type value is 5.
Both ends have to agree to use this before anything is exchanged. The router announces at session start that it supports the extension, by listing the extension type in the data item that lists supported extensions. Once it has said so, it has to handle everything the underlying DLEP extensions define, not just the parts it finds useful.
- EXTENSIONS SUPPORTEDThe router lists the IEEE 802.1Q Aware Credit Window extension type, 5.
- CREDIT WINDOWSThe modem advertises its windows and the classification that maps traffic to them.
- TRAFFICThe router sends only while credits remain for the matching window.
§3Management Considerations
If this extension is supported, that support must be declared using the Extensions Supported Data Item, 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 priority code point to a credit window. Modems may support the configuration of mapping a priority code point to a credit window on a per-VLAN basis. The VID value zero is used by RFC 9892 to indicate that the VID is ignored, the VID 0xFFFF is reserved, and any other 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. Modems may support the configuration of the number of credit windows 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, and 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 use 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, a 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.
The configuration decides which flows share an allowance. A modem should be able to map a priority to a window, and where VLANs are supported it should be able to map a VLAN to a window as well. A router may be able to handle fewer windows than the modem offers, in which case it uses what it can and tells the operator about the mismatch. The one rule that always applies is that the router sends nothing when there is no credit left.
| Configuration | Status |
|---|---|
| Extension support declared in the Extensions Supported Data Item | Must be declared if the extension is supported |
| Diffserv Aware Credit Window Data Items | Must not be emitted unless the peer asked for that support |
| Mapping a priority code point to a credit window | Modems should support it |
| Mapping a priority code point to a credit window per VLAN | Optional for modems |
| Mapping a VLAN to a credit window | Modems should support it where VLANs are supported without PCP support |
| Number of credit windows advertised to the router | Optional for modems |
§4Security Considerations
This document defines a DLEP extension that uses DLEP mechanisms and the credit window flow control mechanisms defined in RFC 9892 and RFC 9893. The defined extension is exposed to vulnerabilities similar to existing DLEP messages and discussed in the Security Considerations section of RFC 8175, such as an injected message resizing a credit window to a value that results in a denial of service. The security mechanisms documented in RFC 8175 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.
The same care applies as for the rest of DLEP: an injected message could resize a credit window and cause a denial of service, and the protections DLEP already defines are used here too. The document also warns about the wildcard setting: a rule that matches any priority or any virtual network will also catch flows that nobody expected it to catch, including ones that appear later, so wildcards should be used only when they are clearly needed.
§5IANA Considerations
IANA has assigned the code point 5 in the Extension Type Values registry of the Dynamic Link Exchange Protocol Parameters registry group to the IEEE 802.1Q Aware Credit Window.
The document asks IANA to record the extension type number that a router lists when it says it supports this feature, so that modems and routers agree on one number.