[要約] RFC 8939は、決定論的ネットワーキング（DetNet）データプレーンのIPに関する技術仕様を定めています。この文書の目的は、IPネットワーク上で時間に敏感なデータの伝送を保証するための方法を提供することです。利用場面としては、工業オートメーション、車載ネットワーク、オーディオビジュアルストリーミングなど、高い信頼性と低遅延が求められるアプリケーションが挙げられます。
Internet Engineering Task Force (IETF) B. Varga, Ed.
Request for Comments: 8939 J. Farkas
Category: Standards Track Ericsson
ISSN: 2070-1721 L. Berger
D. Fedyk
LabN Consulting, L.L.C.
S. Bryant
Futurewei Technologies
November 2020
Deterministic Networking (DetNet) Data Plane: IP
決定論的ネットワーキング（DetNet）データプレーン：IP
Abstract
概要
This document specifies the Deterministic Networking (DetNet) data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. This document builds on the DetNet architecture (RFC 8655) and data plane framework (RFC 8938).
このドキュメントでは、IPホストのための決定論的ネットワーキング（Detnet）データプレーン操作をIPカプセル化されたデータにDetnetサービスを提供するルータとを指定します。IPフローをサポートするためにDetnet固有のカプセル化は定義されていません。代わりに、既存のIP層および上位プロトコルヘッダ情報は、フロー識別およびDetNetサービス配信をサポートするために使用される。このドキュメントはDetnet Architecture（RFC 8655）とデータプレーンフレームワーク（RFC 8938）に基づいています。
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/rfc8939.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8939で入手できます。
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
2.3. Requirements Language
3. Overview of the DetNet IP Data Plane
4. DetNet IP Data Plane Considerations
4.1. End-System-Specific Considerations
4.2. DetNet Domain-Specific Considerations
4.3. Forwarding Sub-Layer Considerations
4.3.1. Class of Service
4.3.2. Quality of Service
4.3.3. Path Selection
4.4. DetNet Flow Aggregation
4.5. Bidirectional Traffic
5. DetNet IP Data Plane Procedures
5.1. DetNet IP Flow Identification Procedures
5.1.1. IP Header Information
5.1.2. Other Protocol Header Information
5.2. Forwarding Procedures
5.3. DetNet IP Traffic Treatment Procedures
6. Management and Control Information Summary
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.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 these flows with extremely low packet loss rates and assured maximum 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]にあります。
This document specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP-encapsulated data. No DetNet-specific encapsulation is defined to support IP flows; instead, the existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. Common data plane procedures and control information for all DetNet data planes can be found in [RFC8938].
このドキュメントは、IPホストのDetnetデータプレーン操作をIPカプセル化されたデータにDetnetサービスを提供するルータのDetNetデータプレーン操作を指定します。IPフローをサポートするためにDetnet固有のカプセル化は定義されていません。代わりに、既存のIP層および上位プロトコルヘッダ情報は、フロー識別およびDetNetサービス配信をサポートするために使用される。すべてのDetNetデータプレーンの一般的なデータプレーン手順と制御情報は[RFC8938]にあります。
The DetNet architecture models the DetNet-related data plane functions as two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service protection (e.g., by the Packet Replication Function (PRF) and Packet Elimination Function (PEF)) and reordering. The forwarding sub-layer is used to provide congestion protection (low loss, assured latency, and limited out-of-order delivery). The service sub-layer generally requires additional header fields to provide its service; for example, see [DetNet-MPLS]. Since no DetNet-specific fields are added to support DetNet IP flows, only the forwarding sub-layer functions are supported using the DetNet IP defined by this document. Service protection can be provided on a per-sub-network basis using technologies such as MPLS [DetNet-MPLS] and Ethernet, as specified by the IEEE 802.1 TSN (Time-Sensitive Networking) task group (referred to in this document simply as "IEEE 802.1 TSN"). See [IEEE802.1TSNTG].
DetNetアーキテクチャは、DetNet関連データプレーンが2つのサブレイヤとして機能します。サービスサブレイヤと転送サブレイヤーです。サービスサブレイヤは、DetNetサービス保護（例えば、パケット複製機能（PRF）およびパケット除去機能（PEF））および並べ替えを提供するために使用される。転送サブレイヤは、輻輳保護（低損失、保証された待ち時間、および限られた順序配信）を提供するために使用されます。サービスサブレイヤは一般にそのサービスを提供するための追加のヘッダフィールドを必要とする。たとえば、[detnet-mpls]を参照してください。 Detnet IP FlowsをサポートするためのDetnet固有のフィールドが追加されていないため、このドキュメントで定義されているDetNet IPを使用して転送サブレイヤ関数のみがサポートされています。サービス保護は、IEEE 802.1 TSN（Time-Senenctive Networking）タスクグループ（単に「ASと呼ばれる」と呼ばれるMPLS [Detnet-MPLS]およびイーサネットなどのテクノロジを使用して、サブネットワークごとに提供できます。 IEEE 802.1 TSN」）。 [IEEE802.1TSNTG]を参照してください。
This document provides an overview of the DetNet IP data plane in Section 3 and considerations that apply to providing DetNet services via the DetNet IP data plane in Section 4. Section 5 provides the procedures for hosts and routers that support IP-based DetNet services. Section 6 summarizes the set of information that is needed to identify an individual DetNet flow.
このドキュメントでは、セクション3のDetnet IPデータプレーンの概要と、Detnet IPデータプレーンを介してDetnet Servicesの提供に適用される検討事項をセクション5に提供します。セクション5では、IPベースのDetNetサービスをサポートするホストとルーターの手順を示します。セクション6は、個々のDETNETフローを識別するために必要な情報のセットをまとめたものです。
This document uses the terminology and concepts 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:
この文書では、次の略語が使用されています。
CoS Class of Service
COSのサービスクラス
DetNet Deterministic Networking
Detnet決定論的ネットワーキング
DN DetNet
DN Detnet
Diffserv Differentiated Services
DiffServ微分サービス
DSCP Differentiated Services Code Point
DSCP差別化サービスコードポイント
L2 Layer 2
L2層2
L3 Layer 3
L3層3
LSP Label Switched Path
LSPラベルスイッチパス
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
PEF Packet Elimination Function
PEFパケット除去機能
PREOF Packet Replication, Elimination, and Ordering Functions
パケットのレプリケーション、除去、および注文機能
PRF Packet Replication Function
PRFパケットレプリケーション機能
QoS Quality of Service
QoSサービス品質
TSN Time-Sensitive Networking. TSN is a task group of the IEEE 802.1 Working Group.
TSNの時間依存ネットワーキング。TSNはIEEE 802.1ワーキンググループのタスクグループです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service using an IP data plane. From a data plane perspective, an end-to-end IP model is followed. As mentioned above, existing IP-layer and higher-layer protocol header information is used to support flow identification and DetNet service delivery. Common data plane procedures and control information for all DetNet data planes can be found in [RFC8938].
このドキュメントでは、Detnet Flowsを識別し、IPデータプレーンを使用してDetNetサービスを提供するために、IPがDetnetノード、すなわちホストおよびルータで使用される方法について説明します。データプレーンの観点からは、エンドツーエンドのIPモデルに従います。上述のように、既存のIP層および高層プロトコルヘッダ情報は、フロー識別およびDetNetサービス配信をサポートするために使用される。すべてのDetNetデータプレーンの一般的なデータプレーン手順と制御情報は[RFC8938]にあります。
The DetNet IP data plane primarily uses 6-tuple-based flow identification, where "6-tuple" refers to information carried in IP-layer and higher-layer protocol headers. The 6-tuple referred to in this document is the same as that defined in [RFC3290]. Specifically, the 6-tuple is destination address, source address, IP protocol, source port, destination port, and DSCP. General background on the use of IP headers and 5-tuples to identify flows and support Quality of Service (QoS) can be found in [RFC3670]. [RFC7657] also provides useful background on the delivery of Diffserv and tuple-based flow identification. Note that a 6-tuple is composed of a 5-tuple plus the addition of a DSCP component.
DetNet IPデータプレーンは、主に6タプルベースのフロー識別を使用します。ここで、「6タプル」は、IP層および上位プロトコルヘッダーで搭載されている情報を参照します。この文書で言及されている6タプルは[RFC3290]で定義されているものと同じです。具体的には、6タプルは宛先アドレス、送信元アドレス、IPプロトコル、送信元ポート、宛先ポート、およびDSCPです。フローとサポートサービス品質（QoS）を識別するためのIPヘッダーと5タプルの使用に関する一般的な背景[RFC3670]。[RFC7657] DiffServおよびタプルベースのフロー識別の送達に役立つ背景を提供します。6タプルは、5タプルプラスDSCPコンポーネントの追加で構成されています。
For some of the protocols, 5-tuples and 6-tuples cannot be used, because the port information is not available (e.g., ICMP, IPsec, and Encapsulating Security Payload (ESP)). This is also the case for flow aggregates. In such cases, using fewer fields is appropriate, such as a 3-tuple (2 IP addresses, IP protocol) or even a 2-tuple (all IP traffic between two IP addresses).
プロトコルのいくつかについては、ポート情報が利用できない（例えば、ICMP、IPSec、およびCenculation Security Payload（ESP））、5タプスと6タプルを使用できません。これはフロー集約にも当てはまります。そのような場合、3タプル（2 IPアドレス、IPプロトコル）、さらには2タプル（2つのIPアドレス間のすべてのIPトラフィック）など、少ないフィールドを使用することが適切です。
The DetNet IP data plane also allows for optional matching on the IPv6 Flow Label field, as defined in [RFC8200].
Detnet IPデータプレーンは、[RFC8200]で定義されているように、IPv6 Flow Labelフィールドでオプションの一致を可能にします。
Non-DetNet and DetNet IP packets have the same protocol header format on the wire. Generally, the fields used in flow identification are forwarded unmodified. However, standard modification of the DSCP field [RFC2474] is not precluded.
非DETNETおよびDETNETIN IPパケットは、ワイヤー上に同じプロトコルヘッダーフォーマットを持ちます。一般に、フロー識別で使用されるフィールドは変更されずに転送されます。ただし、DSCPフィールドの標準変更[RFC2474]は排除されません。
DetNet flow aggregation may be enabled via the use of wildcards, masks, lists, prefixes, and ranges. IP tunnels may also be used to support flow aggregation. In these cases, it is expected that DetNet-aware intermediate nodes will provide DetNet service on the aggregate through resource allocation and congestion control mechanisms.
Detnet Flow集約は、ワイルドカード、マスク、リスト、プレフィックス、および範囲の使用を介して有効になることがあります。IPトンネルはまた、フロー集約をサポートするために使用され得る。このような場合、Detnet対応の中間ノードはリソース割り当てと輻輳制御メカニズムを介して集計にDetnetサービスを提供することが予想されます。
The specific procedures that are required to be implemented by a DetNet node supporting this document can be found in Section 5. The DetNet Controller Plane, as defined in [RFC8655], is responsible for providing each node with the information needed to identify and handle each DetNet flow.
この文書をサポートするDetNetノードによって実装する必要がある特定の手順はセクション5にあります。[RFC8655]で定義されているDetNet Controller Planeは、各ノードの提供に必要な情報を識別して処理するために必要な情報を提供します。Detnet Flow。
DetNet IP Relay Relay DetNet IP End System Node Node End System
Detnet IPリレーリレーDetnet IPエンドシステムノードノードエンドシステム
+----------+ +----------+
| Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service |
+----------+ +----------+ +----------+ +----------+
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+
: Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub- ]----+ +-[ Sub- ]-+
[Network] [Network]
`-----' `-----'
|<--------------------- DetNet IP --------------------->|
Figure 1: A Simple DetNet-Enabled IP Network
図1：単純なDetnet対応IPネットワーク
Figure 1 illustrates a DetNet-enabled IP network. The DetNet-enabled end systems originate IP-encapsulated traffic that is identified within the DetNet domain as DetNet flows based on IP header information. Relay nodes understand the forwarding requirements of the DetNet flow and ensure that node, interface, and sub-network resources are allocated to ensure DetNet service requirements. The dotted line around the Service component of the Relay Nodes indicates that the transit routers are DetNet service aware but do not perform any DetNet service sub-layer function, e.g., PREOF.
図1は、Detnet対応IPネットワークを示しています。Detnet対応エンドシステムは、IPヘッダー情報に基づいてDetNetドメイン内で識別されたIPカプセル化されたトラフィックをDetNetに照会します。リレーノードDetNet Flowの転送要件を理解し、Detnetサービス要件を確保するためにノード、インタフェース、およびサブネットワークリソースが割り当てられていることを確認します。中継ノードのサービスコンポーネントの周囲の点線は、トランジットルータがDetnet Service Awareであるが、任意のDetnet Serviceサブレイヤ関数、例えばPREOFを実行しないことを示している。
| Note: The sub-network can represent a TSN, MPLS network, or | other network technology that can carry DetNet IP traffic.
| ..注：サブネットワークは、TSN、MPLSネットワーク、または|を表すことができます。Detnet IPトラフィックを運ぶことができるその他のネットワーク技術。
IP Edge Edge IP End System Node Node End System
IPエッジエッジIPエンドシステムノードノードエンドシステム
+----------+ +.........+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- E2E Service---:Svc Proxy:-->| Appl. |
+----------+ +.........+ +.........+ +----------+
| IP |<--:IP : :Svc:---- IP flow ----:Svc: :IP :-->| IP |
+----------+ +---+ +---+ +---+ +---+ +----------+
|Forwarding| |Fwd| |Fwd| |Fwd| |Fwd| |Forwarding|
+--------.-+ +-.-+ +-.-+ +-.-+ +-.-+ +---.------+
: Link : \ ,-----. / / ,-----. \
+.......+ +----[ Sub- ]----+ +--[ Sub- ]--+
[network] [network]
`-----' `-----'
|<--- IP --->| |<------ DetNet IP ------>| |<--- IP --->|
Figure 2: Non-DetNet-Aware IP End Systems with DetNet IP Domain
図2：DetNet IPドメインを備えたDetnet対応のIPエンドシステム
Figure 2 illustrates a variant of Figure 1 where the end systems are not DetNet aware. In this case, edge nodes sit at the boundary of the DetNet domain and provide DetNet service proxies for the end applications by initiating and terminating DetNet service for the application's IP flows. The existing header information or an approach such as described in Section 4.4 can be used to support DetNet flow identification.
図2は、エンドシステムがDetnet認識ではない図1の変形例を示しています。この場合、エッジノードはDetnetドメインの境界に座り、アプリケーションのIPフローのDetNetサービスを開始して終了することで、エンドアプリケーションのDetnetサービスプロキシを提供します。既存のヘッダ情報またはセクション4.4に記載されているようなアプローチは、DetNetフロー識別をサポートするために使用することができる。
Note that Figures 1 and 2 can be collapsed, so IP DetNet end systems can communicate over a DetNet IP network with IP end systems.
図1と図2は折りたたまれている可能性があるため、IP Detnet EndシステムはIPエンドシステムを使用してDetNet IPネットワークを介して通信できます。
As non-DetNet and DetNet IP packets have the same protocol header format on the wire, from a data plane perspective, the only difference is that there is flow-associated DetNet information on each DetNet node that defines the flow-related characteristics and required forwarding behavior. As shown above, edge nodes provide a Service Proxy function that "associates" one or more IP flows with the appropriate DetNet flow-specific information and ensures that the flow receives the proper traffic treatment within the domain.
DETENTENTおよびDETNET IPパケットがワイヤ上に同じプロトコルヘッダフォーマットを有するので、データプレーンの観点からは、フロー関連の特性と必要な転送を定義する各DETNETノードにフロー関連のDetNet情報があることである。動作。上記のように、エッジノードは、1つまたは複数のIPフローを適切なDetNetフロー固有の情報と関連付けるサービスプロキシ関数を提供し、そのフローがドメイン内の適切なトラフィック処理を受信することを保証する。
| Note: The operation of IEEE 802.1 TSN end systems over DetNet-
| enabled IP networks is not described in this document. TSN
| over MPLS is described in [DetNet-TSN-over-MPLS].
This section provides considerations related to providing DetNet service to flows that are identified based on their header information.
このセクションでは、ヘッダー情報に基づいて識別されるFlowsにDetnetサービスを提供することに関する考慮事項について説明します。
Data flows requiring DetNet service are generated and terminated on end systems. This document deals only with IP end systems. The protocols used by an IP end system are specific to an application, and end systems peer with other end systems. DetNet's use of 6-tuple IP flow identification means that DetNet must be aware of not only the format of the IP header, but also of the next protocol value carried within an IP packet (see Section 5.1.1.3).
DetNetサービスを必要とするデータフローは、エンドシステムで生成され、終了されます。この文書はIPエンドシステムのみを扱います。IPエンドシステムによって使用されるプロトコルは、アプリケーションに固有のもので、他のエンドシステムとのエンドシステムピアです。Detnetの6タプルIPフロー識別の使用は、DetNetがIPヘッダーのフォーマットだけでなく、IPパケット内で搭載されている次のプロトコル値にも認識する必要があることを意味します（5.1.1.3項を参照）。
For DetNet-unaware IP end systems, service-level proxy functions are needed inside the DetNet domain.
Detnet-Unaware IPエンドシステムの場合、Detnetドメイン内にサービスレベルのプロキシ機能が必要です。
When IP end systems are DetNet aware, no application-level or service-level proxy functions are needed inside the DetNet domain. End systems need to ensure that DetNet service requirements are met when processing packets associated to a DetNet flow. When sending packets, this means that packets are appropriately shaped on transmission and receive appropriate traffic treatment on the connected sub-network; see Sections 4.3.2 and 4.2 for more details. When receiving packets, this means that there are appropriate local node resources, e.g., buffers, to receive and process the packets of that DetNet flow.
IPエンドシステムがDetnet Awareである場合、Detnetドメイン内にアプリケーションレベルまたはサービスレベルのプロキシ機能は必要ありません。エンドシステムは、DetNet Netフローに関連付けられているパケットを処理するときにDetnetサービスの要件が満たされていることを確認する必要があります。パケットを送信するとき、これはパケットが送信上に適切に成形され、接続されたサブネットワーク上で適切なトラフィック処理を受信することを意味する。詳細については4.3.2節および4.2を参照してください。パケットを受信すると、これは、そのDetNet Netフローのパケットを受信し処理するために、適切なローカルノードリソース、例えばバッファーがあることを意味する。
An important additional consideration for DetNet-aware end systems is avoiding IP fragmentation. Full 6-tuple flow identification is not possible on IP fragments, as fragments don't include the transport headers or their port information. As such, it is important that applications and/or end systems use an IP packet size that will avoid fragmentation within the network when sending DetNet flows. The maximum size can be learned via Path MTU Discovery [RFC1191] [RFC8201] or via the Controller Plane. Note that Path MTU Discovery relies on ICMP, which may not follow the same path as an individual DetNet flow.
Detnet対応エンドシステムの重要な追加検討は、IPフラグメンテーションを回避しています。フル6タプルフロー識別はIPフラグメントでは不可能ですが、トランスポートヘッダーやそのポート情報を含めないでください。そのため、アプリケーションやエンドシステムがDetNet Netフローを送信するときにネットワーク内の断片化を回避するIPパケットサイズを使用することが重要です。最大サイズは、PATU Discovery [RFC1191] [RFC8201]またはコントローラプレーンを介して学習できます。PATH MTUディスカバリはICMPに依存しており、これは個々のDetnetフローと同じ経路に従わない可能性があります。
In order to maximize reuse of existing mechanisms, DetNet-aware applications and end systems SHOULD NOT mix DetNet and non-DetNet traffic within a single 5-tuple.
既存のメカニズムの再利用を最大化するために、Detnet対応アプリケーションおよびエンドシステムは、Detnetトラフィックと非Detnetトラフィックを単一の5タプル内に混在させてはいけません。
As a general rule, DetNet IP domains need to be able to forward any DetNet flow identified by the IP 6-tuple. Doing otherwise would limit the number of 6-tuple flow ID combinations that could be used by the end systems. From a practical standpoint, this means that all nodes along the end-to-end path of DetNet flows need to agree on what fields are used for flow identification. Possible consequences of not having such an agreement include some flows interfering with other flows, and the traffic treatment expected for a service not being provided.
一般的な規則として、Detnet IPドメインはIP 6-Tupleによって識別されたDetnet Flowを転送できる必要があります。その他の方法では、エンドシステムで使用できる6タプルフローIDの組み合わせの数を制限します。実際的な観点からは、これはDetNet NETフローのエンドツーエンドパスに沿ったすべてのノードがフロー識別にどのフィールドを使用するかについて同意する必要があることを意味します。そのような契約を持たないという考えられる結果は、他の流れを妨害するいくつかの流れ、ならびにサービスが提供されていないサービスに対して期待される交通扱いを含む。
From a connection-type perspective, two scenarios are identified:
接続型の観点からは、2つのシナリオが識別されます。
1. DN attached: the end system is directly connected to an edge node or the end system is behind a sub-network. (See ES1 and ES2 in Figure 3.)
1. DN接続：エンドシステムはエッジノードに直接接続されているか、エンドシステムはサブネットワークの後ろにあります。（図3のES1とES2を参照）
2. DN integrated: the end system is part of the DetNet domain. (See ES3 in Figure 3.)
2. DN統合：エンドシステムはDetnetドメインの一部です。（図3のES3を参照）
L3 (IP) end systems may use any of these connection types. A DetNet domain allows communication between any end systems using the same encapsulation format, independent of their connection type and DetNet capability. DN-attached end systems have no knowledge about the DetNet domain and its encapsulation format. See Figure 3 for L3 end system connection examples.
L3（IP）エンドシステムは、これらの接続タイプを使用することがあります。DetNet Domainは、接続タイプとDetnet Capabilityとは無関係に、同じカプセル化フォーマットを使用しているすべてのエンドシステム間の通信を可能にします。DN接続エンドシステムには、DetNetドメインとそのカプセル化フォーマットに関する知識がありません。L3エンドシステム接続例については、図3を参照してください。
____+----+
+----+ _____ / | ES3|
| ES1|____ / \__/ +----+___
+----+ \ / \
+ |
____ \ _/
+----+ __/ \ +__ DetNet IP domain /
| ES2|____/ L2/L3 |___/ \ __ __/
+----+ \_______/ \_______/ \___/
Figure 3: Connection Types of L3 End Systems
図3：L3エンドシステムの接続タイプ
Within a DetNet domain, the DetNet-enabled IP routers are interconnected by links and sub-networks to support end-to-end delivery of DetNet flows. From a DetNet architecture perspective, these routers are DetNet relays, as they must be DetNet service aware. Such routers identify DetNet flows based on the IP 6-tuple and ensure that the traffic treatment required by the DetNet service is provided on both the node and any attached sub-network.
DetNetドメイン内では、Detnet対応のIPルータは、DetNet Netフローのエンドツーエンド配信をサポートするために、リンクとサブネットワークによって相互接続されています。Detnetアーキテクチャの観点から見ると、これらのルータはDetnet Service Awareでなければならないため、Detnet Netraterです。そのようなルータはIP 6タプルに基づいてDetNetフローを識別し、DetNetサービスによって必要とされるトラフィック処理がノードと添付のサブネットワークの両方に提供されることを確認します。
This solution provides DetNet functions end to end, but it does so on a per-link and per-sub-network basis. Congestion protection, latency control, and resource allocation (queuing, policing, shaping) are supported using the underlying link/sub-network-specific mechanisms. However, service protection (PRF and PEF) is not provided end to end at the DetNet layer. Instead, service protection can be provided on a per-link (underlying L2 link) and per-sub-network basis.
このソリューションはDetnet関数の終了を終了するが、リンクごとおよびサブネットワークごとにそうする。輻輳保護、待ち時間制御、およびリソース割り当て（キューイング、ポリシング、シェーピング）は、基礎となるリンク/サブネットワーク固有のメカニズムを使用してサポートされています。ただし、サービス保護（PRFとPEF）はDetNetレイヤーで終了する端部には設けられていません。代わりに、サービス保護はリンクごとの（基盤となるL2リンク）およびサブネットワークごとに提供できます。
The DetNet service flow is mapped to the link/sub-network-specific resources using an underlying system-specific means. This implies that each DetNet-aware node on the path looks into the forwarded DetNet service flow packet and utilizes, for example, a 6-tuple to find out the required mapping within a node.
DetNetサービスフローは、基礎となるシステム固有の手段を使用してリンク/サブネットワーク固有のリソースにマッピングされます。これは、パス上の各DetNet対応ノードが転送されたDetnetサービスフローパケットを調べ、例えば6タプルを利用してノード内で必要なマッピングを見つけることを意味します。
As noted earlier, service protection must be implemented within each link/sub-network independently, using the domain-specific mechanisms. This is due to the lack of unified end-to-end sequencing information that could be used by the intermediate nodes. Therefore, service protection (if enabled) cannot be provided end to end, only within sub-networks. This is shown for a scenario with three sub-networks in Figure 4, where each sub-network can provide service protection between its borders. "R" and "E" denote replication and elimination points within the sub-network.
前述のように、ドメイン固有のメカニズムを使用して、サービス保護は各リンク/サブネットワーク内で独立して実装する必要があります。これは、中間ノードによって使用され得る統一されたエンドツーエンドのシーケンス情報がないためです。したがって、サービス保護（有効になっている場合）は、サブネットワーク内でのみ終了して終了することはできません。これは、図4の3つのサブネットワークを持つシナリオについて示されており、各サブネットワークはその境界線間のサービス保護を提供できます。「R」および「E」は、サブネットワーク内の複製点および除去点を示す。
<-------------------- DetNet IP ------------------------>
______
____ / \__
____ / \__/ \___ ______
+----+ __/ +====+ +==+ \ +----+
|src |__/ Sub-N1 ) | | \ Sub-N3\____| dst|
+----+ \_______/ \ Sub-network 2 | \______/ +----+
\_ _/
\ __ __/
\_______/ \___/
+---+ +---------E--------+ +-----+
+----+ | | | | | | | +----+
|src |----R E--------R +---+ E------R E------+ dst|
+----+ | | | | | | | +----+
+---+ +-----R------------+ +-----+
Figure 4: Replication and Elimination in Sub-networks for DetNet IP Networks
図4：DetNet IPネットワークのサブネットワークにおけるレプリケーションと除去
If end-to-end service protection is desired, it can be implemented -- for example, by the DetNet end systems using Layer 4 (L4) transport protocols or application protocols. However, these protocols are out of the scope of this document.
エンドツーエンドのサービス保護が望まれる場合は、例えば、レイヤ4（L4）トランスポートプロトコルまたはアプリケーションプロトコルを使用するDetNet End Systemsによって実装できます。ただし、これらのプロトコルはこの文書の範囲外です。
Note that not mixing DetNet and non-DetNet traffic within a single 5-tuple, as described above, enables simpler 5-tuple filters to be used (or reused) at the edges of a DetNet network to prevent non-congestion-responsive DetNet traffic from escaping the DetNet domain.
上記のように、1つの5タプル内にDetnetトラフィックと非DETNETトラフィックを混在させないことに注意して、非輻輳対応DetNetトラフィックを防ぐために、DetNetネットワークのエッジでより簡単な5タプルフィルタを使用（または再利用）できることに注意してください。Detnetドメインの脱出から。
Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6 is provided using the standard DSCP field [RFC2474] and related mechanisms.
IPv4およびIPv6で運ばれるDetnetフローのサービスクラス（COS）は、標準のDSCPフィールド[RFC2474]と関連メカニズムを使用して提供されます。
One additional consideration for DetNet nodes that support CoS services is that they must ensure that the CoS service classes do not impact the congestion protection and latency control mechanisms used to provide DetNet QoS. This requirement is similar to the requirement for MPLS Label Switching Routers (LSRs) that CoS LSPs cannot impact the resources allocated to TE LSPs [RFC3473].
COSサービスをサポートするDetnetノードの1つの追加の考慮事項は、COSサービスクラスがDetnet QoSを提供するために使用される輻輳保護および待ち時間制御メカニズムに影響を与えないようにする必要があります。この要件は、COS LSPがTE LSPに割り当てられているリソースに影響を与えることができないMPLSラベルスイッチングルータ（LSRS）の要件と似ています[RFC3473]。
Quality of Service (QoS) for DetNet service flows carried in IP must be provided locally by the DetNet-aware hosts and routers supporting DetNet flows. Such support leverages the underlying network layer such as 802.1 TSN. The node-internal traffic control mechanisms used to deliver QoS for IP-encapsulated DetNet flows are outside the scope of this document. From an encapsulation perspective, the combination of the 6-tuple (the typical 5-tuple enhanced with the DSCP) and optionally the flow label uniquely identifies a DetNet IP flow.
IPで搭載されているDetnetサービスフローのサービス品質（QoS）は、Detnet対応のホストとDetNetフローをサポートするルータによってローカルに提供されなければなりません。そのようなサポートは、802.1 TSNのような基礎となるネットワーク層を利用する。IPカプセル化されたDetNetフローにQoSを配信するために使用されるノード内部トラフィック制御メカニズムは、この文書の範囲外です。カプセル化の観点からは、6タプル（DSCPで強化された標準5-タプル）とオプションでフローラベルの組み合わせは、DetNet IPフローを一意に識別します。
Packets that are identified as part of a DetNet IP flow but that have not been the subject of a completed reservation 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 MUST ensure that no DetNet-allocated resource, e.g., queue or shaper, is used by such flows. There are multiple methods that may be used by an implementation to defend service delivery to reserved DetNet flows, including but not limited to:
Detnet IPフローの一部として識別されていたパケットは、予約されたフローに割り当てられたリソースを使用して、QoSを正しく予約されたDetnet Flowsに提供されるQoSを破壊する可能性があります。したがって、DetNetネットワークのネットワークノードは、Detnet割り当てられたリソース、例えばキューまたはシェーパーがそのようなフローによって使用されていないことを確認する必要があります。予約されたDetnetフローへのサービス配信を防御するための実装によって使用され得る複数の方法があります。
* Treating packets associated with an incomplete reservation as non-DetNet traffic.
* 不完全な予約に関連付けられているパケットの扱い。
* Discarding packets associated with an incomplete reservation.
* 不完全な予約に関連したパケットを破棄する。
* Re-marking packets associated with an incomplete reservation. Re-marking can be accomplished by changing the value of the DSCP field to a value that results in the packet no longer matching any other reserved DetNet IP flow.
* 不完全な予約に関連するパケットを再マークする。再マーキングは、DSCPフィールドの値を他の予約済みのDetnet IPフローと一致しなくなる値にDSCPフィールドの値を変更することで実現できます。
While path selection algorithms and mechanisms are out of the scope of the DetNet data plane definition, it is important to highlight the implications of DetNet IP flow identification on path selection and next hops. As mentioned above, the DetNet IP data plane identifies flows using 6-tuple header information as well as the optional (flow label) header field. DetNet generally allows for both flow-specific traffic treatment and flow-specific next hops.
パス選択アルゴリズムとメカニズムはDetnetデータプレーン定義の範囲外であるが、パス選択および次のホップに関するDetnet IPフロー識別の意味を強調することが重要です。上述のように、DetNet IPデータプレーンは、6タプルヘッダ情報およびオプションの（フローラベル）ヘッダフィールドを使用してフローを識別する。Detnetは一般に、フロー固有のトラフィック処理とフロー固有の次のホップの両方を可能にします。
In non-DetNet IP forwarding, it is generally assumed that the same series of next hops, i.e., the same path, will be used for a particular 5-tuple or, in some cases (e.g., [RFC5120]), for a particular 6-tuple. Using different next hops for different 5-tuples does not take any special consideration for DetNet-aware applications.
非DETNETE IP転送では、一般に、同じパス、すなわち同じ経路が特定の5タプルまたは場合によっては特定の5タプルまたは場合によっては特定の場合（例えば、[RFC5120]）が使用されると仮定される。6タプル。異なる5タプルに対して異なる次のホップを使用すると、Detnet対応アプリケーションには特別な考慮がありません。
Care should be taken when using different next hops for the same 5-tuple. As discussed in [RFC7657], unexpected behavior can occur when a single 5-tuple application flow experiences reordering due to being split across multiple next hops. Understanding of the application and transport protocol impact of using different next hops for the same 5-tuple is required. Again, this only indirectly impacts path selection for DetNet flows and this document.
同じ5タプルに対して異なるネクストホップを使用するときは、注意を払う必要があります。[RFC7657]で説明したように、1つの5タプルアプリケーションフローが複数のネクストホップにまたがって分割されたために並べ替えを経験したときに予期しない動作が発生する可能性があります。アプリケーションとトランスポートプロトコルの理解と同じ5タプルに対して異なる次のホップを使用することによる影響が必要です。繰り返しますが、これはDetnet Flowsとこのドキュメントのパス選択に間接的に影響を与えます。
As described in [RFC8938], the ability to aggregate individual flows and their associated resource control into a larger aggregate is an important technique for improving scaling by reducing the state per hop. DetNet IP data plane aggregation can take place within a single node, when that node maintains state about both the aggregated and individual flows. It can also take place between nodes, when one node maintains state about only flow aggregates while the other node maintains state on all or a portion of the component flows. In either case, the management or control function that provisions the aggregate flows must ensure that adequate resources are allocated and configured to provide the combined service requirements of the individual flows. As DetNet is concerned about latency and jitter, more than just bandwidth needs to be considered.
[RFC8938]に記載されているように、個々の流れを集約する能力とそれらに関連するリソースコントロールは、ホップあたりの状態を減らすことによってスケーリングを改善するための重要な技術です。Detnet IPデータプレーン集約は、そのノードが集約フローと個々のフローの両方について状態を維持するときに、単一のノード内で行われる可能性があります。一方のノードがフロー集計のみについての状態を維持するときには、ノード間で起こり、他のノードはコンポーネントの全部または一部の状態を維持しながら、フロー集計を維持することもできます。どちらの場合も、集約フローを規定する管理機能または制御機能は、適切なリソースが個々のフローの複合サービス要件を提供するように割り当てられて構成されていることを確認する必要があります。Detnetが待ち時間とジッタに関するものであるため、帯域幅だけでは考慮する必要があります。
From a single node perspective, the aggregation of IP flows impacts DetNet IP data plane flow identification and resource allocation. As discussed above, IP flow identification uses the IP 6-tuple for flow identification. DetNet IP flows can be aggregated using any of the 6-tuple fields and optionally also by the flow label. The use of prefixes, wildcards, lists, and value ranges allows a DetNet node to identify aggregate DetNet flows. From a resource allocation perspective, DetNet nodes ought to provide service to an aggregate rather than on a component flow basis.
単一ノードの観点から、IPフローの集約はDetnet IPデータプレーンフロー識別とリソース割り当てに影響します。上述のように、IPフロー識別はフロー識別のためにIP 6タプルを使用する。Detnet IPフローは、6つのタプルフィールドのいずれかを使用して、そしてオプションでフローラベルによっても集約できます。プレフィックス、ワイルドカード、リスト、および値の範囲の使用により、DetNetノードが集約Detnet Flowを識別することができます。リソース割り当ての観点からは、DetNetノードは、コンポーネントフローベースではなく集計にサービスを提供する必要があります。
It is the responsibility of the DetNet Controller Plane to properly provision the use of these aggregation mechanisms. This includes ensuring that aggregated flows have compatible (e.g., the same or very similar) QoS and/or CoS characteristics; see Section 4.3.2. It also includes ensuring that per-component-flow service requirements are satisfied by the aggregate; see Section 5.3.
これらの集約メカニズムの使用を適切に提供するのはDetnet Controller Planeの責任です。これは、集約されたフローが互換性のある（例えば、同じまたは非常に類似の）QoSおよび/またはCOS特性を有することを保証することを含む。セクション4.3.2を参照してください。それはまた、コンポーネントごとのサービス要件が集約によって満たされることを保証することを含む。セクション5.3を参照してください。
The DetNet Controller Plane MUST ensure that non-congestion-responsive DetNet traffic is not forwarded outside a DetNet domain.
DetNet Controller Planeは、非輻輳対応のDetNetトラフィックがDetnetドメインの外部に転送されないことを確認する必要があります。
While the DetNet IP data plane must support bidirectional DetNet flows, there are no special bidirectional features within the data plane. The special case of co-routed bidirectional DetNet flows is solely represented at the management 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フローをサポートしている必要があるが、データプレーン内に特別な双方向特徴はありません。共ルーされた双方向DetNetフローの特別な場合は、DetNetデータプレーン内の特定のサポートまたは知識なしに、管理プレーンレベルと制御プレーンレベルでのみ表現されます。運命の共有と関連または共ルーされた双方向フローは、制御レベルで管理できます。
Control and management mechanisms need to support bidirectional flows, but the specification of such mechanisms is out of the scope of this document. An example control plane solution for MPLS can be found in [RFC7551].
制御および管理メカニズムは双方向フローをサポートする必要がありますが、そのようなメカニズムの仕様はこの文書の範囲外です。MPLSの制御面の例は、[RFC7551]にあります。
This section provides DetNet IP data plane procedures. These procedures have been divided into the following areas: flow identification, forwarding, and traffic treatment. Flow identification includes those procedures related to matching IP-layer and higher-layer protocol header information to DetNet flow (state) information and service requirements. Flow identification is also sometimes called "traffic classification"; for example, see [RFC5777]. Forwarding includes those procedures related to next-hop selection and delivery. Traffic treatment includes those procedures related to providing an identified flow with the required DetNet service.
このセクションではDetnet IPデータプレーン手順を説明します。これらの手順は、次の分野に分けられています。フロー識別、転送、および交通治療。フロー識別には、一致するIP層および上位プロトコルヘッダ情報と、DetNet Netフロー（状態）情報とサービス要件に関連する手順が含まれています。フロー識別は「トラフィック分類」とも呼ばれることもあります。たとえば、[RFC5777]を参照してください。転送には、ネクストホップの選択と配信に関連する手順が含まれています。交通治療には、必要なDetnetサービスと識別されたフローを提供することに関するこれらの手順が含まれています。
DetNet IP data plane establishment and operational procedures also have requirements on the control and management systems for DetNet flows, and these are referred to in this section. Specifically, this section identifies a number of information elements that require support via the management and control interfaces supported by a DetNet node. The specific mechanism used for such support is out of the scope of this document. A summary of the requirements for management- and control-related information is included. Conformance language is not used in the summary, since it applies to future mechanisms such as those that may be provided in YANG models [DetNet-YANG].
Detnet IPデータプレーンの確立と運用手順には、DetNetフローの制御システムと管理システムに関する要件があり、これらはこのセクションで参照されます。具体的には、このセクションでは、DetNetノードでサポートされている管理インタフェースと制御インターフェイスを介してサポートを必要とする多くの情報要素を識別します。そのようなサポートに使用される特定のメカニズムはこの文書の範囲外です。管理関連情報および管理関連情報の要件の概要が含まれています。適合言語は、Yang Models [Detnet-Yang]で提供され得るものなどの将来のメカニズムに適用されるため、要約には使用されません。
IP-layer and higher-layer protocol header information is used to identify DetNet flows. All DetNet implementations that support this document MUST identify individual DetNet flows based on the set of information identified in this section. Note that additional requirements for flow identification, e.g., to support other higher-layer protocols, may be defined in the future.
IP層および上位プロトコルヘッダー情報は、DetNetフローを識別するために使用されます。この文書をサポートするすべてのDetnet実装は、このセクションで識別されている情報のセットに基づいて個々のDetNetフローを識別しなければなりません。フロー識別のための追加の要件、例えば他の上位層プロトコルをサポートするためには、将来的に定義され得ることに留意されたい。
The configuration and control information used to identify an individual DetNet flow MUST be ordered by an implementation. Implementations MUST support a fixed order when identifying flows and MUST identify a DetNet flow by the first set of matching flow information.
個々のDetNetフローを識別するために使用される構成および制御情報は、実装によって順序付けされなければなりません。実装はフローを識別するときに固定順序をサポートし、一致する一致フロー情報の最初のセットによってDetNetフローを識別する必要があります。
Implementations of this document MUST support DetNet flow identification when the implementation is acting as a DetNet end system, a relay node, or an edge node.
この文書の実装は、実装がDetNet End System、リレーノード、またはエッジノードとして機能している場合、Detnet Flow Identをサポートしている必要があります。
Implementations of this document MUST support DetNet flow identification based on IP header information. The IPv4 header is defined in [RFC0791], and the IPv6 is defined in [RFC8200].
この文書の実装は、IPヘッダー情報に基づいてDetNet Flow IDをサポートしている必要があります。IPv4ヘッダーは[RFC0791]で定義され、IPv6は[RFC8200]で定義されています。
Implementations of this document MUST support DetNet flow identification based on the Source Address field of an IP packet. Implementations SHOULD support longest prefix matching for this field (see [RFC1812] and [RFC7608]). Note that a prefix length of zero (0) effectively means that the field is ignored.
この文書の実装は、IPパケットの送信元アドレスフィールドに基づいてDetnet Flow IDをサポートしている必要があります。実装はこのフィールドの最長のプレフィックスマッチングをサポートする必要があります（[RFC1812]と[RFC7608]を参照）。ゼロ（0）のプレフィックス長は効果的にフィールドが無視されることを意味します。
Implementations of this document MUST support DetNet flow identification based on the Destination Address field of an IP packet. Implementations SHOULD support longest prefix matching for this field (see [RFC1812] and [RFC7608]). Note that a prefix length of zero (0) effectively means that the field is ignored.
この文書の実装は、IPパケットの宛先アドレスフィールドに基づいてDetnet Flow IDをサポートしている必要があります。実装はこのフィールドの最長のプレフィックスマッチングをサポートする必要があります（[RFC1812]と[RFC7608]を参照）。ゼロ（0）のプレフィックス長は効果的にフィールドが無視されることを意味します。
| Note: Any IP address value is allowed, including an IP | multicast destination address.
| ..注：IPを含むIPアドレスの値はすべて許可されています。マルチキャスト先アドレス。
Implementations of this document MUST support DetNet flow identification based on the IPv4 Protocol field when processing IPv4 packets and the IPv6 Next Header field when processing IPv6 packets. This includes the next protocol values defined in Section 5.1.2 and any other value, including zero. Implementations SHOULD allow for these fields to be ignored for a specific DetNet flow.
このドキュメントの実装は、IPv4パケットを処理するときにIPv4 ProtocolフィールドとIPv6パケットを処理するときにIPv6次のヘッダーフィールドに基づいてDetnet Flow Identideをサポートしている必要があります。これには、セクション5.1.2で定義されている次のプロトコル値と、ゼロを含む他の値が含まれます。実装は、特定のDetnetフローに対してこれらのフィールドを無視することを可能にする必要があります。
These fields are used to support differentiated services [RFC2474] [RFC2475]. Implementations of this document MUST support DetNet flow identification based on the DSCP field in the IPv4 Type of Service field when processing IPv4 packets and the DSCP field in the IPv6 Traffic Class field when processing IPv6 packets. Implementations MUST support list-based matching of DSCP values, where the list is composed of possible field values that are to be considered when identifying a specific DetNet flow. Implementations SHOULD allow for this field to be ignored for a specific DetNet flow.
これらのフィールドは、差別化サービスをサポートするために使用されます[RFC2474] [RFC2475]。このドキュメントの実装は、IPv4パケットのIPv4パケットとIPv6パケットを処理するときにIPv6トラフィッククラスフィールドのDSCPフィールドのDSCPフィールドのDSCPフィールドに基づいてDETNETフローの識別をサポートしている必要があります。実装はDSCP値のリストベースの一致をサポートしなければなりません。ここで、リストは特定のDetnetフローを識別するときに考慮される可能性のあるフィールド値で構成されています。実装は、特定のDetnetフローに対してこのフィールドを無視することを可能にする必要があります。
Implementations of this document SHOULD support identification of DetNet flows based on the IPv6 Flow Label field. Implementations that support matching based on this field MUST allow for it to be ignored for a specific DetNet flow. When this field is used to identify a specific DetNet flow, implementations MAY exclude the IPv6 Next Header field and next header information as part of DetNet flow identification.
この文書の実装は、IPv6 Flow Labelフィールドに基づくDetNetフローの識別をサポートする必要があります。このフィールドに基づくマッチングをサポートする実装は、特定のDetnetフローに対して無視されることを許可する必要があります。このフィールドが特定のDetnet Flowを識別するために使用されるとき、実装はIPv6次のヘッダーフィールドとDetnetフロー識別の一部として次のヘッダー情報を除外することがあります。
Implementations of this document MUST support DetNet flow identification based on header information identified in this section. Support for TCP, UDP, ICMP, and IPsec flows is defined. Future documents are expected to define support for other protocols.
この文書の実装は、このセクションで識別されているヘッダー情報に基づいてDetnet Flow IDをサポートしている必要があります。TCP、UDP、ICMP、およびIPSecフローのサポートが定義されています。将来の文書は他のプロトコルのサポートを定義することが期待されています。
DetNet flow identification for TCP [RFC0793] and UDP [RFC0768] is achieved based on the Source and Destination Port fields carried in each protocol's header. These fields share a common format and common DetNet flow identification procedures.
TCP [RFC0793]およびUDP [RFC0768]のDetnetフロー識別は、各プロトコルのヘッダーで伝送された送信元のポートフィールドと宛先のポートフィールドに基づいて実現されます。これらのフィールドは共通のフォーマットと共通のDetnetフロー識別手順を共有しています。
The rules defined in this section only apply when the IPv4 Protocol or IPv6 Next Header field contains the IANA-defined value for UDP or TCP.
このセクションで定義されている規則は、IPv4プロトコルまたはIPv6次のヘッダーフィールドにUDPまたはTCPのIANA定義値を含む場合にのみ適用されます。
Implementations of this document MUST support DetNet flow identification based on the Source Port field of a TCP or UDP packet. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementations SHOULD support range-based port matching. Implementation MUST also allow for the field to be ignored for a specific DetNet flow.
この文書の実装は、TCPまたはUDPパケットの送信元ポートフィールドに基づいてDetnet Flow IDをサポートしている必要があります。実装は、フィールドで運ばれる特定の値、すなわち正確な値に基づいてフロー識別をサポートしなければならない。実装は範囲ベースのポートマッチングをサポートする必要があります。実装は、特定のDetnetフローに対してフィールドを無視するのも許可する必要があります。
Implementations of this document MUST support DetNet flow identification based on the Destination Port field of a TCP or UDP packet. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementations SHOULD support range-based port matching. Implementation MUST also allow for the field to be ignored for a specific DetNet flow.
この文書の実装は、TCPまたはUDPパケットの宛先ポートフィールドに基づいてDetnet Flow IDをサポートしている必要があります。実装は、フィールドで運ばれる特定の値、すなわち正確な値に基づいてフロー識別をサポートしなければならない。実装は範囲ベースのポートマッチングをサポートする必要があります。実装は、特定のDetnetフローに対してフィールドを無視するのも許可する必要があります。
DetNet flow identification for ICMP [RFC0792] is achieved based on the protocol number in the IP header. Note that ICMP type is not included in the flow definition.
ICMP [RFC0792]のDetNetフロー識別情報は、IPヘッダーのプロトコル番号に基づいて実現されます。なお、ICMPタイプはフロー定義に含まれていません。
IPsec Authentication Header (AH) [RFC4302] and Encapsulating Security Payload (ESP) [RFC4303] share a common format for the Security Parameters Index (SPI) field. Implementations MUST support flow identification based on a particular value carried in the field, i.e., an exact value. Implementations SHOULD also allow for the field to be ignored for a specific DetNet flow.
IPsec認証ヘッダー（AH）[RFC4302]およびセキュリティペイロードのカプセル化（ESP）[RFC4303]セキュリティパラメータインデックス（SPI）フィールドに共通のフォーマットを共有します。実装は、フィールドで運ばれる特定の値、すなわち正確な値に基づいてフロー識別をサポートしなければならない。実装はまた、特定のDetnetフローに対してフィールドを無視することもできます。
The rules defined in this section only apply when the IPv4 Protocol or IPv6 Next Header field contains the IANA-defined value for AH or ESP.
このセクションで定義されている規則は、IPv4プロトコルまたはIPv6次のヘッダーフィールドにAHまたはESPのIANA定義の値が含まれている場合にのみ適用されます。
General requirements for IP nodes are defined in [RFC1122], [RFC1812], and [RFC8504] and are not modified by this document. The typical next-hop selection process is impacted by DetNet. Specifically, implementations of this document SHALL use management and control information to select the one or more outgoing interfaces and next hops to be used for a packet associated with a DetNet flow. Specific management and control information will be defined in future documents, e.g., [DetNet-YANG].
IPノードの一般的な要件は[RFC1122]、[RFC1812]、[RFC8504]で定義されており、この文書によって変更されません。典型的なネクストホップ選択プロセスはDetnetによって影響を受けます。具体的には、この文書の実装は、管理情報と制御情報を使用して、DetNetフローに関連するパケットに使用される1つまたは複数の発信インタフェースと次のホップを選択するものとします。具体的な管理情報と制御情報は、将来の文書、例えば[DetNet-Yang]で定義されます。
The use of multiple paths or links, e.g., ECMP, to support a single DetNet flow is NOT RECOMMENDED. ECMP MAY be used for non-DetNet flows within a DetNet domain.
単一のDetnetフローをサポートするための複数のパスまたはリンク、例えばECMPの使用は推奨されません。ECMPは、DetNetドメイン内の非DETNETフローに使用できます。
The above implies that management and control functions will be defined to support this requirement, e.g., see [DetNet-YANG].
上記のことは、管理機能と制御機能がこの要件をサポートするために定義され、例えば[DetNet-Yang]を参照してください。
Implementations of this document must ensure that a DetNet flow receives the traffic treatment that is provisioned for it via configuration or the Controller Plane, e.g., via [DetNet-YANG]. General information on DetNet service can be found in [DetNet-Flow-Info]. 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). Support can also be provided via an underlying network technology such as MPLS [DetNet-IP-over-MPLS] or IEEE 802.1 TSN [DetNet-IP-over-TSN]. Other mechanisms than the ones used in the TSN case are outside the scope of this document.
この文書の実装は、DetNet Netフローが構成またはコントローラプレーン、例えば[DetNet-Yang]を介してプロビジョニングされるトラフィック処理を受信する必要があります。Detnet Serviceの一般情報は[Detnet-Flow-Info]にあります。異なるフローに異なる扱いを提供するために使用される典型的なメカニズムは、システムリソースの割り当て（キューやバッファなど）と関連パラメータのプロビジョニング（シェーピングやポリシングなど）を含みます。MPLS [Detnet-IP-over-MPLS]またはIEEE 802.1 TSN [Detnet-IP-Over-TSN]などの基礎となるネットワークテクノロジを介してサポートを提供できます。TSNケースで使用されているものよりもその他のメカニズムはこの文書の範囲外です。
The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows:
以下は、個人および集約されたDetnetフローを識別するために必要な情報のセットをまとめたものです。
* IPv4 and IPv6 Source Address field.
* IPv4とIPv6の送信元アドレスフィールド。
* IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the Source Address field is ignored.
* IPv4およびIPv6の送信元アドレスプレフィックス長。ゼロ（0）値は、送信元アドレスフィールドが無視されたことを意味します。
* IPv4 and IPv6 Destination Address field.
* IPv4とIPv6宛先アドレスフィールド。
* IPv4 and IPv6 destination address prefix length, where a zero (0) value effectively means that the Destination Address field is ignored.
* IPv4とIPv6宛先アドレスプレフィックス長。ゼロ（0）値は、宛先アドレスフィールドが無視されたことを効果的に効果的に意味します。
* IPv4 Protocol field. A limited set of values is allowed, and the ability to ignore this field is desirable.
* IPv4プロトコルフィールド限られた値のセットが許容され、このフィールドを無視する能力が望ましいです。
* IPv6 Next Header field. A limited set of values is allowed, and the ability to ignore this field is desirable.
* IPv6次のヘッダーフィールド。限られた値のセットが許容され、このフィールドを無視する能力が望ましいです。
* For the IPv4 Type of Service and IPv6 Traffic Class fields:
* IPv4の種類のサービスとIPv6トラフィッククラスフィールドの場合
- Whether or not the DSCP field is used in flow identification. Use of the DSCP field for flow identification is optional.
- DSCPフィールドがフロー識別で使用されているかどうか。フロー識別のためのDSCPフィールドの使用はオプションです。
- If the DSCP field is used to identify a flow, then the flow identification information (for that flow) includes a list of DSCPs used by that flow.
- DSCPフィールドがフローを識別するために使用される場合、フロー識別情報（そのフローに対する）は、そのフローによって使用されるDSCPのリストを含む。
* IPv6 Flow Label field. This field can be optionally used for matching. When used, this field can be used instead of matching against the Next Header field.
* IPv6フローラベルフィールドこのフィールドは任意選択でマッチングに使用できます。使用されると、次のヘッダーフィールドと一致する代わりにこのフィールドを使用できます。
* TCP and UDP Source Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
* TCPおよびUDPの送信元ポート。正確でワイルドカードマッチングの両方のサポートが必要です。ポート範囲が任意に使用できます。
* TCP and UDP Destination Port. Support for both exact and wildcard matching is required. Port ranges can optionally be used.
* TCPおよびUDP宛先ポート。正確でワイルドカードマッチングの両方のサポートが必要です。ポート範囲が任意に使用できます。
* IPsec Header SPI field. Exact matching is required. Support for wildcard matching is recommended.
* IPsecヘッダーSPIフィールド。正確なマッチングが必要です。ワイルドカードマッチングのサポートをお勧めします。
* For end systems, an optional maximum IP packet size that should be used for that outgoing DetNet IP flow.
* エンドシステムの場合、その発信Detnet IPフローに使用するオプションの最大IPパケットサイズ。
This information MUST be provisioned per DetNet flow via configuration, e.g., via the Controller Plane or the management plane.
この情報は、例えばコントローラ平面または管理プレーンを介して、Detnetフローごとにプロビジョニングされなければならない。
An implementation MUST support ordering of the set of information used to identify an individual DetNet flow. This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value.
実装は、個々のDetNetフローを識別するために使用される情報のセットの順序をサポートしなければなりません。これは、例えば、同じUDP宛先ポート値を有する他のすべてのフローの集合体に対して異なるサービスを提供しながら、特定のUDPフローに対するDetNetサービスを特定のUDPフローに提供するために使用され得る。
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 IP data plane.
Detnetの詳細なセキュリティ上の考慮事項は[Detnet-Security]でカタログ化され、より一般的なセキュリティ上の考慮事項は[RFC8655]に記載されています。このセクションでは、DetNet IPデータプレーンに固有のセキュリティ上の考慮事項を排他的に考慮しています。
Security aspects that are unique to DetNet are those whose aim is to provide the 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ドメインの境界内でネットワークノードを制御する機能を有する可能性がある。
The primary consideration for the DetNet data plane is to maintain integrity of data and delivery of the associated DetNet service traversing the DetNet network. Since no DetNet-specific fields are available in the DetNet IP data plane, the integrity and confidentiality of 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.
DetNetデータプレーンの主な考慮事項は、DetNetネットワークを横切る関連するDetnetサービスのデータと配信の整合性を維持することです。Detnet IPデータプレーンではDetnet固有のフィールドは利用できないため、基礎となるテクノロジによって提供されている場合は、アプリケーションフローの完全性と機密性を保護できます。例えば、IPSec [RFC4301]がIPフローの場合、および/またはIP上のIEEE802.1AE-2018]を使用して、IPSEC [IEEE802E-2018]を使用して、IPSEC（RFC4301）によって提供される暗号化を使用することができます。
From a data plane perspective, this document does not add or modify any 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 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 or within an edge IEEE 802.1 TSN 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ドメインの入力に適用された既存のメカニズムを使用することで、またはエッジIEEE 802.1 TSN内の存在ドメイン。DetNetドメインの外部のエンティティによってDetnet Packetが遅れるのを防ぐため、Detnet Technologyの定義は、MAN-In-The Middle Attacksの軽減を可能にします。たとえば、Detnet内のデバイスの認証と認証を行うことができます。ドメイン。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.
[RFC0768] Postel、J.、 "User Datagram Protocol"、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<https://www.rfc-editor.org/info/rfc768>。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC0791] Postel、J.、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https://www.rfc-editor.org/info/rfc793>。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC1812] Baker、F.、ED。、「IPバージョン4ルータの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<https：//www.rfc-editor.org/info/rfc1812>。
[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>。
[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>。
[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>。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4302] Kent、S.、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<https：//www.rfc-editor.org/info/rfc4302>。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、DOI 10.17487 / RFC4303、2005年12月、<https：//www.rfc-editor.org/info/rfc4303>。
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix Length Recommendation for Forwarding", BCP 198, RFC 7608, DOI 10.17487/RFC7608, July 2015, <https://www.rfc-editor.org/info/rfc7608>.
[RFC7608] Boucadair、M.、Petrescu、A.、およびF. Baker、 "ForwardingのためのIPv6プレフィックス長勧告"、BCP 198、RFC 7608、DOI 10.17487 / RFC7608、2015年7月、<https：//www.rfc-editor.org/info/rfc7608>。
[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>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[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/rfc/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/rfc/rfc8938>。
[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-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-IP-over-TSN] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)", Work in Progress, Internet-Draft, draft-ietf-detnet-ip-over-tsn-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-04>.
[Detnet-IP-over-TSN] Varga、B.、ED、Farkas、J.、Malis、A.、Bryant、「Detnetデータプレーン：IEEE 802.1時間敏感ネットワーク（TSN）」、作業進行中、インターネットドラフト、ドラフト-IETF-Detnet-IP-over-TSN-04,2020、<https：//tools.ietf.org/html/draft-ietf-detnet-ip over-tsn-04>。
[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-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>
[DetNet-TSN-over-MPLS] Varga, B., Ed., Farkas, J., Malis, A., Bryant, S., and D. Fedyk, "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", Work in Progress, Internet-Draft, draft-ietf-detnet-tsn-vpn-over-mpls-04, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-04>.
[Detnet-TSN-over-MPLS] Varga、B、ED。、Farkas、J.、Malis、A.、Bryant、S.、D.Fedyk、「Detnet Data Plane：IEEE 802.1 MPLS上の時間依存ネットワーキング」、進行中の作業、インターネットドラフト、ドラフト-IETF-Detnet-TSN-VPN-over-MPLS-04,2012、<https://tools.ietf.org/html/draft-ietf-detnet-tsn-VPN-over-MPLS-04>。
[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.1TSNTG] IEEE, "Time-Sensitive Networking (TSN) Task Group", <https://1.ieee802.org/tsn/>.
[IEEE802.1TSNTG] IEEE、「時間依存ネットワーキング（TSN）タスクグループ」、<https：//1.ieee802.org/tsn/>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J.およびS.Theering、 "Path Mtu Discovery"、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https：//www.rfc-editor.org/info/rfc1191>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW.Weiss、「差別化サービスのためのアーキテクチャ」、RFC 2475、DOI 10.17487 / RFC2475、12月1998年、<https：//www.rfc-editor.org/info/rfc2475>。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, DOI 10.17487/RFC3290, May 2002, <https://www.rfc-editor.org/info/rfc3290>.
[RFC3290] Bernet、Y.、Blake、S.、Grossman、D.、およびA. Smith、「DiffServルータの非公式管理モデル」、RFC 3290、DOI 10.17487 / RFC3290、2002年5月、<https：// www.rfc-editor.org / info / rfc3290>。
[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>。
[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>。
[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>。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.
[RFC5120] Przygienda、T.、Shen、N.、およびN.Sheth、M-ISI：中間システムにおける中間システムにおける中間システムにおけるマルチトポロジー（MT）ルーティング（IS - ISS） "、RFC 5120、DOI 10.17487 / RFC5120、2008年2月、<https：//www.rfc-editor.org/info/rfc5120>。
[RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Ed., and A. Lior, "Traffic Classification and Quality of Service (QoS) Attributes for Diameter", RFC 5777, DOI 10.17487/RFC5777, February 2010, <https://www.rfc-editor.org/info/rfc5777>.
[RFC5777] Korhonen、J.、Tschofenig、H.、Arumaithurai、M.、Jones、M.、Ed。、およびA. Lior、「直径のトラフィック分類とサービス品質」、RFC 5777、DOI10.17487 / RFC5777、2010年2月、<https：//www.rfc-editor.org/info/rfc5777>。
[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>。
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.
[RFC8201] McCann、J.、Theer、S.、Mogul、J.、およびR. Hinden、Ed。、「IPバージョン6のためのパスMTUディスカバリー」、STD 87、RFC 8201、DOI 10.17487 / RFC8201、2017年7月、<https://www.rfc-editor.org/info/rfc8201>。
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8504] Chown、T.、Loughney、J.、およびT.Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https：//www.rfc-editor.org/ info / rfc8504>。
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. David Black served as technical advisor to the DetNet working group during the development of this document and provided many valuable comments. IESG comments were provided by Murray Kucherawy, Roman Danyliw, Alvaro Retana, Benjamin Kaduk, Rob Wilton, and Érik Vyncke.
著者らは、ターレ、ノーマンフィン、ロアアンダーソン、デビッドブラック、ロドニーカミングス、エタングロスマン、タイルミズラヒ、デビッドモズ、クレイグジョアン、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos、そしてCarlos J. Bernardos。David Blackはこの文書の開発中にDetnetワーキンググループの技術アドバイザーとして機能し、多くの貴重なコメントを提供しました。IESGコメントは、Murray Kucherawy、Roman Danyliw、Alvaro Retana、Benjamin Kaduk、Rob Wilton、およびエリクVynckeによって提供されました。
Contributors
貢献者
The editor of this document wishes to thank and acknowledge the following people who contributed substantially to the content of this document and should be considered coauthors:
この文書の編集者は、この文書の内容に実質的に貢献し、CoAuthorsと見なされるべき次の人々を感謝し、認めたいと考えています。
Jouni Korhonen
Jouni Korhonen
Email: jouni.nospam@gmail.com
Andrew G. Malis Malis Consulting
Andrew G. Malis Malis Consulting.
Email: agmalis@gmail.com
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
Don Fedyk LabN Consulting, L.L.C.
Don Fedyk Labn Consulting、L.L.c。
Email: dfedyk@labn.net
Stewart Bryant Futurewei Technologies
スチュワートブライアントフューチャーワイテクノロジー
Email: sb@stewartbryant.com