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 対応クレジット ウィンドウ拡張
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.

この文書は、宛先固有の共有フロー制御のためのイーサネット IEEE 802.1Q 対応クレジット ウィンドウ スキームを有効にする Dynamic Link Exchange Protocol (DLEP) の拡張機能を定義します。

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.

このドキュメントは 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/rfc9895.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9895 で入手できます。

著作権表示

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 ライセンスに記載されているように保証なしで提供されます。

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
1. はじめに

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 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.

DLEP 仕様では、フロー制御メカニズムは定義されていません。理論的には、DLEP を使用してさまざまなフロー制御手法を実装できますが、このドキュメントでは、ルータからモデムに送信されるトラフィックに対するイーサネット ベースのフロー制御メカニズムを導入する DLEP 拡張機能を指定します。このメカニズムは、1 つ以上の論理「クレジット ウィンドウ」を利用し、通常、それぞれが仮想キューまたは物理キューに関連付けられます。ルータは、モデムによって提供されるトラフィック フロー分類情報を利用して、特定のトラフィック フローに適切なクレジット ウィンドウを決定します。クレジット ウィンドウは、複数のフロー間で共有したり、フローごとに使用したりできます。クレジット ウィンドウ フロー制御に対する Diffserv ベースのアプローチについては、[RFC9894] を参照してください。[RFC9892] のセクション 2.3.1 に規定されているように、Diffserv とイーサネットの両方のトラフィック分類がフローに適用される場合、イーサネットベースの分類が優先されます。

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.

この文書は、[RFC9892] および [RFC9893] で定義されているトラフィック分類およびクレジット ウィンドウのフロー制御メカニズムを利用して、DLEP 宛先、イーサネット仮想ローカル エリア ネットワーク (VLAN)、および優先コード ポイント (PCP) に基づいたクレジット ウィンドウ ベースのフロー制御を可能にします。イーサネット PCP サポートは、3 ビットの「PCP」フィールドを含む IEEE 802.1Q タグ形式 [IEEE8021Q] の一部として指定されています。タグ形式には、12 ビットの「VLAN 識別子 (VID)」フィールドも組み込まれています。

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.

定義されたメカニズムにより、クレジット ウィンドウを複数の DLEP 宛先、VLAN、および PCP 宛てのトラフィック間で共有したり、特定の宛先、VLAN、PCP に関連付けられたトラフィック専用にすることができます。さらに、この拡張機能は、任意の PCP または 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].

この文書で定義されている拡張は、「IEEE 802.1Q Aware Credit Window」、またはより簡単に「Ethernet 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 を参照してください。

1.1. Key Words
1.1. キーワード

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] で説明されているように解釈されます。

2. Extension Usage and Identification
2. 拡張機能の使用法と識別

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].

この文書で定義されている拡張機能は、[RFC9892] および [RFC9893] で定義されているメカニズムと処理に基づいて構築されています。IEEE 802.1Q Aware Credit Window Extension が使用されることを示すために、実装は Extensions Supported Data 項目に IEEE 802.1Q Aware Credit Window Extension Type の値を含めなければなりません ([RFC8175] のセクション 13.6 を参照)。拡張機能がサポートするデータ項目は、[RFC8175] に従って送信および処理されます。IEEE 802.1Q Aware Credit Window Extension の使用を示す実装は、すべてのメッセージ タイプ、データ項目、イーサネット トラフィック分類サブデータ項目、および [RFC9892] および [RFC9893] で定義されているすべての関連処理をサポートしなければなりません (MUST)。

The IEEE 802.1Q Aware Credit Window Extension Type value is 5. See Section 5.

IEEE 802.1Q Aware Credit Window Extension Type の値は 5 です。セクション 5 を参照してください。

3. Management Considerations
3. 管理上の考慮事項

This section provides several network management guidelines for implementations supporting the IEEE 802.1Q Aware Credit Window Extension.

このセクションでは、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.

この拡張がサポートされている場合、そのサポートは、モデムとルーターの両方で設定可能な拡張サポート データ項目 ([RFC8175] のセクション 13.6 を参照) を使用して宣言しなければなりません (MUST)。Diffserv 対応のクレジット ウィンドウ拡張データ項目は、ピアから受信した初期化メッセージでそのようなサポートが指定されていない限り、DLEP 参加者によって発行されてはなりません (MUST NOT)。この文書で定義されている拡張機能の使用は、モデムとルーターの両方で設定可能であるべきです(SHOULD)。

Modems SHOULD support the configuration of mapping a PCP to a credit window (queue).

モデムは、PCP をクレジット ウィンドウ (キュー) にマッピングする構成をサポートすべきです(SHOULD)。

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.

モデムは、VLAN ごとに PCP をクレジット ウィンドウ (キュー) にマッピングする設定をサポートしてもよい(MAY)。VID 値ゼロ (0x0000) は、VID が無視されることを示すために [RFC9892] で使用されます。VID 0xFFFF is reserved.0x0001 ~ 0xFFFE の他の VID 値はトラフィック分類に使用できます。

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).

PCP からのサポートがなくてもモデムによって VLAN がサポートされている場合、モデムは VLAN をクレジット ウィンドウ (キュー) にマッピングする構成をサポートすべきである(SHOULD)。

Modems MAY support the configuration of the number of credit windows (queues) that they advertise to a router.

モデムは、ルーターにアドバタイズするクレジット ウィンドウ (キュー) の数の設定をサポートしてもよい(MAY)。

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.

ルーターは、サポートできるキューの数と許容されるクレジット ウィンドウ構成に制限を課す場合があります。場合によっては、宛先ごとのキューがサポートされない場合があります。モデムによって提供されるクレジット ウィンドウ情報がルータの能力を超える場合、ルータはアドバタイズされたクレジット ウィンドウのサブセットを利用すべきです(SHOULD)。あるいは、ルーターはセッションをリセットし、拡張機能がサポートされていないことを示してもよい(MAY)。いずれの場合も、機能の不一致は、ユーザー インターフェイス通知やエラー ログなどの標準のネットワーク管理メカニズムを通じてユーザーに報告される必要があります (SHOULD)。

Regardless of implementation, if credit windows are in use, the router MUST NOT send traffic to the modem unless sufficient credits are available.

実装に関係なく、クレジット ウィンドウが使用されている場合、ルーターは十分なクレジットが利用可能でない限り、トラフィックをモデムに送信してはなりません (MUST NOT)。

4. Security Considerations
4. セキュリティに関する考慮事項

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 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.

PCP フィールドと VID フィールドを照合するためのワイルドカードが提供されます。ワイルドカードは、多数のパケット フローを照合する場合に便利ですが、予期しないフローや、ワイルドカード 照合が設定された後に表示される新しいフローと誤って照合してしまう可能性があることに注意してください。したがって、明確に必要な場合を除き、ワイルドカードを使用しないことが推奨されます。

5. IANA Considerations
5. IANAの考慮事項

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                     |
                +======+=================================+
                | 5    | IEEE 802.1Q Aware Credit Window |
                +------+---------------------------------+
        

Table 1: Extension Type Value

表 1: 拡張タイプの値

6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献
   [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
6.2. 参考引用
   [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.

この文書は、MANET ワーキング グループでの議論に基づいて作成されました。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 日に彼の逝去を悼みます。私たちは彼の指導、リーダーシップ、そして専門的な卓越性を讃えたいと考えています。私たちは彼のリーダーシップと友情の恩恵を受けることができて幸運でした。彼は寂しくなるだろう。

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