[要約] RFC 8938は、Deterministic Networking (DetNet) Data Plane Frameworkに関する文書で、信頼性と時間的な予測可能性を必要とするアプリケーションのために、データネットワーク内でのデータ転送の決定論的な特性を提供することを目的としています。このフレームワークは、特に産業オートメーション、電力伝送、および輸送システムなどの分野での利用が想定されています。
Internet Engineering Task Force (IETF) B. Varga, Ed.
Request for Comments: 8938 J. Farkas
Category: Informational Ericsson
ISSN: 2070-1721 L. Berger
LabN Consulting, L.L.C.
A. Malis
Malis Consulting
S. Bryant
Futurewei Technologies
November 2020
Deterministic Networking (DetNet) Data Plane Framework
決定論的ネットワーキング（DetNet）データプレーンフレームワーク
Abstract
概要
This document provides an overall framework for the Deterministic Networking (DetNet) data plane. It covers concepts and considerations that are generally common to any DetNet data plane specification. It describes related Controller Plane considerations as well.
この文書は、決定論的ネットワーキング（Detnet）データプレーンの全体的なフレームワークを提供します。それは、任意のDetnetデータプレーン仕様に一般的に一般的な概念と考慮事項をカバーしています。それは関連するコントローラプレーンの考慮事項についても説明しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc8938.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8938で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2020 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
3. Overview of the DetNet Data Plane
3.1. Data Plane Characteristics
3.1.1. Data Plane Technology
3.1.2. Encapsulation
3.2. DetNet-Specific Metadata
3.3. DetNet IP Data Plane
3.4. DetNet MPLS Data Plane
3.5. Further DetNet Data Plane Considerations
3.5.1. Functions Provided on a Per-Flow Basis
3.5.2. Service Protection
3.5.3. Aggregation Considerations
3.5.4. End-System-Specific Considerations
3.5.5. Sub-network Considerations
4. Controller Plane (Management and Control) Considerations
4.1. DetNet Controller Plane Requirements
4.2. Generic Controller Plane Considerations
4.2.1. Flow Aggregation Control
4.2.2. Explicit Routes
4.2.3. Contention Loss and Jitter Reduction
4.2.4. Bidirectional Traffic
4.3. Packet Replication, Elimination, and Ordering Functions
(PREOF)
5. Security Considerations
6. IANA Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
DetNet (Deterministic Networking) provides the ability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end delivery latency. A description of the general background and concepts of DetNet can be found in [RFC8655].
DetNet（確定ネットワーキング）は、極めて低いパケット損失率を持つリアルタイムアプリケーションのために指定されたユニキャストまたはマルチキャストデータフローを持ち運ぶ機能を提供し、最大のエンドツーエンド配信待ち時間を保証します。Detnetの一般的な背景と概念の説明は[RFC8655]にあります。
This document describes the concepts needed by any DetNet data plane specification (i.e., the DetNet-specific use of packet header fields) and provides considerations for any corresponding implementation. It covers the building blocks that provide the DetNet service, the DetNet service sub-layer, and the DetNet forwarding sub-layer functions as described in the DetNet architecture [RFC8655].
この文書では、任意のDetnetデータプレーン仕様（すなわち、パケットヘッダフィールドのDetNet固有の使用）によって必要とされる概念について説明し、任意の対応する実装について考慮する。Detnet Architecture [RFC8655]に記載されているように、Detnetサービス、Detnet Serviceサブレイヤ、およびDetNet Forwardingサブレイヤ機能を提供するビルディングブロックをカバーします。
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 protection and reordering. The forwarding sub-layer leverages traffic engineering mechanisms and provides congestion protection (low loss, assured latency, and limited out-of-order delivery). A particular forwarding sub-layer may have capabilities that are not available on other forwarding sub-layers. DetNet makes use of the existing forwarding sub-layers with their respective capabilities and does not require 1:1 equivalence between different forwarding sub-layer capabilities.
DetNetアーキテクチャは、DetNet関連データプレーンが2つの副層に分解されているとの機能をモデル化しています。サービス副層と転送副層。サービスサブレイヤはDetnetサービス保護と並べ替えを提供するために使用されます。転送サブレイヤは、トラフィックエンジニアリングメカニズムを活用し、輻輳保護（低損失、保証された待ち時間、および限られた順序配信）を提供します。特定の転送サブレイヤは、他の転送サブレイヤでは利用できない機能を有してもよい。Detnetは、既存の転送サブレイヤをそれぞれの機能で使用し、異なる転送サブレイヤ機能間で1：1等価性を必要としません。
As part of the service sub-layer functions, this document describes typical DetNet node data plane operation. It describes the functionality and operation of the Packet Replication Function (PRF), the Packet Elimination Function (PEF), and the Packet Ordering Function (POF) within the service sub-layer. Furthermore, it describes the forwarding sub-layer.
サービスサブレイヤ関数の一部として、このドキュメントでは典型的なDetnetノードデータプレーン動作について説明します。サービスサブレイヤ内のパケット複製機能（PRF）、パケット除去機能（PEF）、パケット順序付け機能（POF）の機能と動作について説明している。さらに、転送サブレイヤーを記述しています。
As defined in [RFC8655], DetNet flows may be carried over network technologies that can provide service characteristics required by DetNet. For example, DetNet MPLS flows can be carried over IEEE 802.1 Time-Sensitive Networking (TSN) sub-networks [IEEE802.1TSNTG]. However, IEEE 802.1 TSN support is not required in DetNet. TSN frame preemption is an example of a forwarding layer capability that is typically not replicated in other forwarding technologies. Most of DetNet's benefits can be gained by running over a data-link layer that has not been specifically enhanced to support all TSN capabilities, but for such networks and traffic mixes, delay and jitter performance may vary due to the forwarding sub-layer's intrinsic properties.
[RFC8655]で定義されているように、Detnet FlowsはDetnetによって要求されるサービス特性を提供できるネットワーク技術を介して運ばれてもよい。たとえば、Detnet MPLSフローは、IEEE 802.1時間依存ネットワーキング（TSN）サブネットワーク[IEEE802.1TSNTG]を介して伝送できます。ただし、IEEE 802.1 TSNサポートはDetnetでは必要ありません。TSNフレームのプリエンプションは、他の転送技術では複製されていない転送層機能の一例です。Detnetの利点のほとんどは、すべてのTSN機能をサポートするように特に強化されていないデータリンクレイヤを介して実行することができますが、そのようなネットワークとトラフィックのミックスには遅延とジッタ性能が転送サブレイヤの固有のプロパティによって異なる場合があります。。
Different application flows, such as Ethernet or IP, can be mapped on top of DetNet. DetNet can optionally reuse header information provided by, or shared with, applications. An example of shared header fields can be found in [RFC8939].
イーサネットまたはIPなどの異なるアプリケーションフローは、Detnetの上にマッピングできます。DetNetは、アプリケーションによって提供された、またはアプリケーションと共有されているヘッダー情報をオプションで再利用できます。[RFC8939]に共有ヘッダーフィールドの例があります。
This document also covers basic concepts related to the Controller Plane and Operations, Administration, and Maintenance (OAM). Data plane OAM specifics are out of scope for this document.
この文書では、コントローラプレーンとオペレーション、管理、メンテナンス（OAM）に関連する基本概念についても説明します。データプレーンOAMの指定はこの文書には範囲外です。
This document uses the terminology established in the DetNet architecture [RFC8655], and it is assumed that the reader is familiar with that document and its terminology.
この文書では、Detnetアーキテクチャ[RFC8655]で確立された用語を使用しており、リーダーはその文書とその用語に精通していると想定されています。
The following abbreviations are used in this document:
この文書では、次の略語が使用されています。
BGP Border Gateway Protocol
BGPボーダーゲートウェイプロトコル
CoS Class of Service
COSのサービスクラス
d-CW DetNet Control Word
D-CW Detnet Control Word.
DetNet Deterministic Networking
Detnet決定論的ネットワーキング
DN DetNet
DN Detnet
GMPLS Generalized Multiprotocol Label Switching
GMPLS一般化マルチプロトコルラベルスイッチング
GRE Generic Routing Encapsulation
GRE汎用ルーティングカプセル化
IPsec IP Security
IPsec IPセキュリティ
L2 Layer 2
L2層2
LSP Label Switched Path
LSPラベルスイッチパス
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
OAM Operations, Administration, and Maintenance
OAMの操作、管理、および保守
PCEP Path Computation Element Communication Protocol
PCEPパス計算要素通信プロトコル
PEF Packet Elimination Function
PEFパケット除去機能
POF Packet Ordering Function
POFパケット順序機能
PREOF Packet Replication, Elimination, and Ordering Functions
パケットのレプリケーション、除去、および注文機能
PRF Packet Replication Function
PRFパケットレプリケーション機能
PSN Packet Switched Network
PSNパケット交換ネットワーク
QoS Quality of Service
QoSサービス品質
S-Label DetNet "service" label
SラベルDETNETNET「サービス」ラベル
TDM Time-Division Multiplexing
TDM時分割多重化
TSN Time-Sensitive Networking
TSNの時間依存ネットワーキング
YANG Yet Another Next Generation
Yangまだ別の次世代
This document describes how application flows, or App-flows [RFC8655], are carried over DetNet networks. The DetNet architecture [RFC8655] models the DetNet-related data plane functions as decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer.
このドキュメントでは、アプリケーションフロー、またはApp-Flows [RFC8655]がDetnetネットワークを介して伝送される方法について説明します。DetNetアーキテクチャ[RFC8655]は、DetNet関連データプレーンが2つの副層に分解されているとおりに機能します。サービスサブレイヤと転送サブレイヤー。
Figure 1, reproduced from [RFC8655], shows a logical DetNet service with the two sub-layers.
図1は、[RFC8655]から再生された、2つの副層を持つ論理Detnetサービスを示します。
| packets going | ^ packets coming ^
v down the stack v | up the stack |
+-----------------------+ +-----------------------+
| Source | | Destination |
+-----------------------+ +-----------------------+
| Service sub-layer: | | Service sub-layer: |
| Packet sequencing | | Duplicate elimination |
| Flow replication | | Flow merging |
| Packet encoding | | Packet decoding |
+-----------------------+ +-----------------------+
| Forwarding sub-layer: | | Forwarding sub-layer: |
| Resource allocation | | Resource allocation |
| Explicit routes | | Explicit routes |
+-----------------------+ +-----------------------+
| Lower layers | | Lower layers |
+-----------------------+ +-----------------------+
v ^
\_________________________/
Figure 1: DetNet Data Plane Protocol Stack
図1：Detnetデータプレーンプロトコルスタック
The DetNet forwarding sub-layer may be directly provided by the DetNet service sub-layer -- for example, by IP tunnels or MPLS. Alternatively, an overlay approach may be used in which the packet is natively carried between key nodes within the DetNet network (say, between PREOF nodes), and a sub-layer is used to provide the information needed to reach the next hop in the overlay.
DETNET転送サブレイヤは、例えばIPトンネルまたはMPLSによって、DetNetサービスサブレイヤによって直接提供されてもよい。あるいは、パケットがDetNetネットワーク内のキーノード間でネイティブに携帯されているオーバーレイアプローチを使用してもよく、サブレイヤはオーバーレイで次のホップに到達するのに必要な情報を提供するために使用される。。
The forwarding sub-layer provides the QoS-related functions needed by the DetNet flow. It may do this directly through the use of queuing techniques and traffic engineering methods, or it may do this through the assistance of its underlying connectivity. For example, it may call upon Ethernet TSN capabilities defined in IEEE 802.1 TSN [IEEE802.1TSNTG]. The forwarding sub-layer uses buffer resources for packet queuing, as well as reservation and allocation of bandwidth capacity resources.
転送サブレイヤは、DetNetフローによって必要とされるQoS関連の関数を提供する。これは、キューイング技術とトラフィックエンジニアリング方法の使用を通じて直接行うことも、その基礎となる接続性の支援を通してこれを行うことがあります。たとえば、IEEE 802.1 TSN [IEEE802.1TSNTG]で定義されているイーサネットTSN機能を呼び出すことがあります。転送サブレイヤは、パケットキューイングのためのバッファリソース、および帯域幅容量リソースの予約および割り当てを使用する。
The service sub-layer provides additional support beyond the connectivity function of the forwarding sub-layer. See Section 4.3 regarding PREOF. The POF uses sequence numbers added to packets, enabling a range of packet order protection from simple ordering and dropping out-of-order packets to more complex reordering of a fixed number of out-of-order, minimally delayed packets. Reordering requires buffer resources and has an impact on the delay and jitter of packets in the DetNet flow.
サービスサブレイヤは、転送サブレイヤの接続関数を超えて追加のサポートを提供する。PREOFに関するセクション4.3を参照してください。POFはパケットに追加されたシーケンス番号を使用し、単純な順序付けからの範囲のパケット順序保護を有効にし、順不同パケットをドロップして、固定数の最小遅延パケットのより複雑な並べ替えを可能にします。並べ替えにはバッファリソースが必要であり、Detnetフローのパケットの遅延とジッタに影響を与えます。
The method of instantiating each of the layers is specific to the particular DetNet data plane method, and more than one approach may be applicable to a given network type.
各層をインスタンス化する方法は、特定のDetNetデータプレーン方式に固有のものであり、複数のアプローチが所与のネットワークタイプに適用可能であり得る。
The data plane has two major characteristics: the technology and the encapsulation, as discussed below.
データプレーンには、次に説明するように、テクノロジとカプセル化の2つの主要な特性があります。
The DetNet data plane is provided by the DetNet service and forwarding sub-layers. The DetNet service sub-layer generally provides its functions for the DetNet application flows by using or applying existing standardized headers and/or encapsulations. The DetNet forwarding sub-layer may provide capabilities leveraging that same header or encapsulation technology (e.g., DN IP or DN MPLS), or it may be achieved via other technologies, as shown in Figure 2 below. DetNet is currently defined for operation over packet-switched (IP) networks or label-switched (MPLS) networks.
DetNetデータプレーンは、DetNetサービスおよび転送サブレイヤによって提供される。DetNet Serviceサブレイヤは、一般に、既存の標準化されたヘッダーおよび/またはカプセル化を使用または適用することによってDetNetアプリケーションフローのためのその機能を提供します。DETNET転送サブレイヤは、その同じヘッダまたはカプセル化技術（例えば、DN IPまたはDN MPLS）を利用する能力を提供してもよいし、下記の図2に示すように、他の技術を介して達成されてもよい。Detnetは現在、パケット交換（IP）ネットワークまたはラベルスイッチ（MPLS）ネットワークを介した操作用に定義されています。
DetNet encodes specific flow attributes (flow identity and sequence number) in packets. For example, in DetNet IP, zero encapsulation is used, and no sequence number is available; in DetNet MPLS, DetNet-specific information may be added explicitly to the packets in the form of an S-Label and a d-CW [DetNet-MPLS].
Detnetは、パケット内の特定のフロー属性（フローIDとシーケンス番号）をエンコードします。たとえば、DetNet IPでは、ゼロのカプセル化が使用され、シーケンス番号は使用できません。Detnet MPLSでは、Detnet固有の情報は、SラベルとD-CW [Detnet-MPLS]の形のパケットに明示的に追加できます。
The encapsulation of a DetNet flow allows it to be sent over a data plane technology other than its native type. DetNet uses header information to perform traffic classification, i.e., identify DetNet flows, and provide DetNet service and forwarding functions. As mentioned above, DetNet may add headers, as is the case for DN MPLS, or may use headers that are already present, as is the case for DN IP. Figure 2 illustrates some relationships between the components.
DetNet Flowのカプセル化により、そのネイティブ型以外のデータプレーンテクノロジを介して送信できます。Detnetはヘッダー情報を使用してトラフィックの分類を実行し、Detnet Flowsを識別し、Detnetサービスと転送機能を提供します。上述のように、DETNETは、DN MPLSの場合と同様に、またはDN IPの場合と同様に、既に存在するヘッダを使用してもよい。図2は、コンポーネント間のいくつかの関係を示しています。
+-----+
| TSN |
+-------+ +-+-----+-+
| DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+
Figure 2: DetNet Service Examples
図2：Detnet Serviceの例
The use of encapsulation is also required if additional information (metadata) is needed by the DetNet data plane and either (1) there is no ability to include it in the client data packet or (2) the specification of the client data plane does not permit the modification of the packet to include additional data. An example of such metadata is the inclusion of a sequence number required by PREOF.
追加情報（メタデータ）がDetNetデータプレーンによって必要とされる場合、カプセル化の使用も必要とされ、（1）クライアントデータパケットに含めることができないか（2）クライアントデータプレーンの仕様はそうではない追加データを含めるためのパケットの変更を許可します。そのようなメタデータの例は、PREOFによって必要とされるシーケンス番号を含めることである。
Encapsulation may also be used to carry or aggregate flows for equipment with limited DetNet capability.
カプセル化はまた、限られたDetNet能力を有する装置のための流動または凝集するために使用され得る。
The DetNet data plane can provide or carry the following metadata:
DetNetデータプレーンは、次のメタデータを提供または運行できます。
1. Flow-ID
1. フローID
2. Sequence number
2. シーケンス番号
The DetNet data plane framework supports a Flow-ID (for identification of the flow or aggregate flow) and/or a sequence number (for PREOF) for each DetNet flow. The Flow-ID is used by both the service and forwarding sub-layers, but the sequence number is only used by the service layer. Metadata can also be used for OAM indications and instrumentation of DetNet data plane operation.
DetNetデータプレーンフレームワークは、各DETNETフローに対するフローID（フローまたは集約フローの識別用）および/またはシーケンス番号（PREOF用）をサポートする。フローIDは、サービスと転送サブレイヤの両方によって使用されますが、シーケンス番号はサービス層によってのみ使用されます。メタデータはまた、OAMの指示とDetNetデータプレーン操作の計測にも使用できます。
Metadata inclusion can be implicit or explicit. Explicit inclusions involve a dedicated header field that is used to include metadata in a DetNet packet. In the implicit method, part of an already-existing header field is used to encode the metadata.
メタデータ包含は暗黙的または明示的にすることができます。明示的な包含物は、Detnetパケットにメタデータを含めるために使用される専用のヘッダーフィールドを含みます。暗黙的方法では、既存のヘッダーフィールドの一部がメタデータをエンコードするために使用されます。
Explicit inclusion of metadata is possible through the use of IP options or IP extension headers. New IP options are almost impossible to get standardized or to deploy in an operational network and will not be discussed further in this text. IPv6 extension headers are finding popularity in current IPv6 development work, particularly in connection with Segment Routing of IPv6 (SRv6) and IP OAM. The design of a new IPv6 extension header or the modification of an existing one is a technique available in the toolbox of the DetNet IP data plane designer.
IPオプションまたはIP拡張ヘッダーを使用して、メタデータを明示的に含めることが可能です。新しいIPオプションは、標準化された、または運用ネットワークに展開することがほとんど不可能であり、このテキストではさらに説明しません。IPv6拡張ヘッダーは、特にIPv6（SRV6）およびIP OAMのセグメントルーティングに関連して、現在のIPv6開発作業で人気を見つけています。新しいIPv6拡張ヘッダーの設計または既存のものの変更は、DetNet IPデータプレーン設計者のツールボックスで利用可能な技術です。
Explicit inclusion of metadata in an IP packet is also possible through the inclusion of an MPLS label stack and the MPLS d-CW, using one of the methods for carrying MPLS over IP [DetNet-MPLS-over-UDP-IP]. This is described in more detail in Section 3.5.5.
IP [Detnet-MPLS-Over-UDP-IP]を介してMPLSを伝送する方法の1つを使用して、MPLSラベルスタックとMPLS D-CWを含めることによって、IPパケット内のメタデータの明示的な含有も可能です。これについては、3.5.5節でさらに詳しく説明します。
Implicit metadata in IP can be included through the use of the network programming paradigm [SRv6-Network-Prog], in which the suffix of an IPv6 address is used to encode additional information for use by the network of the receiving host.
IP内の暗黙のメタデータは、IPv6アドレスのサフィックスが受信側ホストのネットワークで使用するための追加情報をエンコードするために使用されるネットワークプログラミングparadigm [srv6-network-prog]を使用することによって含めることができます。
An MPLS example of explicit metadata is the sequence number used by PREOF, or even the case where all the essential information is included in the DetNet-over-MPLS label stack (the d-CW and the DetNet S-Label).
明示的なメタデータのMPLSの例は、PREOFによって使用されるシーケンス番号、あるいはすべての重要な情報がDetnet-over-MPLSラベルスタック（D-CWとDetNet Sラベル）に含まれる場合でさえあります。
An IP data plane may operate natively or through the use of an encapsulation. Many types of IP encapsulation can satisfy DetNet requirements, and it is anticipated that more than one encapsulation may be deployed -- for example, GRE, IPsec.
IPデータプレーンは、ネイティブにまたはカプセル化の使用を通じて動作することがある。多くの種類のIPカプセル化はDetNet要件を満たすことができ、1つ以上のカプセル化が展開される可能性があることが予想されます。たとえば、GRE、IPsec。
One method of operating an IP DetNet data plane without encapsulation is to use 6-tuple-based flow identification, where "6-tuple" refers to information carried in IP-layer and higher-layer protocol headers. General background on the use of IP headers and 6-tuples to identify flows and support QoS can be found in [RFC3670]. The extra field in the 6-tuple is the DSCP field in the packet. [RFC7657] provides useful background on differentiated services (Diffserv) and tuple-based flow identification. DetNet flow aggregation may be enabled via the use of wildcards, masks, prefixes, and ranges. The operation of this method is described in detail in [RFC8939].
カプセル化なしでIP Detnetデータプレーンを操作する1つの方法は、6タプルベースのフロー識別を使用することです。ここで、「6タプル」は、IP層および上位プロトコルヘッダーで搭載されている情報を参照します。フローとサポートQoSを識別するためのIPヘッダーと6タプルの使用に関する一般的な背景は[RFC3670]にあります。6タプルの余分なフィールドは、パケット内のDSCPフィールドです。[RFC7657]は、差別化サービス（DiffServ）とタプルベースのフロー識別に関する有用な背景を提供します。Detnet Flow集約は、ワイルドカード、マスク、接頭辞、および範囲の使用を介して有効になることがあります。この方法の動作については、[RFC8939]に詳細に説明する。
The DetNet forwarding plane may use explicit route capabilities and traffic engineering capabilities to provide a forwarding sub-layer that is responsible for providing resource allocation and explicit routes. It is possible to include such information in a native IP packet either explicitly or implicitly.
DetNet転送プレーンは、明示的なルート機能とトラフィックエンジニアリング機能と、リソース割り当てと明示的な経路を提供する責任がある転送サブレイヤーを提供することができます。明示的または暗黙的には、ネイティブIPパケットにそのような情報を含めることが可能です。
MPLS provides a forwarding sub-layer for traffic over implicit and explicit paths to the point in the network where the next DetNet service sub-layer action needs to take place. It does this through the use of a stack of one or more labels with various forwarding semantics.
MPLSは、次のDetnet Serviceサブレイヤアクションが行われる必要があるネットワーク内の暗黙的パスと明示的なパスを介したトラフィックの転送サブレイヤーを提供します。これは、さまざまな転送セマンティクスを持つ1つ以上のラベルのスタックを使用しています。
MPLS also provides the ability to identify a service instance that is used to process the packet through the use of a label that maps the packet to a service instance.
MPLSはまた、パケットをサービスインスタンスにマッピングするラベルを使用してパケットを処理するために使用されるサービスインスタンスを識別する機能を提供します。
In cases where metadata is needed to process an MPLS-encapsulated packet at the service sub-layer, the d-CW [DetNet-MPLS] can be used. Although such d-CWs are frequently 32 bits long, there is no architectural constraint on the size of this structure -- only the requirement that it be fully understood by all parties operating on it in the DetNet service sub-layer. The operation of this method is described in detail in [DetNet-MPLS].
サービスサブレイヤでMPLSカプセル化パケットを処理するためにメタデータが必要な場合は、D-CW [Detnet-MPLS]を使用できます。このようなD-CWSは頻繁に32ビットの長さですが、この構造のサイズに建築的な制約はありません - Detnet Serviceのサブレイヤでそれを操作するすべての当事者によって完全に理解されるという要件のみがあります。この方法の動作については、[Detnet-MPLS]に詳しく説明します。
This section provides informative considerations related to providing DetNet service to flows that are identified based on their header information.
このセクションでは、ヘッダー情報に基づいて識別されたフローにDetnetサービスを提供することに関する有益な考慮事項を提供します。
At a high level, the following functions are provided on a per-flow basis.
高レベルでは、以下の機能がフローごとに提供されます。
Resources might be reserved in order to make them available for allocation to specific DetNet flows. This can eliminate packet contention and packet loss for DetNet traffic. This also can reduce jitter for DetNet traffic. Resources allocated to a DetNet flow protect it from other traffic flows. On the other hand, it is assumed that DetNet flows behave in accordance with the reserved traffic profile. It must be possible to detect misbehaving DetNet flows and to ensure that they do not compromise QoS of other flows. Queuing, policing, and shaping policies can be used to ensure that the allocation of resources reserved for DetNet is met.
特定のDetnetフローへの割り当てに使用できるようにするためにリソースが予約されている可能性があります。これにより、Detnetトラフィックのパケットの競合とパケット損失を排除できます。これはDetnetトラフィックのジッタを減らすことができます。Detnet Flowに割り当てられたリソースは他のトラフィックフローからそれを保護します。一方、検出されたトラフィックプロファイルに従ってDetNetフローが動作すると仮定されます。DETNETNETフローを誤って検出し、他のフローのQoSを妥協しないようにすることは可能でなければなりません。Queuing、Policing、およびShapingポリシーを使用して、DetNet用に予約されているリソースの割り当てが満たされていることを確認できます。
A flow can be routed over a specific, precomputed path. This allows control of network delay by steering the packet with the ability to influence the physical path. Explicit routes complement reservation by ensuring that a consistent path can be associated with its resources for the duration of that path. Coupled with the traffic mechanism, this limits misordering and bounds latency. Explicit route computation can encompass a wide set of constraints and can optimize the path for a certain characteristic, e.g., highest bandwidth or lowest jitter. In these cases, the "best" path for any set of characteristics may not be a shortest path. The selection of the path can take into account multiple network metrics. Some of these metrics are measured and distributed by the routing system as traffic engineering metrics.
フローは、特定の事前計算されたパスを介してルーティングすることができます。これにより、物理パスに影響を与える能力を持つパケットを操縦することによってネットワーク遅延を制御できます。明示的なルートは、一貫したパスがそのパスの期間中にそのリソースに関連付けることができるようにすることによって予約を補完的に予約します。トラフィックメカニズムと組み合わされて、これは誤って誤解され、待ち時間を境界に制限します。明示的な経路計算は、幅広い一連の制約を包含することができ、特定の特性、例えば最も高い帯域幅または最低のジッタのための経路を最適化することができる。これらの場合、特性のセットの「最善の」パスは最短経路ではないかもしれません。パスの選択は複数のネットワークメトリックを考慮に入れることができます。これらのメトリックのいくつかは、トラフィック工学メトリックとしてルーティングシステムによって測定され分散されています。
Service protection involves the use of multiple packet streams using multiple paths -- for example, 1+1 or 1:1 linear protection. For DetNet, this primarily relates to packet replication and elimination capabilities. MPLS offers a number of protection schemes. MPLS hitless protection can be used to switch traffic to an already-established path in order to restore delivery rapidly after a failure. Path changes, even in the case of failure recovery, can lead to the out-of-order delivery of data requiring POFs either within the DetNet service or at a high layer in the application traffic. Establishment of new paths after a failure is out of scope for DetNet services.
サービス保護は、複数のパスを使用して複数のパケットストリームを使用することを含みます - たとえば、1 1または1：1の線形保護。Detnetの場合、これは主にパケットの複製と除去機能に関連しています。MPLSは多数の保護方式を提供しています。MPLSヒットレス保護は、障害の後に迅速に配信を復元するために、トラフィックを既に確立されたパスに切り替えるために使用できます。パスの変更は、障害回復の場合でも、Detnetサービス内またはアプリケーショントラフィック内の高層化のいずれかのデータを必要とするデータの順序配信につながる可能性があります。失敗後の新しいパスの確立は、Detnet Servicesの範囲外です。
Network Coding [nwcrg], not to be confused with network programming, comprises several techniques where multiple data flows are encoded. These resulting flows can then be sent on different paths. The encoding operation can combine flows and error recovery information. When the encoded flows are decoded and recombined, the original flows can be recovered. Note that Network Coding uses an alternative to packet-by-packet PREOF. Therefore, for certain network topologies and traffic loads, Network Coding can be used to improve a network's throughput, efficiency, latency, and scalability, as well as resilience to partition, attacks, and eavesdropping, as compared to traditional methods. DetNet could use Network Coding as an alternative to other means of protection. Network Coding is often applied in wireless networks and is being explored for other network types.
ネットワーク符号化[NWCRG]は、ネットワークプログラミングと混同されないように、複数のデータフローが符号化されているいくつかの技術を含む。その結果、結果として得られるフローは、異なるパスで送信できます。エンコード操作は、フローとエラー回復情報を組み合わせることができます。符号化されたフローが復号され再結合されると、元のフローを回復することができる。ネットワーク符号化は、パケットごとのPRESOFの代替方法を使用することに注意してください。したがって、特定のネットワークトポロジおよびトラフィック負荷の場合、ネットワークコーディングを使用して、ネットワークのスループット、効率性、待ち時間、およびスケーラビリティ、および従来の方法と比較して、区切り、攻撃、および盗聴の回復力を向上させることができます。Detnetは、他の保護手段に代わるものとしてネットワークコーディングを使用できます。ネットワークコーディングはしばしば無線ネットワークに適用され、他のネットワークタイプのために探索されています。
The use of packet-by-packet load-sharing of the same DetNet flow over multiple paths is not recommended, except for the cases listed above where PREOF are utilized to improve protection of traffic and maintain order. Packet-by-packet load-sharing, e.g., via Equal-Cost Multipath (ECMP) or Unequal-Cost Multipath (UCMP), impacts ordering and, possibly, jitter.
複数のパスを介した同じDetnetフローのパケットごとの負荷分散の使用は、トラフィックの保護を改善し、順序を維持するためにPREOFが使用されている場合を除いて、上記の場合を除き、推奨されません。例えば、パケットごとの負荷分散、例えば、等価マルチパス（ECMP）または不等費用マルチパス（UCMP）、順序付け、おそらく、ジッタに影響を与えます。
DetNet leverages many different forwarding sub-layers, each of which supports various tools to troubleshoot connectivity -- for example, identification of misbehaving flows. The DetNet service layer can leverage existing mechanisms to troubleshoot or monitor flows, such as those in use by IP and MPLS networks. At the Application layer, a client of a DetNet service can use existing techniques to detect and monitor delay and loss.
Detnetはさまざまな転送サブレイヤーを活用しており、それぞれが接続性をトラブルシューティングするためのさまざまなツールをサポートします。たとえば、誤動作の流れの識別です。DetNet Service Layerは、IPおよびMPLSネットワークで使用されているものなど、既存のメカニズムを活用またはモニターすることができます。アプリケーション層では、Detnetサービスのクライアントは既存のテクニックを使用して遅延と損失を検出して監視できます。
Network analytics can be inherited from the technologies of the service and forwarding sub-layers. At the DetNet service edge, packet and bit counters (e.g., sent, received, dropped, out of sequence) can be maintained.
ネットワーク分析は、サービスのテクノロジと転送副層から継承できます。Detnet Service Edgeでは、パケットおよびビットカウンタ（例えば、送信され、受信、受信、順序が除外され、除外される）を維持することができる。
The provider of a DetNet service may provide other capabilities to monitor flows, such as more detailed loss statistics and timestamping of events. Details regarding these capabilities are out of scope for this document.
DetNetサービスのプロバイダは、より詳細な損失統計やイベントのタイムスタンプなど、フローを監視するための他の機能を提供することがあります。これらの機能に関する詳細はこの文書の範囲外です。
Service protection allows DetNet services to increase reliability and maintain a desired level of service assurance in the case of network congestion or network failure. DetNet relies on the underlying technology capabilities for various protection schemes. Protection schemes enable partial or complete coverage of the network paths and active protection with combinations of the PRF, PEF, and POF.
サービス保護により、ネットワークの輻輳やネットワーク障害の場合、Detnet Servicesは信頼性を高め、希望のレベルのサービス保証を維持できます。Detnetはさまざまな保護方式の基礎となる技術機能に依存しています。保護方式は、PRF、PEF、およびPOFの組み合わせによるネットワークパスと能動的保護の部分的または完全な保護範囲を有効にします。
An example DetNet MPLS network fragment and its packet flow are illustrated in Figure 3.
Detnet MPLSネットワークフラグメントの例とそのパケットフローの例を図3に示します。
1 1.1 1.1 1.2.1 1.2.1 1.2.2
CE1----EN1--------R1-------R2-------R3--------EN2-----CE2
\ 1.2.1 / /
\1.2 /------+ /
+------R4------------------------+
1.2.2
Figure 3: Example of Packet Flow Protected by DetNet
図3：Detnetによって保護されたパケットフローの例
In Figure 3, the numbers are used to identify the instance of a packet. Packet 1 is the original packet. Packets 1.1 and 1.2 are two first-generation copies of packet 1, packet 1.2.1 is a second-generation copy of packet 1.2, and so on. Note that these numbers never appear in the packet and are not to be confused with sequence numbers, labels, or any other identifiers that appear in the packet. They simply indicate the generation number of the original packet so that its passage through the network fragment can be identified for the reader.
図3では、数字はパケットのインスタンスを識別するために使用されます。パケット1は元のパケットです。パケット1.1と1.2はパケット1の2つの最初の世代コピーです。パケット1.2.1はパケット1.2の2世代のコピーなどです。これらの数値はパケットに表示されず、シーケンス番号、ラベル、またはパケットに表示される他の識別子と混同されないように注意してください。それらは単に元のパケットの世代番号を示すので、ネットワークフラグメントを通過することが読み取り者に対して識別できるようにする。
Customer Equipment device CE1 sends a packet into the DetNet-enabled network. This is packet 1. Edge Node EN1 encapsulates the packet as a DetNet packet and sends it to Relay Node R1 (packet 1.1). EN1 makes a copy of the packet (1.2), encapsulates it, and sends this copy to Relay Node R4.
顧客機器装置CE1は、パケットをDetNet対応ネットワークに送信する。これはパケット1である。エッジノードEN1はパケットをDetNetパケットとしてカプセル化し、それを中継ノードR1に送信する（パケット1.1）。EN1はパケット（1.2）のコピーを作成し、カプセル化し、このコピーを中継ノードR4に送信します。
Note that R1 may be directly attached to EN1, or there may be one or more nodes on the path that, for clarity, are not shown in Figure 3. The same holds true for any other path between two DetNet entities as shown in the figure.
R1はEN1に直接接続されていてもよいし、明確にするためには、図3には示されていないパス上に1つ以上のノードがあり得ることに注意してください。図に示すように、2つのDetNetエンティティ間の他のパスについても同様です。。
Relay Node R4 has been configured to send one copy of the packet to Relay Node R2 (packet 1.2.1) and one copy to Edge Node EN2 (packet 1.2.2).
中継ノードR4は、パケットのコピーを中継ノードR2（パケット1.2.1）と1つのコピーにエッジノードEN2（パケット1.2.2）に送信するように構成されている。
R2 receives packet copy 1.2.1 before packet copy 1.1 arrives and, having been configured to perform packet elimination on this DetNet flow, forwards packet 1.2.1 to Relay Node R3. Packet copy 1.1 is of no further use and so is discarded by R2.
R2は、パケットコピー1.1が到着する前にパケットコピー1.2.1を受信し、このDetNetフローでパケット除去を実行するように設定されており、パケット1.2.1を中継ノードR3に転送します。パケットコピー1.1はそれ以上の使用ではなく、R2によって破棄されます。
Edge Node EN2 receives packet copy 1.2.2 from R4 before it receives packet copy 1.2.1 from R2 via Relay Node R3. EN2 therefore strips any DetNet encapsulation from packet copy 1.2.2 and forwards the packet to CE2. When EN2 receives packet copy 1.2.1 later on, the copy is discarded.
エッジノードEN2は、R2からのパケットコピー1.2.1をR2からRELAYノードR3を介して受信する前に、R4からパケットコピー1.2.2を受信します。したがって、EN2はパケットコピー1.2.2からのDetnetカプセル化を妨げ、パケットをCE2に転送します。EN2が後でパケットコピー1.2.1を受信すると、コピーは破棄されます。
The above is of course illustrative of many network scenarios that can be configured.
上記はもちろん構成できる多くのネットワークシナリオを例示するものである。
This example also illustrates a 1:1 protection scheme, meaning there is traffic over each segment of the end-to-end path. Local DetNet relay nodes determine which packets are eliminated and which packets are forwarded. A 1+1 scheme where only one path is used for traffic at a time could use the same topology. In this case, there is no PRF, and traffic is switched upon detection of failure. An OAM scheme that monitors the paths to detect the loss of a path or traffic is required to initiate the switch. A POF may still be used in this case to prevent misordering of packets. In both cases, the protection paths are established and maintained for the duration of the DetNet service.
この例では、1：1の保護方式も示しています。つまり、エンドツーエンドパスの各セグメントにはトラフィックがあります。ローカルDetNetリレーノードは、どのパケットが除去され、どのパケットが転送されるかを決定します。1つのパスのみが一度にトラフィックに使用される1つのスキームは、同じトポロジを使用することができます。この場合、PRFはなく、障害の検出時にトラフィックが切り替わります。パスを検出するためのパスを監視するOAM方式は、スイッチを開始するために必要です。この場合、POFを使用してパケットの誤りを防ぐために使用することができる。どちらの場合も、保護パスはDetnetサービスの期間確立され維持されます。
In the preceding example, proper operation of duplicate elimination and the reordering of packets are dependent on the number of out-of-order packets that can be buffered and the difference in delay of the arriving packets. DetNet uses flow-specific requirements (e.g., maximum number of out-of-order packets, maximum latency of the flow) for configuration of POF-related buffers. If the differential delay between paths is excessively large or there is excessive misordering of the packets, then packets may be dropped instead of being reordered. Likewise, the PEF uses the sequence number to identify duplicate packets, and large differential delays combined with high numbers of packets may exceed the PEF's ability to work properly.
前述の例では、重複排除とパケットの並べ替えの適切な動作は、バッファされ得る順序のパケット数と到着パケットの遅延の差に依存しています。Detnetは、POF関連バッファの構成のためのフロー固有の要件（例えば、最大順序パケットの最大数、フローの最大待ち時間）を使用します。パス間の差動遅延が過度に大きいか、パケットの過度の誤符がある場合、並べ替えられる代わりにパケットが脱落されてもよい。同様に、PEFはシーケンス番号を使用して複製パケットを識別し、多数のパケットと組み合わされた大きな差動遅延がPEFのPEFの能力を正しく機能させる可能性があります。
Ring protection may also be supported if the underlying technology supports it. Many of the same concepts apply; however, rings are normally 1+1 protection for data efficiency reasons. [RFC8227] provides an example of an MPLS Transport Profile (MPLS-TP) data plane that supports ring protection.
基礎となる技術がそれをサポートしている場合は、リング保護もサポートされる可能性があります。同じ概念の多くが適用されます。ただし、リングは通常、データ効率の理由から1 1の保護です。[RFC8227]リング保護をサポートするMPLSトランスポートプロファイル（MPLS-TP）データプレーンの例を示します。
The DetNet data plane also allows for the aggregation of DetNet flows, which can improve scalability by reducing the per-hop state. How this is accomplished is data plane or control plane dependent. When DetNet flows are aggregated, transit nodes provide service to the aggregate and not on a per-DetNet-flow basis. When aggregating DetNet flows, the flows should be compatible, i.e., the same or very similar QoS and CoS characteristics. In this case, nodes performing aggregation will ensure that per-flow service requirements are achieved.
DetNetデータプレーンはまた、DetNetフローの集約を可能にし、それはホップごとの状態を減らすことによってスケーラビリティを向上させることができる。これがどのように達成されるかはデータプレーンまたはコントロールプレーンに依存します。DetNetフローが集約されている場合、トランジットノードは集約にサービスを提供し、Detnet-Flowベースではありません。DETNETの流れを集約するとき、フローは互換性がある、すなわち、同じまたは非常に類似のQoSおよびCoS特性であるべきである。この場合、集約を実行するノードは、フローごとのサービス要件が実現されるようになります。
If bandwidth reservations are used, the reservation should be the sum of all the individual reservations; in other words, the reservations should not add up to an oversubscription of bandwidth reservation. If maximum delay bounds are used, the system should ensure that the aggregate does not exceed the delay bounds of the individual flows.
帯域幅の予約が使用されている場合、予約はすべての個々の予約の合計であるべきです。言い換えれば、予約は帯域幅予約のオーバーサブスクリプションに追加されないでください。最大遅延範囲が使用されている場合、システムは集約が個々のフローの遅延範囲を超えないようにする必要があります。
When an encapsulation is used, the choice of reserving a maximum resource level and then tracking the services in the aggregated service or adjusting the aggregated resources as the services are added is implementation and technology specific.
カプセル化が使用されている場合は、最大リソースレベルを予約して、集約されたサービス内のサービスを追跡するか、またはサービスが追加されているため、アグリゲートされたリソースの調整の選択が実装とテクノロジ固有です。
DetNet flows at edges must be able to handle rejection to an aggregation group due to lack of resources as well as conditions where requirements are not satisfied.
エッジでのDetnetフローは、リソースの不足、および要件が満たされていない条件のために集約グループへの拒否を処理できる必要があります。
IP aggregation has both data plane and Controller Plane aspects. For the data plane, flows may be aggregated for treatment based on shared characteristics such as 6-tuple [RFC8939]. Alternatively, an IP encapsulation may be used to tunnel an aggregate number of DetNet flows between relay nodes.
IP集約には、データプレーンとコントローラの両方の面があります。データプレーンについては、6タプル[RFC8939]などの共有特性に基づく処理のためにフローを集計することができる。あるいは、リレーノード間の集計数のDetNetフローの数をトンネリングするためにIPカプセル化を使用することができる。
MPLS aggregation also has data plane and Controller Plane aspects. MPLS flows are often tunneled in a forwarding sub-layer, under the reservation associated with that MPLS tunnel.
MPLS集約には、データプレーンおよびコントローラプレーンの側面もあります。MPLSフローは、そのMPLSトンネルに関連付けられている予約の下、転送サブレイヤでトンネリングされることが多い。
Data flows requiring DetNet service are generated and terminated on end systems. Encapsulation depends on the application and its preferences. For example, in a DetNet MPLS domain, the sub-layer functions use the d-CWs, S-Labels, and F-Labels [DetNet-MPLS] to provide DetNet services. However, an application may exchange further flow-related parameters (e.g., timestamps) that are not provided by DetNet functions.
DetNetサービスを必要とするデータフローは、エンドシステムで生成され、終了されます。カプセル化はアプリケーションとその好みによって異なります。たとえば、Detnet MPLSドメインでは、サブレイヤー機能はD-CWS、Sラベル、およびFラベル[Detnet-MPLS]を使用してDetNet Servicesを提供します。しかしながら、アプリケーションは、DetNet関数によって提供されないさらなるフロー関連パラメータ（例えば、タイムスタンプ）を交換することができる。
As a general rule, DetNet domains are capable of forwarding any DetNet flows, and the DetNet domain does not mandate the encapsulation format for end systems or edge nodes. Unless some form of proxy is present, end systems peer with similar end systems using the same application encapsulation format. For example, as shown in Figure 4, IP applications peer with IP applications, and Ethernet applications peer with Ethernet applications.
一般的な規則として、DetNetドメインはDetnetフローを転送することができ、Detnetドメインはエンドシステムまたはエッジノードのカプセル化フォーマットを義務付けていません。何らかのプロキシが存在しない限り、同じアプリケーションのカプセル化フォーマットを使用して同様のエンドシステムを搭載したエンドシステムピア。たとえば、図4に示すように、IPアプリケーションがIPアプリケーションと同ピア、イーサネットアプリケーションがイーサネットアプリケーションでピアを入力します。
+-----+
| X | +-----+
+-----+ | X |
| Eth | ________ +-----+
+-----+ _____ / \ | Eth |
\ / \__/ \___ +-----+
\ / \ /
0======== tunnel-1 ========0_
| \
\ |
0========= tunnel-2 =========0
/ \ __/ \
+-----+ \__ DetNet MPLS domain / \
| X | \ __ / +-----+
+-----+ \_______/ \_____/ | X |
| IP | +-----+
+-----+ | IP |
+-----+
Figure 4: End Systems and the DetNet MPLS Domain
図4：エンドシステムとDetNet MPLSドメイン
Any of the DetNet service types may be transported by another DetNet service. MPLS nodes may be interconnected by different sub-network technologies, which may include point-to-point links. Each of these sub-network technologies needs to provide appropriate service to DetNet flows. In some cases, e.g., on dedicated point-to-point links or TDM technologies, all that is required is for a DetNet node to appropriately queue its output traffic. In other cases, DetNet nodes will need to map DetNet flows to the flow semantics (i.e., identifiers) and mechanisms used by an underlying sub-network technology. Figure 5 shows several examples of sub-network encapsulations that can be used to carry DetNet MPLS flows over different sub-network technologies. L2 represents a generic Layer 2 encapsulation that might be used on a point-to-point link. TSN represents the encapsulation used on an IEEE 802.1 TSN network, as described in [DetNet-MPLS-over-TSN]. UDP/IP represents the encapsulation used on a DetNet IP PSN, as described in [DetNet-MPLS-over-UDP-IP].
Detnetサービスタイプのいずれかは、他のDetnetサービスによって転送される可能性があります。 MPLSノードは、ポイントツーポイントリンクを含むことができるさまざまなサブネットワーク技術によって相互接続されてもよい。これらのサブネットワーク技術のそれぞれは、Detnetフローに適切なサービスを提供する必要があります。場合によっては、例えば専用のポイントツーポイントリンクまたはTDMテクノロジでは、必要なのはDetNet Nodeがその出力トラフィックを適切にキューに入れることです。他の場合では、DetNetノードは、基礎となるサブネットワーク技術によって使用されるフローセマンティクス（すなわち、識別子）およびメカニズムにDetNetフローをマッピングする必要がある。図5は、異なるサブネットワーク技術上でDetNet MPLSフローを運ぶために使用できるサブネットワークカプセルのいくつかの例を示しています。 L2は、ポイントツーポイントリンクで使用され得る一般的なレイヤ2カプセル化を表します。 TSNは、[detnet-mpls-over-tsn]で説明されているように、IEEE 802.1 TSNネットワークで使用されるカプセル化を表します。 UDP / IPは、[detnet-mpls-over-over-udp-ip]で説明されているように、Detnet IP PSNで使用されるカプセル化を表します。
+------+ +------+ +------+
App-flow | X | | X | | X |
+-----+======+--+======+--+======+-----+
DetNet-MPLS | d-CW | | d-CW | | d-CW |
+------+ +------+ +------+
|Labels| |Labels| |Labels|
+-----+======+--+======+--+======+-----+
Sub-network | L2 | | TSN | | UDP |
+------+ +------+ +------+
| IP |
+------+
| L2 |
+------+
Figure 5: Example DetNet MPLS Encapsulations in Sub-networks
図5：サブネットワークにおけるDetnet MPLSカプセル化の例
The Controller Plane corresponds to the aggregation of the Control and Management Planes discussed in [RFC7426] and [RFC8655]. While more details regarding any DetNet Controller Plane are out of scope for this document, there are particular considerations and requirements for the Controller Plane that result from the unique characteristics of the DetNet architecture and data plane as defined herein.
コントローラプレーンは、[RFC7426]および[RFC8655]で説明した制御および管理プレーンの集合に対応しています。Detnet Controller Planeに関する詳細は、この文書の範囲外のものですが、ここで定義されているDetnetアーキテクチャとデータプレーンの固有の特性から生じるコントローラプレーンの特別な考慮事項と要件があります。
The primary requirements of the DetNet Controller Plane are that it must be able to:
DetNet Controllerプレーンの主な要件は、次のことができることです。
* Instantiate DetNet flows in a DetNet domain (which may, for example, include some or all of the following: explicit path determination, link bandwidth reservations, restricting flows to IEEE 802.1 TSN links, node buffer and other resource reservations, specification of required queuing disciplines along the path, ability to manage bidirectional flows, etc.) as needed for a flow.
* Detnetドメイン内のDetnetフローをインスタンス化する（たとえば、次の一部または全部を含めることができます。明示的なパスの決定、リンク帯域幅の予約、IEEE 802.1 TSNリンクへの制限、ノードバッファ、およびその他のリソースの予約、必要なキューイング分類の指定経路に沿って、フローに必要なように双方向フローなどを管理する能力。
* In the case of MPLS, manage DetNet S-Label and F-Label allocation and distribution. In cases where the DetNet MPLS encapsulation is being used, see [DetNet-MPLS].
* MPLSの場合は、Detnet SラベルとFラベルの割り当てと配布を管理します。Detnet MPLSのカプセル化が使用されている場合は、[Detnet-MPLS]を参照してください。
* Support DetNet flow aggregation.
* Detnet Flow集計をサポートします。
* Advertise static and dynamic node and link resources such as capabilities and adjacencies to other network nodes (for dynamic signaling approaches) or to network controllers (for centralized approaches).
* 静的および動的なノードおよび機能や隣接関係などのリンクリソース（動的シグナリングアプローチのための）またはネットワークコントローラ（集中的なアプローチのために）をアドバタイズします。
* Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning).
* ドメインで予想されるDetNetフローの数を処理するためのスケール（フローシグナリングまたはプロビジョニングを必要とする可能性があります）。
* Provision flow identification information at each of the nodes along the path. Flow identification may differ, depending on the location in the network and the DetNet functionality (e.g., transit node vs. relay node).
* 経路に沿って各ノードにフロー識別情報を提供する。フロー識別は、ネットワーク内の場所およびDetNet機能（例えば、トランジットノードVS.リレーノード）によって異なる場合がある。
These requirements, as stated earlier, could be satisfied using distributed control protocol signaling (such as RSVP-TE), centralized network management provisioning mechanisms (BGP, PCEP, YANG, [DetNet-Flow-Info], etc.), or hybrid combinations of the two, and could also make use of MPLS-based segment routing.
これらの要件は、前述のように、分散制御プロトコルシグナリング（RSVP-TEなど）、集中型ネットワーク管理プロビジョニングメカニズム（BGP、PCEP、YANG、[DetNet-Flow-Info]など）、またはハイブリッドの組み合わせを使用して満足できます。2つのうち、MPLSベースのセグメントルーティングを利用することもできます。
In the abstract, the results of either distributed signaling or centralized provisioning are equivalent from a DetNet data plane perspective -- flows are instantiated, explicit routes are determined, resources are reserved, and packets are forwarded through the domain using the DetNet data plane.
要約では、分散シグナリングまたは集中型プロビジョニングの結果がDetnetデータプレーンの観点から等価です。フローはインスタンス化され、明示的なルートが決定され、リソースは予約されており、パケットはDetNetデータプレーンを使用してパケットを通って転送されます。
However, from a practical and implementation standpoint, Controller Plane alternatives are not equivalent at all. Some approaches are more scalable than others in terms of signaling load on the network. Some alternatives can take advantage of global tracking of resources in the DetNet domain for better overall network resource optimization. Some solutions are more resilient than others if link, node, or management equipment failures occur. While a detailed analysis of the control plane alternatives is out of scope for this document, the requirements from this document can be used as the basis of a future analysis of the alternatives.
しかしながら、実用的および実施の観点からは、コントローラプレーンの選択肢は全く同等ではない。いくつかのアプローチは、ネットワーク上のシグナリング負荷に関して他のものよりもスケーラブルです。いくつかの代替案は、ネットワークリソースの最適化をより良くするために、DetNetドメイン内のリソースのグローバルな追跡を利用することができます。リンク、ノード、または管理機器の障害が発生した場合、一部のソリューションは他のソリューションよりも弾力がある。コントロールプレーンの詳細な分析はこの文書の範囲外ですが、この文書の要件は代替案の将来の分析の基礎として使用できます。
This section covers control plane considerations that are independent of the data plane technology used for DetNet service delivery.
このセクションでは、Detnet Service Deliveryに使用されるデータプレーン技術とは無関係のコントロールプレーンの考慮事項について説明します。
While the management plane and the control plane are traditionally considered separately, from a data plane perspective, there is no practical difference based on the origin of flow-provisioning information, and the DetNet architecture [RFC8655] refers to these collectively as the "Controller Plane". This document therefore does not distinguish between information provided by distributed control plane protocols (e.g., RSVP-TE [RFC3209] [RFC3473]) or centralized network management mechanisms (e.g., RESTCONF [RFC8040], YANG [RFC7950], PCEP [PCECC]), or any combination thereof. Specific considerations and requirements for the DetNet Controller Plane are discussed in Section 4.1.
管理プレーンと制御プレーンは伝統的に別々に考慮されていますが、データプレーンの観点からは、フロープロビジョニング情報の起源に基づく実際的な違いはなく、DetNetアーキテクチャ[RFC8655]は「コントローラプレーン」としてまとめてこれらを指します。"。したがって、この文書は、分散制御プレーンプロトコル（例えば、RSVP-TE [RFC3209] [RFC3473]）または集中型ネットワーク管理メカニズム（例えば、RESTCONF [RFC8040]、ヤン（RFC7950]、PCEP [PCECC]など）を区別しません。、またはそれらの任意の組み合わせ。DetNet Controllerプレーンの具体的な考慮事項と要件については、4.1節で説明します。
Each respective data plane document also covers the control plane considerations for that technology. For example, [RFC8939] also covers IP control plane normative considerations, and [DetNet-MPLS] also covers MPLS control plane normative considerations.
それぞれのデータプレーン文書はまた、その技術に対する制御プレーンの考慮事項を網羅している。たとえば、[RFC8939]もIPコントロールプレーン規範的考慮事項をカバーしており、[DetNet-MPLS]もMPLS制御プレーン規範的考慮事項をカバーしています。
Flow aggregation means that multiple App-flows are served by a single new DetNet flow. There are many techniques to achieve aggregation. For example, in the case of IP, IP flows that share 6-tuple attributes or flow identifiers at the DetNet sub-layer can be grouped. Another example includes aggregation accomplished through the use of hierarchical LSPs in MPLS and tunnels.
フロー集約は、複数のアプリフローが単一の新しいDetnetフローによって提供されることを意味します。集約を達成するための多くの技術があります。たとえば、IPの場合、Detnetサブレイヤで6タプル属性またはフロー識別子を共有するIPフローをグループ化できます。別の例には、MPLSおよびトンネルで階層的LSPを使用して達成された集計が含まれます。
Control of aggregation involves a set of procedures listed here. Aggregation may use some or all of these capabilities, and the order may vary:
集約の制御はここにリストされている一連の手順を含みます。集約はこれらの機能の一部または全部を使用することができ、注文はさまざまです。
Traffic engineering resource collection and distribution: Available resources are tracked through control plane or management plane databases and distributed amongst controllers or nodes that can manage resources.
トラフィックエンジニアリングリソースの収集と配布：利用可能なリソースは、制御プレーンまたは管理プレーンデータベースを介して追跡され、リソースを管理できるコントローラまたはノードの間で分散されます。
Path computation and resource allocation: When DetNet services are provisioned or requested, one or more paths meeting the requirements are selected and the resources verified and recorded.
パス計算とリソースの割り当て：Detnet Servicesがプロビジョニングまたは要求されている場合、要件を満たす1つ以上のパスが選択され、リソースが検証および記録されます。
Resource assignment and data plane coordination: The assignment of resources along the path depends on the technology and includes assignment of specific links, coordination of queuing, and other traffic management capabilities such as policing and shaping.
リソース割り当てとデータプレーンの連携：経路に沿ったリソースの割り当ては、テクノロジによって異なり、特定のリンクの割り当て、キューイングの調整、およびポリシングやシェーピングなどの他のトラフィック管理機能を含みます。
Assigned resource recording and updating: Depending on the specific technology, the assigned resources are updated and distributed in the databases, preventing oversubscription.
割り当てられたリソースの録音と更新：特定のテクノロジによっては、割り当てられたリソースが更新され、データベースに配布され、オーバーサブスクリプションが防止されます。
Explicit routes are used to ensure that packets are routed through the resources that have been reserved for them and hence provide the DetNet application with the required service. A requirement for the DetNet Controller Plane will be the ability to assign a particular identified DetNet IP flow to a path through the DetNet domain that has been assigned the required per-node resources. This provides the appropriate traffic treatment for the flow and also includes particular links as a part of the path that are able to support the DetNet flow. For example, by using IEEE 802.1 TSN links (as discussed in [DetNet-MPLS-over-TSN]), DetNet parameters can be maintained. Further considerations and requirements for the DetNet Controller Plane are discussed in Section 4.1.
明示的な経路は、パケットがそれらのために予約されているリソースを通してルーティングされることを確実にするために使用され、それ故にDetnetアプリケーションに必要なサービスを提供することを確実にします。DetNet Controller Planeの要件は、必要なノードごとのリソースが割り当てられているDetNetドメインを介して、特定の識別されたDetnet IPフローをパスに割り当てることができます。これはフローのための適切なトラフィック処理を提供し、Detnetフローをサポートすることができるパスの一部としての特定のリンクを含む。たとえば、IEEE 802.1 TSNリンクを使用することで（[Detnet-MPLS-over-TSN]で説明されているように）、DetNetパラメータを維持できます。Detnet Controllerプレーンのさらなる考慮事項および要件については、セクション4.1で説明します。
Whether configuring, calculating, and instantiating these routes is a single-stage or multi-stage process, or is performed in a centralized or distributed manner, is out of scope for this document.
これらの経路を構成、計算、およびインスタンス化するかインスタンス化するか、または集中型または分散方法で実行されているかは、この文書には範囲外です。
There are several approaches that could be used to provide explicit routes and resource allocation in the DetNet forwarding sub-layer. For example:
DetNet転送サブレイヤに明示的なルートとリソース割り当てを提供するために使用できるいくつかのアプローチがあります。例えば：
* The path could be explicitly set up by a controller that calculates the path and explicitly configures each node along that path with the appropriate forwarding and resource allocation information.
* パスは、パスを計算するコントローラによって明示的に設定され、そのパスに沿って各ノードを適切な転送とリソースの割り当て情報で明示的に設定できます。
* The path could use a distributed control plane such as RSVP [RFC2205] or RSVP-TE [RFC3473] extended to support DetNet IP flows.
* パスは、RSVP [RFC2205]またはRSVP-TE [RFC3473]などの分散制御プレーンを使用してDetNet IPフローをサポートします。
* The path could be implemented using IPv6-based segment routing when extended to support resource allocation.
* パスは、リソース割り当てをサポートするように拡張されたときにIPv6ベースのセグメントルーティングを使用して実装できます。
See Section 4.1 for further discussion of these alternatives. In addition, [RFC2386] contains useful background information on QoS-based routing, and [RFC5575] (which will be updated by [Flow-Spec-Rules]) discusses a specific mechanism used by BGP for traffic flow specification and policy-based routing.
これらの選択肢についてのさらなる議論については、セクション4.1を参照してください。また、[RFC2386]にはQoSベースのルーティングに関する有用な背景情報が含まれており、[Flow-Spec-Rulessによって更新される）は、トラフィックフローの指定とポリシーベースのルーティングのためにBGPが使用する特定のメカニズムについて説明しています。。
This document does not specify the mechanisms needed to eliminate packet contention or packet loss or to reduce jitter for DetNet flows at the DetNet forwarding sub-layer. The ability to manage node and link resources to be able to provide these functions is a necessary part of the DetNet Controller Plane. It is also necessary to be able to control the required queuing mechanisms used to provide these functions along a flow's path through the network. See [RFC8939] and Section 4.1 for further discussion of these requirements. Some forms of protection may minimize packet loss or change jitter characteristics in the cases where packets are reordered when out-of-order packets are received at the service sub-layer.
この文書は、パケットの競合やパケット損失を排除するため、またはDetNet転送サブレイヤでのDetNetフローのジッタを減らすために必要なメカニズムを指定していません。これらの機能を提供できるようにノードとリンクリソースを管理する機能は、DetNet Controllerプレーンの必要な部分です。ネットワークを通るフローの経路に沿ってこれらの機能を提供するために使用される必要なキューイングメカニズムを制御することができることも必要である。これらの要件についてのさらなる議論については、[RFC8939]とセクション4.1を参照してください。いくつかの形式の保護は、パケットの損失を最小限に抑えることができ、またはパケットがサービスサブレイヤで受信されたときにパケットが並べ替えられる場合には、パケットが並べ替えられる場合がある。
In many cases, DetNet flows can be considered unidirectional and independent. However, there are cases where the DetNet service requires bidirectional traffic from a DetNet application service perspective. IP and MPLS typically treat each direction separately and do not force interdependence of each direction. The IETF MPLS Working Group has studied bidirectional traffic requirements. The definitions provided in [RFC5654] are useful to illustrate terms such as associated bidirectional flows and co-routed bidirectional flows. MPLS defines a point-to-point associated bidirectional LSP as consisting of two unidirectional point-to-point LSPs, one from A to B and the other from B to A, which are regarded as providing a single logical bidirectional forwarding path. This is analogous to standard IP routing. MPLS defines a point-to-point co-routed bidirectional LSP as an associated bidirectional LSP that satisfies the additional constraint that its two unidirectional component LSPs follow the same path (in terms of both nodes and links) in both directions. An important property of co-routed bidirectional LSPs is that their unidirectional component LSPs share fate. In both types of bidirectional LSPs, resource reservations may differ in each direction. The concepts of associated bidirectional flows and co-routed bidirectional flows can also be applied to DetNet IP flows.
多くの場合、Detnet Flowは単方向で独立していると見なすことができます。ただし、DetnetサービスにDetnetアプリケーションサービスの観点から双方向トラフィックが必要な場合があります。 IPおよびMPLは通常、各方向を別々に扱い、各方向の相互依存を強制しない。 IETF MPLSワーキンググループは双方向のトラフィック要件を研究しました。 [RFC5654]で提供されている定義は、関連する双方向フローおよび共ルード双方向フローなどの用語を説明するのに役立ちます。 MPLSは、2つの単方向点間LSPからなるポイントツーポイント関連双方向LSP、AからBへ、もう1つはBからAへ、もう1つは単一の論理双方向転送経路を提供すると見なされます。これは標準のIPルーティングに似ています。 MPLSは、両方の単方向コンポーネントLSPが同じ経路に従う追加の制約（両方向の両方の点で）に従う追加の制約を満たす関連する双方向LSPとして、ポイントツーポイント共ルード双方向LSPを定義します。共配線双方向LSPの重要な性質は、それらの一方向コンポーネントLSPが運命を共有することです。両方の種類の双方向LSPでは、リソース予約は各方向に異なる場合があります。関連する双方向フローの概念と共ルード双方向フローもDetNet IPフローに適用できます。
While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features with respect to the data plane other than the need for the two directions of a co-routed bidirectional flow to take the same path. That is to say, bidirectional DetNet flows are solely represented at the management plane and control plane levels, without specific support or knowledge within the DetNet data plane. Fate-sharing and associated or co-routed bidirectional flows can be managed at the control level.
DetNet IPデータプレーンが双方向DetNetフローをサポートしている必要があるが、同じ経路をとるために同時経路双方向フローの2つの方向の必要性以外のデータプレーンに関して特別な双方向特徴はない。すなわち、双方向のDETNETフローは、DetNetデータプレーン内の特定のサポートまたは知識なしに、管理プレーンおよび制御プレーンレベルでのみ表現される。Fate-Sharingおよび関連する双方向フローは、コントロールレベルで管理できます。
DetNet's use of PREOF may increase the complexity of using co-routing bidirectional flows, because if PREOF are used, the replication points in one direction would have to match the elimination points in the other direction, and vice versa. In such cases, the optimal points for these functions in one direction may not match the optimal points in the other, due to network and traffic constraints. Furthermore, due to the per-packet service protection nature, bidirectional forwarding may not be ensured. The first packet of received member flows is selected by the elimination function independently of which path it has taken through the network.
DetnetのPREOFの使用は、共ルーティング双方向フローを使用することの複雑さを高めることができます。なぜなら、1方向の複製点は他の方向の除去点と一致する必要があるため、その逆も同様です。そのような場合、ネットワークとトラフィックの制約により、一方向のこれらの機能の最適な点は、もう一方の方向に最適な点と一致しない可能性があります。さらに、パケットごとのサービス保護の性質のために、双方向の転送が保証されない可能性があります。受信メンバフローの最初のパケットは、ネットワークを介して実行されたパスとは無関係に除去関数によって選択されます。
Control and management mechanisms need to support bidirectional flows, but the specification of such mechanisms is out of scope for this document. Example control plane solutions for MPLS can be found in [RFC3473], [RFC6387], and [RFC7551]. These requirements are included in Section 4.1.
制御および管理メカニズムは双方向フローをサポートする必要がありますが、そのようなメカニズムの仕様はこの文書の範囲外です。例示的な制御プレーンソリューションMPLSの場合は[RFC3473]、[RFC6387]、[RFC7551]にあります。これらの要件はセクション4.1に含まれています。
The Controller Plane protocol solution required for managing the processing of PREOF is outside the scope of this document. That said, it should be noted that the ability to determine, for a particular flow, optimal packet replication and elimination points in the DetNet domain requires explicit support. There may be existing capabilities that can be used or extended -- for example, GMPLS end-to-end recovery [RFC4872] and GMPLS segment recovery [RFC4873].
PREOFの処理を管理するために必要なコントローラプレーンプロトコルソリューションは、この文書の範囲外です。つまり、DetNetドメイン内の特定のフロー、最適なパケット複製、および排除点を決定する能力が明示的なサポートを必要とすることに留意されたい。既存の機能がある場合があります。既存の機能があります。たとえば、GMPLSエンドツーエンドリカバリ[RFC4872]とGMPLSセグメントの回復[RFC4873]。
Security considerations for DetNet are described in detail in [DetNet-Security]. General security considerations for the DetNet architecture are described in [RFC8655]. This section considers architecture-level DetNet security considerations applicable to all data planes.
Detnetのセキュリティ上の考慮事項は[Detnet-Security]で詳しく説明しています。Detnetアーキテクチャの一般的なセキュリティ上の考慮事項は[RFC8655]に記載されています。このセクションでは、すべてのデータプレーンに適用されるアーキテクチャレベルのDetnetセキュリティの考慮事項を考慮します。
Part of what makes DetNet unique is its ability to provide specific and reliable QoS (delivering data flows with extremely low packet loss rates and bounded end-to-end delivery latency), and the security-related aspects of protecting that QoS are similarly unique.
Detnet Uniqueを設定するものの一部は、特定の信頼性の高いQoS（極めて低いパケット損失率と最終的なエンドツーエンド配信待ち時間を持つデータフローを配信する）、およびそのQoSを保護するセキュリティ関連の側面を同じように提供する能力です。
As for all communications protocols, the primary consideration for the 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 is 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 Ethernet (Layer 2) flows.
すべての通信プロトコルに関しては、データプレーンに対する主な考慮事項は、データの完全性を維持することであり、DetNetネットワークを通過する関連するDetNetサービスの配信の配信を維持することである。アプリケーションフローは、基礎となる技術によって提供されているものが何にもかかわらず保護できます。例えば、IPSec [RFC4301]によってIPSEC（RFC4301]が提供され、イーサネット（レイヤ2）の場合はMACSEC [IEEE802.1AE-2018]を使用する基礎となるサブネットワークによって提供されるなど、暗号化が使用されてもよい。
At the management and control levels, 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 can be prevented or mitigated -- for example, through the use of existing mechanisms such as policing and shaping applied at the input of a DetNet domain. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definitions can allow for the mitigation of man-in-the-middle attacks -- for example, through the use of authentication and authorization of devices within the DetNet domain.
Detnetサービスの中断のない可用性を提供するために、DOS攻撃や遅延攻撃に対して規定を行うことができます。DOS攻撃から保護するために、悪意のある機器や故障のための過剰な交通量を防止または軽減することができます。たとえば、DetNetドメインの入力に適用されるポリシングや整形などの既存のメカニズムを使用することができます。DetNetドメインの外部のエンティティによってDetnet Packetが遅れるのを防ぐため、Detnet Technologyの定義は、MAN-In-The Middle Attacksの軽減を可能にします。たとえば、Detnet内のデバイスの認証と認証を行うことができます。ドメイン。
In order to prevent or mitigate DetNet attacks on other networks via flow escape, edge devices can, for example, use existing mechanisms such as policing and shaping applied at the output of a DetNet domain.
フローエスケープを介して他のネットワーク上でのDetNet攻撃を防止または軽減するために、エッジデバイスは、例えば、DetNetドメインの出力で適用されるポリシングやシェーピングなどの既存のメカニズムを使用することができる。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[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>。
[DetNet-Flow-Info] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "DetNet Flow Information Model", Work in Progress, Internet-Draft, draft-ietf-detnet-flow-information-model-11, 21 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11>.
[DetNet-Flow-Info] Varga、B、Farkas、J.、Cummings、R.、Jiang、Y.、D. Fedyk、「Detnet Flow Information Model」、進行中の作業、インターネットドラフト、ドラフトIETF-detnet-flow-information-model-11,21月21日、<https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11>
[DetNet-MPLS] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-13, 11 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-13>.
[Detnet-MPLS]バルガ、B、ED。、Farkas、J.、Berger、L.、Malis、A.、Bryant、S.、J.Korhhonen、「Detnet Data Plane：MPLS」、進行中の働き、2020年10月11日、<https：//tools.ietf.org/html/draft-ietf-detnet-mpls-13>。
[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-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-04>.
[Detnet-MPLS-over-TSN] Varga、B、ED。、Farkas、J.、Malis、A.、Bryant、「Detnet Data Plane：IEEE 802.1時間敏感ネットワーク（TSN）」、作業進行中、インターネットドラフト、ドラフト - IETF-Detnet-MPLS-over-TSN-04,2020、<https：//tools.ietf.org/html/draft-ietf-detnet-mpls-over-tsn-04>。
[DetNet-MPLS-over-UDP-IP] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "DetNet Data Plane: MPLS over UDP/IP", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-over-udp-ip-07, 11 October 2020, <https://tools.ietf.org/html/ draft-ietf-detnet-mpls-over-udp-ip-07>.
[Detnet-MPLS-OVER-UDP-IP] VARGA、B、ED。、Farkas、J.、Berger、L.、Malis、A.、およびS.ブライアント、「Detnetデータプレーン：UDP / IP上のMPLS」、進行中の作業、インターネットドラフト、ドラフト - IETF-Detnet-MPLS-over-UDP-IP-07,110、<https：//tools.ietf.org/html/ romft-ietf-detnet-mpls-OVER-UDP-IP-07>。
[DetNet-Security] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-12, 2 October 2020, <https://tools.ietf.org/html/draft-ietf-detnet-security-12>.
[Detnet-Security] Grossman、E.、ED。、Mizrahi、T.、およびA.ハッカー、「決定論的ネットワーキング（DetnetInstry）セキュリティ上の考慮事項」、進行中の作業、インターネットドラフト、ドラフトIETF-Detnet-Security-12、2020年10月2日、<https://tools.ietf.org/html/draft-ietf-detnet-security-12>
[Flow-Spec-Rules] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-rfc5575bis-27, 15 October 2020, <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-27>.
[フロースペック規則] LOIBL、C、HARES、S.、Raszuk、R.、McPherson、D.、およびM. Bacher、「フロー仕様規則の普及」、進行中の作業、インターネットドラフト、ドラフト - <https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-idr-rfc5575bis-idr-rfc 5575bis - 27>。
[IEEE802.1AE-2018] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE Std 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1ae-2018] IEEE、「地元の地域と首都圏のIEEE規格ネットワーク - メディアアクセス管理（MAC）セキュリティ」、IEEE STD 802.1AE-2018、DOI 10.1109 / IEEESTD.2018.8585421、2018年12月、<https：//ieeexplore.ieee.org/document/8585421>。
[IEEE802.1TSNTG] IEEE, "Time-Sensitive Networking (TSN) Task Group", <https://1.ieee802.org/tsn/>.
[IEEE802.1TSNTG] IEEE、「時間依存ネットワーキング（TSN）タスクグループ」、<https：//1.ieee802.org/tsn/>。
[nwcrg] IRTF, "Coding for efficient NetWork Communications Research Group (nwcrg)", <https://datatracker.ietf.org/rg/nwcrg/about>.
[NWCRG] IRTF、「効率的なネットワーク通信研究グループ（NWCRG）のコーディング（NWCRG）」、<https://datatracker.ietf.org/rg/nwcrg/about>。
[PCECC] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", Work in Progress, Internet-Draft, draft-ietf-pce-pcep-extension-for-pce-controller-08, 1 November 2020, <https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-08>.
[PCECC] Li、Z.、Peng、S.、NEGI、MS、Zhao、Q.、C.Zhou、「PCEの中央コントローラ（PCECCの中央コントローラ（PCECC）としてPCEを使用するためのプロトコル拡張機能」、進行中の作業、インターネットドラフト、ドラフト - IETF-PCE-PCEP-Extension-for-PCE-Controller-08、2020年11月1日、<https：//tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller-08>。
[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>。
[RFC2386] Crawley, E., Nair, R., Rajagopalan, B., and H. Sandick, "A Framework for QoS-based Routing in the Internet", RFC 2386, DOI 10.17487/RFC2386, August 1998, <https://www.rfc-editor.org/info/rfc2386>.
[RFC2386]クローリー、E.、Nair、R.、Rajagalan、B.、およびH. Sandick、「インターネットにおけるQoSベースルーティングのためのフレームワーク」、RFC 2386、DOI 10.17487 / RFC2386、1998年8月、<https：//www.rfc-editor.org/info/rfc2386>。
[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>。
[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>。
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, DOI 10.17487/RFC3670, January 2004, <https://www.rfc-editor.org/info/rfc3670>.
[RFC3670]ムーア、B.、Durham、D.、Strassner、J.、Westerinen、A.およびW.Weiss、「ネットワークデバイスQoSデータパスのメカニズムを説明するための情報モデル」、RFC 3670、DOI 10.17487 / RFC3670、2004年1月<https：//www.rfc-editor.org/info/rfc3670>。
[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>。
[RFC4872] Lang, J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007, <https://www.rfc-editor.org/info/rfc4872>.
[RFC4872] Lang、JP、ED。、REKHTER、Y、ED。、およびD.Papadimitriou、ED。、「エンドツーエンド一般化マルチプロトコルラベルスイッチング（GMPLS）リカバリのサポートのRSVP-TE拡張」。、RFC 4872、DOI 10.17487 / RFC4872、2007年5月、<https：//www.rfc-editor.org/info/rfc4872>。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>.
[RFC4873] Berger、L.、Bryskin、I。、Papadimitriou、D.、およびA. Farrel、 "GMPLSセグメントの回復"、RFC 4873、DOI 10.17487 / RFC4873、2007年5月、<https：//www.rfc-編集者.ORG / INFO / RFC4873>。
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., and D. McPherson, "Dissemination of Flow Specification Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, <https://www.rfc-editor.org/info/rfc5575>.
[RFC5575] Marques、P.、Sheth、N.、Raszuk、R.、Greene、B.、Mauch、J.、およびD. McPherson、「フロー仕様規則の普及」、RFC 5575、DOI 10.17487 / RFC5575、8月2009年、<https://www.rfc-editor.org/info/rfc5575>。
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, DOI 10.17487/RFC5654, September 2009, <https://www.rfc-editor.org/info/rfc5654>.
[RFC5654] Nive-Jenkins、B.、ED。、Brungard、D.、ED。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「MPLSトランスポートプロファイルの要求」、RFC 5654、DOI 10.17487 / RFC5654、2009年9月、<https：//www.rfc-editor.org/info/rfc5654>。
[RFC6387] Takacs, A., Berger, L., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 6387, DOI 10.17487/RFC6387, September 2011, <https://www.rfc-editor.org/info/rfc6387>.
[RFC6387] Takacs、A。、Berger、L.、Caviglia、D.、Fedyk、D.、およびJ.Meuriic、「GMPLS非対称帯域幅双方向ラベルスイッチパス（LSP）」、RFC 6387、DOI 10.17487 / RFC6387、9月2011年、<https：//www.rfc-editor.org/info/rfc6387>。
[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-Defined Networking (SDN): Layers and Architecture Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2015, <https://www.rfc-editor.org/info/rfc7426>.
[RFC7426] Haleplidis、E.、Ed。、Pentikisis、K.、Ed。、Denazis、S.、Hadi Salim、J.、Meyer、D.、およびO.Koufopavlouou、「ソフトウェア定義ネットワーキング（SDN）：レイヤー2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[RFC7551] Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015, <https://www.rfc-editor.org/info/rfc7551>.
[RFC7551] Zhang、F.、Ed。、Jing、R.、R. Gandhi、Ed。、「関連する双方向ラベルスイッチ付きパス（LSP）」、RFC 7551、DOI 10.17487 / RFC7551、2015年5月<https：//www.rfc-editor.org/info/rfc7551>。
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services (Diffserv) and Real-Time Communication", RFC 7657, DOI 10.17487/RFC7657, November 2015, <https://www.rfc-editor.org/info/rfc7657>.
[RFC7657]黒、D.、ED。P. Jones、「差別化サービス（DiffServ）およびリアルタイム通信」、RFC 7657、DOI 10.17487 / RFC 7657、2015年11月、<https：//www.rfc-editor.org/info/rfc7657>。
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.
[RFC7950] Bjorklund、M.、ED。、「Yang 1.1データモデリング言語」、RFC 7950、DOI 10.17487 / RFC7950、2016年8月、<https://www.rfc-editor.org/info/rfc7950>。
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.
[RFC8040] Bierman、A.、Bjorklund、M.、K。Watsen、 "Restconf Protoction"、RFC 8040、DOI 10.17487 / RFC8040、2017年1月、<https：//www.rfc-editor.org/info/rfc8040>。
[RFC8227] Cheng, W., Wang, L., Li, H., van Helvoort, H., and J. Dong, "MPLS-TP Shared-Ring Protection (MSRP) Mechanism for Ring Topology", RFC 8227, DOI 10.17487/RFC8227, August 2017, <https://www.rfc-editor.org/info/rfc8227>.
[RFC8227] Cheng、W.、Wang、L.、Li、H.、Van Helvoort、H.、およびJ. Dong、RFCトポロジーのMPLS-TP共有リング保護（MSRP）メカニズム、RFC 8227、DOI10.17487 / RFC8227、2017年8月、<https：//www.rfc-editor.org/info/rfc8227>。
[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>。
[SRv6-Network-Prog] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "SRv6 Network Programming", Work in Progress, Internet-Draft, draft-ietf-spring-srv6- network-programming-26, 26 November 2020, <https://tools.ietf.org/html/draft-ietf-spring-srv6- network-programming-26>.
[SRV6-Network-PROG] Filsfils、C、ED。、Camarillo、P.、ED。、Leddy、J.、Voyer、D.、松島、S、およびZ.Li、「SRV6ネットワークプログラミング」、仕事進行中、インターネットドラフト、ドラフト - IETF-Spring-SRV6-ネットワークプログラミング26,26,26、<https://tools.ietf.org/html/draft-ietf-spring-srv6-ネットワークプログラミング - 26>。
Acknowledgements
謝辞
The authors wish to thank Pat Thaler, Norman Finn, Loa Andersson, David Black, Rodney Cummings, Ethan Grossman, Tal Mizrahi, David Mozes, Craig Gunther, George Swallow, Yuanlong Jiang, and Carlos J. Bernardos for their various contributions to this work.
著者らは、ターレ、ノーマンフィン、ロアアンダーソン、デビッドブラック、ロドニーカミングス、エタングロスマン、タイルミズラヒ、デビッドモズ、クレイグジョアン、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos。
Contributors
貢献者
The following people contributed substantially to the content of this document:
以下の人々はこの文書の内容に実質的に貢献しました。
Don Fedyk Jouni Korhonen
ドン・フェデ・ジュニ・コルホネン
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