[要約] RFC 8964は、決定論的ネットワーキング（DetNet）データプレーンのMPLS実装に関するものです。この文書の目的は、高い信頼性と低遅延を必要とするアプリケーションのために、MPLSネットワーク上でのデータ転送の予測可能性を向上させることにあります。利用場面としては、産業オートメーション、5G通信ネットワーク、および車載ネットワークなどが挙げられます。
Internet Engineering Task Force (IETF) B. Varga, Ed.
Request for Comments: 8964 J. Farkas
Category: Standards Track Ericsson
ISSN: 2070-1721 L. Berger
LabN Consulting, L.L.C.
A. Malis
Malis Consulting
S. Bryant
Futurewei Technologies
J. Korhonen
January 2021
Deterministic Networking (DetNet) Data Plane: MPLS
決定論的ネットワーキング（DetNet）データプレーン：MPLS.
Abstract
概要
This document specifies the Deterministic Networking (DetNet) data plane when operating over an MPLS Packet Switched Network. It leverages existing pseudowire (PW) encapsulations and MPLS Traffic Engineering (MPLS-TE) encapsulations and mechanisms. This document builds on the DetNet architecture and data plane framework.
このドキュメントは、MPLSパケット交換ネットワークを介して動作するときの決定論的ネットワーキング（DetNet）データプレーンを指定します。既存の疑似回線（PW）のカプセル化とMPLSトラフィックエンジニアリング（MPLS-TE）カプセル化とメカニズムを活用します。このドキュメントはDetnetアーキテクチャとデータプレーンフレームワークに構築されています。
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8964.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8964で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Terms Used in This Document
2.2. Abbreviations
2.3. Requirements Language
3. Overview of the DetNet MPLS Data Plane
3.1. Layers of DetNet Data Plane
3.2. DetNet MPLS Data Plane Scenarios
4. MPLS-Based DetNet Data Plane Solution
4.1. DetNet over MPLS Encapsulation Components
4.2. MPLS Data Plane Encapsulation
4.2.1. DetNet Control Word and DetNet Sequence Number
4.2.2. S-Labels
4.2.3. F-Labels
4.3. OAM Indication
4.4. Flow Aggregation
4.4.1. Aggregation via LSP Hierarchy
4.4.2. Aggregating DetNet Flows as a New DetNet Flow
4.5. Service Sub-Layer Considerations
4.5.1. Edge Node Processing
4.5.2. Relay Node Processing
4.6. Forwarding Sub-Layer Considerations
4.6.1. Class of Service
4.6.2. Quality of Service
5. Management and Control Information Summary
5.1. Service Sub-Layer Information Summary
5.1.1. Service Aggregation Information Summary
5.2. Forwarding Sub-Layer Information Summary
6. Security Considerations
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
Deterministic Networking (DetNet) is a service that can be offered by a network to DetNet flows. DetNet provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. General background and concepts of DetNet can be found in the DetNet architecture [RFC8655].
決定論的ネットワーキング（DetNet）は、ネットワークによってDetnet Flowsに提供できるサービスです。DetNetは、極めて低いパケット損失率と最終的な終了配信待ち時間を持つデータフローの配信機能を提供します。Detnetの一般的な背景と概念は、DetNet Architecture [RFC8655]にあります。
The purpose of this document is to describe the use of the MPLS data plane to establish and support DetNet flows. The DetNet architecture models the DetNet-related data plane functions as being decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service functions, such as protection and reordering. At the DetNet data plane, a new set of functions (Packet Replication, Elimination and Ordering Functions (PREOF)) provide the tasks specific to the service sub-layer. The forwarding sub-layer is used to provide forwarding assurance (low loss, assured latency, and limited out-of-order delivery). The use of the functionalities of the DetNet service sub-layer and the DetNet forwarding sub-layer require careful design and control by the Controller Plane in addition to the DetNet-specific use of MPLS encapsulation as specified by this document.
この文書の目的は、Detnetフローを確立しサポートするためのMPLSデータプレーンの使用を説明することです。DetNetアーキテクチャは、DetNet関連データプレーンが2つの副層に分解されているとの機能をモデル化しています。サービス副層と転送副層。サービスサブレイヤは、保護や並べ替えなどのDetNetサービス機能を提供するために使用されます。DetNetデータプレーンでは、新しい関数セット（パケット複製、除去および順序付け関数（PREOF））がサービスサブレイヤに固有のタスクを提供します。転送サブレイヤは、転送保証（低損失、保証された待ち時間、および限られた順序配信の制限）を提供するために使用されます。DetNet ServiceサブレイヤおよびDetNet Forwardingサブレイヤの機能を使用するには、このドキュメントによって指定されているMPLSカプセル化のDetnet固有の使用に加えて、コントローラプレーンによる慎重な設計と制御が必要です。
This document specifies the DetNet data plane operation and the on-wire encapsulation of DetNet flows over an MPLS-based Packet Switched Network (PSN) using the service reference model. MPLS encapsulation already provides a solid foundation of building blocks to enable the DetNet service and forwarding sub-layer functions. MPLS-encapsulated DetNet can be carried over a variety of different network technologies that can provide the level of service required for DetNet. However, the specific details of how DetNet MPLS is carried over different network technologies are out of scope for this document.
このドキュメントは、サービス参照モデルを使用してMPLSベースのパケット交換ネットワーク（PSN）を介したDetnetデータプレーンの操作とDetNetフローのオンイワイヤカプセル化を指定します。MPLSカプセル化はすでにDetnetサービスと転送サブレイヤ関数を有効にするためのビルディングブロックの基礎を提供しています。MPLSカプセル化DetNetは、Detnetに必要なサービスレベルを提供できるさまざまなネットワーク技術を介して伝送できます。ただし、Detnet MPLSが異なるネットワークテクノロジでどのように運ばれるかの具体的な詳細は、この文書の範囲外です。
MPLS-encapsulated DetNet flows can carry different types of traffic. The details of the types of traffic that are carried in DetNet are also out of scope for this document. An example of IP using DetNet MPLS sub-networks can be found in [RFC8939]. DetNet MPLS may use an associated controller and Operations, Administration, and Maintenance (OAM) functions that are defined outside of this document.
MPLSカプセル化Detnetフローはさまざまな種類のトラフィックを運ぶことができます。Detnetで搭載されているトラフィックの種類の詳細もこの文書の範囲外です。Detnet MPLSサブネットワークを使用したIPの例は[RFC8939]にあります。DetNet MPLSは、このドキュメントの外部で定義されている関連コントローラと操作、管理、およびメンテナンス（OAM）機能を使用できます。
Background information common to all data planes for DetNet can be found in the DetNet data plane framework [RFC8938].
Detnetのすべてのデータプレーンに共通の背景情報Detnet Data Plane Framework [RFC8938]にあります。
This document uses the terminology established in the DetNet architecture [RFC8655] and the DetNet data plane framework [RFC8938]. The reader is assumed to be familiar with these documents, any terminology defined therein, and basic MPLS-related terminologies in [RFC3031].
この文書では、Detnetアーキテクチャ[RFC8655]とDetNet Data Plane Framework [RFC8938]で設定されている用語を使用しています。リーダーは、これらの文書、そこに定義された任意の用語、および[RFC3031]の基本的なMPLS関連のターミニーに精通していると見なされます。
The following terminology is introduced in this document:
この文書では、次の用語が紹介されています。
F-Label A DetNet "forwarding" label that identifies the Label Switched Path (LSP) used to forward a DetNet flow across an MPLS PSN, i.e., a hop-by-hop label used between Label Switching Routers (LSRs).
f-label MPLS PSN、すなわちラベルスイッチングルータ（LSRS）間で使用されるポップバイホップラベルを転送するために使用されるラベルスイッチパス（LSP）を識別するDetnet「転送」ラベル。
S-Label A DetNet "service" label that is used between DetNet nodes that implement the DetNet service sub-layer functions. An S-Label is used to identify a DetNet flow at the DetNet service sub-layer at a receiving DetNet node.
S-Label Detnetサービスのサブレイヤ関数を実装するDetnetノード間で使用されるDetnet "Service"ラベル。Sラベルは、受信したDetNetノードでDetNetサービスサブレイヤでのDetNetフローを識別するために使用されます。
A-Label A special case of an S-Label, whose aggregation properties are known only at the aggregation and deaggregation end points.
A - ラベル集約プロパティが集約および停止端点でのみ知られているSラベルの特別なケース。
d-CW A DetNet Control Word (d-CW) that is used for sequencing information of a DetNet flow at the DetNet service sub-layer.
D-CW DetNet ServiceのサブレイヤのDetNetフローの情報をシーケンスするために使用されるDetNet Control Word（D-CW）。
The following abbreviations are used in this document:
この文書では、次の略語が使用されています。
CoS Class of Service
COSのサービスクラス
CW Control Word
CWコントロールワード
DetNet Deterministic Networking
Detnet決定論的ネットワーキング
LSR Label Switching Router
LSRラベルスイッチングルータ
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
MPLS-TE Multiprotocol Label Switching Traffic Engineering
MPLS-TEマルチプロトコルラベルスイッチングトラフィックエンジニアリング
MPLS-TP Multiprotocol Label Switching Transport Profile
MPLS-TPマルチプロトコルラベルスイッチングトランスポートプロファイル
OAM Operations, Administration, and Maintenance
OAMの操作、管理、および保守
PE Provider Edge
PEプロバイダのエッジ
PEF Packet Elimination Function
PEFパケット除去機能
PRF Packet Replication Function
PRFパケットレプリケーション機能
PREOF Packet Replication, Elimination and Ordering Functions
パケットのレプリケーション、除去および順序付け機能
POF Packet Ordering Function
POFパケット順序機能
PSN Packet Switched Network
PSNパケット交換ネットワーク
PW Pseudowire
PW擬似ワイヤー
QoS Quality of Service
QoSサービス品質
S-PE Switching Provider Edge
S-PEスイッチングプロバイダエッジ
T-PE Terminating Provider Edge
T-PE終端プロバイダーエッジ
TSN Time-Sensitive Networking
TSNの時間依存ネットワーキング
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
MPLS provides a wide range of capabilities that can be utilized by DetNet. A straight-forward approach utilizing MPLS for a DetNet service sub-layer is based on the existing pseudowire (PW) encapsulations and utilizes existing MPLS-TE encapsulations and mechanisms. Background on PWs can be found in [RFC3985], [RFC3032], and [RFC3031]. Background on MPLS-TE can be found in [RFC3272] and [RFC3209].
MPLSはDetnetによって利用できる幅広い機能を提供します。DetNetサービスサブレイヤ用のMPLSを利用する直接的なアプローチは、既存の疑似回線（PW）カプセル化に基づいており、既存のMPLS-TEカプセル化およびメカニズムを利用する。PWSの背景は、[RFC3985]、[RFC3032]、[RFC3031]にあります。MPLS-TEの背景は[RFC3272]と[RFC3209]にあります。
DetNet MPLS
.
Bottom of Stack .
(inner label) +------------+
| Service | d-CW, S-Label (A-Label)
+------------+
| Forwarding | F-Label(s)
+------------+
Top of Stack .
(outer label) .
Figure 1: DetNet Adaptation to MPLS Data Plane
図1：MPLSデータプレーンへのDetnet適応
The DetNet MPLS data plane representation is illustrated in Figure 1. The service sub-layer includes a DetNet Control Word (d-CW) and an identifying service label (S-Label). The DetNet Control Word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385]. An aggregation label (A-Label) is a special case of S-Label used for aggregation.
DetNet MPLSデータプレーン表現を図1に示す。サービスサブレイヤは、DetNet制御ワード（D - CW）と識別サービスラベル（Sラベル）とを含む。DetNet Control Word（D-CW）は、[RFC4385]で定義されている一般的なPW MPLS制御ワード（PWMCW）に準拠しています。集約ラベル（Aラベル）は、集約に使用されるSラベルの特別な場合です。
A node operating on a received DetNet flow at the DetNet service sub-layer uses the local context associated with a received S-Label, i.e., a received F-Label, to determine which local DetNet operation(s) are applied to that packet. An S-Label may be taken from the platform label space [RFC3031], making it unique and enabling DetNet flow identification regardless of which input interface or LSP the packet arrives on. It is important to note that S-Label values are driven by the receiver, not the sender.
DetNet Serviceサブレイヤで受信したDetnetフロー上で動作するノードは、受信されたSラベル、すなわち受信されたFラベルに関連付けられたローカルコンテキスト、すなわち受信されたFラベルを使用して、どのローカルDetNet動作がそのパケットに適用されるかを決定する。Sラベルは、プラットフォームラベルスペース[RFC3031]から取られている場合があり、パケットがどの入力インタフェースまたはLSPに到着するかに関係なく、それを独自に、Detnet Flow IDを有効にします。送信者ではなく、Sラベル値が受信者によって駆動されることに注意することが重要です。
The DetNet forwarding sub-layer is supported by zero or more forwarding labels (F-Labels). MPLS-TE encapsulations and mechanisms can be utilized to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes.
DetNet転送サブレイヤは、ゼロ以上の転送ラベル（Fラベル）によってサポートされています。MPLS-TEカプセル化およびメカニズムを利用して、リソース割り当ておよび明示的な経路を提供する責任がある転送サブレイヤーを提供することができます。
DetNet MPLS Relay Transit Relay DetNet MPLS
End System Node Node Node End System
(T-PE) (S-PE) (LSR) (S-PE) (T-PE)
+----------+ +----------+
| Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ +---------+ +---------+ +----------+
| Service |<--| Service |-- DetNet flow --| Service |-->| Service |
+----------+ +---------+ +----------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| |Forwarding| |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +----.---.-+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub- ]-+ +......+ +-[ Sub- ]-+
[Network] [Network]
`-----' `-----'
|<- LSP -->| |<-------- LSP -----------| |<--- LSP -->|
|<----------------- DetNet MPLS --------------------->|
Figure 2: A DetNet MPLS Network
図2：Detnet MPLSネットワーク
Figure 2 illustrates a hypothetical DetNet MPLS-only network composed of DetNet-aware MPLS-enabled end systems operating over a DetNet-aware MPLS network. In this figure, the relay nodes are PE devices that define the MPLS LSP boundaries, and the transit nodes are LSRs.
図2は、DetNet対応MPLSネットワークを介して動作するDetnet対応のMPLS対応エンドシステムからなる仮想Detnet MPLS専用ネットワークを示しています。この図では、リレーノードはMPLS LSP境界を定義するPEデバイスであり、トランジットノードはLSRSです。
DetNet end systems and relay nodes understand the particular needs of DetNet flows and provide both DetNet service and forwarding sub-layer functions. In the case of MPLS, DetNet service-aware nodes add, remove, and process d-CWs, S-Labels, and F-Labels as needed. DetNet MPLS nodes provide functionality analogous to T-PEs when they sit at the edge of an MPLS domain and S-PEs when they are in the middle of an MPLS domain; see [RFC6073].
DetNet End SystemとRelayノードはDetnet Flowの特定のニーズを理解し、Detnetサービスと転送サブレイヤ機能の両方を提供します。MPLSの場合、Detnetサービス対応ノードは、必要に応じてD-CWS、Sラベル、およびFラベルを追加、削除、および処理します。Detnet MPLSノードは、MPLSドメインの中央にあるときにMPLSドメインの端に座ると、T-PEと類似した機能を提供します。[RFC6073]を参照してください。
In a DetNet MPLS network, transit nodes may be DetNet-service-aware or DetNet-unaware MPLS Label Switching Routers (LSRs). In this latter case, such LSRs would be unaware of the special requirements of the DetNet service sub-layer but would still provide traffic engineering functions and the QoS capabilities needed to ensure that the (TE) LSPs meet the service requirements of the carried DetNet flows.
Detnet MPLSネットワークでは、トランジットノードはDetnet-Service-AwareまたはDetnet-NataWare MPLSラベルスイッチングルータ（LSRS）であり得る。この後者の場合、そのようなLSRはDetNet Serviceサブレイヤの特別な要件を認識していませんが、（TE）LSPが運搬したDetnetフローのサービス要件を満たすために必要なトラフィックエンジニアリング機能とQoS機能を提供します。。
The application of DetNet using MPLS supports a number of control and management plane types. These types support certain MPLS data plane deployments. For example, RSVP-TE, MPLS-TP, or MPLS Segment Routing (when extended to support resource allocation) are all valid MPLS deployment cases.
MPLSを使用したDetNetのアプリケーションは、いくつかの制御および管理プレーンタイプをサポートしています。これらのタイプは特定のMPLSデータプレーンの展開をサポートしています。たとえば、RSVP-TE、MPLS-TP、またはMPLSセグメントルーティング（リソース割り当てをサポートする場合）はすべて有効なMPLSデプロイメントケースです。
Figure 3 illustrates how an end-to-end MPLS-based DetNet service is provided in more detail. In this figure, the Customer Edge (CE1 and CE2) are able to send and receive MPLS-encapsulated DetNet flows, and R1, R2, and R3 are relay nodes in the middle of a DetNet network. The 'X' in the end systems and relay nodes represents potential DetNet compound flow packet replication and elimination points. In this example, service protection is supported utilizing at least two DetNet member flows and TE LSPs. For a unidirectional flow, R1 supports PRF, and R3 supports PEF and POF. Note that the relay nodes may change the underlying forwarding sub-layer, for example, tunneling MPLS over IEEE 802.1 TSN [DetNet-MPLS-over-TSN] or simply over interconnected network links.
図3は、エンドツーエンドMPLSベースのDetNetサービスがどのように詳細に提供されるかを示しています。この図では、顧客エッジ（CE1とCE2）はMPLSカプセル化されたDetNetフローを送受信することができ、R1、R2、およびR3はDetNetネットワークの途中でリレーノードです。エンドシステムおよび中継ノードの「X」は、潜在的なDetnet Complect Flowパケットの複製と除去点を表します。この例では、サービス保護は少なくとも2つのDetNetメンバーフローとTE LSPを利用してサポートされています。一方向の流れのために、R1はPRFをサポートし、R3はPEFとPOFをサポートします。中継ノードは、基礎となる転送サブレイヤ、例えば、IEEE802.1 TSN [Detnet - MPLS - OVER - TSN]または単に相互接続されたネットワークリンクを介してMPLSをトンネリングすることができることに留意されたい。
DetNet DetNet
DetNet Service Transit Transit Service DetNet
MPLS | |<-Tnl->| |<-Tnl->| | MPLS
End | V 1 V V 2 V | End
System | +--------+ +--------+ +--------+ | System
+---+ | | R1 |=======| R2 |=======| R3 | | +---+
| X...DFa...|._X_....|..DF1..|.__ ___.|..DF3..|...._X_.|.DFa..|.X |
|CE1|========| \ | | X | | / |======|CE2|
| | | | \_.|..DF2..|._/ \__.|..DF4..|._/ | | | |
+---+ | |=======| |=======| | +---+
^ +--------+ +--------+ +--------+ ^
| Relay Node Relay Node Relay Node |
| (S-PE) (S-PE) (S-PE) |
| |
|<---------------------- DetNet MPLS --------------------->|
| |
|<--------------- End-to-End DetNet Service -------------->|
-------------------------- Data Flow ------------------------->
Figure 3: MPLS-Based Native DetNet
図3：MPLSベースのネイティブDetnet
X - Optional service protection (none, PRF, PREOF, PEF/POF)
X - オプションのサービス保護（なし、PRF、PREOF、PEF / POF）
DFx - DetNet member flow x over a TE LSP
DFX - TE LSP上のDETNETメンバーフローX
To carry DetNet over MPLS, the following is required:
DetnetをMPLSに搭載するには、次のことが必要です。
1. A method of identifying the MPLS payload type.
1. MPLSペイロードタイプを識別する方法。
2. A method of identifying the DetNet flow(s) to the processing element.
2. 処理要素へのDetNetフローを識別する方法。
3. A method of distinguishing DetNet OAM packets from DetNet data packets.
3. DetnetデータパケットからDetnet OAMパケットを区別する方法。
4. A method of carrying the DetNet sequence number.
4. Detnetシーケンス番号を搭載する方法。
5. A suitable LSP to deliver the packet to the egress PE.
5. パケットを出力PEに配信するのに適したLSP。
6. A method of carrying queuing and forwarding indication.
6. キューイングと転送表示を行う方法。
In this design, an MPLS service label (the S-Label) is similar to a pseudowire (PW) label [RFC3985] and is used to identify both the DetNet flow identity and the MPLS payload type satisfying (1) and (2) in the list above. OAM traffic discrimination happens through the use of the Associated Channel method described in [RFC4385]. The DetNet sequence number is carried in the DetNet Control Word, which also carries the Data/OAM discriminator. To simplify implementation and to maximize interoperability, two sequence number sizes are supported: a 16-bit sequence number and a 28-bit sequence number. The 16-bit sequence number is needed to support some types of legacy clients. The 28-bit sequence number is used in situations where it is necessary to ensure that, in high-speed networks, the sequence number space does not wrap whilst packets are in flight.
この設計では、MPLSサービスラベル（Sラベル）は疑似回線（PW）ラベル[RFC3985]と似ており、Detnet Flow IDとMPLSペイロードタイプの両方を識別するために使用されます（1）と（2）上記のリスト。OAMトラフィックの差別は、[RFC4385]に記載されている関連チャネル方法を使用して行われます。DetNetシーケンス番号はDetNet Control Wordで搭載されており、データ/ OAM弁別器も搭載しています。実装を簡単にし、相互運用性を最大化するために、2つのシーケンス番号サイズがサポートされています.16ビットのシーケンス番号と28ビットのシーケンス番号。16ビットのシーケンス番号は、いくつかの種類のレガシクライアントをサポートするために必要です。28ビットのシーケンス番号は、高速ネットワークでは、シーケンス番号スペースがフライト内に折り返されないようにするために必要な状況で使用されます。
The LSP used to forward the DetNet packet is not restricted regarding any method used for establishing that LSP (for example, MPLS-LDP, MPLS-TE, MPLS-TP [RFC5921], MPLS Segment Routing [RFC8660], etc.). The F-Label(s) and the S-Label may be used alone or together to indicate the required queue processing as well as the forwarding parameters. Note that the possible use of Penultimate Hop Popping (PHP) means that the S-Label may be the only label received at the terminating DetNet service.
Detnetパケットを転送するために使用されるLSPは、そのLSPを確立するために使用される方法に関して制限されません（たとえば、MPLS-LDP、MPLS-TE、MPLS-TP [RFC5921]、MPLSセグメントルーティング[RFC8660]など）。FラベルおよびSラベルは、必要なキュー処理ならびに転送パラメータを示すために単独でまたは一緒に使用されてもよい。最後から集中ホップポップピング（PHP）の使用可能な使用は、Sラベルが終端のDetnetサービスで受信された唯一のラベルである可能性があることに注意してください。
Figure 4 illustrates a DetNet data plane MPLS encapsulation. The MPLS-based encapsulation of the DetNet flows is well suited for the scenarios described in [RFC8938]. Furthermore, an end-to-end DetNet service, i.e., native DetNet deployment (see Section 3.2), is also possible if DetNet end systems are capable of initiating and terminating MPLS-encapsulated packets.
図4は、DetnetデータプレーンMPLSカプセル化を示す。Detnet FlowのMPLSベースのカプセル化は、[RFC8938]に記載されているシナリオに最適です。さらに、DetNet End SystemsがMPLSカプセル化されたパケットを開始し終了することができる場合、エンドツーエンドのDetnetサービス、すなわちネイティブDetnet展開（セクション3.2を参照）が可能である。
The MPLS-based DetNet data plane encapsulation consists of:
MPLSベースのDetNetデータプレーンのカプセル化は次のもので構成されています。
* A DetNet Control Word (d-CW) containing sequencing information for packet replication and duplicate elimination purposes, and the OAM indicator.
* パケットレプリケーションのシーケンス情報と重複排除目的、およびOAMインジケータを含むDetNet制御ワード（D - CW）。
* A DetNet service label (S-Label) that identifies a DetNet flow at the receiving DetNet service sub-layer processing node.
* 受信したDetNetサービスサブレイヤ処理ノードでDetNetフローを識別するDetNetサービスラベル（Sラベル）。
* Zero or more DetNet MPLS forwarding label(s) (F-Label) used to direct the packet along the Label Switched Path (LSP) to the next DetNet service sub-layer processing node along the path. When PHP is in use, there may be no F-Label in the protocol stack on the final hop.
* ゼロ以上のDETNET MPLS転送ラベル（Fラベル）（Fラベル）ラベルスイッチド経路（LSP）に沿ってパケットをパスに沿って次のDetnet Serviceサブレイヤ処理ノードに送信するために使用されます。PHPが使用されている場合、最終ホップ上のプロトコルスタックにFラベルがない可能性があります。
* The necessary data-link encapsulation is then applied prior to transmission over the physical media.
* 必要なデータリンクカプセル化は、物理メディアを介した伝送の前に適用される。
DetNet MPLS-based encapsulation
Detnet MPLSベースのカプセル化
+---------------------------------+
| |
| DetNet App-Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+---------------------------------+ +--> DetNet data plane
| S-Label | | MPLS encapsulation
+---------------------------------+ |
| [ F-Label(s) ] | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 4: Encapsulation of a DetNet App-Flow in an MPLS PSN
図4：MPLS PSN内のDetNetアプリケーションフローのカプセル化
A DetNet Control Word (d-CW) conforms to the Generic PW MPLS Control Word (PWMCW) defined in [RFC4385]. The d-CW formatted as shown in Figure 5 MUST be present in all DetNet packets containing App-flow data. This format of the d-CW was created in order to (1) allow larger sequence number space to avoid sequence number rollover frequency in some applications and (2) allow sequence numbering systems that include the value zero as a valid sequence number, which simplifies implementation.
DetNet Control Word（D-CW）は、[RFC4385]で定義されている一般的なPW MPLS制御ワード（PWMCW）に準拠しています。図5に示すようにフォーマットされたD-CWは、アプリフローデータを含むすべてのDetNetパケットに存在する必要があります。D-CWのこのフォーマットは、（1）のように、（1）より大きなシーケンス番号スペースを使用してシーケンス番号のロールオーバー周波数を回避し、（2）値0を有効なシーケンス番号としてゼロを含むシーケンス番号付けシステムを許可します。実装。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DetNet Control Word
図5：Detnet Control Word
(bits 0 to 3) Per [RFC4385], MUST be set to zero (0).
（RFC4385]ごとに（ビット0~3）、ゼロ（0）に設定する必要があります。
Sequence Number (bits 4 to 31) An unsigned value implementing the DetNet sequence number. The sequence number space is a circular one with no restriction on the initial value.
シーケンス番号（ビット4~31）DetNetシーケンス番号を実装する符号なし値。シーケンス番号スペースは、初期値に制限がない円形のものです。
A separate sequence number space MUST be maintained by the node that adds the d-CW for each DetNet App-flow, i.e., DetNet service. The following Sequence Number field lengths MUST be supported:
各DETNETアプリフロー、すなわちDetNetサービスに対してD - CWを追加するノードによって別々のシーケンス番号スペースを維持する必要があります。次のシーケンス番号フィールド長をサポートする必要があります。
* 0 bits
* 0ビット
* 16 bits
* 16ビット
* 28 bits
* 28ビット
The sequence number length MUST be provisioned on a per-DetNet-service basis via configuration, i.e., via the Controller Plane described in [RFC8938].
シーケンス番号の長さは、設定、すなわち[RFC8938]に記載されているコントローラプレーンを介してDETENTENTEサービスごとにプロビジョニングされなければならない。
A 0-bit Sequence Number field length indicates that there is no DetNet sequence number used for the flow. When the length is zero, the Sequence Number field MUST be set to zero (0) on all packets sent for the flow.
0ビットのシーケンス番号フィールド長は、フローに使用されるDetNetシーケンス番号がないことを示します。長さがゼロの場合、フローに対して送信されたすべてのパケットでシーケンス番号フィールドをゼロ（0）に設定する必要があります。
When the Sequence Number field length is 16 or 28 bits for a flow, the sequence number MUST be incremented by one for each new App-flow packet sent. When the field length is 16 bits, d-CW bits 4 to 15 MUST be set to zero (0). The values carried in this field can wrap, and it is important to note that zero (0) is a valid field value. For example, where the sequence number size is 16 bits, the sequence will contain: 65535, 0, 1, where zero (0) is an ordinary sequence number.
シーケンス番号フィールド長がフローに対して16または28ビットの場合、シーケンス番号は送信された新しいAppフローパケットごとに1つずつインクリメントされなければなりません。フィールド長が16ビットの場合、D-CWビット4~15はゼロ（0）に設定する必要があります。このフィールドで搬送されている値はラップでき、ゼロ（0）が有効なフィールド値であることに注意することが重要です。たとえば、シーケンス番号サイズが16ビットの場合、シーケンスには65535,0,1、ゼロ（0）が通常のシーケンス番号です。
It is important to note that this document differs from [RFC4448], where a sequence number of zero (0) is used to indicate that the sequence number check algorithm is not used.
この文書は[RFC4448]とは異なるため、シーケンス番号確認アルゴリズムが使用されていないことを示すためにゼロ（0）のシーケンス番号を使用します。
The sequence number is optionally used during receive processing, as described below in Sections 4.2.2.2 and 4.2.2.3.
以下のセクション4.2.2.2および4.2.2.3で説明するように、シーケンス番号は受信処理中に任意に使用されます。
A DetNet flow at the DetNet service sub-layer is identified by an S-Label. MPLS-aware DetNet end systems and edge nodes, which are by definition MPLS ingress and egress nodes, MUST add (push) and remove (pop) a DetNet service-specific d-CW and S-Label. Relay nodes MAY swap S-Label values when processing a DetNet flow, i.e., incoming and outgoing S-Labels of a DetNet flow can be different.
DetNet ServiceサブレイヤのDetNetフローは、Sラベルによって識別されます。Definition MPLSの入力と出力ノードによるMPLS対応Detnet End SystemsおよびEdgeノードは、Detnet Service固有のD-CWとSラベルを追加（プッシュ）し（POP）しなければなりません。RELAYノードは、DetNetフロー、すなわちDetNet Netフローの着信および発信Sラベルを処理するときにSラベル値をスワップすることができる。
S-Label values MUST be provisioned per DetNet service via configuration, i.e., via the Controller Plane described in [RFC8938]. Note that S-Labels provide identification at the downstream DetNet service sub-layer receiver, not the sender. As such, S-Labels MUST be allocated by the entity that controls the service sub-layer receiving a node's label space and MAY be allocated from the platform label space [RFC3031]. Because S-Labels are local to each node, rather than being a global identifier within a domain, they must be advertised to their upstream DetNet service-aware peer nodes (i.e., a DetNet MPLS end system or a DetNet relay or edge node) and interpreted in the context of their received F-Label(s). In some PREOF topologies, the node performing replication will be sending to multiple nodes performing PEF or POF and may need to send different S-Label values for the different member flows for the same DetNet service.
Sラベル値は、[RFC8938]に記載されている構成、すなわちコントローラプレーンを介してDETNETサービスごとにプロビジョニングする必要があります。Sラベルは、送信者ではなくダウンストリームDetnetサービスサブレイヤレシーバで識別を提供します。そのため、Sラベルは、ノードのラベルスペースを受信したサービスサブレイヤを制御するエンティティによって割り当てられ、プラットフォームラベルスペース[RFC3031]から割り当てることができます。Sラベルはドメイン内のグローバル識別子であるのではなく、各ノードのローカルであるため、それらを上流のDetnetサービス対応ピアノード（すなわち、Detnet MPLSエンドシステムまたはDetNet RelayまたはEdge Node）にアドバタイズする必要があります。受信したFラベルの文脈で解釈されます。いくつかのPROFトポロジでは、レプリケーションを実行するノードは、PEFまたはPOFを実行する複数のノードに送信され、同じDetNetサービスに対して異なるメンバーフローに対して異なるSラベル値を送信する必要があるかもしれません。
An S-Label will normally be at the bottom of the label stack once the last F-Label is removed, immediately preceding the d-CW. To support OAM at the service sub-layer level, an OAM Associated Channel Header (ACH) [RFC4385] together with a Generic Associated Channel Label (GAL) [RFC5586] MAY be used in place of a d-CW.
D-CWの直前の最後のFラベルが除去されると、Sラベルがラベルスタックの下部にあります。サービスサブレイヤーレベルでOAMをサポートするために、GENIAL関連チャネルラベル（GAL）[RFC5586]とともにOAM関連チャネルヘッダー（ACH）[RFC4385]をD-CWの代わりに使用できます。
Similarly, an Entropy Label Indicator (ELI) and Entropy Label (EL) [RFC6790] MAY be carried below the S-Label in the label stack in networks where DetNet flows would otherwise receive ECMP treatment. When ELs are used, the same EL value SHOULD be used for all of the packets sent using a specific S-Label to force the flow to follow the same path. However, as outlined in [RFC8938], the use of ECMP for DetNet flows is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows within a DetNet domain.
同様に、エントロピーラベルインジケータ（ELI）およびエントロピーラベル（EL）[RFC6790]は、DetNetフローがそうでなければECMP処理を受信するネットワーク内のラベルスタック内のSラベルの下に運ばれてもよい。ELSを使用すると、特定のSラベルを使用して送信されたすべてのパケットに同じEL値を使用してフローを同じパスに従って強制的に使用する必要があります。ただし、[RFC8938]で概説されているように、Detnet FlowのECMPの使用はお勧めできません。ECMPは、DetNetドメイン内の非DETNETフローに使用できます。
When receiving a DetNet MPLS packet, an implementation MUST identify the DetNet service associated with the incoming packet based on the S-Label. When a node is using platform labels for S-Labels, no additional information is needed, as the S-Label uniquely identifies the DetNet service. In the case where platform labels are not used, zero or more F-Labels proceeding the S-Label MUST be used together with the S-Label to uniquely identify the DetNet service associated with a received packet. The incoming interface MAY also be used together with any present F-Label(s) and the S-Label to uniquely identify an incoming DetNet service, for example, in the case where PHP is used. Note that the choice to use the platform label space for an S-Label or an S-Label plus one or more F-Labels to identify DetNet services is a local implementation choice, with one caveat. When one or more F-Labels, or the incoming interface, is needed together with an S-Label to uniquely identify a service, the Controller Plane must ensure that incoming DetNet MPLS packets arrive with the needed information (F-Label(s) and/or the incoming interface) and provision the needed information. The provisioned information MUST then be used to identify incoming DetNet service based on the combination of S-Label and F-Label(s) or the incoming interface.
Detnet MPLSパケットを受信すると、実装はSラベルに基づいて着信パケットに関連するDetNetサービスを識別する必要があります。 S-LabelがDetNetサービスを一意に識別するため、ノードがSラベルにプラットフォームラベルを使用している場合は、追加情報は必要ありません。プラットフォームラベルが使用されていない場合には、Sラベルを進める0個以上のFラベルをSラベルと一緒に使用して、受信したパケットに関連付けられたDetNetサービスを一意に識別する必要があります。入ってくるインターフェースはまた、任意のFラベルとSラベルと共に使用されて、例えばPHPが使用される場合には着信Detnetサービスを一意に識別することができる。 SラベルまたはSラベルにプラットフォームのラベルスペースを使用することを選択することは、DetNet Servicesを識別するための1つまたは複数のFラベルに1つまたは複数のFラベルを加えて、1つの警告を使用して、ローカル実装の選択です。 1つ以上のFラベル、または着信インターフェースがSラベルと一緒に必要な場合、サービスを一意に識別するためにSラベルと一緒に必要な場合、コントローラプレーンは、受信したDetnet MPLSパケットが必要な情報（FラベルS）に到着させることを保証する必要があります。 /または着信インタフェース）と必要な情報をプロビジョニングします。プロビジョニングされた情報は、SラベルとFラベルの組み合わせまたは着信インターフェースの組み合わせに基づいて着信Detnetサービスを識別するために使用されなければなりません。
The use of platform labels for S-Labels matches other pseudowire encapsulations for consistency, but there is no hard requirement in this regard.
Sラベル用のプラットフォームラベルの使用は、一貫性のために他の疑似回線のカプセル化に一致していますが、この点に関して難しい要件はありません。
Implementation details of PREOF are out of scope for this document. [IEEE802.1CB-2017] defines equivalent replication and elimination-specific aspects, which can be applied to PRF and PEF.
PREOFの実装詳細はこの文書の範囲外です。[IEEE802.1cb-2017]は、PRFとPEFに適用できる同等の複製と排除特異的側面を定義します。
The Packet Replication Function (PRF) MAY be supported by an implementation for outgoing DetNet flows. The use of the PRF for a particular DetNet service MUST be provisioned via configuration, i.e., via the Controller Plane described in [RFC8938]. When replication is configured, the same App-flow data will be sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs. An S-Label value MUST be configured per outgoing member flow. The same d-CW field value MUST be used on all outgoing member flows for each replicated MPLS packet.
パケット複製機能（PRF）は、発信DetNetフローの実装によってサポートされてもよい。特定のDetNetサービスのためのPRFの使用は、構成、すなわち[RFC8938]に記載されているコントローラプレーンを介してプロビジョニングする必要がある。レプリケーションが設定されている場合、転送サブレイヤLSPを使用して、同じApp-Flowデータが複数の送信DetNetメンバーフローを介して送信されます。Sラベル値は、発信メンバーフローごとに設定する必要があります。レプリケートされたMPLSパケットごとに、同じD-CWフィールド値をすべての送信メンバーフローに使用する必要があります。
Implementations MAY support the Packet Elimination Function (PEF) for received DetNet MPLS flows. When supported, use of the PEF for a particular DetNet service MUST be provisioned via configuration, i.e., via the Controller Plane described in [RFC8938].
実装は、受信したDetNet MPLSフローのためのパケット除去機能（PEF）をサポートすることができる。サポートされると、特定のDetNetサービスのためのPEFの使用は、構成、すなわち[RFC8938]に記載されているコントローラプレーンを介してプロビジョニングする必要がある。
After a DetNet service is identified for a received DetNet MPLS packet, as described above, if PEF is configured for that DetNet service, duplicate (replicated) instances of a particular sequence number MUST be discarded. The specific mechanisms used for an implementation to identify which received packets are duplicates and which are new is an implementation choice. Note that, per Section 4.2.1, the Sequence Number field length may be 16 or 28 bits, and the field value can wrap. PEF MUST NOT be used with DetNet flows configured with a d-CW Sequence Number field length of 0 bits.
上述のように、受信したDetNet MPLSパケットに対してDetNetサービスが識別された後、そのDetNetサービスに対してPEFが構成されている場合、特定のシーケンス番号の重複（複製）インスタンスを破棄する必要があります。どの受信したパケットが重複していて新しいものが新たなものである実装に使用される特定のメカニズムは実装の選択です。なお、セクション4.2.1ごとに、シーケンス番号フィールド長は16または28ビットで、フィールド値は折り返すことができます。D-CWシーケンス番号フィールド長0ビットで構成されたDETNETフローでは、PEFを使用しないでください。
An implementation MAY constrain the maximum number of sequence numbers that are tracked on either a platform-wide or per-flow basis. Some implementations MAY support the provisioning of the maximum number of sequence numbers that are tracked on either a platform-wide or per-flow basis.
実装は、プラットフォーム全体またはフローベースで追跡されるシーケンス番号の最大数を制限することがあります。いくつかの実装形態は、プラットフォーム全体またはフローベースで追跡されるシーケンス番号の最大数のプロビジョニングをサポートすることができる。
A function that is related to in-order delivery is the Packet Ordering Function (POF). Implementations MAY support POF. When supported, use of the POF for a particular DetNet service MUST be provisioned via configuration, i.e., via the Controller Plane described by [RFC8938]. Implementations MAY require that PEF and POF be used in combination. There is no requirement related to the order of execution of the PEF and POF in an implementation.
注文配信に関連する機能は、パケット順序付け機能（POF）です。実装はPOFをサポートするかもしれません。サポートされている場合、特定のDetnetサービスのためのPOFの使用は、構成、すなわち[RFC8938]によって記述されたコントローラプレーンを介してプロビジョニングされなければならない。実装には、PEFとPOFを組み合わせて使用する必要があります。実装におけるPEFとPOFの実行順序に関連する要件はありません。
After a DetNet service is identified for a received DetNet MPLS packet, as described above, if POF is configured for that DetNet service, packets MUST be processed in the order indicated in the received d-CW Sequence Number field, which may not be in the order the packets are received. As defined in Section 4.2.1, the Sequence Number field length may be 16 or 28 bits, the sequence number is incremented by one (1) for each new MPLS packet sent for a particular DetNet service, and the field value can wrap. The specific mechanisms used for an implementation to identify the order of received packets is an implementation choice.
上述のように、受信したDetNet MPLSパケットについてDetNetサービスが識別された後、POFがそのDetNetサービスに対して構成されている場合、パケットは受信したD-CWシーケンス番号フィールドに示されている順序で処理されなければならず、注文パケットを受信します。セクション4.2.1で定義されているように、シーケンス番号フィールド長は16または28ビットであり得るが、シーケンス番号は特定のDetNetサービスに対して送信された新しいMPLSパケットごとに1つずつインクリメントされ、フィールド値は折り返されます。受信パケットの順序を識別するために実装に使用される特定のメカニズムは実装の選択です。
An implementation MAY constrain the maximum number of out-of-order packets that can be processed on either a platform-wide or per-flow basis. The number of out-of-order packets that can be processed also impacts the latency of a flow.
実装は、プラットフォーム全体またはフローベースで処理できる順不同パケットの最大数を制限することがあります。処理できる順序外パケットの数もフローの待ち時間に影響を与えます。
The latency impact on the system resources needed to support a specific DetNet flow will need to be evaluated by the Controller Plane based on that flow's traffic specification. An example traffic specification that can be used with MPLS-TE can be found in [RFC2212].
特定のDetnetフローをサポートするのに必要なシステムリソースへの待ち時間の影響は、そのフローのトラフィック仕様に基づいてコントローラプレーンによって評価される必要があります。MPLS-TEで使用できるトラフィック仕様の例を[RFC2212]にあります。
DetNet implementations can use flow-specific requirements (e.g., maximum number of out-of-order packets and maximum latency of the flow) for configuration of POF-related buffers. POF implementation details are out of scope for this document, and POF configuration parameters are implementation specific. The Controller Plane identifies and sets the POF configuration parameters.
DetNet実装は、POF関連バッファを構成するためのフロー固有の要件（例えば、最大順序のパケットの最大数とフローの最大待ち時間）を使用できます。POF実装の詳細はこの文書の範囲外で、POF構成パラメータは実装固有です。コントローラプレーンは、POF構成パラメータを識別して設定します。
F-Labels support the DetNet forwarding sub-layer. F-Labels are used to provide LSP-based connectivity between DetNet service sub-layer processing nodes.
FラベルはDetNet転送サブレイヤをサポートします。Fラベルは、DetNetサービスサブレイヤ処理ノード間でLSPベースの接続を提供するために使用されます。
DetNet MPLS end systems, edge nodes, and relay nodes may operate at the DetNet service sub-layer with understanding of DetNet services and their requirements. As mentioned earlier, when operating at this layer, such nodes can push, pop, or swap (pop then push) S-Labels. In all cases, the F-Label(s) used for a DetNet service are always replaced, and the following procedures apply.
Detnet MPLSエンドシステム、エッジノード、および中継ノードは、DetNetサービスのサブレイヤーでDetnetサービスとその要件を理解することができます。前述のように、このレイヤで動作するとき、そのようなノードはSラベルを押す（POPから押す）（POP）を押すことができます。すべての場合において、DetNetサービスに使用されるFラベルは常に置き換えられ、以下の手順が適用されます。
When sending a DetNet flow, zero or more F-Labels MAY be pushed on top of an S-Label by the node pushing an S-Label. The F-Label(s) to be pushed when sending a particular DetNet service MUST be provisioned per outgoing S-Label via configuration, i.e., via the Controller Plane discussed in [RFC8938]. F-Label(s) can also provide context for an S-Label. To allow for the omission of F-Label(s), an implementation SHOULD also allow an outgoing interface to be configured per S-Label.
Detnet Flowを送信するとき、ゼロ以上のFラベルは、Sラベルを押すノードによってSラベルの上に押すことができます。特定のDETNETサービスを送信するときにプッシュされるFラベルは、構成を介して、すなわち[RFC8938]で説明されているコントローラプレーンを介して発信Sラベルごとにプロビジョニングされなければならない。FラベルはSラベルの文脈を提供することもできます。Fラベルの省略を可能にするために、実装はまた、Sラベルごとに発信インタフェースを設定できるようにする必要があります。
Note that when PRF is supported, the same App-flow data will be sent over multiple outgoing DetNet member flows using forwarding sub-layer LSPs. This means that an implementation may be sending different sets of F-Labels per DetNet member flow, each with a different S-Label.
PRFがサポートされている場合、転送サブレイヤLSPを使用して、同じAppフローデータが複数の送信DetNetメンバーフローを介して送信されます。これは、実装がDetNetメンバの流れごとに異なるセットのFラベルを送信している可能性があり、それぞれ異なるSラベルを持つ。
When a single set of F-Labels is provisioned for a particular outgoing S-Label, that set of F-Labels MUST be pushed after the S-Label is pushed. The outgoing packet is then forwarded, as described below in Section 4.2.3.2. When a single outgoing interface is provisioned, the outgoing packet is then forwarded, as described below in Section 4.2.3.2.
単一のFラベルが特定の発信Sラベルに対してプロビジョニングされると、Sラベルが押された後にFラベルのセットを押す必要があります。次に、4.2.3.2項で説明するように、発信パケットが転送されます。単一の発信インターフェイスがプロビジョニングされると、次に説明するように、発信パケットが転送されます。
When multiple sets of outgoing F-Labels or interfaces are provisioned for a particular DetNet service (i.e., for PRF), a copy of the outgoing packet, including the pushed member flow-specific S-Label, MUST be made per F-Label set and outgoing interface. Each set of provisioned F-Labels are then pushed onto a copy of the packet. Each copy is then forwarded, as described below in Section 4.2.3.2.
複数のセットの発信Fラベルまたはインターフェースが特定のDetNetサービス（PRFの場合）にプロビジョニングされている場合、プッシュされたメンバーフロー固有のSラベルを含む発信パケットのコピーをFラベルセットごとに行う必要があります。そして発信インターフェース。プロビジョニングされたFラベルの各セットは、パケットのコピーにプッシュされます。次に、4.2.3.2項で以下に説明するように、各コピーが転送されます。
As described in the previous section, when receiving a DetNet MPLS flow, an implementation identifies the DetNet service associated with the incoming packet based on the S-Label. When a node is using platform labels for S-Labels, any F-Labels can be popped, and the S-Label uniquely identifies the DetNet service. In the case where platform labels are not used, incoming F-Label(s) and, optionally, the incoming interface MUST also be provisioned for a DetNet service.
前のセクションで説明されているように、Detnet MPLSフローを受信すると、実装は、Sラベルに基づいて着信パケットに関連するDetNetサービスを識別する。ノードがSラベルにプラットフォームラベルを使用している場合、Fラベルをポップすることができ、SラベルはDetNetサービスを一意に識別します。プラットフォームラベルが使用されていない場合は、着信Fラベルと任意選択で、着信インタフェースをDetNetサービスのためにプロビジョニングする必要があります。
All DetNet-aware MPLS nodes process F-Labels as needed to meet the service requirements of the DetNet flow or flows carried in the LSPs represented by the F-Labels. This includes normal push, pop, and swap operations. Such processing is essentially the same type of processing provided for TE LSPs, although the specific service parameters, or traffic specification, can differ. When the DetNet service parameters of the DetNet flow or flows carried in an LSP represented by an F-Label can be met by an existing TE mechanism, the forwarding sub-layer processing node MAY be a DetNet-unaware, i.e., standard, MPLS LSR. Such TE LSPs may provide LSP forwarding service as defined in, but not limited, to the following: [RFC3209], [RFC3270], [RFC3272], [RFC3473], [RFC4875], [RFC5440], and [RFC8306].
すべてのDetnet対応MPLSノードは、Fラベルによって表されるLSPで運ばれるDetNetフローまたはフローのサービス要件を満たすために必要に応じてFラベルを処理します。これには、通常のプッシュ、POP、スワップ操作が含まれます。そのような処理は、本質的にTE LSPに対して提供された同じ種類の処理であるが、特定のサービスパラメータ、またはトラフィック仕様は異なるであろう。Fラベルによって表されるLSPで運ばれるDetNetフローまたはフローのDetnetサービスパラメータを既存のTEメカニズムによって満たすことができる場合、転送サブレイヤ処理ノードはDetnet - Nataware、すなわち標準、MPLS LSRであり得る。。このようなTE LSPは、次のように定義されているがこれらに限定されないが、以下のようにLSP転送サービスを提供することができる。[RFC3209]、[RFC3272]、[RFC3473]、[RFC4875]、[RFC8306]。
More specifically, as mentioned above, the DetNet forwarding sub-layer provides explicit routes and allocated resources, and F-Labels are used to map to each. Explicit routes are supported based on the topmost (outermost) F-Label that is pushed or swapped and the LSP that corresponds to this label. This topmost (outgoing) label MUST be associated with a provisioned outgoing interface and, for non-point-to-point outgoing interfaces, a next-hop LSR. Note that this information MUST be provisioned via configuration or the Controller Plane. In the previously mentioned special case where there are no added F-Labels and the outgoing interface is not a point-to-point interface, the outgoing interface MUST also be associated with a next-hop LSR.
具体的には、上述のように、DetNet Forwardingサブレイヤは明示的なルートを提供し、割り当てられたリソースを提供し、Fラベルはそれぞれにマッピングされます。明示的なルートは、プッシュまたはスワップされ、このラベルに対応するLSPがプッシュまたはスワップされた最上位（最も外側）Fラベルに基づいてサポートされています。この一番上の（発信）ラベルは、プロビジョニングされた発信インターフェイス、および非ポイントツーポイントの発信インターフェイス、ネクストホップLSRに関連付けられている必要があります。この情報は構成またはコントローラの平面を介してプロビジョニングする必要があります。前述の特別な場合では、追加されたFラベルがなく、発信インターフェイスがポイントツーポイントインターフェイスではない場合、発信インターフェイスもネクストホップLSRに関連付ける必要があります。
Resources may be allocated in a hierarchical fashion per each LSP that is represented by each F-Label. Each LSP MAY be provisioned with a service parameter that dictates the specific traffic treatment to be received by the traffic carried over that LSP. Implementations of this document MUST ensure that traffic carried over each LSP represented by one or more F-Labels receives the traffic treatment provisioned for that LSP. Typical mechanisms used to provide different treatment to different flows include the allocation of system resources (such as queues and buffers) and provisioning of related parameters (such as shaping and policing) that may be found in implementations of the Resource ReSerVation Protocol (RSVP) [RFC2205] and RSVP-TE [RFC3209] [RFC3473]. Support can also be provided via an underlying network technology, such as IEEE 802.1 TSN [DetNet-MPLS-over-TSN]. The specific mechanisms selected by a DetNet node to ensure DetNet service delivery requirements are met for supported DetNet flows is outside the scope of this document.
各Fラベルによって表される各LSPごとにリソースを階層的に割り当てることができる。各LSPは、そのLSPを介して運ばれるトラフィックによって受信されるべき特定のトラフィック処理を決定するサービスパラメータを使用することができる。この文書の実装は、1つ以上のFラベルによって表される各LSPに対して伝送されるトラフィックが、そのLSPのためにプロビジョニングされたトラフィック処理を受け取ることを保証しなければなりません。異なるフローに異なる扱いを提供するために使用される典型的なメカニズムは、リソース予約プロトコルの実装（RSVP）の実装に見られる可能性があるシステムリソースの割り当て（キューやバッファなど）と関連パラメータ（シェーピングやポリシングなど）のプロビジョニングに含まれる。 RFC2205とRSVP-TE [RFC3209] [RFC3473]。 IEEE 802.1 TSN [Detnet-MPLS-OVER-TSN]など、基礎となるネットワークテクノロジを介してサポートを提供することもできます。 Detnet Service Delivery要件を確実にするためにDetnetノードによって選択された特定のメカニズムは、サポートされているDetnetフローに対して満たされています。この文書の範囲外です。
Packets that are marked in a way that do not correspond to allocated resources, e.g., lack a provisioned F-Label, can disrupt the QoS offered to properly reserved DetNet flows by using resources allocated to the reserved flows. Therefore, the network nodes of a DetNet network:
割り当てられたリソースに対応しない方法でマークされているパケットは、プロビジョニングされたFラベルを欠いていますが、予約されたフローに割り当てられたリソースを使用することによって、適切に予約されたDetNet Flowsに提供されるQoSを中断することができます。したがって、DetNetネットワークのネットワークノード
* MUST defend the DetNet QoS by discarding or remarking (to an allocated DetNet flow or noncompeting non-DetNet flow) packets received that are not associated with a completed resource allocation.
* 完了したリソース割り当てに関連付けられていない受信された受信された受信された受信された受信された受信された受信されたパケットを廃棄または廃棄することによってDetnet QoSを守る必要があります。
* MUST NOT use a DetNet allocated resource, e.g., a queue or shaper reserved for DetNet flows, for any packet that does match the corresponding DetNet flow.
* 対応するDetNetフローと一致する任意のパケットについて、DetNet割り当てられたリソース、例えばDetnetフロー用のキューまたはシェーパーを使用しないでください。
* MUST ensure a QoS flow does not exceed its allocated resources or provisioned service level.
* QoSフローが割り当てられたリソースまたはプロビジョニングされたサービスレベルを超えないようにする必要があります。
* MUST ensure a CoS flow or service class does not impact the service delivered to other flows. This requirement is similar to the requirement for MPLS LSRs that CoS LSPs do not impact the resources allocated to TE LSPs, e.g., via [RFC3473].
* COSフローまたはサービスクラスが他のフローに配信されるサービスに影響を与えないようにする必要があります。この要件は、COS LSPがTE LSPに割り当てられたリソースに影響を与えないMPLS LSRの要求と似ています。例えば、[RFC3473]
Subsequent sections provide additional considerations related to CoS (Section 4.6.1), QoS (Section 4.6.2), and aggregation (Section 4.4).
後続のセクションでは、CoS（4.6.1項）、QoS（4.6.2）、および集約に関する追加の考慮事項を提供します（セクション4.4）。
OAM follows the procedures set out in [RFC5085] with the restriction that only Virtual Circuit Connectivity Verification (VCCV) type 1 is supported.
OAMは、[RFC5085]で設定した手順に従います。仮想回線接続検証（VCCV）タイプ1のみがサポートされていることを制限します。
As shown in Figure 3 of [RFC5085], when the first nibble of the d-CW is 0x0, the payload following the d-CW is normal user data. However, when the first nibble of the d-CW is 0x1, the payload that follows the d-CW is an OAM payload with the OAM type indicated by the value in the d-CW Channel Type field.
[RFC5085]の図3に示すように、D-CWの最初のニブルが0x0の場合、D-CWに続くペイロードは通常のユーザーデータです。ただし、D-CWの最初のニブルが0x1である場合、D-CWに続くペイロードは、D-CW Channel Typeフィールドの値で示されているOAMタイプを持つOAMペイロードです。
The reader is referred to [RFC5085] for a more detailed description of the Associated Channel mechanism and to the DetNet work on OAM [DetNet-MPLS-OAM] for more information about DetNet OAM.
Detnet OAMの詳細については、関連付けられているチャネルメカニズムの詳細については、リーダーを[RFC5085]と呼ばれます。
Additional considerations on DetNet-specific OAM are subjects for further study.
Detnet固有のOAMに関するさらなる考慮事項は、さらなる研究の対象です。
The ability to aggregate individual flows and their associated resource control into a larger aggregate is an important technique for improving scaling of control in the data, management, and control planes. The DetNet data plane allows for the aggregation of DetNet flows to improved scaling. There are two methods of supporting flow aggregation covered in this section.
個々のフローを集約する機能とそれらに関連するリソースコントロールは、データ、管理、および制御プレーンにおける制御のスケーリングを改善するための重要な手法です。DetNetデータプレーンは、DetNet Flowの集約がスケーリングの向上を可能にします。このセクションで覆われているフロー集約をサポートする方法は2つあります。
The resource control and management aspects of aggregation (including the configuration of queuing, shaping, and policing) are the responsibility of the DetNet Controller Plane and are out of scope for this document. It is also the responsibility of the Controller Plane to ensure that consistent aggregation methods are used.
集約のリソース制御と管理の側面（キューイング、シェーピング、およびポリシングの設定を含む）は、DetNet Controller Planeの責任であり、この文書の範囲外です。一貫した集計方法が確実に使用されるように、コントローラプレーンの責任でもあります。
DetNet flows forwarded via MPLS can leverage MPLS-TE's existing support for hierarchical LSPs (H-LSPs); see [RFC4206]. H-LSPs are typically used to aggregate control and resources; they may also be used to provide OAM or protection for the aggregated LSPs. Arbitrary levels of aggregation naturally fall out of the definition for hierarchy and the MPLS label stack [RFC3032]. DetNet nodes that support aggregation (LSP hierarchy) map one or more LSPs (labels) into and from an H-LSP. Both carried LSPs and H-LSPs may or may not use the Traffic Class (TC) field, i.e., L-LSPs (Label-Only-Inferred-PSC LSPs) or E-LSPs (EXP-Inferred-PSC LSPs [RFC3270], which were renamed to "Explicitly TC-encoded-PSC LSPs" in Section 2.2 of [RFC5462]). Such nodes will need to ensure that individual LSPs and H-LSPs receive the traffic treatment required to ensure the required DetNet service is preserved.
MPLSを介して転送されたDetnet Flowsは、MPLS-TEの既存のサポートを階層的LSP（H-LSP）に利用することができます。[RFC4206]を参照してください。H-LSPは通常、コントロールとリソースを集約するために使用されます。それらはまた、凝集したLSPのOAMまたは保護を提供するために使用され得る。任意のレベルの集約は、階層の定義とMPLSラベルスタック[RFC3032]の定義から自然に解決されます。集約（LSP階層）をサポートするDetNetノード（LSP階層）は、H-LSPへの1つ以上のLSP（ラベル）をマッピングします。携帯LSPとH - LSPの両方が、トラフィッククラス（TC）フィールド、すなわちL - LSP（Label-only-PSP LSP）またはE-LSPを使用してもしなくてもよい（exp-推論-PSC LSPS [RFC3270]、これは[RFC5462]のセクション2.2の「明示的にTC-Encoded-PSC LSP」に改名されました。そのようなノードは、個々のLSPとH-LSPが必要なDetNetサービスが保持されていることを保証するために必要なトラフィック処理を受けることを保証する必要があります。
Additional details of the traffic control capabilities needed at a DetNet-aware node may be covered in the new service definitions mentioned above or in separate future documents. Controller Plane mechanisms will also need to ensure that the service required on the aggregate flow are provided, which may include the discarding or remarking mentioned in the previous sections.
Detnet対応ノードで必要とされるトラフィック制御機能の詳細は、上記の新しいサービス定義で、または別々の将来の文書で説明されている可能性があります。コントローラ平面メカニズムはまた、集約フローに必要なサービスが提供されることを確実にする必要があり、前述のセクションで説明した廃棄または緩和を含むことができる。
An aggregate can be built by layering DetNet flows, including both their S-Label and (when present) F-Labels, as shown below:
以下に示すように、Sラベルと（現在）Fラベルの両方を含むDetNet Flowを階層化することによって集計を作成できます。
+---------------------------------+
| |
| DetNet Flow |
| Payload Packet |
| |
+---------------------------------+ <--\
| DetNet Control Word | |
+=================================+ |
| S-Label | |
+---------------------------------+ |
| [ F-Label(s) ] | +----DetNet data plane
+---------------------------------+ |
| DetNet Control Word | |
+=================================+ |
| A-Label | |
+---------------------------------+ |
| F-Label(s) | <--/
+---------------------------------+
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 6: DetNet Aggregation as a New DetNet Flow
図6：新しいDetnetフローとしてのDetnet集約
Both the aggregation label, which is referred to as an A-Label, and the individual flow's S-Label have their MPLS S bit set indicating the bottom of stack, and the d-CW allows the PREOF to work. An A-Label is a special case of an S-Label, whose properties are known only at the aggregation and deaggregation end points.
A - ラベルと呼ばれる集約ラベルはどちらも、個々のフローのSラベルにスタックの底を示すMPLS Sビットセットがあり、D-CWはPREOFが機能することを可能にします。AラベルはSラベルの特別な場合であり、その性質は凝集および脱凝集端点でのみ知られている。
It is a property of the A-Label that what follows is a d-CW followed by an MPLS label stack. A relay node processing the A-Label would not know the underlying payload type, and the A-Label would be processed as a normal S-Label. This would only be known to a node that was a peer of the node imposing the S-Label. However, there is no real need for it to know the payload type during aggregation processing.
A-ラベルの特性は、以下のものがD-CWとそれに続くMPLSラベルスタックです。Aラベルを処理するリレーノードの処理は、基盤となるペイロードタイプを知らず、aラベルは通常のSラベルとして処理されます。これは、Sラベルを課すノードのピアであったノードにのみ知られています。ただし、集計処理中にペイロードタイプを知るための本当の必要性はありません。
As in the previous section, nodes supporting this type of aggregation will need to ensure that individual and aggregated flows receive the traffic treatment required to ensure the required DetNet service is preserved. Also, it is the Controller Plane's responsibility to ensure that the service required on the aggregate flow is properly provisioned.
前のセクションと同様に、このタイプの集約をサポートするノードは、必要なDetNetサービスを確実に保持するために必要なトラフィック処理を受けることを確実にする必要があります。また、集約フローに必要なサービスが正しくプロビジョニングされていることを確認するのはコントローラプレーンの責任です。
The internal procedures for edge and relay nodes related to PREOF are implementation specific. The order of a packet elimination or replication is out of scope for this specification.
PREOFに関連するエッジおよび中継ノードの内部手順は実装固有のものです。パケット除去または複製の順序は、この仕様の範囲外です。
It is important that the DetNet layer is configured such that a DetNet node never receives its own replicated packets. If it were to receive such packets, the replication function would make the loop more destructive of bandwidth than a conventional unicast loop. Ultimately, the TTL in the S-Label will cause the packet to die during a transient loop, but given the sensitivity of applications to packet latency, the impact on the DetNet application would be severe. To avoid the problem of a transient forwarding loop, changes to an LSP supporting DetNet MUST be loop-free.
DetNetノードが独自の複製パケットを受信しないようにDetNet Layerが構成されていることが重要です。そのようなパケットを受信することであった場合、レプリケーション関数は、従来のユニキャストループよりも帯域幅をより破壊的にすることになるだろう。最終的に、SラベルのTTLは、パケットが一時的なループ中にダイを入れることを引き起こしますが、パケット待ち時間へのアプリケーションの感度が与えられると、DetNetアプリケーションへの影響は厳しくなります。一時的な転送ループの問題を回避するために、DETNETをサポートするLSPへの変更はループフリーでなければなりません。
A DetNet edge node operates in the DetNet forwarding sub-layer and service sub-layer. An edge node is responsible for matching incoming packets to the service they require and encapsulating them accordingly. An edge node may perform PRF, PEF, and/or POF. Details on encapsulation can be found in Section 4.2; details on PRF can be found in Section 4.2.2.1; details on PEF can be found in Section 4.2.2.2; and details on POF can be found in Section 4.2.2.3.
DetNet Edgeノードは、DetNet転送サブレイヤおよびサービスサブレイヤで動作します。エッジノードは、受信パケットを必要なサービスにマッチングし、それに応じてカプセル化する責任があります。エッジノードは、PRF、PEF、および/またはPOFを実行することができる。カプセル化に関する詳細はセクション4.2にあります。PRFの詳細はセクション4.2.2.1にあります。PEFの詳細は4.2.2.2節にあります。そしてPOFの詳細はセクション4.2.2.3にあります。
A DetNet relay node operates in the DetNet forwarding sub-layer and service sub-layer. For DetNet using MPLS, forwarding-related processing is performed on the F-Label. This processing is done within an extended forwarder function. Whether an incoming DetNet flow receives DetNet-specific processing depends on how the forwarding is programmed. Some relay nodes may be DetNet service aware for certain DetNet services, while, for other DetNet services, these nodes may perform as unmodified LSRs that only understand how to switch MPLS-TE LSPs, i.e., as a transit node; see Section 4.4. Again, this is entirely up to how the forwarding has been programmed.
Detnet Relayノードは、DetNet転送サブレイヤおよびサービスサブレイヤで動作します。MPLSを使用したDetnetの場合、F-Labelで転送関連処理が行われます。この処理は拡張フォワーダ関数内で行われる。着信DetnetフローがDetNet固有の処理を受信するかどうかは、転送がどのようにプログラムされるかによって異なります。いくつかの中継ノードは、特定のDetNetサービスを受信することができ、他のDetNetサービスのために、これらのノードは、MPLS-TE LSP、すなわちトランジットノードを切り替える方法のみを理解している未変性LSRとして実行され得る。セクション4.4を参照してください。繰り返しますが、これは完全に転送がどのようにプログラムされているかまでです。
During the elimination and replication process, the sequence number of an incoming DetNet packet MUST be preserved and carried in the corresponding outgoing DetNet packet. For example, a relay node that performs both PEF and PRF first performs PEF on incoming packets to create a compound flow. It then performs PRF and copies the App-flow data and the d-CW into packets for each outgoing DetNet member flow.
排除および複製プロセス中に、着信Detnolパケットのシーケンス番号を保存して対応する発信DetNetパケットに搭載する必要があります。例えば、PEFとPRFの両方を実行する中継ノードは、最初に受信パケット上でPEFを実行して複合フローを作成する。その後、PRFを実行し、APP-FlowデータとD-CWを発信しているDetNetメンバーの流れごとにパケットにコピーします。
The internal design of a relay node is out of scope for this document. However, the reader's attention is drawn to the need to make any PREOF state available to the packet processor(s) dealing with packets to which PREOF must be applied and to maintain that state in such a way that it is available to the packet processor operation on the next packet in the DetNet flow (which may be a duplicate, a late packet, or the next packet in sequence).
中継ノードの内部設計はこの文書には範囲外です。ただし、リーダーの注意は、PREOFが適用されなければならないパケットを扱うパケットプロセッサで任意のPREOF状態を使用可能にし、それがパケットプロセッサ操作で使用可能になるようにその状態を維持する必要性に描かれています。Detnetフローの次のパケットでは（これは、重複、遅延パケット、または次のパケットでもよい）。
Class of Service (CoS) and Quality of Service (QoS) are terms that are often used interchangeably and confused with each other. In the context of DetNet, CoS is used to refer to mechanisms that provide traffic-forwarding treatment based on non-flow-specific traffic classification, and QoS is used to refer to mechanisms that provide traffic-forwarding treatment based on DetNet flow-specific traffic classification. Examples of existing network-level CoS mechanisms include Differentiated Services (Diffserv), which is enabled by the IP header Differentiated Services Code Point (DSCP) field [RFC2474] and MPLS label Traffic Class field [RFC5462] and at Layer 2 by IEEE 802.1p Priority Code Point (PCP).
サービスクラス（COS）とサービス品質（QoS）は、互換的に互換的に使用され、互いに混同されることが多い用語です。DetNetの文脈では、COSは、非流動特有のトラフィック分類に基づくトラフィック転送処理を提供するメカニズムを指すために使用され、QoSはDetnetフロー固有のトラフィックに基づくトラフィック転送処理を提供するメカニズムを指すために使用されます。分類。既存のネットワークレベルのCOSメカニズムの例には、IPヘッダー微分サービスコードポイント（DSCP）フィールド[RFC2474]およびMPLS Label Traffic Classフィールド[RFC5462]とIEEE 802.1pによるレイヤ2でイネーブルされた差別化サービス（DiffServ）があります。優先順位コードポイント（PCP）。
CoS for DetNet flows carried in PWs and MPLS is provided using the
existing MPLS Differentiated Services (Diffserv) architecture
[RFC3270]. Both E-LSP and L-LSP MPLS Diffserv modes MAY be used to
support DetNet flows. The Traffic Class field (formerly the EXP
field) of an MPLS label follows the definition of [RFC5462] and
[RFC3270]. The Uniform, Pipe, and Short Pipe Diffserv tunneling and
TTL processing models are described in [RFC3270] and [RFC3443] and
MAY be used for MPLS LSPs supporting DetNet flows. MPLS Explicit
Congestion Notification (ECN) MAY also be used, as defined in ECN
[RFC5129] and updated by [RFC5462].
In addition to explicit routes and packet replication and elimination (described in Section 4 above), DetNet provides zero congestion loss and bounded latency and jitter. As described in [RFC8655], there are different mechanisms that may be used separately or in combination to deliver a zero congestion loss service. This includes QoS mechanisms at the MPLS layer, which may be combined with the mechanisms defined by the underlying network layer, such as IEEE 802.1 TSN.
明示的なルートとパケットの複製と消去（上記のセクションで説明されている）に加えて、DetNetは輻輳損失と有界の待ち時間とジッタをゼロにします。[RFC8655]に記載されているように、ゼロ輻輳損失サービスを提供するために別々にまたは組み合わせて使用できるさまざまなメカニズムがあります。これには、MPLS層でのQoSメカニズムが含まれます。これは、IEEE 802.1 TSNなどの基礎となるネットワーク層によって定義されたメカニズムと組み合わせることができます。
QoS mechanisms for flow-specific traffic treatment typically include a guarantee/agreement for the service and allocation of resources to support the service. Example QoS mechanisms include discrete resource allocation, admission control, flow identification and isolation, and sometimes path control, traffic protection, shaping, policing, and remarking. Example protocols that support QoS control include the Resource ReSerVation Protocol (RSVP) [RFC2205] and RSVP-TE [RFC3209] [RFC3473]. The existing MPLS mechanisms defined to support CoS [RFC3270] can also be used to reserve resources for specific traffic classes.
流量特有の交通治療のためのQoSメカニズムは、通常、サービスを支援するためのサービスおよびリソースの割り当てに対する保証/契約を含む。例QoSメカニズムには、ディスクリートリソース割り当て、アドミッションコントロール、フロー識別、および分離、および時にはパス制御、トラフィック保護、シェーピング、ポリシング、およびリマークがあります。QoS制御をサポートするプロトコルには、リソース予約プロトコル（RFC2205]とRSVP-TE [RFC3209] [RFC3473]があります。CoS [RFC3270]をサポートするように定義されている既存のMPLSメカニズムは、特定のトラフィッククラスのリソースを予約するためにも使用できます。
A baseline set of QoS capabilities for DetNet flows carried in PWs and MPLS can be provided by MPLS-TE [RFC3209] [RFC3473]. TE LSPs can also support explicit routes (path pinning). Current service definitions for packet TE LSPs can be found in "Specification of the Controlled-Load Network Element Service" [RFC2211], "Specification of Guaranteed Quality of Service" [RFC2212], and "Ethernet Traffic Parameters" [RFC6003]. Additional service definitions are expected in future documents to support the full range of DetNet services. In all cases, the existing label-based marking mechanisms defined for TE LSPs and even E-LSPs are used to support the identification of flows requiring DetNet QoS.
PWSおよびMPLSで運ばれるDetnet Flowのベースラインセットは、MPLS-TE [RFC3209] [RFC3473]によって提供できます。TE LSPは明示的なルート（パスピン（パスピン）をサポートできます。パケットTE LSPの現在のサービス定義「制御ロードネットワーク要素サービスの指定」[RFC2211]、「保証されたサービス品質の仕様」[RFC2212]、「イーサネットトラフィックパラメータ」[RFC6003]に記載されています。将来のドキュメントでは、Detnet Servicesの全範囲をサポートするための追加のサービス定義が期待されています。全ての場合において、TE LSPおよびE - LSPに対して定義された既存のラベルベースのマーキングメカニズムは、DetNet QoSを必要とするフローの識別をサポートするために使用される。
The specific information needed for the processing of each DetNet service depends on the DetNet node type and the functions being provided on the node. This section summarizes this information based on the DetNet sub-layer and if the DetNet traffic is being sent or received. All DetNet node types are DetNet forwarding sub-layer aware, while all but transit nodes are service sub-layer aware. This is shown in Figure 2.
各DETNETサービスの処理に必要な特定の情報は、DetNet NOノードタイプとノード上に提供されている機能によって異なります。このセクションでは、Detnetサブレイヤに基づいて、DetNetトラフィックが送受信されている場合に基づいてこの情報をまとめたものです。すべてのDetNetノードタイプはDetnet Forwardingサブレイヤー対応ですが、すべてのトランジットノードはサービスサブレイヤー対応です。これを図2に示す。
Much like other MPLS labels, there are a number of alternatives available for DetNet S-Label and F-Label advertisement to an upstream peer node. These include distributed signaling protocols (such as RSVP-TE), centralized label distribution via a controller that manages both the sender and the receiver using the Network Configuration Protocol (NETCONF) and YANG, BGP, the Path Computation Element Communication Protocol (PCEP), etc., and hybrid combinations of the two. The details of the Controller Plane solution required for the label distribution and the management of the label number space are out of scope for this document. Particular DetNet considerations and requirements are discussed in [RFC8938]. Conformance language is not used in the summary, since it applies to future mechanisms, such as those that may be provided in signaling and YANG models, e.g., [DetNet-YANG].
他のMPLSラベルと同じように、Detnet SラベルおよびFラベル広告にアップストリームピアノードへの代替案がいくつかあります。これらには、ネットワーク構成プロトコル（NETCONF）およびYANG、BGP、PATH計算要素通信プロトコル（PCE）を使用して、送信者と受信機の両方を管理するコントローラを介した、分散シグナリングプロトコル（RSVP-TEなど）が含まれます。2つのハイブリッドの組み合わせなど。ラベル分布に必要なコントローラプレーンソリューションの詳細とラベル番号スペースの管理はこの文書に対して範囲外です。特定のDetnetの考慮事項と要件は[RFC8938]で説明されています。シグナリングとYANDモデル、例えば[DetNet-Yang]などの将来のメカニズムに適用されるので、適合言語は概要には使用されません。
The following summarizes the information that is needed (on a per-service basis) on nodes that are service sub-layer aware and transmit DetNet MPLS traffic:
以下は、サービスサブレイヤ認証と送信DetNet MPLSトラフィックであるノード上の（サービスごとに）必要とされる情報を要約しています。
* App-flow identification information, e.g., IP information as defined in [DetNet-IP-over-MPLS]. Note that this information is not needed on DetNet relay nodes.
* アプリフロー識別情報、例えばDetnet-IP-over-MPLSで定義されているIP情報。この情報はDetnet Relayノードでは必要ありません。
* The sequence number length to be used for the service. Valid values include 0, 16, and 28 bits. 0 bits cannot be used when PEF or POF is configured for the service.
* サービスに使用されるシーケンス番号の長さ。有効な値には0,16、および28ビットが含まれます。サービスのためにPEFまたはPOFが設定されている場合は、0ビットを使用できません。
* If PRF is to be provided for the service.
* PRFがサービスの提供される場合。
* The outgoing S-Label for each of the service's outgoing DetNet (member) flows.
* 各サービスの発信Detnet（メンバー）の流れの発信Sラベル。
* The forwarding sub-layer information associated with the output of the service sub-layer. Note that when PRF is provisioned, this information is per DetNet member flow. Logically, the forwarding sub-layer information is a pointer to further details of transmission of DetNet flows at the forwarding sub-layer.
* サービスサブレイヤの出力に関連付けられた転送サブレイヤ情報。PRFがプロビジョニングされると、この情報はDetnetメンバーのフローごとです。論理的には、転送サブレイヤ情報は、転送サブレイヤにおけるDetNetフローの送信のさらなる詳細へのポインタである。
The following summarizes the information that is needed (on a per-service basis) on nodes that are service sub-layer aware and receive DetNet MPLS traffic:
以下は、サービスサブレイヤー対応ノード上の（サービスごとに）必要とされる情報を要約し、Detnet MPLSトラフィックを受信します。
* The forwarding sub-layer information associated with the input of the service sub-layer. Note that when PEF is provisioned, this information is per DetNet member flow. Logically, the forwarding sub-layer information is a pointer to further details of the reception of DetNet flows at the forwarding sub-layer or A-Label.
* サービスサブレイヤの入力に関連する転送サブレイヤ情報。PEFがプロビジョニングされている場合、この情報はDetnetメンバーフローごとです。論理的には、転送サブレイヤ情報は、転送サブレイヤまたはA - ラベルにおけるDetNetフローの受信のさらなる詳細へのポインタである。
* The incoming S-Label for the service.
* サービスの着信Sラベル。
* If PEF or POF is to be provided for the service.
* PEFまたはPOFがサービスの提供される場合。
* The sequence number length to be used for the service. Valid values included 0, 16, and 28 bits. 0 bits cannot be used when PEF or POF are configured for the service.
* サービスに使用されるシーケンス番号の長さ。有効な値は0,16、および28ビットを含みます。PEFまたはPOFがサービスに設定されている場合は、0ビットを使用できません。
* App-flow identification information, e.g., IP information as defined in [DetNet-IP-over-MPLS]. Note that this information is not needed on DetNet relay nodes.
* アプリフロー識別情報、例えばDetnet-IP-over-MPLSで定義されているIP情報。この情報はDetnet Relayノードでは必要ありません。
Nodes performing aggregation using A-Labels, per Section 4.4.2, require the additional information summarized in this section.
セクション4.4.2ごとにアラベルを使用したアグリゲーションを実行するノードは、このセクションに要約された追加情報を必要とします。
The following summarizes the additional information that is needed on a node that sends aggregated flows using A-Labels:
A-LABELSを使用して集計フローを送信するノードで必要な追加情報を次に示します。
* The S-Labels or F-Labels that are to be carried over each aggregated service.
* 集約された各サービスの上に運ばれるSラベルまたはFラベル。
* The A-Label associated with each aggregated service.
* 各集約サービスに関連付けられているAラベル。
* The other S-Label information summarized above.
* 上記の他のSラベル情報。
On the receiving node, the A-Label provides the forwarding context of an incoming interface or an F-Label and is used in subsequent service or forwarding sub-layer receive processing, as appropriate. The related additional configuration that may be provided is discussed elsewhere in this section.
受信ノードでは、Aラベルは、着信インターフェースまたはFラベルの転送コンテキストを提供し、必要に応じて、後続のサービスまたは転送サブレイヤ受信処理で使用される。提供され得る関連する追加の構成については、このセクションの他の場所で説明されています。
The following summarizes the information that is needed (on a per-forwarding-sub-layer-flow basis) on nodes that are forwarding sub-layer aware and send DetNet MPLS traffic:
以下に、サブレイヤー対応を転送しているノード上の（転送副層フローごとに）必要な情報をまとめ、Detnet MPLSトラフィックを送信します。
* The outgoing F-Label stack to be pushed. The stack may include H-LSP labels.
* プッシュする発信Fラベルスタック。スタックはH - LSPラベルを含み得る。
* The traffic parameters associated with a specific label in the stack. Note that there may be multiple sets of traffic parameters associated with specific labels in the stack, e.g., when H-LSPs are used.
* スタック内の特定のラベルに関連付けられているトラフィックパラメータ。たとえば、H-LSPが使用されている場合、スタック内の特定のラベルに関連する複数のセットのトラフィックパラメータがある可能性があることに注意してください。
* Outgoing interface and, for unicast traffic, the next-hop information.
* 発信インターフェース、およびユニキャストトラフィックの場合、ネクストホップ情報。
* Sub-network-specific parameters on a technology-specific basis. For example, see [DetNet-MPLS-over-TSN].
* テクノロジ固有のサブネットワーク固有のパラメータたとえば、[detnet-mpls-over-tsn]を参照してください。
The following summarizes the information that is needed (on a per-forwarding-sub-layer-flow basis) on nodes that are forwarding sub-layer aware and receive DetNet MPLS traffic:
以下に、サブレイヤー対応の範囲を転送してDetnet MPLSトラフィックを受信しているノード上の（転送副層フローごとに）必要とされる情報を次に示します。
* The incoming interface. For some implementations and deployment scenarios, this information may not be needed.
* 着信インタフェース一部の実装と展開シナリオでは、この情報は必要ない場合があります。
* The incoming F-Label stack to be popped. The stack may include H-LSP labels.
* 着信するFラベルスタックがポップされます。スタックはH - LSPラベルを含み得る。
* How the incoming forwarding sub-layer flow is to be handled, i.e., forwarded as a transit node or provided to the service sub-layer.
* 移入転送サブレイヤフローがどのように処理されるべきか、すなわち、トランジットノードとして転送されるか、またはサービスサブレイヤに提供される。
It is the responsibility of the DetNet Controller Plane to properly provision both flow identification information and the flow-specific resources needed to provide the traffic treatment needed to meet each flow's service requirements. This applies for aggregated and individual flows.
各フローのサービス要件を満たすために必要なトラフィック処理を提供するために必要なフロー識別情報とフロー固有のリソースの両方を適切に提供することは、DetNet Controller Planeの責任です。これは集約された個々のフローに適用されます。
Detailed security considerations for DetNet are cataloged in [DetNet-Security], and more general security considerations are described in [RFC8655]. This section exclusively considers security considerations that are specific to the DetNet MPLS data plane. The considerations raised related to MPLS networks in general in [RFC5920] are equally applicable to the DetNet MPLS data plane.
Detnetの詳細なセキュリティ上の考慮事項は[Detnet-Security]でカタログ化され、より一般的なセキュリティ上の考慮事項は[RFC8655]に記載されています。このセクションでは、DetNet MPLSデータプレーンに固有のセキュリティ上の考慮事項を排他的に考慮します。[RFC5920]において一般的なMPLSネットワークに関連する考慮事項は、DetNet MPLSデータプレーンにも等しく適用されます。
Security aspects that are unique to DetNet are those whose aim is to protect the support of specific QoS aspects of DetNet, which are primarily to deliver data flows with extremely low packet loss rates and bounded end-to-end delivery latency. Achieving such loss rates and bounded latency may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 [RFC3552] that can arbitrarily drop or delay any or all traffic. In order to present meaningful security considerations, we consider a somewhat weaker attacker who does not control the physical links of the DetNet domain but may have the ability to control a network node within the boundary of the DetNet domain.
Detnetに固有のセキュリティの側面は、その目的がDetnetの特定のQoS側面のサポートを保護することです。このような損失率を達成し、BCP 72 [RFC3552]のインターネット脅威モデルによって想定されているものなど、任意のトラフィックを任意またはすべてのトラフィックに遅らせることができることが想定されている可能性の高い敵対的な敵対者には不可能である可能性があります。意味のあるセキュリティ上の考慮事項を提示するために、DetNetドメインの物理的なリンクを制御しないが、DetNetドメインの境界内でネットワークノードを制御する機能を有する可能性がある。
An additional consideration for the DetNet data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Application flows can be protected through whatever means are provided by the underlying technology. For example, encryption may be used, such as that provided by IPsec [RFC4301] for IP flows and/or by an underlying sub-network using MACsec [IEEE802.1AE-2018] for IP over Ethernet (Layer 2) flows. MPLS doesn't provide any native security services to account for confidentiality and integrity.
DetNetデータプレーンに対する追加の考慮事項は、データの完全性を維持することであり、DetNetネットワークを通過する関連するDetNetサービスの配信を維持することである。アプリケーションフローは、基礎となる技術によって何にもかかわらず提供されます。例えば、IPSec [RFC4301]がIPフローの場合、および/またはIP上のIEEE802.1AE-2018]を使用して、IPSEC [IEEE802E-2018]を使用して、IPSEC（RFC4301）によって提供される暗号化を使用することができます。MPLSは、機密性と整合性を説明するためのネイティブのセキュリティサービスを提供しません。
From a data plane perspective, this document does not add or modify any application header information.
データプレーンの観点から見ると、この文書はアプリケーションヘッダー情報を追加または変更しません。
At the management and control level, DetNet flows are identified on a per-flow basis, which may provide Controller Plane attackers with additional information about the data flows (when compared to Controller Planes that do not include per-flow identification). This is an inherent property of DetNet that has security implications that should be considered when determining if DetNet is a suitable technology for any given use case.
管理レベルおよび制御レベルでは、DETNETフローはフローごとに識別され、これはデータフローに関する追加の情報を有するコントローラプレーン攻撃者に（フロー識別は含まないコントローラプレーンと比較した場合）。これはDetnetの本来のプロパティであり、Detnetが特定のユースケースに適した技術であるかどうかを判断するときに考慮する必要があるセキュリティの意味を持つDetnetの固有の財産です。
To provide uninterrupted availability of the DetNet service, provisions can be made against DoS attacks and delay attacks. To protect against DoS attacks, excess traffic due to malicious or malfunctioning devices is prevented or mitigated through the use of existing mechanisms, for example, by policing and shaping incoming traffic. To prevent DetNet packets from having their delay manipulated by an external entity, precautions need to be taken to ensure that all devices on an LSP are those intended to be there by the network operator and that they are well behaved. In addition to physical security, technical methods, such as authentication and authorization of network equipment and the instrumentation and monitoring of the LSP packet delay, may be used. If a delay attack is suspected, traffic may be moved to an alternate path, for example, through changing the LSP or management of the PREOF configuration.
Detnetサービスの中断のない可用性を提供するために、DOS攻撃や遅延攻撃に対して規定を行うことができます。DOS攻撃から保護するために、悪意のある機器や故障した装置による過剰な交通量は、例えば、着信トラフィックをポリシングおよびシェーピングすることによって、既存のメカニズムの使用を通じて防止または軽減される。Detnet Packetsが外部のエンティティによって操作されるのを防ぐために、LSP上のすべてのデバイスがネットワークオペレータによってそこにあることを意図したものであり、それらが正しく動作していることを確実にするために予防措置を講じる必要があります。物理的なセキュリティに加えて、ネットワーク機器の認証および承認などの技術的方法およびLSPパケット遅延の計測および監視を使用することができる。遅延攻撃が疑われる場合は、PREOF構成のLSPまたは管理を変更することによって、トラフィックを代替パスに移動させることができます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, DOI 10.17487/RFC2211, September 1997, <https://www.rfc-editor.org/info/rfc2211>.
[RFC2211] wroclawski、J.、「制御負荷ネットワーク要素サービスの仕様」、RFC 2211、DOI 10.17487 / RFC2211、1997年9月、<https：//www.rfc-editor.org/info/rfc2211>。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, DOI 10.17487/RFC2212, September 1997, <https://www.rfc-editor.org/info/rfc2212>.
[RFC2212] Shenker、S.、Partridge、C、C、およびR.Guerin、「保証されたサービス品質の仕様」、RFC 2212、DOI 10.17487 / RFC2212、1997年9月、<https：//www.rfc-editor.org/ info / rfc2212>。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
[RFC3031]ローゼン、E.、Viswanathan、A.およびR.Callon、 "Multiprotocol Label Switche Architecture"、RFC 3031、DOI 10.17487 / RFC3031、2001年1月、<https：//www.rfc-editor.org/info/ RFC3031>。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.
[RFC3032]ローゼン、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T.、およびA. CONTA、「MPLSラベルスタックエンコーディング」、RFC 3032、DOI 10.17487/ RFC3032、2001年1月、<https://www.rfc-editor.org/info/rfc3032>。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC3209] awduche、D.、Berger、L.、GaN、D.、Li、T.、Srinivasan、V.、G.Svp-Te：LSPトンネルのRSVPへの拡張機能、RFC 3209、DOI10.17487 / RFC3209、2001年12月、<https：//www.rfc-editor.org/info/rfc3209>。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, DOI 10.17487/RFC3270, May 2002, <https://www.rfc-editor.org/info/rfc3270>.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、J.Heinanen、Multi-Protocol Label Switching（MPLS）差別化サービスのサポート、RFC 3270、DOI 10.17487 / RFC3270、2002年5月、<https：//www.rfc-editor.org/info/rfc3270>。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, DOI 10.17487/RFC3443, January 2003, <https://www.rfc-editor.org/info/rfc3443>.
[RFC3443] Agarwal、P.およびB.Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワーク（MPLS）ネットワーク（MPLS）ネットワーク（MPLS）ネットワーク（MPLS）ネットワーク（TTL）処理、RFC 3443、DOI 10.17487 / RFC3443、<https：// www。rfc-editor.org/info/rfc3443>。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>.
[RFC3473] Berger、L.、ED。、「一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張機能」、RFC 3473、DOI 10.17487 / RFC3473、2003年1月、<https：//www.rfc-editor.org/info/rfc3473>。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <https://www.rfc-editor.org/info/rfc4206>.
[RFC4206] Kompella、K.およびY.Rekhter、一般化マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE） "、RFC 4206、DOI 10.17487 / RFC4206、2005年10月、<HTTPS）//www.rfc-editor.org/info/rfc4206>。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, DOI 10.17487/RFC4385, February 2006, <https://www.rfc-editor.org/info/rfc4385>.
[RFC4385]ブライアント、S.、ツバメ、G.、MARTINI、L.、およびD.マクファーソン、「疑似回線エミュレーションエッジエッジエッジツーエッジ（PWE3）コントロール（PWE3）コントロール単語（MPLS PSNで使用する）、RFC 4385、DOI 10.17487 /2006年2月、<https：//www.rfc-editor.org/info/rfc4385>。
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5085] Nadeau、T.、ED。「Pseudowire仮想サーキット接続検証（VCCV）：擬似電車の制御チャネル、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<https：//www.rfc-editor.org/info/ RFC5085>。
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January 2008, <https://www.rfc-editor.org/info/rfc5129>.
[RFC5129]デイビー、B.、Briscoe、B.、J. Tay、「MPLSの明示的な輻輳マーク」、RFC 5129、DOI 10.17487 / RFC5129、2008年1月、<https://www.rfc-editor.org/情報/ RFC5129>。
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, <https://www.rfc-editor.org/info/rfc5462>.
[RFC5462] Andersson、L.およびR.Asati、 "Multiprotocol Label Switching（MPLS）ラベルスタックエントリ：" exp "フィールド"トラフィッククラス "フィールド"、RFC 5462、DOI 10.17487 / RFC5462、2009年2月、<https：//www.rfc-editor.org/info/rfc5462>。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, DOI 10.17487/RFC5586, June 2009, <https://www.rfc-editor.org/info/rfc5586>.
[RFC5586] Bocci、M.、Ed。、Vigoueux、M.、Ed。、およびS. Bryant、Ed。、「MPLSジェネリック関連チャネル」、RFC 5586、DOI 10.17487 / RFC5586、2009年6月、<https：//www.rfc-editor.org/info/rfc5586>。
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, <https://www.rfc-editor.org/info/rfc6790>.
[RFC6790] Kompella、K.、Drake、J.、Amante、S.、Henderickx、W.、L. Yong、「MPLS転送におけるエントロピーラベルの使用」、RFC 6790、DOI 10.17487 / RFC6790、2012年11月、<https://www.rfc-editor.org/info/rfc6790>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.
[RFC8938] Varga、B.、Ed。、Farkas、J.、Berger、L.、Malis、A.、およびS.ブライアント、「決定論的ネットワーキング（DetnetInstring）データプレーンフレームワーク」、RFC 8938、DOI 10.17487 / RFC8938、2020年11月、<https：//www.rfc-editor.org/info/rfc8938>。
[DetNet-IP-over-MPLS] Varga, B., Ed., Berger, L., Fedyk, D., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP over MPLS", Work in Progress, Internet-Draft, draft-ietf-detnet-ip-over-mpls-09, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-09>.
[Detnet-IP-over-MPLS] Varga、B.、ED。、Berger、L.、Fedyk、D.、Bryant、S.、およびJ.Korhonen、「Detnet Data Plane：MPLS over MPLS」、進行中の作業、インターネットドラフト、ドラフト - IETF-Detnet-IP-over-MPLS-09,110、<https：//tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-09>。
[DetNet-MPLS-OAM] Mirsky, G. and M. Chen, "Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with MPLS Data Plane", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-oam-02, 15 January 2021, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-oam-02>.
[Detnet-Mpls-OAM] Mirsky、G.およびM. Chen、MPLSデータプレーンを搭載した決定論的ネットワーク（Detnet）のための「操作、管理および保守（OAM）」、進行中の作業、インターネットドラフト、ドラフト-IETF-Detnet-MPLS-OAM-02,15 1月15日、<https：//tools.ietf.org/html/draft-ietf-detnet-mpls-oam-02>。
[DetNet-MPLS-over-TSN] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-over-tsn-05, 13 December 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-05>.
[Detnet-MPLS-over-TSN] Varga、B、ED。、Farkas、J.、Malis、A.、Bryant、「Detnet Data Plane：IEEE 802.1時間敏感ネットワーク（TSN）」、作業進行中、インターネットドラフト、ドラフト - IETF-Detnet-MPLS-over-TSN-05,12月13日、<https：//tools.ietf.org/html/draft-ietf-detnet-mpls over-tsn-05>。
[DetNet-Security] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-13, 11 December 2020, <https://tools.ietf.org/html/draft-ietf-detnet-security-13>.
[Detnet-Security] Grossman、E.、ED。、Mizrahi、T.、およびA.ハッカー、「決定論的ネットワーキング（DetnetISTIC）セキュリティ上の考慮事項」、進行中の作業、インターネットドラフト、ドラフトIETF-Detnet-Security-132020年12月11日、<https://tools.ietf.org/html/draft-ietf-detnet-security-13>。
[DetNet-YANG] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) Configuration YANG Model", Work in Progress, Internet-Draft, draft-ietf-detnet-yang-09, 16 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-yang-09>.
[Detnet-Yang] Geng、X.、Chen、M.、Ryoo、Y.、Fedyk、D.、Rahman、R.、およびZ. Li、「決定論的ネットワーキング（Detnet）構成Yangモデル」、進行中の作業、2020年11月16日、インターネットドラフト、Draft-Ietf-Detnet-Yang-09、<https：//tools.ietf.org/html/draft-ietf-detnet-yang-09>。
[IEEE802.1AE-2018] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1ae-2018] IEEE、「地元の地域と首都圏のIEEE規格ネットワーク - メディアアクセス管理（Mac）セキュリティ」、IEEE 802.1ae-2018、DOI 10.1109 / IEEESTD.2018.8585421、2018年12月、<https：// ieeexplore.ieee.org / document / 8585421>。
[IEEE802.1CB-2017] IEEE, "IEEE Standard for Local and metropolitan area networks-- Frame Replication and Elimination for Reliability", IEEE 802.1CB-2017, DOI 10.1109/IEEESTD.2017.8091139, October 2017, <https://ieeexplore.ieee.org/document/8091139>.
[IEEE802.1cb-2017] IEEE、「地方および首都圏のネットワークのためのIEEE規格 - フレームレプリケーションと信頼性の排除」、IEEE 802.1CB-2017、DOI 10.1109 / IEEESTD.2017.8091139、<https：// ieeexplore.ieee.org / document / 8091139>。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、DOI10.17487 / RFC2205、1997年9月、<https：//www.rfc-editor.org/info/rfc2205>。
[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>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F.、およびD.黒、「IPv4およびIPv6ヘッダーのDSフィールドの定義」、RFC 2474、DOI 10.17487 / RFC2474、1998年12月、<https：//www.rfc-editor.org/info/rfc2474>。
[RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, <https://www.rfc-editor.org/info/rfc3272>.
[RFC3272] awduche、D.、Chiu、A.、Elwalid、A.、Widjaja、I.、およびX. Xiao、「インターネットトラフィックエンジニアリングの原理」、RFC 3272、DOI 10.17487 / RFC3272、2002年5月、<https://www.rfc-editor.org/info/rfc3272>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E.およびB.Korver、「セキュリティ上のRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/ RFC3552>。
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, DOI 10.17487/RFC3985, March 2005, <https://www.rfc-editor.org/info/rfc3985>.
[RFC3985]ブライアント、S。、ED。P. Pate、Ed。、「疑似ワイヤーエミュレーションエッジツーエッジ（PWE3）アーキテクチャ」、RFC 3985、DOI 10.17487 / RFC3985、2005年3月、<https：//www.rfc-editor.org/info/rfc3985>。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4301] Kent、S.およびK.SEO、「インターネットプロトコルのためのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<https：//www.rfc-editor.org/info/rfc4301>。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, <https://www.rfc-editor.org/info/rfc4448>.
[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、G. Heron、「MPLSネットワーク上のイーサネット輸送のためのカプセル化方法」、RFC 4448、DOI 10.17487 / RFC4448、2006年4月<https://www.rfc-editor.org/info/rfc4448>。
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>.
[RFC4875] Aggarwal、R.、Ed。、Papadimitriou、D.、Ed。、「リソース予約プロトコルへの拡張 - ポイントツーマルチポイントTEラベルのためのトラフィックエンジニアリング（RSVP-TE）2007年5月、<https：//www.rfc-editor.org/info/frfc4875> Paths（LSP） "、RFC 4875 / RFC4875、DOI 10.17487 / RFC4875。
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
[RFC5440] Vasseur、JP。、ED。そしてJL。Le Roux、Ed。、「PATH計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、DOI 10.17487 / RFC5440、2009年3月、<https：//www.rfc-editor.org/info/rfc5440>。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <https://www.rfc-editor.org/info/rfc5920>.
[RFC5920] Fang、L.、Ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、DOI 10.17487 / RFC5920、<https：//www.rfc-editor.org/info/rfc5920>。
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, DOI 10.17487/RFC5921, July 2010, <https://www.rfc-editor.org/info/rfc5921>.
[RFC5921] BOCCI、M、ED。、Bryant、S、ED。、霜、D.、ED。、Levrau、L.、およびL. Berger、「トランスポートネットワークにおけるMPLSのためのフレームワーク」、RFC 5921、DOI 10.17487 / RFC5921、2010年7月、<https：//www.rfc-editor.org/info/rfc5921>。
[RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", RFC 6003, DOI 10.17487/RFC6003, October 2010, <https://www.rfc-editor.org/info/rfc6003>.
[RFC6003] Papadimitriou、D.、「イーサネットトラフィックパラメータ」、RFC 6003、DOI 10.17487 / RFC6003、2010年10月、<https://www.rfc-editor.org/info/rfc6003>。
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, DOI 10.17487/RFC6073, January 2011, <https://www.rfc-editor.org/info/rfc6073>.
[RFC6073] Martini、L.、Metz、C.、Nadeau、T.、Bocci、M.、およびM. Aissaoui、RFC 6073、DOI 10.17487 / RFC6073、2011年1月、<https：// www.rfc-editor.org / info / rfc6073>。
[RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, <https://www.rfc-editor.org/info/rfc8306>.
[RFC8306] Zhao、Q.、Dhody、D.、ED。、Palleti、R.、およびD. king、「ポイントツーマルチポイントトラフィックエンジニアリングラベルスイッチドパスのためのパス計算要素通信プロトコル（PCE）への拡張」、RFC 8306、DOI 10.17487 / RFC8306、2017年11月、<https：//www.rfc-editor.org/info/rfc8306>。
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, <https://www.rfc-editor.org/info/rfc8660>.
[RFC8660] Bashandy、A.、ED。、Filsfils、C。、ED。、Presidi、S.、Decraene、B.、Litkowski、S.、およびR. Shakir、「MPLSデータプレーンを使用したセグメントルーティング」、RFC8660、DOI 10.17487 / RFC8660、2019年12月、<https：//www.rfc-editor.org/info/rfc8660>。
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
[RFC8939]バラジャ、B、ED。、Farkas、J.、Berger、L.、Fedyk、D.、およびS.Bryant、「決定論的ネットワーキング（DECTINAL）データプレーン：IP」、RFC 8939、DOI 10.17487 / RFC8939、2020年11月、<https：//www.rfc-editor.org/info/rfc8939>。
Acknowledgements
謝辞
The authors wish to thank Pat Thaler, Norman Finn, Loa Anderson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, Jeong-dong Ryoo, and Carlos J. Bernardos for their various contributions to this work.
著者らは、ダビデブラック、ロドニーカミングス、エタングロスマン、スルミズラヒ、デビッドモズ、クレイグジャン、ジョーンドンリュウ、カルロスJ.バーナルド、そしてCarlos J. Bernardosの著、カルミスハイヤー、ジョージ・ツ・スワロー、そしてCarlos J. Bernardosを感謝します。この作品への様々な貢献。
Contributors
貢献者
The editor of this document wishes to thank and acknowledge the following person who contributed substantially to the content of this document and should be considered a coauthor:
この文書の編集者は、この文書の内容に実質的に貢献した次の人を感謝し、認識し、共著者と見なすべきです。
Don Fedyk LabN Consulting, L.L.C.
Don Fedyk Labn Consulting、L.L.c。
Email: dfedyk@labn.net
Authors' Addresses
著者の住所
Balázs Varga (editor) Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary
Balázsvarga（編集）エリクソンブダペストMagyar Tudosok Krt。11. 1117ハンガリー
Email: balazs.a.varga@ericsson.com
János Farkas Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary
JánosFarkas Ericsson Budapest Magyar Tudosok Krt。11. 1117ハンガリー
Email: janos.farkas@ericsson.com
Lou Berger LabN Consulting, L.L.C.
Lou Berger Labn Consulting、L.C.
Email: lberger@labn.net
Andrew G. Malis Malis Consulting
Andrew G. Malis Malis Consulting.
Email: agmalis@gmail.com
Stewart Bryant Futurewei Technologies
スチュワートブライアントフューチャーワイテクノロジー
Email: sb@stewartbryant.com
Jouni Korhonen
Jouni Korhonen
Email: jouni.nospam@gmail.com