Internet Engineering Task Force (IETF) B. Cheng
Request for Comments: 9894 MIT Lincoln Laboratory
Category: Standards Track D. Wiggins
ISSN: 2070-1721
L. Berger
LabN Consulting, L.L.C.
D. Eastlake 3rd, Ed.
Independent
January 2026
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a Diffserv aware credit window scheme for destination-specific and shared flow control.
この文書は、宛先固有の共有フロー制御のための Diffserv 対応クレジット ウィンドウ スキームを有効にする Dynamic Link Exchange Protocol (DLEP) の拡張機能を定義します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。インターネット標準の詳細については、RFC 7841 のセクション 2 を参照してください。
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/rfc9894.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9894 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
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
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.
Dynamic Link Exchange Protocol (DLEP) は [RFC8175] で定義されています。このプロトコルは、DLEP ピア間のリンク関連の制御情報の交換を提供します。DLEP ピアはモデムとルーターで構成されます。DLEP は、メカニズムの基本セットと、可能な拡張機能のサポートを定義します。このドキュメントでは、そのような拡張機能の 1 つを定義します。
The DLEP specification does not include any flow control capability. Various flow control techniques are theoretically possible with DLEP. This document defines a DLEP extension that provides a Diffserv-based flow control mechanism for traffic sent from a router to a modem. Flow control is provided using one or more logical "credit windows", each of which will typically be supported by an associated virtual or physical queue. A router will use traffic flow classification information provided by the modem to identify which traffic is associated with each credit window. Credit windows may be shared or dedicated on a per-flow basis. See [RFC9895] for an Ethernet-based version of credit window flow control. As specified in Section 2.3.1 of [RFC9892], when both Diffserv and Ethernet traffic classification are specified for a flow, the Ethernet information takes precedence.
DLEP 仕様にはフロー制御機能は含まれていません。DLEP では理論的にはさまざまなフロー制御技術が可能です。この文書では、ルーターからモデムに送信されるトラフィックに Diffserv ベースのフロー制御メカニズムを提供する DLEP 拡張機能を定義します。フロー制御は 1 つ以上の論理「クレジット ウィンドウ」を使用して提供され、通常、それぞれのクレジット ウィンドウは関連する仮想キューまたは物理キューによってサポートされます。ルーターは、モデムによって提供されるトラフィック フロー分類情報を使用して、どのトラフィックが各クレジット ウィンドウに関連付けられているかを識別します。クレジット ウィンドウは、フローごとに共有または専用にすることができます。クレジット ウィンドウ フロー制御のイーサネット ベースのバージョンについては、[RFC9895] を参照してください。[RFC9892] のセクション 2.3.1 に規定されているように、フローに対して Diffserv とイーサネットの両方のトラフィック分類が指定されている場合、イーサネット情報が優先されます。
This document uses the traffic classification and credit window flow control mechanisms defined in [RFC9892] and [RFC9893] to provide credit-window-based flow control based on DLEP destinations and Differentiated Services Code Points (DSCPs) [RFC2475]. The defined mechanism allows for credit windows to be shared across traffic sent to multiple DLEP destinations and DSCPs, or used exclusively for traffic sent to a particular destination and/or DSCP. The extension also supports the "wildcard" matching of any DSCP.
この文書は、[RFC9892] および [RFC9893] で定義されているトラフィック分類およびクレジット ウィンドウのフロー制御メカニズムを使用して、DLEP 宛先と DSCP (Differentiated Services Code Points) [RFC2475] に基づいたクレジット ウィンドウ ベースのフロー制御を提供します。定義されたメカニズムにより、クレジット ウィンドウを複数の DLEP 宛先および DSCP に送信されるトラフィック間で共有したり、特定の宛先や DSCP に送信されたトラフィックにのみ使用したりすることができます。この拡張機能は、DSCP の「ワイルドカード」マッチングもサポートしています。
The extension defined in this document is referred to as the "Diffserv Aware Credit Window" or, more simply, the "DA Credit" extension. The reader should be familiar with both the traffic classification and credit window flow control mechanisms defined in [RFC9892] and [RFC9893].
この文書で定義されている拡張機能は、「Diffserv Aware Credit Window」またはより簡単に「DA Credit」拡張機能と呼ばれます。読者は、[RFC9892] および [RFC9893] で定義されているトラフィック分類とクレジット ウィンドウのフロー制御メカニズムの両方に精通している必要があります。
This document defines a new DLEP Extension Type value that is used to indicate support for the extension. See Section 2.
この文書では、拡張機能のサポートを示すために使用される新しい DLEP 拡張タイプの値を定義します。セクション 2 を参照してください。
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.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The extension defined in this document is built on the mechanisms and processing defined in [RFC9892] and [RFC9893]. To indicate that the Diffserv Aware Credit Window Extension is to be used, an implementation MUST include the Diffserv 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 Diffserv Aware Credit Window Extension MUST support all message types, Data Items, the Diffserv Traffic Classification Sub-Data Item, and all related processing defined in [RFC9892] and [RFC9893].
この文書で定義された拡張機能は、[RFC9892] および [RFC9893] で定義されたメカニズムと処理に基づいて構築されています。Diffserv Aware Credit Window Extension が使用されることを示すために、実装は Extensions Supported Data 項目に Diffserv Aware Credit Window Extension Type の値を含めなければなりません ([RFC8175] のセクション 13.6 を参照)。拡張機能がサポートするデータ項目は、[RFC8175] に従って送信および処理されます。Diffserv Aware Credit Window Extension の使用を示す実装は、すべてのメッセージ タイプ、データ項目、Diffserv トラフィック分類サブデータ項目、および [RFC9892] および [RFC9893] で定義されているすべての関連処理をサポートしなければなりません (MUST)。
The Diffserv Aware Credit Window Extension Type value is 6. See Section 5.
Diffserv Aware Credit Window Extension Type の値は 6 です。セクション 5 を参照してください。
This section provides several network management guidelines for implementations supporting the Diffserv Aware Credit Window Extension.
このセクションでは、Diffserv 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]). 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. That configuration can be implemented using a proprietary Command-Line Interface or by implementing a YANG module. The definition of the YANG module is out of scope for this document.
この拡張がサポートされている場合、そのサポートは拡張サポート データ項目を使用して宣言しなければなりません ([RFC8175] のセクション 13.6 を参照)。Diffserv 対応のクレジット ウィンドウ拡張データ項目は、ピアから受信した初期化メッセージでそのようなサポートが指定されていない限り、DLEP 参加者によって発行されてはなりません (MUST NOT)。この文書で定義されている拡張機能の使用は、モデムとルーターの両方で設定可能であるべきです(SHOULD)。この構成は、独自のコマンドライン インターフェイスを使用するか、YANG モジュールを実装することによって実装できます。YANG モジュールの定義は、このドキュメントの範囲外です。
Modems SHOULD support the configuration of mapping a DSCP to a credit window (queue).
モデムは、DSCP をクレジット ウィンドウ (キュー) にマッピングする設定をサポートすべきです (SHOULD)。
Modems MAY support the configuration of the number of credit windows (queues) to advertise to a router.
モデムは、ルーターにアドバタイズするためのクレジット ウィンドウ (キュー) の数の設定をサポートしてもよい(MAY)。
Routers may have limits on the number of queues that they can support and limits on supported credit window combinations. Per-destination queues might not be supported at all. 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. Alternatively, a 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 via normal network management mechanisms, such as user interface messages or error logging.
ルーターには、サポートできるキューの数に制限があり、サポートされるクレジット ウィンドウの組み合わせに制限がある場合があります。宛先ごとのキューはまったくサポートされない可能性があります。モデムによって提供されるクレジット ウィンドウ情報がルーターの能力を超える場合、ルーターは提供されたクレジット ウィンドウのサブセットを使用すべきです(SHOULD)。あるいは、ルーターはセッションをリセットし、拡張機能がサポートされていないことを示してもよい(MAY)。いずれの場合も、機能の不一致は、ユーザー インターフェイス メッセージやエラー ログなどの通常のネットワーク管理メカニズムを介してユーザーに報告されるべきです(SHOULD)。
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.
どのような場合でも、クレジット ウィンドウが使用されている場合、クレジットが利用できないトラフィックをルーターによってモデムに送信してはなりません (MUST NOT)。
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.
この文書は、[RFC9892] および [RFC9893] で定義されている DLEP メカニズムとクレジット ウィンドウ フロー制御メカニズムを使用する DLEP 拡張を定義します。これらのドキュメントの「セキュリティに関する考慮事項」セクションも参照してください。
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.
定義された拡張機能は、既存の DLEP メッセージと同様の脆弱性にさらされており、[RFC8175] のセキュリティに関する考慮事項セクションで説明されています。たとえば、挿入されたメッセージによってクレジット ウィンドウのサイズが変更され、サービス拒否が発生するなどの脆弱性があります。[RFC8175] に文書化されているセキュリティメカニズムは、この文書で定義されているメカニズムに同様に適用できます。
Wildcards for matching Priority Code Point (PCP) and VLAN Identifier (VID) fields (see [RFC9895]) 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 needed.
Priority Code Point (PCP) フィールドと VLAN Identifier (VID) フィールドを照合するためのワイルドカードが提供されています ([RFC9895] を参照)。ワイルドカードは、多数のパケット フローを照合する場合に便利ですが、予期しないフローや、ワイルドカード 照合が設定された後に表示される新しいフローと誤って照合してしまう可能性があることに注意してください。したがって、必要な場合を除き、ワイルドカードを使用しないことが推奨されます。
IANA has assigned the following code point in the "Extension Type Values" registry in the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry group:
IANA は、「Dynamic Link Exchange Protocol (DLEP) Parameters」レジストリ グループの「Extension Type Values」レジストリに次のコード ポイントを割り当てました。
+======+==============================+
| Code | Description |
+======+==============================+
| 6 | Diffserv Aware Credit Window |
+------+------------------------------+
Table 1: Extension Type Value
表 1: 拡張タイプの値
[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>.
[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>.
[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>.
Many useful comments were received from contributors to the MANET Working Group, notably Ronald in 't Velt.
MANET ワーキング グループの貢献者、特に 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.
私たちは、この DLEP 作業および関連する DLEP 作業に関して、David Wiggins と短時間の間協力することができて光栄でした。IETF への彼の貢献と、最初で決定的なオープンソース DLEP 実装の公開は、DLEP が受け入れられるために重要でした。私たちは、2023 年 11 月 26 日に彼の逝去を悼みます。私たちは彼の指導、リーダーシップ、そして専門的な卓越性を讃えたいと考えています。私たちは彼のリーダーシップと友情の恩恵を受けることができて幸運でした。彼がいなくなると寂しくなるだろう。
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
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