Internet Engineering Task Force (IETF) B. Cheng
Request for Comments: 9892 MIT Lincoln Laboratory
Category: Standards Track D. Wiggins
ISSN: 2070-1721
L. Berger
D. Fedyk, Ed.
LabN Consulting, L.L.C.
January 2026
This document defines a new Data Item for the Dynamic Link Exchange Protocol (DLEP) to support traffic classification. Traffic classification information identifies traffic flows based on frame/ packet content such as a destination address. The Data Item is defined in an extensible and reusable fashion. Its use will be mandated in other documents defining specific DLEP extensions. This document also introduces DLEP Sub-Data Items and defines two new Sub-Data Items to support Diffserv and Ethernet traffic classification.
この文書は、トラフィック分類をサポートするために、Dynamic Link Exchange Protocol (DLEP) の新しいデータ項目を定義します。トラフィック分類情報は、宛先アドレスなどのフレーム/パケットの内容に基づいてトラフィック フローを識別します。データ項目は、拡張可能で再利用可能な方法で定義されます。その使用は、特定の DLEP 拡張機能を定義する他の文書で義務付けられます。このドキュメントでは、DLEP サブデータ項目も紹介し、Diffserv およびイーサネット トラフィック分類をサポートする 2 つの新しいサブデータ項目を定義します。
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/rfc9892.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9892 で入手できます。
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. Traffic Classification
2.1. Traffic Classification Data Item
2.1.1. Traffic Classification Sub-Data Item
2.2. Diffserv Traffic Classification Sub-Data Item
2.2.1. Router Receive Processing
2.3. Ethernet Traffic Classification Sub-Data Item
2.3.1. Router Receive Processing
3. Compatibility
4. Security Considerations
5. IANA Considerations
5.1. Data Item Type Values
5.2. Traffic Classification Sub-Data Item Type Values
5.3. Registration Guidance
6. References
6.1. Normative References
6.2. Informative References
Acknowledgments
Authors' Addresses
The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. This protocol provides the exchange of link-related control information between DLEP peers. DLEP peers are comprised of a modem and a router. DLEP defines a base set of mechanisms as well as support for possible extensions. DLEP defines Data Items, which are sets of information that can be reused in DLEP messaging. The DLEP specification does not include any flow identification beyond DLEP endpoints, i.e., flows are identified based on their DLEP endpoint.
Dynamic Link Exchange Protocol (DLEP) は [RFC8175] で定義されています。このプロトコルは、DLEP ピア間のリンク関連の制御情報の交換を提供します。DLEP ピアはモデムとルーターで構成されます。DLEP は、メカニズムの基本セットと、可能な拡張機能のサポートを定義します。DLEP は、DLEP メッセージングで再利用できる情報のセットであるデータ項目を定義します。DLEP 仕様には、DLEP エンドポイントを超えるフロー識別は含まれていません。つまり、フローは DLEP エンドポイントに基づいて識別されます。
This document defines DLEP Data Item formats that provide flow identification on a more granular basis. Specifically, it enables a router to use traffic flow classification information provided by the modem to identify traffic flows based on a combination of information found in a data plane header. (For general background on traffic classification, see Section 2.3 of [RFC2475].) The Data Item is structured to allow for the use of the defined traffic classification information with applications such as credit window flow control as specified in [RFC9893]. [RFC9893] provides an example of combining traffic classification and credit window flow control.
この文書は、より詳細なベースでフロー識別を提供する DLEP データ項目形式を定義します。具体的には、ルーターがモデムによって提供されるトラフィック フロー分類情報を使用して、データ プレーン ヘッダーに含まれる情報の組み合わせに基づいてトラフィック フローを識別できるようにします。(トラフィック分類の一般的な背景については、[RFC2475] のセクション 2.3 を参照してください。) データ項目は、[RFC9893] で規定されているクレジット ウィンドウ フロー制御などのアプリケーションで、定義されたトラフィック分類情報を使用できるように構造化されています。[RFC9893] は、トラフィック分類とクレジット ウィンドウ フロー制御を組み合わせる例を提供しています。
This document defines traffic classification based on a DLEP destination and flows identified by either Differentiated Services Code Points (DSCPs) [RFC2475] or IEEE 802.1Q Ethernet Priority Code Points (PCPs) [IEEE8021Q]. The defined mechanism allows for flows to be described in a flexible fashion and, when combined with applications such as credit window flow control, allows credit windows to be (1) shared across traffic sent to multiple DLEP destinations and as part of multiple flows or (2) used exclusively for traffic sent to a particular destination and/or belonging to a particular flow. The extension also supports the "wildcard" matching of any flow (DSCP or PCP). Traffic classification information is provided such that it can be readily extended to support other traffic classification techniques or can be used by extensions that are not related to credit windows, such as the extension defined in [RFC8651] or even 5-tuple IP flows.
この文書は、DLEP 宛先と、Differentiated Services Code Points (DSCP) [RFC2475] または IEEE 802.1Q Ethernet Priority Code Points (PCP) [IEEE8021Q] のいずれかによって識別されるフローに基づいてトラフィック分類を定義します。定義されたメカニズムにより、フローを柔軟な方法で記述することが可能になり、クレジット ウィンドウ フロー制御などのアプリケーションと組み合わせることで、クレジット ウィンドウを (1) 複数の DLEP 宛先に送信されるトラフィック間で複数のフローの一部として共有したり、(2) 特定の宛先に送信されるトラフィックおよび/または特定のフローに属するトラフィック専用に使用したりすることができます。この拡張機能は、任意のフロー (DSCP または PCP) の「ワイルドカード」マッチングもサポートしています。トラフィック分類情報は、他のトラフィック分類技術をサポートするために容易に拡張できるように、または [RFC8651] で定義されている拡張機能や 5 タプル IP フローなどのクレジット ウィンドウに関連しない拡張機能によって使用できるように提供されます。
This document defines support for traffic classification using a single new Data Item (see Section 2.1) for general support and defines two new Sub-Data Items to support identification of flows based on DSCPs and PCPs (see Sections 2.2 and 2.3).
この文書は、一般的なサポートとして 1 つの新しいデータ項目 (セクション 2.1 を参照) を使用したトラフィック分類のサポートを定義し、DSCP および PCP に基づくフローの識別をサポートする 2 つの新しいサブデータ項目 (セクション 2.2 および 2.3 を参照) を定義します。
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 Traffic Classification Data Item represents a list of flows that may be used at the same time to provide different service classes for traffic sent from a router to a modem. The data plane information used to identify each flow is represented in a separate Sub-Data Item. The Data Item and Sub-Data Item structures are intended to be independent of any specific usage of the flow identification, e.g., flow control. The Sub-Data Item structure is also intended to allow for future traffic classification types, e.g., 5-tuple flows. While the structure of the Data Items is extensible, actual flow information is expected to be used in an extension-dependent manner. Support for DSCP and PCP-based flows is defined via individual Sub-Data Items; see below. Other types of flow identification, e.g., based on IP transport-layer protocol and ports, may be defined in the future via new Sub-Data Items. Note that when extensions supporting multiple Sub-Data Item types are negotiated, these types MAY be combined in a single Data Item.
トラフィック分類データ項目は、ルーターからモデムに送信されるトラフィックに異なるサービス クラスを提供するために同時に使用できるフローのリストを表します。各フローを識別するために使用されるデータ プレーン情報は、別個のサブデータ項目で表されます。データ項目およびサブデータ項目の構造は、フロー制御などのフロー識別の特定の使用法から独立することを目的としています。サブデータ項目構造は、将来のトラフィック分類タイプ (5 タプル フローなど) を可能にすることも目的としています。データ項目の構造は拡張可能ですが、実際のフロー情報は拡張子に依存した方法で使用されることが期待されます。DSCP および PCP ベースのフローのサポートは、個々のサブデータ項目によって定義されます。以下を参照してください。IP トランスポート層プロトコルやポートなどに基づく他のタイプのフロー識別は、将来、新しいサブデータ項目を通じて定義される可能性があります。複数のサブデータ項目タイプをサポートする拡張がネゴシエートされる場合、これらのタイプを単一のデータ項目に結合してもよいことに注意してください。
Each list of flows is identified using a "Traffic Classification Identifier" or "TID" and is expected to represent a valid combination of data plane identifiers that may be used at the same time. Each flow is identified via a "Flow Identifier" or "FID". Each FID is defined in a Sub-Data Item that carries the data plane identifier or identifiers used to associate traffic with the flow. A DLEP destination address is also needed to complete traffic classification information used in extensions such as flow control. This information is expected to be provided in an extension-specific manner. For example, this address can be provided by a modem when it identifies the traffic classification set in a Destination Up Message using the Credit Window Association Data Item defined in [RFC9893]. TID and FID values have modem-local scope.
フローの各リストは、「トラフィック分類識別子」または「TID」を使用して識別され、同時に使用できるデータ プレーン識別子の有効な組み合わせを表すことが期待されます。各フローは、「フロー識別子」または「FID」によって識別されます。各 FID は、トラフィックをフローに関連付けるために使用されるデータ プレーン識別子を運ぶサブデータ項目で定義されます。DLEP 宛先アドレスは、フロー制御などの拡張で使用されるトラフィック分類情報を完成させるためにも必要です。この情報は、拡張機能固有の方法で提供されることが期待されます。たとえば、このアドレスは、モデムが [RFC9893] で定義されているクレジット ウィンドウ関連付けデータ項目を使用して宛先アップ メッセージに設定されたトラフィック分類を識別するときに、モデムによって提供されます。TID と FID の値にはモデムローカルのスコープがあります。
This section defines the Traffic Classification Data Item. This Data Item is used by a modem to provide a router with traffic classification information. When an extension requires the use of any Data Item, the Data Items, including this Traffic Classification Data Item, SHOULD be included by a modem in any Session Initialization Response Message (e.g., see [RFC9893]). Updates to previously provided traffic classifications or new traffic classifications MAY be sent by a modem by including the Data Item in Session Update Messages. More than one Data Item MAY be included in a message to provide information on multiple traffic classifiers.
このセクションでは、トラフィック分類データ項目を定義します。このデータ項目は、ルーターにトラフィック分類情報を提供するためにモデムによって使用されます。拡張機能が何らかのデータ項目の使用を必要とする場合、このトラフィック分類データ項目を含むデータ項目は、モデムによってセッション初期化応答メッセージに含められるべきです(例、[RFC9893]を参照)。以前に提供されたトラフィック分類または新しいトラフィック分類の更新は、セッション更新メッセージにデータ項目を含めることによってモデムによって送信されてもよい(MAY)。複数のトラフィック分類子に関する情報を提供するために、複数のデータ項目をメッセージに含めることができます (MAY)。
The set of traffic classification information provided in the Data Item is identified using a TID. The actual information related to data planes that is used in traffic classification is provided in a variable list of Traffic Classification Sub-Data Items.
データ項目で提供されるトラフィック分類情報のセットは、TID を使用して識別されます。トラフィック分類に使用されるデータ プレーンに関連する実際の情報は、トラフィック分類サブデータ項目の変数リストで提供されます。
The format of the Traffic Classification Data Item is as follows:
トラフィック分類データ項目の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Traffic Class. Identifier (TID)| Num SDIs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Traffic Classification Sub-Data Item n ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type:
データ項目タイプ:
29
29
Length:
長さ：
Variable
変数
Per Section 11.3 of [RFC8175], Length is the number of octets in the Data Item, excluding the Data Item Type and Length fields. The length here is limited by the packet data unit (PDU) length supported. For example, if the packet is limited to 1400 bytes, then the length MUST NOT exceed this value. If larger packets are supported, the maximum MUST be adjusted to be smaller than or equal to the maximum PDU. Multiple messages can be used if there is more data than will fit in a single TLV.
[RFC8175] のセクション 11.3 によれば、長さは、データ項目タイプと長さフィールドを除いた、データ項目内のオクテット数です。ここでの長さは、サポートされているパケット データ ユニット (PDU) の長さによって制限されます。たとえば、パケットが 1400 バイトに制限されている場合、長さはこの値を超えてはなりません。より大きなパケットがサポートされている場合、最大値は最大 PDU 以下になるように調整しなければなりません (MUST)。単一の TLV に収まりきらないデータがある場合は、複数のメッセージを使用できます。
Traffic Classification Identifier (TID):
トラフィック分類識別子 (TID):
A 16-bit unsigned integer identifying a traffic classification set. There is no restriction on values used by a modem, and there is no requirement for sequential or ordered values.
トラフィック分類セットを識別する 16 ビットの符号なし整数。モデムで使用される値に制限はなく、連続した値や順序付けされた値の要件もありません。
Num SDIs:
SDI の数:
An 8-bit unsigned integer indicating the number of Traffic Classification Sub-Data Items included in the Data Item. A value of zero (0) is allowed and indicates that no traffic should be matched against this TID.
データ項目に含まれるトラフィック分類サブデータ項目の数を示す 8 ビットの符号なし整数。値ゼロ (0) が許可され、この TID と一致するトラフィックがないことを示します。
Reserved:
予約済み：
For the Traffic Classification Data Item, this reserved field is currently unused. It MUST be set to all zeros for this version of the Data Item and is currently ignored on reception. This allows for future extensions of the Data Item if needed.
トラフィック分類データ項目の場合、この予約フィールドは現在使用されていません。このバージョンのデータ項目ではすべて 0 に設定する必要があり、現在は受信時に無視されます。これにより、必要に応じて将来のデータ項目の拡張が可能になります。
Traffic Classification Sub-Data Item:
トラフィック分類サブデータ項目:
Zero or more Traffic Classification Sub-Data Items of the format defined in Section 2.1.1 MAY be included. The number MUST match the value carried in the Num SDIs field.
セクション 2.1.1 で定義された形式のトラフィック分類サブデータ項目が 0 個以上含まれてもよい (MAY)。この数値は、Num SDI フィールドに含まれる値と一致する必要があります。
A router receiving the Traffic Classification Data Item MUST locate the traffic classification information that is associated with the TID indicated in each received Data Item. If no associated traffic classification information is found, the router MUST initialize a new information set using the values carried in the Data Item. If the associated traffic classification information is found, the router MUST replace the corresponding information using the values carried in the Data Item. In both cases, a router MUST also ensure that any data plane state (e.g., see [RFC9893]) that is associated with the TID is updated as needed.
トラフィック分類データ項目を受信するルータは、受信した各データ項目に示されている TID に関連付けられたトラフィック分類情報を見つけなければなりません (MUST)。関連するトラフィック分類情報が見つからない場合、ルータはデータ項目で伝送される値を使用して新しい情報セットを初期化しなければなりません(MUST)。関連するトラフィック分類情報が見つかった場合、ルータは、データ項目で伝送される値を使用して、対応する情報を置き換えなければなりません(MUST)。どちらの場合も、ルータは、TID に関連付けられたデータ プレーンの状態 ([RFC9893] を参照) が必要に応じて更新されることも保証しなければなりません (MUST)。
All Traffic Classification Sub-Data Items share a common format that is patterned after the standard DLEP Data Item format. See Section 11.3 of [RFC8175]. There is no requirement on, or meaning to, Sub-Data Item ordering. Any errors or inconsistencies encountered in parsing Sub-Data Items are handled in the same fashion as any other Data Item parsing error encountered in DLEP. See [RFC8175].
すべてのトラフィック分類サブデータ項目は、標準の DLEP データ項目形式に倣った共通の形式を共有します。[RFC8175] のセクション 11.3 を参照してください。サブデータ項目の順序付けに関する要件やその意味はありません。サブデータ項目の解析中に発生したエラーまたは不一致は、DLEP で発生した他のデータ項目解析エラーと同じ方法で処理されます。[RFC8175]を参照してください。
The format of the Traffic Classification Sub-Data Item is as follows:
トラフィック分類サブデータ項目の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Data Item Type:
サブデータ項目タイプ:
A 16-bit unsigned integer that indicates the type and corresponding format of the Sub-Data Item's Value field. Sub-Data Item Types are scoped within the Data Item in which they are carried, i.e., the Sub-Data Item Type field MUST be used together with the Traffic Classification Data Item Type to identify the format of the Sub-Data Item. Traffic Classification Sub-Data Item Types are managed according to the IANA registry described in Section 5.2.
サブデータ項目の値フィールドのタイプと対応する形式を示す 16 ビットの符号なし整数。サブデータ項目タイプは、それらが伝送されるデータ項目内にスコープされます。つまり、サブデータ項目タイプのフィールドは、サブデータ項目の形式を識別するために、トラフィック分類データ項目タイプと一緒に使用されなければなりません(MUST)。トラフィック分類サブデータ項目タイプは、セクション 5.2 で説明されている IANA レジストリに従って管理されます。
Length:
長さ：
Variable
変数
Per Section 11.3 of [RFC8175], Length is a 16-bit unsigned integer that is the number of octets in the Sub-Data Item, excluding the Data Item Type and Length fields. Each Sub-Data Item has its own Length field.
[RFC8175] のセクション 11.3 によれば、長さは 16 ビットの符号なし整数であり、データ項目タイプと長さフィールドを除くサブデータ項目のオクテット数です。各サブデータ項目には独自の長さフィールドがあります。
Value:
値：
A field of <Length> octets that contains data specific to a particular Data Item.
特定のデータ項目に固有のデータを含む <Length> オクテットのフィールド。
The Diffserv Traffic Classification Sub-Data Item identifies the set of DSCPs that should be treated as a single flow, i.e., receive the same traffic treatment. DSCPs are identified in a list of Diffserv fields. An implementation that does not support DSCPs and wants the same traffic treatment for all traffic to a destination or destinations would indicate 0 DSCPs.
Diffserv トラフィック分類サブデータ項目は、単一のフローとして扱われる、つまり同じトラフィック処理を受ける必要がある DSCP のセットを識別します。DSCP は Diffserv フィールドのリストで識別されます。DSCP をサポートせず、1 つまたは複数の宛先へのすべてのトラフィックに対して同じトラフィック処理を必要とする実装では、0 DSCP が示されます。
The format of the Diffserv Traffic Classification Sub-Data Item is as follows:
Diffserv トラフィック分類サブデータ項目の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type (1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Identifier (FID) | Num DSCPs | DS Field 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DS Field 2 | ... | DS Field n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Data Item Type:
サブデータ項目タイプ:
Sub-Data Item Type with value one (1) identifies the Diffserv Traffic Classification Sub-Data Item Type in the format defined in Section 2.1.1.
値 1 のサブデータ項目タイプは、セクション 2.1.1 で定義された形式で Diffserv トラフィック分類サブデータ項目タイプを識別します。
Length:
長さ：
Variable
変数
Length is defined above. For this Sub-Data Item, it is equal to three (3) octets plus the value of the Num DSCPs field. This means that the maximum Length value is 3 + 64 or 67 octets. The definition can be in multiple Sub-Data Items that are much smaller than this.
長さは上記で定義されています。このサブデータ項目の場合、これは 3 オクテットに Num DSCPs フィールドの値を加えたものと等しくなります。これは、最大の長さの値が 3 + 64、つまり 67 オクテットであることを意味します。定義は、これよりもはるかに小さい複数のサブデータ項目に含めることができます。
Flow Identifier (FID):
フロー識別子 (FID):
A 16-bit unsigned integer representing the data plane information carried in the Sub-Data Item that is to be used in identifying a flow. The value 0xFFFF is reserved and MUST NOT be used in this field.
フローの識別に使用されるサブデータ項目で伝送されるデータ プレーン情報を表す 16 ビットの符号なし整数。値 0xFFFF は予約されており、このフィールドでは使用してはなりません。
Num DSCPs:
DSCP の数:
An 8-bit unsigned integer indicating the number of DSCPs carried in the Sub-Data Item. A zero (0) indicates a (wildcard) match against any DSCP value that does not have an explicit match to a FID. A typical use of this is mapping any DSCPs that are not explicitly mapped to a default queue.
サブデータ項目で伝送される DSCP の数を示す 8 ビットの符号なし整数。ゼロ (0) は、FID と明示的に一致しない DSCP 値に対する (ワイルドカード) 一致を示します。これの一般的な使用法は、デフォルト キューに明示的にマップされていない DSCP をマッピングすることです。
DS Field:
DS フィールド:
Each DS Field is 8 bits long and carries the DSCP field as defined in [RFC2474].
各 DS フィールドは 8 ビット長で、[RFC2474] で定義されている DSCP フィールドを伝送します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | MBZ |
+---+---+---+---+---+---+---+---+
DSCP:
DSCP:
Differentiated Services Code Point [RFC2474]
差別化サービス コード ポイント [RFC2474]
MBZ:
MBZ:
Must Be Zero - set to zero when transmitted
ゼロである必要があります - 送信時にゼロに設定されます
A router receiving the Traffic Classification Sub-Data Item MUST validate the information on receipt, prior to using the carried information, including potentially updating the data behavior as determined by the extension requiring the use of the Sub-Data Item. Validation failures MUST be treated as an error as described in Section 2.1.1.
トラフィック分類サブデータ項目を受信するルーターは、サブデータ項目の使用を必要とする拡張によって決定されるデータ動作の更新の可能性を含め、伝送される情報を使用する前に、受信時に情報を検証しなければなりません(MUST)。検証の失敗は、セクション 2.1.1 で説明されているようにエラーとして扱われなければなりません (MUST)。
Once validated, the receiver MUST ensure that each DS Field value is listed only once across the whole Traffic Classification Data Item. Note that this check is across the Data Item and not the individual Sub-Data Items. If the same DS Field value is listed more than once within the same Traffic Classification Data Item, the Data Item MUST be treated as an error as described in Section 2.1.1.
検証後、受信者は、各 DS フィールド値がトラフィック分類データ項目全体にわたって 1 回だけリストされることを保証しなければなりません (MUST)。このチェックは、個々のサブデータ項目ではなく、データ項目全体にわたって行われることに注意してください。同じトラフィック分類データ項目内に同じ DS フィールド値が複数回リストされている場合、そのデータ項目はセクション 2.1.1 で説明されているようにエラーとして扱われなければなりません (MUST)。
The Ethernet Traffic Classification Sub-Data Item identifies the VLAN and PCPs that should be treated as a single flow, i.e., receive the same traffic treatment. Ethernet PCP support is defined as part of the IEEE 802.1Q tag format [IEEE8021Q] and includes a 3-bit "PCP" field. The tag format also includes a 12-bit "VLAN Identifier (VID)" field. PCPs are identified in a list of Priority Fields. An implementation that does not support PCPs and wants the same traffic treatment for all traffic to a destination or destinations would indicate 0 PCPs. Such an implementation could identify a VLAN to use per destination.
イーサネット トラフィック分類サブデータ項目は、単一のフローとして扱われる必要がある、つまり同じトラフィック処理を受ける必要がある VLAN と PCP を識別します。イーサネット PCP サポートは、IEEE 802.1Q タグ形式 [IEEE8021Q] の一部として定義されており、3 ビットの「PCP」フィールドが含まれています。タグ形式には、12 ビットの「VLAN 識別子 (VID)」フィールドも含まれています。PCP は優先フィールドのリストで識別されます。PCP をサポートせず、1 つまたは複数の宛先へのすべてのトラフィックに対して同じトラフィック処理を必要とする実装では、0 PCP が示されます。このような実装では、宛先ごとに使用する VLAN を識別できます。
The format of the Ethernet Traffic Classification Sub-Data Item is as follows:
イーサネット トラフィック分類サブデータ項目の形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Data Item Type (2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow Identifier (FID) |NumPCPs| VLAN Identifier (VID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pri. 1| Pri. 2| ..... | ..... | ..... | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Data Item Type:
サブデータ項目タイプ:
Sub-Data Item Type with value two (2) identifies the Ethernet Traffic Classification Sub-Data Item Type in the format defined in Section 2.1.1.
値 2 のサブデータ項目タイプは、セクション 2.1.1 で定義された形式でイーサネット トラフィック分類サブデータ項目タイプを識別します。
Length:
長さ：
Variable
変数
Length is defined above. For this Sub-Data Item, it is equal to four (4) plus the number of octets needed to accommodate the number of Priority Fields indicated by the NumPCPs field. Note that as the length is in octets and each Priority Field is 4 bits, the total length of this Sub-Data Item is the 2 octets of Flow Identifier, plus the 2 octets for NumPCPs and VLAN Identifier plus the number of octets for PCPs. The number of octets for the PCPs is computed by rounding up NumPCPs to the nearest even value and dividing by 2. This TLV has maximum length of 4 plus 8 divided by 2 or 8 octets.
長さは上記で定義されています。このサブデータ項目の場合、これは、4 に NumPCPs フィールドによって示される優先フィールドの数を収容するのに必要なオクテット数を加えたものに等しくなります。長さはオクテット単位であり、各優先度フィールドは 4 ビットであるため、このサブデータ項目の合計長は、フロー識別子の 2 オクテットに、NumPCP と VLAN 識別子の 2 オクテットを加え、PCP のオクテット数を加えたものであることに注意してください。PCP のオクテット数は、NumPCP を最も近い偶数値に切り上げ、2 で割ることによって計算されます。この TLV の最大長は、4 に 8 を加えたものを 2 または 8 オクテットで割ったものになります。
Flow Identifier (FID):
フロー識別子 (FID):
A 16-bit unsigned integer representing the data plane information carried in the Sub-Data Item that is to be used in identifying a flow. The value 0xFFFF is reserved and MUST NOT be used in this field.
フローの識別に使用されるサブデータ項目で伝送されるデータ プレーン情報を表す 16 ビットの符号なし整数。値 0xFFFF は予約されており、このフィールドでは使用してはなりません。
NumPCPs:
PCP の数:
A 4-bit unsigned integer indicating the number of Priority Fields carried in the Sub-Data Item. A zero (0) indicates a (wildcard) match against any PCP value that does not have an explicit match to a FID. A typical use of a wildcard is mapping any PCPs that are not explicitly mapped to a default queue. The maximum number of PCPs is 8.
サブデータ項目で伝送される優先フィールドの数を示す 4 ビットの符号なし整数。ゼロ (0) は、FID と明示的に一致しない PCP 値に対する (ワイルドカード) 一致を示します。ワイルドカードの一般的な使用法は、デフォルト キューに明示的にマップされていない PCP をマップすることです。PCP の最大数は 8 です。
VLAN Identifier (VID):
VLAN 識別子 (VID):
A 12-bit unsigned integer field indicating the VLAN to be used in traffic classification. VID value zero (0x000) is used to indicate that the VID is to be ignored. VID 0xFFF is reserved. Any other VID value from 0x001 through 0xFFE can be used in traffic classification. Any explicitly mapped VLANs are matched first. Any VLANs that do not have a mapping will then map to this default mapping.
トラフィック分類に使用される VLAN を示す 12 ビットの符号なし整数フィールド。VID 値ゼロ (0x000) は、VID が無視されることを示すために使用されます。VID 0xFFF は予約されています。0x001 から 0xFFE までの他の VID 値はトラフィック分類に使用できます。明示的にマップされた VLAN が最初に照合されます。マッピングのない VLAN は、このデフォルトのマッピングにマッピングされます。
Priority:
優先度：
Each Priority Field is 4 bits long and indicates a PCP field as defined in [IEEE8021Q]. Note that zero (0) is a valid value for PCP.
各優先フィールドは 4 ビット長で、[IEEE8021Q] で定義されている PCP フィールドを示します。PCP の有効な値はゼロ (0) であることに注意してください。
0 1 2 3
+---+---+---+---+
| PCP |MBZ|
+---+---+---+---+
PCP:
PCP:
Priority Code Point [IEEE8021Q]
優先コードポイント[IEEE8021Q]
MBZ:
MBZ:
Must Be Zero - set to zero when transmitted
ゼロである必要があります - 送信時にゼロに設定されます
Pad:
Pad:
A field that is 4 bits long and is included when NumPCPs is an odd number. This field MUST be set to zero by the sender and MUST be ignored on receipt.
4 ビット長のフィールドで、NumPCPs が奇数の場合に含まれます。このフィールドは送信者によってゼロに設定されなければならず、受信時には無視されなければなりません。
A router receiving the Traffic Classification Sub-Data Item MUST validate the information on receipt, prior to using the carried information, including potentially updating the data behavior as determined by the extension requiring the use of the Sub-Data Item. Note that validation can include usage-specific semantics such as those found in [RFC9893]. Any failures MUST be treated as an error as described in Section 2.1.1.
トラフィック分類サブデータ項目を受信するルーターは、サブデータ項目の使用を必要とする拡張によって決定されるデータ動作の更新の可能性を含め、伝送される情報を使用する前に、受信時に情報を検証しなければなりません(MUST)。検証には、[RFC9893] にあるような使用法固有のセマンティクスが含まれる場合があることに注意してください。セクション 2.1.1 で説明されているように、あらゆる失敗はエラーとして扱われなければなりません (MUST)。
After successful validation, the receiver MUST ensure that each Priority Field value is listed only once across the whole Traffic Classification Data Item. Note that this check is across the Data Item and not the individual Sub-Data Items. If the same Priority Field value is listed more than once within the same Traffic Classification Data Item, the Data Item MUST be treated as an error as described in Section 2.1.1.
検証が成功した後、受信者は、各優先度フィールド値がトラフィック分類データ項目全体にわたって 1 回だけリストされていることを確認しなければなりません (MUST)。このチェックは、個々のサブデータ項目ではなく、データ項目全体にわたって行われることに注意してください。同じトラフィック分類データ項目内に同じ優先度フィールド値が複数回リストされている場合、そのデータ項目はセクション 2.1.1 で説明されているようにエラーとして扱われなければなりません (MUST)。
In cases where both Traffic Classification Sub-Data Item Types are defined, matching on Ethernet information takes precedence. More specifically, when a packet matches both a DSCP indicated in a Diffserv Traffic Classification Sub-Data Item (Section 2.2) and a VID/PCP identified in an Ethernet Traffic Classification Sub-Data Item (Section 2.3), the TID associated with the matching VLAN/PCP MUST be used.
両方のトラフィック分類サブデータ項目タイプが定義されている場合、イーサネット情報の一致が優先されます。より具体的には、パケットが Diffserv トラフィック分類サブデータ項目 (セクション 2.2) で示される DSCP とイーサネットトラフィック分類サブデータ項目 (セクション 2.3) で識別される VID/PCP の両方に一致する場合、一致する VLAN/PCP に関連付けられた TID を使用しなければなりません (MUST)。
The formats defined in this document will only be used when extensions require their use.
この文書で定義されている形式は、拡張機能で使用が必要な場合にのみ使用されます。
The DLEP specification [RFC8175] defines the handling of unexpected appearances of any Data Items, including those defined in this document.
DLEP 仕様 [RFC8175] は、この文書で定義されているものを含む、あらゆるデータ項目の予期せぬ出現の処理を定義しています。
This document introduces finer-grained flow identification mechanisms for DLEP. These mechanisms expose vulnerabilities similar to existing DLEP messages. An example of a threat to which traffic classification might be susceptible is where a malicious actor masquerading as a DLEP peer could inject an alternate Traffic Classification Data Item, changing the mapping of traffic to queues; this would in turn cause delay, congestion, or loss in one or more service classes. Other possible threats are discussed in the Security Considerations section of [RFC8175] and are also applicable, but not specific, to traffic classification.
このドキュメントでは、DLEP のより詳細なフロー識別メカニズムを紹介します。これらのメカニズムは、既存の DLEP メッセージと同様の脆弱性を暴露します。トラフィック分類が影響を受ける可能性のある脅威の例としては、DLEP ピアを装った悪意のある攻撃者が代替トラフィック分類データ項目を挿入し、トラフィックのキューへのマッピングを変更する可能性がある場合が挙げられます。これにより、1 つ以上のサービス クラスで遅延、輻輳、または損失が発生します。他の考えられる脅威については、[RFC8175] のセキュリティに関する考慮事項のセクションで説明されており、これもトラフィック分類に適用されますが、特定のものではありません。
The transport-layer security mechanisms documented in [RFC8175], along with the latest versions of [BCP195], [IEEE-802.1AE], and [IEEE-802.1X] at the time of this writing, can be applied to this document. Implementations following the "networked deployment" model described in Section 4 ("Implementation Scenarios") of [RFC8175] SHOULD refer to [BCP195] for additional details. The Layer 2 security mechanisms documented in [RFC8175] can also, with some updates, be applied to the mechanisms defined in this document. Examples of technologies that can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X].
[RFC8175] に文書化されているトランスポート層セキュリティ メカニズムと、この文書の執筆時点での最新バージョンの [BCP195]、[IEEE-802.1AE]、および [IEEE-802.1X] をこの文書に適用できます。[RFC8175] のセクション 4 (「実装シナリオ」) で説明されている「ネットワーク展開」モデルに従った実装は、追加の詳細については [BCP195] を参照すべきである(SHOULD)。[RFC8175] に文書化されているレイヤ 2 セキュリティメカニズムは、いくつかの更新を加えて、この文書で定義されているメカニズムに適用することもできます。レイヤ 2 リンクを保護するために導入できるテクノロジーの例には、[IEEE-802.1AE] および [IEEE-802.1X] が含まれます。
IANA has assigned the following value from the "Specification Required" range [RFC8126] in the DLEP "Data Item Type Values" registry:
IANA は、DLEP「データ項目タイプ値」レジストリの「要求仕様」範囲 [RFC8126] から次の値を割り当てました。
+===========+========================+
| Type Code | Description |
+===========+========================+
| 29 | Traffic Classification |
+-----------+------------------------+
Table 1: New Data Item Type Value
表 1: 新しいデータ項目タイプの値
IANA has created a new DLEP registry named "Traffic Classification Sub-Data Item Type Values".
IANA は、「トラフィック分類サブデータ項目タイプ値」という名前の新しい DLEP レジストリを作成しました。
Table 2 shows the registration policies [RFC8126] for the registry:
表 2 は、レジストリの登録ポリシー [RFC8126] を示しています。
+=============+=========================+
| Range | Registration Procedures |
+=============+=========================+
| 1-65407 | Specification Required |
+-------------+-------------------------+
| 65408-65534 | Private Use |
+-------------+-------------------------+
Table 2: Registration Policies
表 2: 登録ポリシー
Table 3 shows the initial contents of the registry:
表 3 は、レジストリの初期内容を示しています。
+=============+=================================+=============+
| Type Code | Description | Reference |
+=============+=================================+=============+
| 0 | Reserved | RFC 9892 |
+-------------+---------------------------------+-------------+
| 1 | Diffserv Traffic Classification | [RFC2474] |
+-------------+---------------------------------+-------------+
| 2 | Ethernet Traffic Classification | [IEEE8021Q] |
+-------------+---------------------------------+-------------+
| 3-65407 | Unassigned | |
+-------------+---------------------------------+-------------+
| 65408-65534 | Reserved for Private Use | RFC 9892 |
+-------------+---------------------------------+-------------+
| 65535 | Reserved | RFC 9892 |
+-------------+---------------------------------+-------------+
Table 3: Initial Registry Contents
表 3: 初期レジストリの内容
This registry encompasses packet traffic classification, where standard packet header identifiers in packets or data frames indicate Quality of Service (QoS) treatment. It includes two specific entries for widely recognized identifiers used in QoS management for IP and Ethernet networks. Reserved values are set aside for similar future identifiers that may emerge to denote QoS treatment. However, requests for new entries are not expected to be frequent.
このレジストリにはパケット トラフィックの分類が含まれており、パケットまたはデータ フレーム内の標準パケット ヘッダー識別子がサービス品質 (QoS) 処理を示します。これには、IP およびイーサネット ネットワークの QoS 管理で使用される、広く認識されている識別子の 2 つの特定のエントリが含まれています。予約値は、QoS 処理を示すために出現する可能性のある将来の同様の識別子のために確保されます。ただし、新規エントリーのリクエストはそれほど多くないと予想されます。
Allocations within the registry are subject to the following requirements:
レジストリ内の割り当てには、次の要件が適用されます。
1. Documentation of the intended use of the requested value, in compliance with the "Specification Required" policy defined in [RFC8126].
1. [RFC8126] で定義されている「要求される仕様」ポリシーに準拠した、要求された値の使用目的の文書化。
2. Approval by the designated expert (DE) appointed by the IESG. The DE must do the following:
2. IESG によって任命された指定専門家 (DE) による承認。DE は次のことを行う必要があります。
* Verify that the requested value is clearly documented and its purpose and usage are unambiguous.
* 要求された値が明確に文書化されており、その目的と使用法が明確であることを確認してください。
* Ensure that the proposed value does not conflict with existing work or ongoing efforts within the IETF.
* 提案された値が、IETF 内の既存の作業や進行中の取り組みと矛盾しないようにしてください。
* Confirm that any specification requesting a code point has undergone review by the MANET Working Group (or a successor mailing list designated by the IESG).
* コード ポイントを要求する仕様はすべて、MANET ワーキング グループ (または IESG が指定する後継メーリング リスト) によるレビューを受けていることを確認してください。
* Validate that external specifications requesting code points are publicly available, are permanently archived, and do not conflict with active or published IETF work.
* コード ポイントを要求する外部仕様が公的に利用可能であり、永久にアーカイブされており、アクティブまたは公開されている IETF の作業と競合しないことを検証します。
* Ensure that the review process is conducted in a timely manner, with any disputes resolved through consultation with the appropriate working groups.
* レビュープロセスが適時に実施され、紛争があれば適切な作業グループとの協議を通じて解決されるようにしてください。
This section provides guidance for registrations in the "Traffic Classification Sub-Data Item Type Values" registry. To simplify future registrations in DLEP-related registries, it is recommended that the guidance in this section apply to all registries within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry group that use the "Specification Required" policy [RFC8126]. Future specifications may point to the guidance in this document.
このセクションでは、「トラフィック分類サブデータ項目タイプ値」レジストリへの登録に関するガイダンスを提供します。DLEP 関連のレジストリへの将来の登録を簡素化するために、このセクションのガイダンスを、「仕様必須」ポリシー [RFC8126] を使用する「ダイナミック リンク交換プロトコル (DLEP) パラメータ」レジストリ グループ内のすべてのレジストリに適用することをお勧めします。将来の仕様では、このドキュメントのガイダンスが参照される可能性があります。
[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>.
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[IEEE-802.1AE]
IEEE, "IEEE Standard for Local and metropolitan area
networks-Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2018.8585421, IEEE Std 802.1AE-2018,
December 2018,
<https://ieeexplore.ieee.org/document/8585421>.
[IEEE-802.1X]
IEEE, "802.1X-2020 - IEEE Standard for Local and
Metropolitan Area Networks--Port-Based Network Access
Control", DOI 10.1109/IEEESTD.2020.9018454, IEEE Std IEEE-
802.1X-2020, February 2020,
<https://ieeexplore.ieee.org/document/9018454>.
[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>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link
Exchange Protocol (DLEP) Control-Plane-Based Pause
Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,
<https://www.rfc-editor.org/info/rfc8651>.
[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>.
[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>.
The Sub-Data Item format was inspired by Rick Taylor's "Data Item Containers". He also proposed the separation of credit windows from traffic classification at IETF 98. This document was derived from [RFC9894] as a result of discussions at IETF 101. Many useful comments were received from contributors to the MANET Working Group, notably Ronald in 't Velt and David Black.
サブデータ項目形式は、Rick Taylor の「データ項目コンテナー」からインスピレーションを受けました。彼はまた、IETF 98 でトラフィック分類からクレジット ウィンドウを分離することも提案しました。この文書は、IETF 101 での議論の結果、[RFC9894] から派生したものです。MANET ワーキング グループの貢献者、特に Ronald in't Velt と David Black から多くの有益なコメントを受け取りました。
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
Don Fedyk (editor)
LabN Consulting, L.L.C.
Email: dfedyk@labn.net