rfc9895.original   rfc9895.txt 
MANET D. Wiggins Internet Engineering Task Force (IETF) D. Wiggins
Internet-Draft Request for Comments: 9895
Intended status: Standards Track L. Berger Category: Standards Track L. Berger
Expires: 25 September 2025 LabN Consulting, L.L.C. ISSN: 2070-1721 LabN Consulting, L.L.C.
D. Eastlake, Ed. D. Eastlake 3rd, Ed.
Independent Independent
24 March 2025 November 2025
DLEP IEEE 802.1Q Aware Credit Window Extension Dynamic Link Exchange Protocol (DLEP) IEEE 802.1Q Aware Credit Window
draft-ietf-manet-dlep-ether-credit-extension-09 Extension
Abstract Abstract
This document defines an extension to the Dynamic Link Exchange This document defines an extension to the Dynamic Link Exchange
Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit- Protocol (DLEP) that enables an Ethernet IEEE 802.1Q aware credit-
window scheme for destination-specific and shared flow control. window scheme for destination-specific and shared flow control.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 September 2025. 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 Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Key Words
2. Extension Usage and Identification . . . . . . . . . . . . . 3 2. Extension Usage and Identification
3. Management Considerations . . . . . . . . . . . . . . . . . . 4 3. Management Considerations
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References
6.1. Normative References . . . . . . . . . . . . . . . . . . 5 6.1. Normative References
6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses
1. Introduction 1. Introduction
The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
The protocol provides the exchange of link related control The protocol provides the exchange of link-related control
information between DLEP peers. DLEP peers consist of a modem and a 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 router. DLEP defines a base set of mechanisms as well as support for
possible extensions. This document defines one such extension. possible extensions. This document defines one such extension.
The DLEP specification does not define any flow control mechanisms. The DLEP specification does not define any flow control mechanisms.
While various flow control techniques could be theoretically While in theory various flow control techniques could be implemented
implemented with DLEP, this document specifies a DLEP extension that with DLEP, this document specifies a DLEP extension that introduces
introduces an Ethernet-based flow control mechanism for traffic an Ethernet-based flow control mechanism for traffic transmitted from
transmitted from a router to a modem. This mechanism utilizes one or a router to a modem. This mechanism utilizes one or more logical
more logical "Credit Windows", each of which is typically associated "Credit Windows", each of which is typically associated with a
with a virtual or physical queue. The router leverages traffic flow virtual or physical queue. The router leverages traffic flow
classification information provided by the modem to determine the classification information provided by the modem to determine the
appropriate credit window for a given traffic flow. Credit windows appropriate credit window for a given traffic flow. Credit windows
may be allocated on either a shared or a per-flow basis. For a may be allocated on either a shared or a per-flow basis. For a
DiffServ-based approach to credit window flow control, refer to Diffserv-based approach to credit window flow control, refer to
[I-D.ietf-manet-dlep-da-credit-extension]. As specified in [RFC9894]. As specified in Section 2.3.1 of [RFC9892], when both
Section 2.3.1 of [I-D.ietf-manet-dlep-traffic-classification], when Diffserv and Ethernet traffic classification are applied to a flow,
both DiffServ and Ethernet traffic classification are applied to a Ethernet-based classification takes precedence.
flow, Ethernet-based classification takes precedence.
This document leverages the traffic classification and credit window This document leverages the traffic classification and credit window
control mechanisms defined in control mechanisms defined in [RFC9892] and [RFC9893] to enable
[I-D.ietf-manet-dlep-traffic-classification] and credit-window-based flow control based on DLEP destinations, Ethernet
[I-D.ietf-manet-dlep-credit-flow-control] to enable credit window- Virtual Local Area Networks (VLANs), and Priority Code Points (PCPs).
based flow control based on DLEP destinations, Ethernet VLANs, and Ethernet PCP support is specified as part of the IEEE 802.1Q tag
Priority Code Points (PCPs). Ethernet PCP support is specified as format [IEEE8021Q], which includes a 3-bit "PCP" field. The tag
part of the IEEE 802.1Q [IEEE8021Q] tag format, which includes a format also incorporates a 12-bit "VLAN Identifier (VID)" field.
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 The defined mechanism allows credit windows to be shared across
traffic destined for multiple DLEP destinations, Virtual Local Area traffic destined for multiple DLEP destinations, VLANs, and PCPs, or
Networks (VLANs), and PCPs, or to be dedicated exclusively to traffic to be dedicated exclusively to traffic associated with a specific
associated with a specific destination, VLAN, and/or PCP. destination, VLAN, and/or PCP. Additionally, this extension supports
Additionally, this extension supports "wildcard" matching for any PCP "wildcard" matching for any PCP or VID.
or VID.
The extension defined in this document is referred to as "IEEE 802.1Q The extension defined in this document is referred to as the "IEEE
Aware Credit Window" or, more simply, the "Ethernet Credit" 802.1Q Aware Credit Window" or, more simply, the "Ethernet Credit"
extension. The reader should be familiar with both the traffic extension. The reader should be familiar with both the traffic
classification and credit window control mechanisms defined in classification and credit window control mechanisms defined in
[I-D.ietf-manet-dlep-traffic-classification] and [RFC9892] and [RFC9893].
[I-D.ietf-manet-dlep-credit-flow-control].
This document defines a new DLEP Extension Type Value in Section 2 This document defines a new DLEP Extension Type Value that is used to
which is used to indicate support for the extension. indicate support for the extension. See Section 2.
1.1. Key Words 1.1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Extension Usage and Identification 2. Extension Usage and Identification
The extension defined in this document is composed of the mechanisms The extension defined in this document is composed of the mechanisms
and processing defined in and processing defined in [RFC9892] and [RFC9893]. To indicate that
[I-D.ietf-manet-dlep-traffic-classification] and the IEEE 802.1Q Aware Credit Window Extension is to be used, an
[I-D.ietf-manet-dlep-credit-flow-control]. To indicate that the IEEE implementation MUST include the IEEE 802.1Q Aware Credit Window Type
802.1Q Aware Credit Window Extension is to be used, an implementation Value in the Extensions Supported Data Item (see Section 13.6 of
MUST include the IEEE 802.1Q Aware Credit Window Type Value in the [RFC8175]). The Extensions Supported Data Item is sent and processed
Extensions Supported Data Item. The Extensions Supported Data Item according to [RFC8175]. Any implementation that indicates the use of
is sent and processed according to [RFC8175]. Any implementation the IEEE 802.1Q Aware Credit Window Extension MUST support all
that indicates use of the IEEE 802.1Q Aware Credit Window Extension message types, Data Items, the Ethernet Traffic Classification Sub-
MUST support all Messages, Data Items, the Ethernet Traffic Data Item, and all related processing defined in [RFC9892] and
Classification Sub-Data Item, and all related processing defined in [RFC9893].
[I-D.ietf-manet-dlep-traffic-classification] and
[I-D.ietf-manet-dlep-credit-flow-control].
The IEEE 802.1Q Aware Credit Window Extension Type Value is TBA1, see The IEEE 802.1Q Aware Credit Window Extension Type Value is 5. See
Section 5. Section 5.
3. Management Considerations 3. Management Considerations
This section provides several network management guidelines to This section provides several network management guidelines for
implementations supporting the IEEE 802.1Q Aware Credit Window implementations supporting the IEEE 802.1Q Aware Credit Window
Extension. Extension.
If this extension is supported, that support MUST be declared using If this extension is supported, that support MUST be declared using
the Extensions Supported Data Item (see Section 13.6 of [RFC8175]) the Extensions Supported Data Item (see Section 13.6 of [RFC8175]),
which is configurable on both modems and routers. DiffServ Aware which is configurable on both modems and routers. Diffserv Aware
Credit Window Extension Data Items MUST NOT be emitted by a DLEP Credit Window Extension Data Items MUST NOT be emitted by a DLEP
participant unless such support was specified in the initialization participant unless such support was specified in the initialization
message received from its peer. The use of the extension defined in message received from its peer. The use of the extension defined in
this document SHOULD be configurable on both modems and routers. this document SHOULD be configurable on both modems and routers.
Modems SHOULD support the configuration of PCP to credit window Modems SHOULD support the configuration of mapping a PCP to a credit
(queue) mapping. window (queue).
Modems MAY support the configuration of PCP to credit window (queue) Modems MAY support the configuration of mapping a PCP to a credit
mapping on a per VLAN basis. VID value zero (0) is used by window (queue) on a per-VLAN basis. VID value zero (0) is used by
[I-D.ietf-manet-dlep-traffic-classification] to indicate that VID is [RFC9892] to indicate that the VID is ignored and any VID value is
ignored and any VID value is used in traffic classification. used in traffic classification.
When VLANs are supported by a modem without support from PCPs, the When VLANs are supported by a modem without support from PCPs, the
modem SHOULD support the configuration of VLAN to credit window modem SHOULD support the configuration of mapping a VLAN to a credit
(queue) mapping. window (queue).
Modems MAY support configuration of the number of credit windows Modems MAY support the configuration of the number of credit windows
(queues) that they advertise to a router. (queues) that they advertise to a router.
Routers may impose limitations on the number of queues they can Routers may impose limitations on the number of queues they can
support and on the allowable credit window configurations. In some support and on the allowable credit window configurations. In some
cases, per-destination queues may not be supported. If the credit cases, per-destination queues may not be supported. If the credit
window information provided by the modem exceeds the router's window information provided by the modem exceeds the router's
capabilities, the router SHOULD utilize a subset of the advertised capabilities, the router SHOULD utilize a subset of the advertised
credit windows. Alternatively, the router MAY reset the session and credit windows. Alternatively, the router MAY reset the session and
indicate that the extension is not supported. In either case, any indicate that the extension is not supported. In either case, any
mismatch in capabilities SHOULD be reported to the user through mismatch in capabilities SHOULD be reported to the user through
standard network management mechanisms, such as user interface standard network management mechanisms, such as user interface
notifications or error logging. notifications or error logging.
Regardless of implementation, if credit windows are in use, the Regardless of implementation, if credit windows are in use, the
router MUST NOT send traffic to the modem unless sufficient credits router MUST NOT send traffic to the modem unless sufficient credits
are available. are available.
4. Security Considerations 4. Security Considerations
This document defines a DLEP extension that uses DLEP mechanisms and This document defines a DLEP extension that uses DLEP mechanisms and
the credit window control and flow mechanisms defined in the credit window control and flow mechanisms defined in [RFC9892]
[I-D.ietf-manet-dlep-traffic-classification] and and [RFC9893]. See also the Security Considerations sections of
[I-D.ietf-manet-dlep-credit-flow-control]. See also the Security those documents.
Considerations sections of those documents.
The defined extension is exposed to vulnerabilities similar to The defined extension is exposed to vulnerabilities similar to
existing DLEP messages and discussed in the Security Considerations existing DLEP messages and discussed in the Security Considerations
section of [RFC8175] such as an injected message resizing a credit section of [RFC8175], such as an injected message resizing a credit
window to a value that results in a denial of service. The security window to a value that results in a denial of service. The security
mechanisms documented in [RFC8175] can be applied equally to the mechanisms documented in [RFC8175] can be applied equally to the
mechanism defined in this document. mechanism defined in this document.
Wildcards for matching PCP and VID fields are provided which may be Wildcards for matching PCP and VID fields are provided. Note that
convenient to match a number of packet flows but could inadvertently wildcards may be convenient for matching a number of packet flows but
match unexpected flows or new flows that appear after the wildcard could inadvertently match unexpected flows or new flows that appear
matching has been set up. It is therefore RECOMMENDED that wildcards after the wildcard matching has been set up. It is therefore
not be used unless clearly needed. RECOMMENDED that wildcards not be used unless clearly needed.
5. IANA Considerations 5. IANA Considerations
IANA is requested to assign one code point in the "Extension Type IANA has assigned the following code point in the "Extension Type
Values" registry in the "Dynamic Link Exchange Protocol (DLEP) Values" registry in the "Dynamic Link Exchange Protocol (DLEP)
Parameters" registry group as follows: Parameters" registry group:
+======+=================================+ +======+=================================+
| Code | Description | | Code | Description |
+======+=================================+ +======+=================================+
| TBA1 | IEEE 802.1Q Aware Credit Window | | 5 | IEEE 802.1Q Aware Credit Window |
+------+---------------------------------+ +------+---------------------------------+
Table 1: Requested Extension Type Value Table 1: Extension Type Value
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-manet-dlep-credit-flow-control]
Cheng, B., Wiggins, D., Berger, L., Ratliff, S., and E.
Kinzie, "Dynamic Link Exchange Protocol (DLEP) Credit-
Based Flow Control Messages and Data Items", Work in
Progress, Internet-Draft, draft-ietf-manet-dlep-credit-
flow-control, 3 January 2025,
<https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-
credit-flow-control>.
[I-D.ietf-manet-dlep-traffic-classification]
Cheng, B., Wiggins, D., Berger, L., and D. Fedyk, "Dynamic
Link Exchange Protocol (DLEP) Traffic Classification Data
Item", Work in Progress, Internet-Draft, draft-ietf-manet-
dlep-traffic-classification, 19 November 2024,
<https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-
traffic-classification>.
[IEEE8021Q] [IEEE8021Q]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Bridges and Bridged Networks", Networks--Bridges and Bridged Networks",
DOI 10.1109/IEEESTD.2022.10004498, IEEE 802.1Q-2022, July DOI 10.1109/IEEESTD.2022.10004498, IEEE Std 802.1Q-2022,
2022, <https://ieeexplore.ieee.org/document/8403927>. December 2022,
<https://ieeexplore.ieee.org/document/10004498>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017, DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>. <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,
November 2025, <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, November 2025,
<https://www.rfc-editor.org/info/rfc9893>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-manet-dlep-da-credit-extension] [RFC9894] Cheng, B., Wiggins, D., Berger, L., and D. Eastlake 3rd,
Cheng, B., Wiggins, D., Berger, L., and D. E. Eastlake, Ed., "Dynamic Link Exchange Protocol (DLEP) Diffserv Aware
"DLEP DiffServ Aware Credit Window Extension", Work in Credit Window Extension", RFC 9894, DOI 10.17487/RFC9894,
Progress, Internet-Draft, draft-ietf-manet-dlep-da-credit- November 2025, <https://www.rfc-editor.org/info/rfc9894>.
extension, 15 December 2024,
<https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-
da-credit-extension/>.
Appendix A. Acknowledgments Acknowledgments
The document was motivated by discussions in the MANET working group. This document was motivated by discussions in the MANET Working
Many useful comments were received from contributors to the MANET Group. Many useful comments were received from contributors to the
working group, notably Ronald in't Velt. MANET Working Group, notably Ronald in 't Velt.
We had the honor of working too briefly with David Wiggins on this We had the honor of working too briefly with David Wiggins on this
and related DLEP work. His contribution to the IETF and publication and related DLEP work. His contribution to the IETF and publication
of the first and definitive open source DLEP implementation have been of the first and definitive open-source DLEP implementation have been
critical to the acceptance of DLEP. We mourn his passing on November critical to the acceptance of DLEP. We mourn his passing on November
23, 2023. We wish to recognize his guidance, leadership and 26, 2023. We wish to recognize his guidance, leadership, and
professional excellence. We were fortunate to benefit from his professional excellence. We were fortunate to benefit from his
leadership and friendship. He shall be missed. leadership and friendship. He shall be missed.
Authors' Addresses Authors' Addresses
David Wiggins David Wiggins
Email: david@none.org
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Email: lberger@labn.net Email: lberger@labn.net
Donald E. Eastlake 3rd (editor) Donald E. Eastlake 3rd (editor)
Independent Independent
2386 Panoramic Circle 2386 Panoramic Circle
Apopka, Florida 32703 Apopka, FL 32703
United States of America United States of America
Phone: +1-508-333-2270 Phone: +1-508-333-2270
Email: d3e3e3@gmail.com Email: d3e3e3@gmail.com
 End of changes. 42 change blocks. 
144 lines changed or deleted 125 lines changed or added

This html diff was produced by rfcdiff 1.48.