[要約] RFC 8655は、決定論的ネットワーキングアーキテクチャに関する標準化ドキュメントであり、ネットワーク通信の予測可能性と信頼性を向上させることを目的としています。
Internet Engineering Task Force (IETF) N. Finn
Request for Comments: 8655 Huawei
Category: Standards Track P. Thubert
ISSN: 2070-1721 Cisco
B. Varga
J. Farkas
Ericsson
October 2019
Deterministic Networking Architecture
確定的ネットワーキングアーキテクチャ
Abstract
概要
This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low data loss rates and bounded latency within a network domain. Techniques used include 1) reserving data-plane resources for individual (or aggregated) DetNet flows in some or all of the intermediate nodes along the path of the flow, 2) providing explicit routes for DetNet flows that do not immediately change with the network topology, and 3) distributing data from DetNet flow packets over time and/or space to ensure delivery of each packet's data in spite of the loss of a path. DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and Time-Sensitive Networking (TSN) as defined by IEEE 802.1.
このドキュメントは、決定論的ネットワーキング（DetNet）の全体的なアーキテクチャを提供します。これは、ネットワークドメイン内で非常に低いデータ損失率と制限されたレイテンシでリアルタイムアプリケーションの指定されたユニキャストまたはマルチキャストデータフローを伝送する機能を提供します。使用される手法には、1）フローのパスに沿った一部またはすべての中間ノードの個々の（または集約された）DetNetフロー用にデータプレーンリソースを予約する、2）ネットワークトポロジですぐに変化しないDetNetフローに明示的なルートを提供する、および3）DetNetフローパケットからのデータを時間および/または空間に分散して、パスが失われた場合でも各パケットのデータを確実に配信します。 DetNetはIPレイヤーで動作し、IEEE 802.1で定義されているMPLSやTime-Sensitive Networking（TSN）などの下位レイヤーテクノロジーを介してサービスを提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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/rfc8655.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8655で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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 Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Terms Used in This Document
2.2. Dictionary of Terms Used by TSN and DetNet
3. Providing the DetNet Quality of Service
3.1. Primary Goals Defining the DetNet QoS
3.2. Mechanisms to Achieve DetNet QoS
3.2.1. Resource Allocation
3.2.2. Service Protection
3.2.3. Explicit Routes
3.3. Secondary Goals for DetNet
3.3.1. Coexistence with Normal Traffic
3.3.2. Fault Mitigation
4. DetNet Architecture
4.1. DetNet Stack Model
4.1.1. Representative Protocol Stack Model
4.1.2. DetNet Data-Plane Overview
4.1.3. Network Reference Model
4.2. DetNet Systems
4.2.1. End System
4.2.2. DetNet Edge, Relay, and Transit Nodes
4.3. DetNet Flows
4.3.1. DetNet Flow Types
4.3.2. Source Transmission Behavior
4.3.3. Incomplete Networks
4.4. Traffic Engineering for DetNet
4.4.1. The Application Plane
4.4.2. The Controller Plane
4.4.3. The Network Plane
4.5. Queuing, Shaping, Scheduling, and Preemption
4.6. Service Instance
4.7. Flow Identification at Technology Borders
4.7.1. Exporting Flow Identification
4.7.2. Flow Attribute Mapping between Layers
4.7.3. Flow-ID Mapping Examples
4.8. Advertising Resources, Capabilities, and Adjacencies
4.9. Scaling to Larger Networks
4.10. Compatibility with Layer 2
5. Security Considerations
6. Privacy Considerations
7. IANA Considerations
8. Informative References
Acknowledgements
Authors' Addresses
This document provides the overall architecture for Deterministic Networking (DetNet), which provides a capability for the delivery of data flows with extremely low packet loss rates and bounded end-to-end delivery latency. DetNet is for networks that are under a single administrative control or within a closed group of administrative control; these include campus-wide networks and private WANs. DetNet is not for large groups of domains such as the Internet.
このドキュメントでは、決定論的ネットワーキング（DetNet）の全体的なアーキテクチャを提供します。これにより、パケット損失率が非常に低く、エンドツーエンドの配信遅延が制限されたデータフローを配信できます。 DetNetは、単一の管理制御下または閉鎖された管理制御グループ内にあるネットワーク用です。これには、キャンパス全体のネットワークとプライベートWANが含まれます。 DetNetは、インターネットなどの大規模なドメイングループ用ではありません。
DetNet operates at the IP layer and delivers service over lower-layer technologies such as MPLS and IEEE 802.1 Time-Sensitive Networking (TSN). DetNet provides a reliable and available service by dedicating network resources such as link bandwidth and buffer space to DetNet flows and/or classes of DetNet flows, and by replicating packets along multiple paths. Unused reserved resources are available to non-DetNet packets as long as all guarantees are fulfilled.
DetNetはIPレイヤーで動作し、MPLSやIEEE 802.1 Time-Sensitive Networking（TSN）などの下位レイヤーテクノロジーを介してサービスを提供します。 DetNetは、リンク帯域幅やバッファスペースなどのネットワークリソースをDetNetフローやDetNetフローのクラスに専用化し、複数のパスに沿ってパケットを複製することにより、信頼性の高い利用可能なサービスを提供します。未使用の予約済みリソースは、すべての保証が満たされている限り、DetNet以外のパケットで使用できます。
The "Deterministic Networking Problem Statement" [RFC8557] introduces DetNet, and "Deterministic Networking Use Cases" [RFC8578] summarizes the need for it. See [DETNET-FRAMEWORK] for specific techniques that can be used to identify DetNet flows and assign them to specific paths through a network.
「Deterministic Networking Problem Statement」[RFC8557]はDetNetを紹介し、「Deterministic Networkingユースケース」[RFC8578]はその必要性を要約しています。 DetNetフローを識別し、ネットワークを介して特定のパスに割り当てるために使用できる特定の手法については、[DETNET-FRAMEWORK]を参照してください。
A goal of DetNet is a converged network in all respects, including the convergence of sensitive non-IP networks onto a common network infrastructure. The presence of DetNet flows does not preclude non-DetNet flows, and the benefits offered DetNet flows should not, except in extreme cases, prevent existing Quality-of-Service (QoS) mechanisms from operating in a normal fashion, subject to the bandwidth required for the DetNet flows. A single source-destination pair can trade both DetNet and non-DetNet flows. End systems and applications need not instantiate special interfaces for DetNet flows. Networks are not restricted to certain topologies; connectivity is not restricted. Any application that generates a data flow that can be usefully characterized as having a maximum bandwidth should be able to take advantage of DetNet, as long as the necessary resources can be reserved. Reservations can be made by the application itself, via network management, centrally by an application's controller, or by other means, for instance, by placing on-demand reservation via a distributed Control Plane, e.g., leveraging the Resource Reservation Protocol (RSVP) [RFC2205]. QoS requirements of DetNet flows can be met if all network nodes in a DetNet domain implement DetNet capabilities. DetNet nodes can be interconnected with different sub-network technologies (Section 4.1.2) where the nodes of the subnet are not DetNet aware (Section 4.1.3).
DetNetの目標は、機密性の高い非IPネットワークの共通ネットワークインフラストラクチャへの収束を含む、あらゆる点で統合されたネットワークです。 DetNetフローの存在は、DetNet以外のフローを排除するものではなく、DetNetフローが提供する利点は、極端な場合を除いて、必要な帯域幅に従って既存のサービス品質（QoS）メカニズムが通常の方法で動作することを妨げるべきではありません。 DetNetフローの場合。 1つのソースと宛先のペアは、DetNetフローと非DetNetフローの両方を取引できます。エンドシステムとアプリケーションは、DetNetフロー用の特別なインターフェイスをインスタンス化する必要はありません。ネットワークは特定のトポロジーに限定されません。接続は制限されていません。最大帯域幅を持つと便利に特徴付けることができるデータフローを生成するアプリケーションは、必要なリソースを予約できる限り、DetNetを利用できるはずです。予約は、アプリケーション自体によって、ネットワーク管理を介して、アプリケーションのコントローラによって集中的に、または他の手段、たとえば、リソース予約プロトコル（RSVP）を活用するなど、分散型コントロールプレーンを介してオンデマンド予約を行うことによって行うことができます。 RFC2205]。 DetNetドメインのすべてのネットワークノードがDetNet機能を実装している場合、DetNetフローのQoS要件を満たすことができます。 DetNetノードは、サブネットのノードがDetNetに対応していない場合（セクション4.1.3）、さまざまなサブネットワークテクノロジー（セクション4.1.2）と相互接続できます。
Many applications that are intended to be served by DetNet require the ability to synchronize the clocks in end systems to a sub-microsecond accuracy. Some of the queue-control techniques defined in Section 4.5 also require time synchronization among network nodes. The means used to achieve time synchronization are not addressed in this document. DetNet can accommodate various time-synchronization techniques and profiles that are defined elsewhere to address the needs of different market segments.
DetNetによるサービスを目的とした多くのアプリケーションでは、エンドシステムのクロックをマイクロ秒未満の精度で同期する機能が必要です。セクション4.5で定義されているキュー制御手法の一部では、ネットワークノード間の時間同期も必要です。時間の同期を達成するために使用される手段は、このドキュメントでは扱いません。 DetNetは、さまざまな市場セグメントのニーズに対応するために他の場所で定義されているさまざまな時間同期手法とプロファイルに対応できます。
The following terms are used in the context of DetNet in this document:
このドキュメントでは、DetNetのコンテキストで次の用語が使用されています。
allocation The dedication of resources to support a DetNet flow. Depending on an implementation, the resource may be reused by non-DetNet flows when it is not used by the DetNet flow.
割り当てDetNetフローをサポートするためのリソースの割り当て。実装によっては、DetNetフローで使用されていないリソースが、DetNet以外のフローで再利用される場合があります。
App-flow The payload (data) carried over a DetNet service.
App-flow DetNetサービスで伝送されるペイロード（データ）。
DetNet compound flow and DetNet member flow A DetNet compound flow is a DetNet flow that has been separated into multiple duplicate DetNet member flows for service protection at the DetNet service sub-layer. Member flows are merged back into a single DetNet compound flow such that there are no duplicate packets. "Compound" and "member" are strictly relative to each other, not absolutes; a DetNet compound flow comprising multiple DetNet member flows can, in turn, be a member of a higher-order compound.
DetNet複合フローとDetNetメンバーフローDetNet複合フローは、DetNetサービスサブレイヤーでサービスを保護するために、複数の重複するDetNetメンバーフローに分離されたDetNetフローです。メンバーフローは、重複するパケットがないように、単一のDetNet複合フローにマージされます。 「コンパウンド」と「メンバー」は、絶対的なものではなく、互いに厳密に相対的なものです。複数のDetNetメンバーフローを含むDetNet複合フローは、さらに高次の複合のメンバーになることができます。
DetNet destination An end system capable of terminating a DetNet flow.
DetNet宛先DetNetフローを終了できるエンドシステム。
DetNet domain The portion of a network that is DetNet aware. It includes end systems and DetNet nodes.
DetNetドメインDetNet対応のネットワークの部分。これには、エンドシステムとDetNetノードが含まれます。
DetNet edge node An instance of a DetNet relay node that acts as a source and/or destination at the DetNet service sub-layer. For example, it can include a DetNet service sub-layer proxy function for DetNet service protection (e.g., the addition or removal of packet sequencing information) for one or more end systems, it can start or terminate resource allocation at the DetNet forwarding sub-layer, or it can aggregate DetNet services into new DetNet flows. It is analogous to a Label Edge Router (LER) or a Provider Edge (PE) router.
DetNetエッジノードDetNetサービスサブレイヤーでソースまたは宛先、あるいはその両方として機能するDetNetリレーノードのインスタンス。たとえば、1つまたは複数のエンドシステムのDetNetサービス保護（パケットシーケンス情報の追加または削除など）のためのDetNetサービスサブレイヤープロキシ機能を含めることができ、DetNet転送サブシステムでリソース割り当てを開始または終了できます。または、DetNetサービスを新しいDetNetフローに集約できます。これは、ラベルエッジルーター（LER）またはプロバイダーエッジ（PE）ルーターに似ています。
DetNet flow A sequence of packets that conforms uniquely to a flow identifier and to which the DetNet service is to be provided. It includes any DetNet headers added to support the DetNet service and forwarding sub-layers.
DetNetフローフロー識別子に一意に準拠し、DetNetサービスが提供される一連のパケット。これには、DetNetサービスと転送サブレイヤーをサポートするために追加されたDetNetヘッダーが含まれます。
DetNet forwarding sub-layer DetNet functionality is divided into two sub-layers. One of them is the DetNet forwarding sub-layer, which optionally provides resource allocation for DetNet flows over paths provided by the underlying network.
DetNet転送サブレイヤーDetNet機能は2つのサブレイヤーに分かれています。それらの1つは、DetNet転送サブレイヤーであり、オプションで、基盤となるネットワークによって提供されるパスを介したDetNetフローのリソース割り当てを提供します。
DetNet intermediate node A DetNet relay node or DetNet transit node.
DetNet中間ノードDetNetリレーノードまたはDetNetトランジットノード。
DetNet node A DetNet edge node, a DetNet relay node, or a DetNet transit node.
DetNetノードDetNetエッジノード、DetNetリレーノード、またはDetNetトランジットノード。
DetNet relay node A DetNet node that includes a service sub-layer function that interconnects different DetNet forwarding sub-layer paths to provide service protection. A DetNet relay node participates in the DetNet service sub-layer. It typically incorporates DetNet forwarding sub-layer functions as well, in which case it is collocated with a transit node.
DetNetリレーノードさまざまなDetNet転送サブレイヤーパスを相互接続してサービス保護を提供するサービスサブレイヤー機能を含むDetNetノード。 DetNetリレーノードは、DetNetサービスサブレイヤーに参加します。通常、DetNet転送サブレイヤー機能も組み込まれています。その場合、トランジットノードと同じ場所に配置されます。
DetNet service sub-layer DetNet functionality is divided into two sub-layers. One of them is the DetNet service sub-layer, at which a DetNet service (e.g., service protection) is provided.
DetNetサービスサブレイヤーDetNet機能は2つのサブレイヤーに分かれています。それらの1つは、DetNetサービスサブレイヤーであり、DetNetサービス（サービス保護など）が提供されます。
DetNet service proxy A proxy that maps between App-flows and DetNet flows.
DetNetサービスプロキシApp-flowとDetNetフロー間をマッピングするプロキシ。
DetNet source An end system capable of originating a DetNet flow.
DetNetソースDetNetフローを開始できるエンドシステム。
DetNet system A DetNet-aware end system, transit node, or relay node. "DetNet" may be omitted in some text.
DetNetシステムDetNet対応のエンドシステム、トランジットノード、またはリレーノード。 「DetNet」は、一部省略されている場合があります。
DetNet transit node A DetNet node, operating at the DetNet forwarding sub-layer, that utilizes link-layer and/or network-layer switching across multiple links and/or sub-networks to provide paths for DetNet service sub-layer functions. It typically provides resource allocation over those paths. An MPLS Label Switch Router (LSR) is an example of a DetNet transit node.
DetNetトランジットノードDetNet転送サブレイヤーで動作するDetNetノード。複数のリンクやサブネットワーク間でリンクレイヤーやネットワークレイヤーの切り替えを利用して、DetNetサービスサブレイヤー機能にパスを提供します。通常、これらのパスを介してリソースが割り当てられます。 MPLSラベルスイッチルータ（LSR）は、DetNetトランジットノードの例です。
DetNet-UNI A User-to-Network Interface (UNI) with DetNet-specific functionalities. It is a packet-based reference point and may provide multiple functions like encapsulation, status, synchronization, etc.
DetNet-UNI DetNet固有の機能を備えたUser-to-Network Interface（UNI）。これはパケットベースの基準点であり、カプセル化、ステータス、同期などの複数の機能を提供する場合があります。
end system Commonly called a "host" in the RFC series and an "end station" in IEEE 802 standards. End systems of interest to this document are either sources or destinations of DetNet flows, and they may or may not be aware of DetNet forwarding sub-layers or DetNet service sub-layers.
エンドシステム一般に、RFCシリーズでは「ホスト」と呼ばれ、IEEE 802標準では「エンドステーション」と呼ばれます。このドキュメントの対象となるエンドシステムは、DetNetフローの送信元または宛先のいずれかであり、DetNet転送サブレイヤーまたはDetNetサービスサブレイヤーを認識している場合と認識していない場合があります。
link A connection between two DetNet nodes. It may be composed of a physical link or a sub-network technology that can provide appropriate traffic delivery for DetNet flows.
リンク2つのDetNetノード間の接続。 DetNetフローに適切なトラフィック配信を提供できる物理リンクまたはサブネットワークテクノロジーで構成されている場合があります。
Packet Elimination Function (PEF) A function that eliminates duplicate copies of packets to prevent excess packets flooding the network or duplicate packets being sent out of the DetNet domain. A PEF can be implemented by a DetNet edge node, a DetNet relay node, or an end system.
パケット削除機能（PEF）パケットの重複コピーを削除して、過剰なパケットによるネットワークのフラッディングや重複パケットがDetNetドメインから送信されるのを防ぐ機能。 PEFは、DetNetエッジノード、DetNetリレーノード、またはエンドシステムによって実装できます。
Packet Replication Function (PRF) A function that replicates DetNet flow packets and forwards them to one or more next hops in the DetNet domain. The number of packet copies sent to the next hops is a parameter specific to the DetNet flow at the point of replication. A PRF can be implemented by a DetNet edge node, a DetNet relay node, or an end system.
パケット複製機能（PRF）DetNetフローパケットを複製し、DetNetドメイン内の1つ以上のネクストホップに転送する機能。ネクストホップに送信されるパケットコピーの数は、レプリケーションポイントでのDetNetフローに固有のパラメーターです。 PRFは、DetNetエッジノード、DetNetリレーノード、またはエンドシステムによって実装できます。
PREOF A collective name for Packet Replication, Elimination, and Ordering Functions.
PREOFパケット複製、除去、および順序付け機能の総称。
Packet Ordering Function (POF) A function that reorders packets within a DetNet flow that are received out of order. This function can be implemented by a DetNet edge node, a DetNet relay node, or an end system.
パケット順序付け機能（POF）順不同で受信されたDetNetフロー内のパケットを並べ替える機能。この機能は、DetNetエッジノード、DetNetリレーノード、またはエンドシステムによって実装できます。
reservation The set of resources allocated between a source and one or more destinations through DetNet nodes and subnets associated with a DetNet flow in order to provide the provisioned DetNet service.
予約プロビジョニングされたDetNetサービスを提供するために、DetNetノードとDetNetフローに関連付けられたサブネットを介してソースと1つ以上の宛先の間に割り当てられたリソースのセット。
This section serves as a dictionary for translating the terms used by the Time-Sensitive Networking (TSN) Task Group [IEEE802.1TSNTG] of the IEEE 802.1 WG to those of the Deterministic Networking (detnet) WG of the IETF.
このセクションは、IEEE 802.1 WGのTime-Sensitive Networking（TSN）タスクグループ[IEEE802.1TSNTG]で使用される用語を、IETFのDeterministic Networking（detnet）WGの用語に翻訳するための辞書として機能します。
Listener The term used by IEEE 802.1 for a destination of a DetNet flow.
リスナーIEEE 802.1がDetNetフローの宛先に使用する用語。
Relay system The term used by IEEE 802.1 for a DetNet intermediate node.
リレーシステムDetNet中間ノードのためにIEEE 802.1で使用される用語。
Stream The term used by IEEE 802.1 for a DetNet flow.
ストリームIEEE 802.1がDetNetフローに使用する用語。
Talker The term used by IEEE 802.1 for the source of a DetNet flow.
トーカーDetNetフローのソースとしてIEEE 802.1で使用される用語。
The DetNet QoS can be expressed in terms of:
DetNet QoSは、次の点で表すことができます。
* Minimum and maximum end-to-end latency from source to destination, timely delivery, and bounded jitter (packet delay variation) derived from these constraints.
* これらの制約から導出される、送信元から宛先への最小および最大のエンドツーエンドレイテンシ、タイムリーな配信、および制限付きジッター（パケット遅延変動）
* Packet loss ratio under various assumptions as to the operational states of the nodes and links.
* ノードとリンクの動作状態に関するさまざまな仮定の下でのパケット損失率。
* An upper bound on out-of-order packet delivery. It is worth noting that some DetNet applications are unable to tolerate any out-of-order delivery.
* 順不同のパケット配信の上限。一部のDetNetアプリケーションは、順不同の配信を許容できないことに注意してください。
It is a distinction of DetNet that it is concerned solely with worst-case values for the end-to-end latency, jitter, and misordering. Average, mean, or typical values are of little interest, because they do not affect the ability of a real-time system to perform its tasks. In general, a trivial priority-based queuing scheme will give better average latency to a data flow than DetNet; however, it may not be a suitable option for DetNet because of its worst-case latency.
エンドツーエンドのレイテンシ、ジッター、および順序の乱れのワーストケース値のみに関係しているのは、DetNetの違いです。平均値、平均値、または標準値は、リアルタイムシステムがそのタスクを実行する能力に影響を与えないため、ほとんど意味がありません。一般に、些細な優先度ベースのキューイングスキームは、DetNetよりもデータフローの平均レイテンシを向上させます。ただし、最悪の場合のレイテンシのため、DetNetには適さない可能性があります。
Three techniques are used by DetNet to provide these qualities of service:
これらのサービス品質を提供するために、DetNetでは3つの手法が使用されています。
* Resource allocation (Section 3.2.1)
* リソースの割り当て（セクション3.2.1）
* Service protection (Section 3.2.2)
* サービス保護（セクション3.2.2）
* Explicit routes (Section 3.2.3)
* 明示的なルート（セクション3.2.3）
Resource allocation operates by assigning resources, e.g., buffer space or link bandwidth, to a DetNet flow (or flow aggregate) along its path. Resource allocation greatly reduces, or even eliminates entirely, packet loss due to output packet contention within the network, but it can only be supplied to a DetNet flow that is limited at the source to a maximum packet size and transmission rate. As DetNet flows are assumed to be rate limited and DetNet is designed to provide sufficient allocated resources (including provisioned capacity), the use of transport-layer congestion control [RFC2914] for App-flows is not required; however, if resources are allocated appropriately, use of congestion control should not impact transmission negatively.
リソース割り当ては、パスに沿ってDetNetフロー（またはフローアグリゲート）にリソース（バッファースペースやリンク帯域幅など）を割り当てることで機能します。リソースの割り当てにより、ネットワーク内の出力パケットの競合によるパケット損失が大幅に削減または完全に排除されますが、送信元で最大パケットサイズと伝送速度に制限されているDetNetフローにのみ供給することができます。 DetNetフローはレート制限されていると想定され、DetNetは十分な割り当てリソース（プロビジョニングされた容量を含む）を提供するように設計されているため、App-flowにトランスポート層輻輳制御[RFC2914]を使用する必要はありません。ただし、リソースが適切に割り当てられていれば、輻輳制御を使用しても伝送に悪影響はありません。
Resource allocation addresses two of the DetNet QoS requirements: latency and packet loss. Given that DetNet nodes have a finite amount of buffer space, resource allocation necessarily results in a maximum end-to-end latency. Resource allocation also addresses contention-related packet loss.
リソース割り当ては、遅延とパケット損失という2つのDetNet QoS要件に対応します。 DetNetノードのバッファスペースには限りがあるため、リソースの割り当ては必然的に最大のエンドツーエンドのレイテンシになります。リソース割り当ては、コンテンション関連のパケット損失にも対処します。
Other important contributions to packet loss are random media errors and equipment failures. Service protection is the name for the mechanisms used by DetNet to address these losses. The mechanisms employed are constrained by the need to meet the users' latency requirements. Packet replication and elimination (Section 3.2.2.2) and packet encoding (Section 3.2.2.3) are described in this document to provide service protection, but other mechanisms may also be found. For instance, packet encoding can be used to provide service protection against random media errors, while packet replication and elimination can be used to provide service protection against equipment failures. This mechanism distributes the contents of DetNet flows over multiple paths in time and/or space, so that the loss of some of the paths does need not cause the loss of any packets.
パケット損失の他の重要な原因は、ランダムなメディアエラーと機器の障害です。サービス保護は、DetNetがこれらの損失に対処するために使用するメカニズムの名前です。採用されているメカニズムは、ユーザーのレイテンシ要件を満たす必要性によって制約されています。このドキュメントでは、サービスの保護を提供するために、パケットの複製と削除（セクション3.2.2.2）およびパケットエンコーディング（セクション3.2.2.3）について説明しますが、他のメカニズムも見つかる場合があります。たとえば、パケットエンコーディングを使用してランダムメディアエラーに対するサービス保護を提供でき、パケットの複製と除去を使用して機器の障害に対するサービス保護を提供できます。このメカニズムは、DetNetフローのコンテンツを時間および/または空間で複数のパスに分散するため、一部のパスが失われてもパケットが失われる必要はありません。
The paths are typically (but not necessarily) explicit routes so that they do not normally suffer temporary interruptions caused by the convergence of routing or bridging protocols.
通常、パスは明示的なルートですが（必ずしもそうではありません）、ルーティングまたはブリッジングプロトコルの収束によって引き起こされる一時的な中断を通常受けません。
These three techniques can be applied individually or applied together; it results that eight combinations, including none (no DetNet), are possible. Some combinations, however, are of wider utility than others. This separation keeps the protocol stack coherent and maximizes interoperability with existing and developing standards in the IETF and other Standards Development Organizations. The following are examples of typical expected combinations:
これらの3つの手法は、個別に適用することも、一緒に適用することもできます。結果として、なし（DetNetなし）を含む8つの組み合わせが可能になります。ただし、一部の組み合わせは、他の組み合わせよりも用途が広くなっています。この分離により、プロトコルスタックの一貫性が維持され、IETFおよびその他の標準開発組織における既存の標準および開発中の標準との相互運用性が最大化されます。以下は、典型的な予想される組み合わせの例です。
* The combination of explicit routes and service protection is the technique employed by seamless redundancy mechanisms applied on a ring topology, e.g., as described in [IEC-62439-3]. In this example, explicit routes are achieved by limiting the physical topology of the network to a ring. Sequentialization, replication, and duplicate elimination are facilitated by packet tags added at the front or the end of Ethernet frames. [RFC8227] provides another example in the context of MPLS.
* 明示的なルートとサービス保護の組み合わせは、たとえば[IEC-62439-3]で説明されているように、リングトポロジに適用されるシームレスな冗長メカニズムによって採用される手法です。この例では、ネットワークの物理トポロジをリングに制限することにより、明示的なルートが実現されます。逐次化、複製、重複排除は、イーサネットフレームの前または終わりに追加されたパケットタグによって容易になります。 [RFC8227]は、MPLSのコンテキストで別の例を提供します。
* Resource allocation alone was originally offered by Audio Video Bridging as defined by IEEE 802.1 [IEEE802.1BA]. As long as the network suffers no failures, packet loss due to output packet contention can be eliminated through the use of a reservation protocol (e.g., the Multiple Stream Registration Protocol [IEEE802.1Q]), shapers in every bridge, and proper dimensioning.
* リソース割り当てのみは、IEEE 802.1 [IEEE802.1BA]で定義されているように、元々オーディオビデオブリッジングによって提供されていました。ネットワークで障害が発生しない限り、出力パケットの競合によるパケット損失は、予約プロトコル（たとえば、Multiple Stream Registration Protocol [IEEE802.1Q]）、すべてのブリッジのシェーパー、および適切なディメンジョンを使用することで解消できます。
* Using all three together gives maximum protection.
* 3つすべてを一緒に使用すると、最大限の保護が得られます。
There are, of course, simpler methods available (and employed today) to achieve levels of latency and packet loss that are satisfactory for many applications. Prioritization and over-provisioning is one such technique. However, these methods generally work best in the absence of any significant amount of noncritical traffic in the network (if, indeed, such traffic is supported at all). They may also work only if the critical traffic constitutes only a small portion of the network's theoretical capacity, if all systems are functioning properly, or if actions by end systems that disrupt the network's operations are absent.
もちろん、多くのアプリケーションにとって満足のいくレベルの遅延とパケット損失を達成するために利用可能な（そして今日採用されている）より単純な方法があります。優先順位付けとオーバープロビジョニングは、そのような手法の1つです。ただし、これらの方法は一般に、ネットワークに重要ではない大量の重要でないトラフィックがない場合に最適に機能します（実際にそのようなトラフィックがサポートされている場合）。また、重要なトラフィックがネットワークの理論上の容量のごく一部である場合、すべてのシステムが適切に機能している場合、またはネットワークの運用を妨害するエンドシステムによるアクションがない場合にのみ機能します。
There are any number of methods in use, defined, or in progress for accomplishing each of the above techniques. It is expected that the DetNet architecture defined in this document will assist various vendors, users, and/or "vertical" Standards Development Organizations (dedicated to a single industry) in making selections among the available means of implementing DetNet networks.
上記の各手法を実行するために、使用、定義、または進行中の方法はいくつもあります。このドキュメントで定義されているDetNetアーキテクチャは、さまざまなベンダー、ユーザー、および/または「単一の業界専用の」標準開発組織が、DetNetネットワークを実装するための利用可能な手段を選択するのに役立ちます。
The primary means by which DetNet achieves its QoS assurances is to reduce, or even completely eliminate, packet loss due to output packet contention within a DetNet node as a cause of packet loss. This can be achieved only by the provision of sufficient buffer storage at each node through the network to ensure that no packets are dropped due to a lack of buffer storage. Note that App-flows are generally not expected to be responsive to implicit [RFC2914] or explicit congestion notification [RFC3168].
DetNetがQoS保証を達成する主な手段は、パケット損失の原因としてのDetNetノード内での出力パケット競合によるパケット損失を減らす、または完全になくすことです。これは、ネットワークを介して各ノードに十分なバッファストレージを提供し、バッファストレージの不足によりパケットがドロップされないようにすることによってのみ実現できます。 App-flowは通常、暗黙的な[RFC2914]または明示的な輻輳通知[RFC3168]に応答することが期待されていないことに注意してください。
Ensuring adequate buffering requires, in turn, that the source and every DetNet node along the path to the destination (or nearly every node; see Section 4.3.3) be careful to regulate its output to not exceed the data rate for any DetNet flow, except for brief periods when making up for interfering traffic. Any packet sent ahead of its time potentially adds to the number of buffers required by the next-hop DetNet node and may thus exceed the resources allocated for a particular DetNet flow. Furthermore, rate limiting (e.g., using traffic policing) and shaping functions (e.g., shaping as defined in [RFC2475]) at the ingress of the DetNet domain must be applied. This is needed for meeting the requirements of DetNet flows as well as for protecting non-DetNet traffic from potentially misbehaving DetNet traffic sources. Note that large buffers have some issues (see, e.g., [BUFFERBLOAT]).
次に、適切なバッファリングを確実にするには、ソースと宛先へのパスに沿ったすべてのDetNetノード（またはほぼすべてのノード。セクション4.3.3を参照）が、DetNetフローのデータレートを超えないように出力を調整する必要があります。干渉するトラフィックを補う短い期間を除きます。その時間より前に送信されたパケットは、ネクストホップのDetNetノードに必要なバッファの数に追加される可能性があるため、特定のDetNetフローに割り当てられたリソースを超える可能性があります。さらに、DetNetドメインの入口でのレート制限（トラフィックポリシングの使用など）およびシェーピング機能（[RFC2475]で定義されたシェーピングなど）を適用する必要があります。これは、DetNetフローの要件を満たし、DetNetトラフィックソースの誤動作の可能性から非DetNetトラフィックを保護するために必要です。大きなバッファにはいくつかの問題があることに注意してください（たとえば、[BUFFERBLOAT]を参照）。
The low-level mechanisms described in Section 4.5 provide the necessary regulation of transmissions by an end system or DetNet node to provide resource allocation. The allocation of the bandwidth and buffers for a DetNet flow requires provisioning. A DetNet node may have other resources requiring allocation and/or scheduling that might otherwise be over-subscribed and trigger the rejection of a reservation.
セクション4.5で説明する低レベルのメカニズムは、リソース割り当てを提供するために、エンドシステムまたはDetNetノードによる送信の必要な調整を提供します。 DetNetフローに帯域幅とバッファを割り当てるには、プロビジョニングが必要です。 DetNetノードには、割り当てやスケジューリングを必要とする他のリソースがあり、そうでない場合はオーバーサブスクライブされ、予約の拒否がトリガーされる可能性があります。
A core objective of DetNet is to enable the convergence of sensitive non-IP networks onto a common network infrastructure. This requires the accurate emulation of currently deployed mission-specific networks, which, for example, rely on point-to-point analog (e.g., 4-20mA modulation) and serial-digital cables (or buses) for highly reliable, synchronized, and jitter-free communications. While the latency of analog transmissions is basically the speed of light, legacy serial links are usually slow (in the order of Kbps) compared to, say, Gigabit Ethernet, and some latency is usually acceptable. What is not acceptable is the introduction of excessive jitter, which may, for instance, affect the stability of control systems.
DetNetの中心的な目的は、機密性の高い非IPネットワークを共通のネットワークインフラストラクチャに統合できるようにすることです。これには、現在配備されているミッション固有ネットワークの正確なエミュレーションが必要です。たとえば、ポイントツーポイントアナログ（4-20mA変調など）とシリアルデジタルケーブル（またはバス）に依存して、信頼性が高く、同期されています。ジッタのない通信。アナログ伝送のレイテンシは基本的に光の速度ですが、レガシーシリアルリンクは通常、ギガビットイーサネットなどに比べて低速（Kbpsのオーダー）であり、ある程度のレイテンシは通常許容されます。許容できないのは、たとえば制御システムの安定性に影響を与える可能性のある過剰なジッターの導入です。
Applications that are designed to operate on serial links usually do not provide services to recover the jitter, because jitter simply does not exist there. DetNet flows are generally expected to be delivered in order, and the precise time of reception influences the processes. In order to converge such existing applications, there is a desire to emulate all properties of the serial cable, such as clock transportation, perfect flow isolation, and fixed latency. While minimal jitter (in the form of specifying minimum, as well as maximum, end-to-end latency) is supported by DetNet, there are practical limitations on packet-based networks in this regard. In general, users are encouraged to use a combination of:
シリアルリンクで動作するように設計されたアプリケーションは、ジッターが存在しないため、通常、ジッターを回復するサービスを提供しません。 DetNetフローは、通常、順番に配信されることが期待されており、受信の正確な時刻がプロセスに影響します。このような既存のアプリケーションを統合するために、クロック転送、完全なフローの分離、固定遅延など、シリアルケーブルのすべてのプロパティをエミュレートすることが求められています。最小限のジッター（最小および最大のエンドツーエンドのレイテンシを指定する形式）がDetNetでサポートされていますが、この点に関してパケットベースのネットワークには実際的な制限があります。一般に、ユーザーは次の組み合わせを使用することをお勧めします。
* Sub-microsecond time synchronization among all source and destination end systems, and
* すべてのソースおよび宛先エンドシステム間のサブマイクロ秒の時間同期、および
* Time-of-execution fields in the application packets.
* アプリケーションパケットの実行時間フィールド。
Jitter reduction is provided by the mechanisms described in Section 4.5 that also provide resource allocation.
ジッタの低減は、リソース割り当ても提供するセクション4.5で説明されているメカニズムによって提供されます。
Service protection aims to mitigate or eliminate packet loss due to equipment failures, including random media and/or memory faults. These types of packet loss can be greatly reduced by spreading the data over multiple disjoint forwarding paths. Various service protection methods are described in [RFC6372], e.g., 1+1 linear protection. The functional details of an additional method are described in Section 3.2.2.2, which can be implemented as described in Section 3.2.2.3 or as specified in [DETNET-MPLS] in order to provide 1+n hitless protection. The appropriate service protection mechanism depends on the scenario and the requirements.
サービス保護は、ランダムなメディアやメモリの障害など、機器の障害によるパケット損失を軽減または排除することを目的としています。これらのタイプのパケット損失は、データを複数のばらばらの転送パスに分散させることで大幅に削減できます。 [RFC6372]には、1 + 1線形保護など、さまざまなサービス保護方法が記述されています。追加のメソッドの機能の詳細はセクション3.2.2.2で説明されており、セクション3.2.2.3で説明されているように、または[DETNET-MPLS]で指定されているように実装して、1 + nヒットレス保護を提供できます。適切なサービス保護メカニズムは、シナリオと要件によって異なります。
Out-of-order packet delivery can be a side effect of service protection. Packets delivered out of order impact the amount of buffering needed at the destination to properly process the received data. Such packets also influence the jitter of a flow. The guarantees of a DetNet service include a maximum amount of misordering as a constraint. Zero misordering would be a valid service constraint to reflect that the end system(s) of the flow cannot tolerate any out-of-order delivery. A DetNet Packet Ordering Function (POF) (Section 3.2.2.2) can be used to provide in-order delivery.
順不同のパケット配信は、サービス保護の副作用となる可能性があります。順不同で配信されたパケットは、受信データを適切に処理するために宛先で必要なバッファリングの量に影響を与えます。このようなパケットは、フローのジッターにも影響します。 DetNetサービスの保証には、制約として最大数の誤順序が含まれます。順序の乱れがないことは、フローのエンドシステムが順不同の配信を許容できないことを反映する有効なサービス制約です。 DetNetパケットオーダー機能（POF）（セクション3.2.2.2）を使用して、順序どおりの配信を提供できます。
This section describes a service protection method that sends copies of the same packets over multiple paths.
このセクションでは、複数のパスを介して同じパケットのコピーを送信するサービス保護方法について説明します。
The DetNet service sub-layer includes the PRF, PEF, and POF for use in DetNet edge, relay node, and end-system packet processing. These functions can be enabled in a DetNet edge node, relay node, or end system. The collective name for all three functions is Packet Replication, Elimination, and Ordering Functions (PREOF). The packet replication and elimination service protection method altogether involves four capabilities:
DetNetサービスサブレイヤーには、DetNetエッジ、リレーノード、エンドシステムのパケット処理で使用するPRF、PEF、POFが含まれています。これらの機能は、DetNetエッジノード、リレーノード、またはエンドシステムで有効にできます。 3つすべての機能の総称は、パケット複製、除去、および順序付け機能（PREOF）です。パケット複製および除去サービスの保護方法には、4つの機能が含まれます。
* Sequencing information is provided to the packets of a DetNet compound flow. This may be done by adding a sequence number or time stamp as part of DetNet, or it may be inherent in the packet, e.g., in a higher-layer protocol or associated to other physical properties such as the precise time (and radio channel) of reception of the packet. This is typically done once, at or near the source.
* シーケンス情報は、DetNet複合フローのパケットに提供されます。これは、DetNetの一部としてシーケンス番号またはタイムスタンプを追加することで実行できます。または、パケットに固有である可能性があります。パケットの受信。これは通常、ソースで、またはソースの近くで1回実行されます。
* The PRF replicates these packets into multiple DetNet member flows and typically sends them along multiple different paths to the destination(s), e.g., over the explicit routes described in Section 3.2.3. The location within a DetNet node and the mechanism used for the PRF are left open for implementations.
* PRFはこれらのパケットを複数のDetNetメンバーフローに複製し、通常、複数の異なるパスに沿って、たとえばセクション3.2.3で説明されている明示的なルートを介して宛先に送信します。 DetNetノード内の場所とPRFに使用されるメカニズムは、実装のために開いたままです。
* The PEF eliminates duplicate packets of a DetNet flow based on the sequencing information and a history of received packets. The output of the PEF is always a single packet. This may be done at any DetNet node along the path to save network resources further downstream, in particular if multiple replication points exist. But the most common case is to perform this operation at the very edge of the DetNet network, preferably in or near the receiver. The location within a DetNet node and the mechanism used for the PEF is left open for implementations.
* PEFは、シーケンス情報と受信パケットの履歴に基づいて、DetNetフローの重複パケットを排除します。 PEFの出力は常に単一のパケットです。これは、特に複数のレプリケーションポイントが存在する場合、ネットワークリソースをさらに下流に節約するために、パスに沿った任意のDetNetノードで実行できます。しかし、最も一般的なケースは、DetNetネットワークの最端、好ましくは受信機の中または近くでこの操作を実行することです。 DetNetノード内の場所とPEFに使用されるメカニズムは、実装のために開いたままにしておきます。
* The POF uses the sequencing information to reorder a DetNet flow's packets that are received out of order.
* POFはシーケンス情報を使用して、順不同で受信されたDetNetフローのパケットを並べ替えます。
The order in which a DetNet node applies PEF, POF, and PRF to a DetNet flow is left open for implementations.
DetNetノードがPEF、POF、およびPRFをDetNetフローに適用する順序は、実装のために開いたままにしておきます。
Some service protection mechanisms rely on switching from one flow to another when a failure of a flow is detected. Contrarily, packet replication and elimination combines the DetNet member flows sent along multiple different paths and performs a packet-by-packet selection of which to discard, e.g., based on sequencing information.
一部のサービス保護メカニズムは、フローの障害が検出されたときに、あるフローから別のフローへの切り替えに依存しています。反対に、パケットの複製と除去は、複数の異なるパスに沿って送信されたDetNetメンバーフローを組み合わせ、破棄するパケットごとの選択を、たとえばシーケンス情報に基づいて実行します。
In the simplest case, this amounts to 1) replicating each packet in a source that has two interfaces and 2) conveying them through the network along separate (Shared Risk Link Group (SRLG) disjoint) paths to the similarly dual-homed destinations that 3) reorder the packets and 4) discard the duplicates. This ensures that one path remains, even if some DetNet intermediate node fails. The sequencing information can also be used for loss detection and for reordering.
最も単純なケースでは、これは1）2つのインターフェースを持つ送信元で各パケットを複製し、2）ネットワークを介して別々の（共有リスクリンクグループ（SRLG）分離）パスに沿って同様にデュアルホーム接続された宛先にそれらを転送することになります3 ）パケットを並べ替え、4）重複を破棄します。これにより、DetNet中間ノードに障害が発生した場合でも、1つのパスが確実に残ります。シーケンス情報は、損失の検出と並べ替えにも使用できます。
DetNet relay nodes in the network can provide replication and elimination facilities at various points in the network so that multiple failures can be accommodated.
ネットワーク内のDetNetリレーノードは、ネットワーク内のさまざまなポイントで複製および排除機能を提供できるため、複数の障害に対応できます。
This is shown in Figure 1, where the two relay nodes each replicate (R) the DetNet flow on input, sending the DetNet member flows to both the other relay node and to the end system, and eliminate duplicates (E) on the output interface to the right-hand end system. Any one link in the network can fail, and the DetNet compound flow can still get through. Furthermore, two links can fail, as long as they are in different segments of the network.
これを図1に示します。2つのリレーノードはそれぞれ、入力でDetNetフローを複製（R）し、DetNetメンバーフローを他のリレーノードとエンドシステムの両方に送信し、出力インターフェイスの重複（E）を排除します。右側のエンドシステムに。ネットワーク内のいずれかのリンクに障害が発生しても、DetNet複合フローは引き続き通過できます。さらに、ネットワークの異なるセグメントにある限り、2つのリンクに障害が発生する可能性があります。
> > > > > > > > > relay > > > > > > > >
> /------------+ R node E +------------\ >
> / v + ^ \ >
end R + v | ^ + E end
system + v | ^ + system
> \ v + ^ / >
> \------------+ R relay E +-----------/ >
> > > > > > > > > node > > > > > > > >
Figure 1: Packet Replication and Elimination
図1：パケットの複製と排除
Packet replication and elimination does not react to and correct failures; it is entirely passive. Thus, intermittent failures, mistakenly created packet filters, or misrouted data is handled just the same as the equipment failures that are handled by typical routing and bridging protocols.
パケットの複製と除去は、障害に反応して修正することはありません。それは完全に受動的です。したがって、断続的な障害、誤って作成されたパケットフィルター、または誤ってルーティングされたデータは、通常のルーティングおよびブリッジングプロトコルで処理される機器の障害と同じように処理されます。
If member flows that take different-length paths through the network are combined, a merge point may require extra buffering to equalize the delays over the different paths. This equalization ensures that the resultant compound flow will not exceed its contracted bandwidth even after one of the paths is restored after a failure. The extra buffering can be also used to provide in-order delivery.
ネットワークを介して異なる長さのパスを使用するメンバーフローが結合される場合、マージポイントは、異なるパス上の遅延を等しくするために追加のバッファリングを必要とする場合があります。この等化により、パスの1つが障害後に復元された後でも、結果の複合フローが契約帯域幅を超えないことが保証されます。追加のバッファリングを使用して、順序どおりの配信を提供することもできます。
There are methods for using multiple paths to provide service protection that involve encoding the information in a packet belonging to a DetNet flow into multiple transmission units, combining information from multiple packets into any given transmission unit. Such techniques, also known as "network coding", can be used as a DetNet service protection technique.
複数のパスを使用してサービス保護を提供する方法には、DetNetフローに属するパケットの情報を複数の伝送ユニットにエンコードし、複数のパケットからの情報を任意の所定の伝送ユニットに結合する方法があります。 「ネットワークコーディング」としても知られているこのような技術は、DetNetサービス保護技術として使用できます。
In networks controlled by typical dynamic control protocols such as IS-IS or OSPF, a network topology event in one part of the network can impact, at least briefly, the delivery of data in parts of the network remote from the failure or recovery event. Even the use of redundant paths through a network, e.g., as defined by [RFC6372], does not eliminate the chances of packet loss. Furthermore, out-of-order packet delivery can be a side effect of route changes.
IS-ISやOSPFなどの一般的な動的制御プロトコルによって制御されるネットワークでは、ネットワークの一部のネットワークトポロジイベントが、障害または復旧イベントから離れたネットワークの一部でのデータ配信に、少なくとも一時的に影響を与える可能性があります。たとえば、[RFC6372]で定義されているように、ネットワークを介した冗長パスを使用しても、パケット損失の可能性は排除されません。さらに、順不同のパケット配信は、ルート変更の副作用になる可能性があります。
Many real-time networks rely on physical rings of two-port devices, with a relatively simple ring control protocol. This supports redundant paths for service protection with a minimum of wiring. As an additional benefit, ring topologies can often utilize different topology management protocols from those used for a mesh network, with a consequent reduction in the response time to topology changes. Of course, this comes at some cost in terms of increased hop count, and thus latency, for the typical path.
多くのリアルタイムネットワークは、比較的単純なリング制御プロトコルを使用して、2ポートデバイスの物理リングに依存しています。これは、最小限の配線でサービス保護のための冗長パスをサポートします。追加の利点として、リングトポロジは、メッシュネットワークに使用されるものとは異なるトポロジ管理プロトコルを利用できることが多く、その結果、トポロジ変更への応答時間が短縮されます。もちろん、これには、一般的なパスのホップカウントの増加、つまりレイテンシという面でいくらかコストがかかります。
In order to get the advantages of low hop count and still ensure against even very brief losses of connectivity, DetNet employs explicit routes where the path taken by a given DetNet flow does not change, at least not immediately and likely not at all, in response to network topology events. Service protection (see Sections 3.2.2 and 3.2.2.3) over explicit routes provides a high likelihood of continuous connectivity. Explicit routes can be established in various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) [RFC8402], via a SDN approach [RFC8453], with IS-IS [RFC7813], etc. Explicit routes are typically used in MPLS TE (Traffic Engineering) Label Switched Paths (LSPs).
ホップカウントが少ないという利点を得て、接続が非常に短時間でも失われないようにするために、DetNetは、指定されたDetNetフローがたどるパスが変化しない、少なくともすぐには反応せず、ほとんど反応しないという明示的なルートを採用しています。ネットワークトポロジイベントに。明示的なルートを介したサービス保護（セクション3.2.2および3.2.2.3を参照）は、継続的な接続の可能性を高くします。明示的なルートは、RSVP-TE [RFC3209]、セグメントルーティング（SR）[RFC8402]、SDNアプローチ[RFC8453]、IS-IS [RFC7813]など、さまざまな方法で確立できます。明示的なルートは、通常、MPLS TE（Traffic Engineering）ラベルスイッチドパス（LSP）で使用されます。
Out-of-order packet delivery can be a side effect of distributing a single flow over multiple paths, especially when there is a change from one path to another when combining the flow. This is irrespective of the distribution method used and also applies to service protection over explicit routes. As described in Section 3.2.2.1, out-of-order packets influence the jitter of a flow and impact the amount of buffering needed to process the data; therefore, the guarantees of a DetNet service include a maximum amount of misordering as a constraint. The use of explicit routes helps to provide in-order delivery because there is no immediate route change with the network topology, but the changes are plannable as they are between the different explicit routes.
順不同のパケット配信は、特にフローを結合する際に1つのパスから別のパスに変更がある場合、単一のフローを複数のパスに分散することの副作用となる可能性があります。これは、使用される配布方法に関係なく、明示的なルートを介したサービス保護にも適用されます。セクション3.2.2.1で説明したように、順序が正しくないパケットはフローのジッターに影響を与え、データの処理に必要なバッファリングの量に影響を与えます。したがって、DetNetサービスの保証には、制約として最大数の誤順序が含まれます。明示的なルートを使用すると、ネットワークトポロジーですぐにルートが変更されることはありませんが、異なる明示的なルート間であるため、変更は計画可能です。
Many applications require DetNet to provide additional services, including coexistence with other QoS mechanisms (Section 3.3.1) and protection against misbehaving transmitters (Section 3.3.2).
多くのアプリケーションでは、他のQoSメカニズムとの共存（セクション3.3.1）やトランスミッタの誤動作に対する保護（セクション3.3.2）など、DetNetが追加のサービスを提供する必要があります。
A DetNet network supports the dedication of a high proportion of the network bandwidth to DetNet flows. But, no matter how much is dedicated for DetNet flows, it is a goal of DetNet to coexist with existing Class-of-Service schemes (e.g., DiffServ). It is also important that non-DetNet traffic not disrupt the DetNet flow, of course (see Sections 3.3.2 and 5). For these reasons:
DetNetネットワークは、ネットワーク帯域幅の大部分をDetNetフローに専念することをサポートします。しかし、DetNetフローにどれだけ専念しても、既存のサービスクラススキーム（DiffServなど）と共存することがDetNetの目標です。もちろん、DetNet以外のトラフィックがDetNetフローを中断しないことも重要です（セクション3.3.2および5を参照）。これらの理由により：
* Bandwidth (transmission opportunities) not utilized by a DetNet flow is available to non-DetNet packets (though not to other DetNet flows).
* DetNetフローでは利用されない帯域幅（送信機会）は、（他のDetNetフローではなく）非DetNetパケットで利用できます。
* DetNet flows can be shaped or scheduled, in order to ensure that the highest-priority non-DetNet packet is also ensured a worst-case latency.
* DetNetフローは、最優先の非DetNetパケットでも最悪の場合の遅延が保証されるように、シェーピングまたはスケジュールできます。
* When transmission opportunities for DetNet flows are scheduled in detail, the algorithm constructing the schedule should leave sufficient opportunities for non-DetNet packets to satisfy the needs of the users of the network. Detailed scheduling can also permit the time-shared use of buffer resources by different DetNet flows.
* DetNetフローの送信機会が詳細にスケジュールされている場合、スケジュールを構築するアルゴリズムは、DetNet以外のパケットがネットワークのユーザーのニーズを満たす十分な機会を残す必要があります。詳細なスケジューリングでは、さまざまなDetNetフローによるバッファリソースの時分割使用を許可することもできます。
Starvation of non-DetNet traffic must be avoided, for example, by traffic policing and shaping functions (e.g., [RFC2475]). Thus, the net effect of the presence of DetNet flows in a network on the non-DetNet flows is primarily a reduction in the available bandwidth.
非DetNetトラフィックの枯渇は、たとえば、トラフィックポリシングおよびシェーピング機能（[RFC2475]など）によって回避する必要があります。したがって、ネットワーク内のDetNetフローの存在が非DetNetフローに及ぼす最終的な影響は、主に使用可能な帯域幅の減少です。
Robust real-time systems require reducing the number of possible failures. Filters and policers should be used in a DetNet network to detect if DetNet packets are received on the wrong interface, at the wrong time, or in too great a volume. Furthermore, filters and policers can take actions to discard the offending packets or flows, or trigger shutting down the offending flow or the offending interface.
堅牢なリアルタイムシステムでは、起こり得る障害の数を減らす必要があります。フィルターとポリサーをDetNetネットワークで使用して、DetNetパケットが間違ったインターフェイスで、間違った時間に、または大量に受信されたかどうかを検出する必要があります。さらに、フィルターとポリサーは、問題のパケットまたはフローを破棄するアクションを実行したり、問題のフローまたは問題のインターフェイスのシャットダウンをトリガーしたりできます。
It is also essential that filters and service remarking be employed at the network edge to prevent non-DetNet packets from being mistaken for DetNet packets and thus impinging on the resources allocated to DetNet packets. In particular, sending DetNet traffic into networks that have not been provisioned in advance to handle that DetNet traffic has to be treated as a fault. The use of egress traffic filters, or equivalent mechanisms, to prevent this from happening are strongly recommended at the edges of DetNet networks and DetNet supporting networks. In this context, the term 'provisioned' has a broad meaning, e.g., provisioning could be performed via an administrative decision that the downstream network has the available capacity to carry the DetNet traffic that is being sent into it.
また、DetNet以外のパケットがDetNetパケットと間違われ、DetNetパケットに割り当てられたリソースに影響を与えないように、フィルターとサービスリマーキングをネットワークエッジで使用することも重要です。特に、DetNetトラフィックを処理するために事前にプロビジョニングされていないネットワークにDetNetトラフィックを送信することは、障害として処理する必要があります。 DetNetネットワークとDetNetサポートネットワークのエッジでは、これを防ぐために出力トラフィックフィルターまたは同等のメカニズムを使用することを強くお勧めします。このコンテキストでは、「プロビジョニングされた」という用語には幅広い意味があります。たとえば、ダウンストリームネットワークに送信されているDetNetトラフィックを伝送するための利用可能な容量があるという管理上の決定を介してプロビジョニングを実行できます。
Note that the sending of App-flows that do not use transport-layer congestion control per [RFC2914] into a network that is not provisioned to handle such traffic has to be treated as a fault and prevented. PRF-generated DetNet member flows also need to be treated as not using transport-layer congestion control even if the original App-flow supports transport-layer congestion control because PREOF can remove congestion indications at the PEF and thereby hide such indications (e.g., drops, ECN markings, increased latency) from end systems.
[RFC2914]によるトランスポート層の輻輳制御を使用しないApp-flowを、そのようなトラフィックを処理するようにプロビジョニングされていないネットワークに送信することは、障害として扱い、防止する必要があることに注意してください。元のApp-flowがトランスポート層の輻輳制御をサポートしている場合でも、PRFで生成されたDetNetメンバーフローは、トランスポート層の輻輳制御を使用していないものとして扱う必要があります。 、ECNマーキング、レイテンシの増加）エンドシステムから。
The mechanisms to support these requirements are both Data Plane and implementation specific. Solutions that are data-plane specific will be specified in the relevant data-plane solution document. There also exist techniques, at present and/or in various stages of standardization, that can support these fault-mitigation tasks that deliver a high probability that misbehaving systems will have zero impact on well-behaved DetNet flows with the exception, of course, of the receiving interface(s) immediately downstream from the misbehaving device. Examples of such techniques include traffic policing and shaping functions (e.g., those described in [RFC2475]), separating flows into per-flow rate-limited queues, and potentially applying active queue management [RFC7567].
これらの要件をサポートするメカニズムは、データプレーンと実装固有の両方です。データプレーン固有のソリューションは、関連するデータプレーンソリューションドキュメントで指定されます。現在および/または標準化のさまざまな段階で、これらの障害軽減タスクをサポートできる手法も存在します。これらの障害軽減タスクは、当然ながら例外として、正常に動作するシステムが正常に動作するDetNetフローに影響を与えない可能性が高いです。正常に動作しないデバイスのすぐ下流にある受信インターフェイス。このような手法の例としては、トラフィックポリシングおよびシェーピング機能（[RFC2475]で説明されている機能など）、フローごとのレート制限キューへの分離、アクティブキュー管理の適用[RFC7567]などがあります。
DetNet functionality (Section 3) is implemented in two adjacent sub-layers in the protocol stack: the DetNet service sub-layer and the DetNet forwarding sub-layer. The DetNet service sub-layer provides DetNet service, e.g., service protection, to higher layers in the protocol stack and applications. The DetNet forwarding sub-layer supports DetNet service in the underlying network, e.g., by providing explicit routes and resource allocation to DetNet flows.
DetNet機能（セクション3）は、プロトコルスタックの2つの隣接するサブレイヤー、DetNetサービスサブレイヤーとDetNet転送サブレイヤーに実装されています。 DetNetサービスサブレイヤーは、プロトコルスタックおよびアプリケーションの上位レイヤーにサービス保護などのDetNetサービスを提供します。 DetNet転送サブレイヤーは、たとえば、DetNetフローへの明示的なルートとリソース割り当てを提供することにより、基盤となるネットワークでのDetNetサービスをサポートします。
Figure 2 illustrates a conceptual DetNet data-plane layering model. One may compare it to that in [IEEE802.1CB], Annex C.
図2は、概念的なDetNetデータプレーンレイヤーモデルを示しています。 [IEEE802.1CB]の附属書Cと比較することができます。
| 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 2: DetNet Data-Plane Protocol Stack
図2：DetNetデータプレーンプロトコルスタック
Not all sub-layers are required for any given application, or even for any given network. The functionality shown in Figure 2 is:
特定のアプリケーション、または特定のネットワークにすべてのサブレイヤーが必要なわけではありません。図2に示す機能は次のとおりです。
Application Shown as "source" and "destination" in the diagram.
図では「ソース」と「宛先」として示されているアプリケーション。
Packet sequencing As part of the DetNet service sub-layer, the packet sequencing function supplies the sequence number for packet replication and elimination for DetNet service protection (Section 3.2.2.2); thus, its peer is duplicate elimination. This sub-layer is not needed if a higher-layer protocol is expected to perform any packet sequencing and duplicate elimination required by the DetNet flow replication.
パケットシーケンスパケットシーケンス機能は、DetNetサービスサブレイヤーの一部として、DetNetサービス保護のためにパケットの複製と削除のためのシーケンス番号を提供します（セクション3.2.2.2）。したがって、そのピアは重複排除です。上位層のプロトコルが、DetNetフローの複製に必要なパケットシーケンスと重複排除を実行することが予想される場合、このサブ層は必要ありません。
Duplicate elimination As part of the DetNet service sub-layer, based on the sequence number supplied by its peer (packet sequencing), duplicate elimination discards any duplicate packets generated by DetNet flow replication. It can operate on member flows, compound flows, or both. The replication may also be inferred from other information such as the precise time of reception in a scheduled network. The duplicate elimination sub-layer may also perform resequencing of packets to restore packet order in a flow that was disrupted by the loss of packets on one or another of the multiple paths taken.
重複排除ピアから提供されたシーケンス番号（パケットシーケンス）に基づいて、DetNetサービスサブレイヤーの一部として、重複排除は、DetNetフローレプリケーションによって生成された重複パケットを破棄します。メンバーフロー、複合フロー、またはその両方を操作できます。複製は、スケジュールされたネットワークでの正確な受信時刻など、他の情報から推測することもできます。重複排除サブレイヤは、パケットの再シーケンスを実行して、複数のパスのうちの1つまたは別のパスでのパケット損失によって中断されたフローのパケット順序を復元することもできます。
Flow replication As part of DetNet service protection, packets that belong to a DetNet compound flow are replicated into two or more DetNet member flows. This function is separate from packet sequencing. Flow replication can be an explicit replication and remarking of packets or can be performed by, for example, techniques similar to ordinary multicast replication, albeit with resource allocation implications. Its peer is DetNet flow merging.
フロー複製DetNetサービス保護の一部として、DetNet複合フローに属するパケットは、2つ以上のDetNetメンバーフローに複製されます。この機能は、パケットの順序付けとは別のものです。フローレプリケーションは、明示的なレプリケーションとパケットの再マーキングである場合と、リソース割り当ての影響はあるものの、たとえば通常のマルチキャストレプリケーションと同様の手法で実行される場合があります。そのピアは、DetNetフローのマージです。
Flow merging As part of the DetNet service sub-layer, the flow merging function combines DetNet member flows together for packets coming up the stack belonging to a specific DetNet compound flow. DetNet flow merging, together with packet sequencing, duplicate elimination, and DetNet flow replication perform packet replication and elimination (Section 3.2.2). Its peer is DetNet flow replication.
フローのマージDetNetサービスサブレイヤーの一部として、フローマージ機能は、特定のDetNet複合フローに属するスタックに到達するパケットに対して、DetNetメンバーフローを結合します。 DetNetフローのマージと、パケットシーケンス、重複排除、およびDetNetフローレプリケーションは、パケットの複製と排除を実行します（セクション3.2.2）。そのピアは、DetNetフローレプリケーションです。
Packet encoding As part of DetNet service protection, as an alternative to packet sequencing and flow replication, packet encoding combines the information in multiple DetNet packets, perhaps from different DetNet compound flows, and transmits that information in packets on different DetNet member flows. Its peer is packet decoding.
パケットエンコーディングDetNetサービス保護の一部として、パケットシーケンスとフローレプリケーションの代替として、パケットエンコーディングは、おそらく異なるDetNet複合フローからの複数のDetNetパケットの情報を組み合わせ、その情報を異なるDetNetメンバーフローのパケットに送信します。そのピアはパケットのデコードです。
Packet decoding As part of DetNet service protection, as an alternative to flow merging and duplicate elimination, packet decoding takes packets from different DetNet member flows and computes from those packets the original DetNet packets from the compound flows input to packet encoding. Its peer is packet encoding.
パケットデコードDetNetサービス保護の一部として、フローのマージと重複排除の代わりに、パケットデコードは異なるDetNetメンバーフローからパケットを取得し、それらのパケットから、パケットエンコードへの複合フロー入力からの元のDetNetパケットを計算します。そのピアはパケットエンコーディングです。
Resource allocation The DetNet forwarding sub-layer provides resource allocation. See Section 4.5. The actual queuing and shaping mechanisms are typically provided by the underlying subnet. These can be closely associated with the means of providing paths for DetNet flows. The path and the resource allocation are conflated in this figure.
リソースの割り当てDetNet転送サブレイヤーは、リソースの割り当てを提供します。セクション4.5を参照してください。実際のキューイングおよびシェーピングメカニズムは、通常、基盤となるサブネットによって提供されます。これらは、DetNetフローのパスを提供する手段と密接に関連しています。この図では、パスとリソース割り当てが統合されています。
Explicit routes Explicit routes are arrangements of fixed paths operated at the DetNet forwarding sub-layer that are determined in advance to avoid the impact of network convergence on DetNet flows.
明示的ルート明示的ルートは、DetNetフローへのネットワーク収束の影響を回避するために事前に決定された、DetNet転送サブレイヤーで動作する固定パスの配置です。
Operations, Administration, and Maintenance (OAM) leverages in-band and out-of-band signaling that validates whether the service is effectively obtained within QoS constraints. OAM is not shown in Figure 2; it may reside in any number of the layers. OAM can involve specific tagging added in the packets for tracing implementation or network configuration errors; traceability enables finding whether a packet is a replica, which DetNet relay node performed the replication, and which segment was intended for the replica. Active and hybrid OAM methods require additional bandwidth to perform fault management and performance monitoring of the DetNet domain. OAM may, for instance, generate special test probes or add OAM information into the data packet.
運用、管理、および保守（OAM）は、サービスがQoS制約内で効果的に取得されるかどうかを検証するインバンドおよびアウトオブバンドシグナリングを活用します。 OAMは図2には示されていません。任意の数のレイヤーに存在できます。 OAMには、実装エラーまたはネットワーク構成エラーを追跡するために、パケットに追加された特定のタグ付けが含まれる場合があります。トレーサビリティにより、パケットがレプリカであるかどうか、どのDetNetリレーノードがレプリケーションを実行したか、どのセグメントがレプリカ用であったかを見つけることができます。アクティブおよびハイブリッドOAM方式では、DetNetドメインの障害管理とパフォーマンス監視を実行するために追加の帯域幅が必要です。たとえば、OAMは特別なテストプローブを生成したり、OAM情報をデータパケットに追加したりできます。
The packet replication and elimination functions may be performed either at the source and destination ends of a DetNet compound flow or in a DetNet relay node.
パケットの複製と削除の機能は、DetNet複合フローの送信元と宛先の端、またはDetNetリレーノードで実行できます。
A "Deterministic Network" will be composed of DetNet-enabled end systems, DetNet edge nodes, and DetNet relay nodes, which collectively deliver DetNet services. DetNet relay and edge nodes are interconnected via DetNet transit nodes (e.g., LSRs), which support DetNet but are not DetNet service aware. All DetNet nodes are connected to sub-networks, where a point-to-point link is also considered a simple sub-network. These sub-networks provide DetNet-compatible service for support of DetNet traffic. Examples of sub-network technologies include MPLS TE, TSN as defined by IEEE 802.1, and OTN (Optical Transport Network). Of course, multilayer DetNet systems may also be possible, where one DetNet appears as a sub-network and provides service to a higher-layer DetNet system. A simple DetNet concept network is shown in Figure 3. Note that in this and following figures, "Forwarding" and "Fwd" refer to the DetNet forwarding sub-layer, and "Service" and "Svc" refer to the DetNet service sub-layer; both of these sub-layers are described in detail in Section 4.1.1.
「確定的ネットワーク」は、DetNet対応のエンドシステム、DetNetエッジノード、DetNetリレーノードで構成され、DetNetサービスを集合的に提供します。 DetNetリレーとエッジノードは、DetNetトランジットノード（LSRなど）を介して相互接続されます。これらのノードは、DetNetをサポートしますが、DetNetサービスを認識しません。すべてのDetNetノードはサブネットワークに接続されており、ポイントツーポイントリンクも単純なサブネットワークと見なされます。これらのサブネットワークは、DetNetトラフィックをサポートするためのDetNet互換サービスを提供します。サブネットワークテクノロジーの例には、MPLS TE、IEEE 802.1で定義されているTSN、OTN（Optical Transport Network）などがあります。もちろん、1つのDetNetがサブネットワークとして表示され、上位層のDetNetシステムにサービスを提供する多層DetNetシステムも可能です。簡単なDetNetコンセプトネットワークを図3に示します。この図と次の図で、「転送」と「Fwd」はDetNet転送サブレイヤーを指し、「サービス」と「Svc」はDetNetサービスサブレイヤーを指します。層;これらのサブレイヤーの両方については、セクション4.1.1で詳しく説明します。
TSN Edge Transit Relay DetNet End System Node Node Node End System
TSNエッジトランジットリレーDetNetエンドシステムノードノードノードエンドシステム
+----------+ +.........+ +----------+
| Appl. |<--:Svc Proxy:-- End-to-End Service -------->| Appl. |
+----------+ +---------+ +---------+ +----------+
| TSN | |TSN| |Svc|<- DetNet flow --: Service :-->| Service |
+----------+ +---+ +---+ +--------+ +---------+ +----------+
|Forwarding| |Fwd| |Fwd| | Fwd | |Fwd| |Fwd| |Forwarding|
+-------.--+ +-.-+ +-.-+ +--.----.+ +-.-+ +-.-+ +---.------+
: Link : / ,-----. \ : Link : / ,-----. \
+........+ +-[ Sub- ]-+ +.......+ +-[ Sub- ]-+
[network] [network]
`-----' `-----'
Figure 3: A Simple DetNet-Enabled Network
図3：シンプルなDetNet対応ネットワーク
DetNet Data Plane is divided into two sub-layers: the DetNet service sub-layer and the DetNet forwarding sub-layer. This helps to explore and evaluate various combinations of the data-plane solutions available. Some of them are illustrated in Figure 4. This separation of DetNet sub-layers, while helpful, should not be considered a formal requirement. For example, some technologies may violate these strict sub-layers and still be able to deliver a DetNet service.
DetNetデータプレーンは、DetNetサービスサブレイヤーとDetNet転送サブレイヤーの2つのサブレイヤーに分かれています。これは、利用可能なデータプレーンソリューションのさまざまな組み合わせを調査および評価するのに役立ちます。それらの一部を図4に示します。このDetNetサブレイヤーの分離は、有用ではありますが、正式な要件と見なすべきではありません。たとえば、一部のテクノロジはこれらの厳密なサブレイヤーに違反している場合でも、DetNetサービスを提供できる場合があります。
.
.
+-----------------------------+
| DetNet Service sub-layer | PW, UDP, GRE
+-----------------------------+
| DetNet Forwarding sub-layer | IPv6, IPv4, MPLS TE LSPs, MPLS SR
+-----------------------------+
.
.
Figure 4: DetNet Adaptation to Data Plane
図4：データプレーンへのDetNetの適応
In some networking scenarios, the end system initially provides a DetNet flow encapsulation, which contains all information needed by DetNet nodes (e.g., DetNet flow based on the Real-time Transport Protocol (RTP) [RFC3550] that is carried over a native UDP/IP network or pseudowire (PW)). In other scenarios, the encapsulation formats might differ significantly.
一部のネットワーキングシナリオでは、エンドシステムは最初にDetNetフローカプセル化を提供します。これには、DetNetノードに必要なすべての情報が含まれます（たとえば、ネイティブUDP /を介して伝送されるリアルタイムトランスポートプロトコル（RTP）[RFC3550に基づくDetNetフロー] IPネットワークまたは疑似配線（PW））。他のシナリオでは、カプセル化形式が大幅に異なる場合があります。
There are many valid options to create a data-plane solution for DetNet traffic by selecting a technology approach for the DetNet service sub-layer and also selecting a technology approach for the DetNet forwarding sub-layer. There are a large number of valid combinations.
DetNetサービスサブレイヤーのテクノロジーアプローチを選択し、DetNetフォワーディングサブレイヤーのテクノロジーアプローチを選択することで、DetNetトラフィックのデータプレーンソリューションを作成するための有効なオプションは多数あります。有効な組み合わせは多数あります。
One of the most fundamental differences between different potential data-plane options is the basic headers used by DetNet nodes. For example, the basic service can be delivered based on an MPLS label or an IP header. This decision impacts the basic forwarding logic for the DetNet service sub-layer. Note that in both cases, IP addresses are used to address DetNet nodes. The selected DetNet forwarding sub-layer technology also needs to be mapped to the subnet technology used to interconnect DetNet nodes. For example, DetNet flows will need to be mapped to TSN Streams.
さまざまな潜在的なデータプレーンオプション間の最も基本的な違いの1つは、DetNetノードで使用される基本的なヘッダーです。たとえば、基本的なサービスは、MPLSラベルまたはIPヘッダーに基づいて配信できます。この決定は、DetNetサービスサブレイヤーの基本的な転送ロジックに影響を与えます。どちらの場合も、IPアドレスはDetNetノードのアドレス指定に使用されることに注意してください。選択したDetNet転送サブレイヤーテクノロジーは、DetNetノードの相互接続に使用されるサブネットテクノロジーにもマップする必要があります。たとえば、DetNetフローはTSNストリームにマップする必要があります。
Figure 5 shows another view of the DetNet service-related reference points and main components.
図5は、DetNetサービス関連の参照ポイントと主要コンポーネントの別のビューを示しています。
DetNet DetNet
End System End System
_ _
/ \ +----DetNet-UNI (U) / \
/App\ | /App\
/-----\ | /-----\
| NIC | v ________ | NIC |
+--+--+ _____ / \ DetNet-UNI (U) --+ +--+--+
| / \__/ \ | |
| / +----+ +----+ \_____ | |
| / | | | | \_______ | |
+------U PE +----+ P +----+ \ _ v |
| | | | | | | ___/ \ |
| +--+-+ +----+ | +----+ | / \_ |
\ | | | | | / \ |
\ | +----+ +--+-+ +--+PE |------ U-----+
\ | | | | | | | | | \_ _/
\ +---+ P +----+ P +--+ +----+ | \____/
\___ | | | | /
\ +----+__ +----+ DetNet-1 DetNet-2
| \_____/ \___________/ |
| |
| | End-to-End Service | | | |
<------------------------------------------------------------->
| | DetNet Service | | | |
| <------------------------------------------------> |
| | | | | |
Figure 5: DetNet Service Reference Model (Multidomain)
図5：DetNetサービス参照モデル（マルチドメイン）
DetNet User-to-Network Interfaces (DetNet-UNIs) ("U" in Figure 5) are assumed in this document to be packet-based reference points and provide connectivity over the packet network. A DetNet-UNI may provide multiple functions. For example, it may:
このドキュメントでは、DetNetユーザーネットワークインターフェイス（DetNet-UNI）（図5の「U」）は、パケットベースの参照ポイントであり、パケットネットワーク経由の接続を提供するものと想定しています。 DetNet-UNIは複数の機能を提供する場合があります。たとえば、次のような場合があります。
* add encapsulation specific to networking technology to the DetNet flows if necessary,
* 必要に応じて、ネットワーキングテクノロジー固有のカプセル化をDetNetフローに追加します。
* provide status of the availability of the resources associated with a reservation,
* 予約に関連付けられているリソースの可用性のステータスを提供する、
* provide a synchronization service for the end system, or
* エンドシステムに同期サービスを提供する、または
* carry enough signaling to place the reservation in a network without a controller or in a network where the controller only deals with the network but not the end systems.
* コントローラのないネットワーク、またはコントローラがエンドシステムではなくネットワークのみを処理するネットワークで予約を行うのに十分な信号を伝送します。
Internal reference points of end systems (between the application and the Network Interface Card (NIC)) are more challenging from the control perspective, and they may have extra requirements (e.g., in-order delivery is expected in end system internal reference points, whereas it is considered optional over the DetNet-UNI).
エンドシステムの内部参照ポイント（アプリケーションとネットワークインターフェイスカード（NIC）の間）は、制御の観点から見るとより困難であり、追加の要件がある場合があります（たとえば、エンドシステムの内部参照ポイントでは順序どおりの配信が期待されますが、 DetNet-UNIよりもオプションと見なされます）。
The traffic characteristics of an App-flow can be CBR (constant bit rate) or VBR (variable bit rate) and can have Layer 1, Layer 2, or Layer 3 encapsulation (e.g., TDM (time-division multiplexing) Ethernet, IP). These characteristics are considered as input for resource reservation and might be simplified to ensure determinism during packet forwarding (e.g., making reservations for the peak rate of VBR traffic, etc.).
App-flowのトラフィック特性は、CBR（固定ビットレート）またはVBR（可変ビットレート）で、レイヤー1、レイヤー2、またはレイヤー3カプセル化（TDM（時分割多重）イーサネット、IPなど）を持つことができます。 。これらの特性はリソース予約の入力と見なされ、パケット転送中の確定性を確保するために簡略化される場合があります（VBRトラフィックのピークレートの予約など）。
An end system may or may not be aware of the DetNet forwarding sub-layer or DetNet service sub-layer. That is, an end system may or may not contain DetNet-specific functionality. End systems with DetNet functionalities may have the same or different forwarding sub-layer as the connected DetNet domain. Categorization of end systems are shown in Figure 6.
エンドシステムは、DetNet転送サブレイヤまたはDetNetサービスサブレイヤを認識している場合と認識していない場合があります。つまり、エンドシステムには、DetNet固有の機能が含まれる場合と含まれない場合があります。 DetNet機能を備えたエンドシステムは、接続されているDetNetドメインと同じまたは異なる転送サブレイヤを持っている場合があります。エンドシステムの分類を図6に示します。
End system
|
|
| DetNet aware ?
/ \
+------< >------+
NO | \ / | YES
| v |
DetNet-unaware |
End system |
| Service/Forwarding
| sub-layer
/ \ aware ?
+--------< >-------------+
f-aware | \ / | s-aware
| v |
| | both |
| | |
DetNet f-aware | DetNet s-aware
End system | End system
v
DetNet sf-aware
End system
Figure 6: Categorization of End Systems
図6：エンドシステムの分類
The following are some known use case examples for end systems:
以下は、エンドシステムのいくつかの既知の使用例です。
DetNet unaware The classic case requiring service proxies.
DetNetを知らないサービスプロキシを必要とする古典的なケース。
DetNet f-aware A system that is aware of the DetNet forwarding sub-layer. It knows about some TSN functions (e.g., reservation) but not about service protection.
DetNet f-aware DetNet転送サブレイヤーを認識するシステム。一部のTSN機能（予約など）は認識していますが、サービス保護は認識していません。
DetNet s-aware A system that is aware of the DetNet service sub-layer. It supplies sequence numbers but doesn't know about resource allocation.
DetNet s-aware DetNetサービスサブレイヤーを認識するシステム。シーケンス番号を提供しますが、リソースの割り当てについては知りません。
DetNet sf-aware A fully functioning DetNet end system. It has DetNet functionalities and usually the same forwarding paradigm as the connected DetNet domain. It can be treated as an integral part of the DetNet domain.
DetNet sf-aware完全に機能するDetNetエンドシステム。これにはDetNet機能があり、通常は接続されているDetNetドメインと同じ転送パラダイムを持っています。これは、DetNetドメインの不可欠な部分として扱うことができます。
As shown in Figure 3, DetNet edge nodes providing proxy service and DetNet relay nodes providing the DetNet service sub-layer are DetNet aware, and DetNet transit nodes need only be aware of the DetNet forwarding sub-layer.
図3に示すように、プロキシサービスを提供するDetNetエッジノードと、DetNetサービスサブレイヤーを提供するDetNetリレーノードは、DetNet対応であり、DetNetトランジットノードは、DetNet転送サブレイヤーのみを認識する必要があります。
In general, if a DetNet flow passes through one or more DetNet-unaware network nodes between two DetNet nodes providing the DetNet forwarding sub-layer for that flow, there is a potential for disruption or failure of the DetNet QoS. A network administrator needs to 1) ensure that the DetNet-unaware network nodes are configured to minimize the chances of packet loss and delay and 2) provision enough extra buffer space in the DetNet transit node following the DetNet-unaware network nodes to absorb the induced latency variations.
一般に、DetNetフローがそのフローにDetNet転送サブレイヤーを提供する2つのDetNetノード間の1つ以上のDetNet非対応ネットワークノードを通過する場合、DetNet QoSが中断または失敗する可能性があります。ネットワーク管理者は、1）パケット損失と遅延の可能性を最小限に抑えるようにDetNet非対応ネットワークノードが構成されていることを確認し、2）DetNet非対応ネットワークノードに続くDetNetトランジットノードに、誘導されたノードを吸収するのに十分な追加のバッファスペースをプロビジョニングする必要があります。レイテンシの変動。
A DetNet flow can have different formats while its packets are forwarded between the peer end systems depending on the type of the end systems. Corresponding to the end system types, the following possible types/formats of a DetNet flow are distinguished in this document. The different flow types have different requirements to DetNet nodes.
パケットがピアエンドシステム間で転送される間、DetNetフローはエンドシステムのタイプに応じて異なるフォーマットを持つことができます。このドキュメントでは、エンドシステムのタイプに対応して、DetNetフローの以下の可能なタイプ/フォーマットが区別されます。フロータイプが異なると、DetNetノードに対する要件も異なります。
App-flow The payload (data) carried over a DetNet flow between DetNet-unaware end systems. An App-flow does not contain any DetNet-related attributes and does not imply any specific requirement on DetNet nodes.
App-flow DetNet非対応エンドシステム間でDetNetフローを介して伝送されるペイロード（データ）。 App-flowにはDetNet関連の属性が含まれておらず、DetNetノードの特定の要件を意味するものではありません。
DetNet-f-flow The specific format of a DetNet flow. It only requires the resource allocation features provided by the DetNet forwarding sub-layer.
DetNet-f-flow DetNetフローの特定の形式。 DetNet転送サブレイヤによって提供されるリソース割り当て機能のみが必要です。
DetNet-s-flow The specific format of a DetNet flow. It only requires the service protection feature ensured by the DetNet service sub-layer.
DetNet-s-flow DetNetフローの特定の形式。 DetNetサービスサブレイヤーによって保証されるサービス保護機能のみが必要です。
DetNet-sf-flow The specific format of a DetNet flow. It requires both the DetNet service sub-layer and the DetNet forwarding sub-layer functions during forwarding.
DetNet-sf-flow DetNetフローの特定の形式。転送時には、DetNetサービスサブレイヤーとDetNet転送サブレイヤーの両方の機能が必要です。
For the purposes of resource allocation, DetNet flows can be synchronous or asynchronous. In synchronous DetNet flows, at least the DetNet nodes (and possibly the end systems) are closely time synchronized, typically to better than 1 microsecond. By transmitting packets from different DetNet flows or classes of DetNet flows at different times, using repeating schedules synchronized among the DetNet nodes, resources such as buffers and link bandwidth can be shared over the time domain among different DetNet flows. There is a trade-off among techniques for synchronous DetNet flows between the burden of fine-grained scheduling and the benefit of reducing the required resources, especially buffer space.
リソース割り当ての目的で、DetNetフローは同期または非同期にすることができます。同期DetNetフローでは、少なくともDetNetノード（および場合によってはエンドシステム）が厳密に時間同期され、通常は1マイクロ秒を超えます。異なるDetNetフローまたはDetNetフローのクラスからのパケットを異なる時間に送信し、DetNetノード間で同期された繰り返しスケジュールを使用して、バッファーやリンク帯域幅などのリソースを異なるDetNetフロー間で時間領域で共有できます。同期DetNetフローの技法には、きめの細かいスケジューリングの負担と、必要なリソース、特にバッファスペースを削減する利点の間でトレードオフがあります。
In contrast, asynchronous DetNet flows are not coordinated with a fine-grained schedule, so relay and end systems must assume worst-case interference among DetNet flows contending for buffer resources. Asynchronous DetNet flows are characterized by:
対照的に、非同期のDetNetフローはきめ細かなスケジュールで調整されないため、リレーおよびエンドシステムは、バッファリソースをめぐって競合するDetNetフロー間の最悪の場合の干渉を想定する必要があります。非同期のDetNetフローの特徴は次のとおりです。
* A maximum packet size;
* 最大パケットサイズ。
* An observation interval; and
* 観測間隔。そして
* A maximum number of transmissions during that observation interval.
* その観測間隔中の送信の最大数。
These parameters, together with knowledge of the protocol stack used (and thus the size of the various headers added to a packet), provide the bandwidth that is needed for the DetNet flow.
これらのパラメーターは、使用されるプロトコルスタックの知識（およびパケットに追加されるさまざまなヘッダーのサイズ）とともに、DetNetフローに必要な帯域幅を提供します。
The source is required not to exceed these limits in order to obtain DetNet service. If the source transmits less data than this limit allows, then the unused resource, such as link bandwidth, can be made available by the DetNet system to non-DetNet packets as long as all guarantees are fulfilled. However, making those resources available to DetNet packets in other DetNet flows would serve no purpose. Those other DetNet flows have their own dedicated resources, on the assumption that all DetNet flows can use all of their resources over a long period of time.
DetNetサービスを受けるには、ソースがこれらの制限を超えないようにする必要があります。ソースがこの制限で許可されているよりも少ないデータを送信する場合、リンク帯域幅などの未使用のリソースは、すべての保証が満たされている限り、DetNetシステムで非DetNetパケットに利用できます。ただし、これらのリソースを他のDetNetフローのDetNetパケットで使用できるようにしても、意味がありません。すべての他のDetNetフローは長期間にわたってすべてのリソースを使用できるという前提で、これらの他のDetNetフローには専用のリソースがあります。
There is no expectation in DetNet for App-flows to be responsive to congestion control [RFC2914] or explicit congestion notification [RFC3168]. The assumption is that a DetNet flow, to be useful, must be delivered in its entirety. That is, while any useful application is written to expect a certain number of lost packets, the real-time applications of interest to DetNet demand that the loss of data due to the network is a rare event.
App-flowが輻輳制御[RFC2914]または明示的な輻輳通知[RFC3168]に応答することは、DetNetでは期待されていません。 DetNetフローは、有用であるためには、全体を配信する必要があると想定しています。つまり、有用なアプリケーションは特定の数のパケット損失を予測するように作成されていますが、DetNetに関係するリアルタイムアプリケーションは、ネットワークによるデータの損失がまれなイベントであることを要求しています。
Although DetNet strives to minimize the changes required of an application to allow it to shift from a special-purpose digital network to an Internet Protocol network, one fundamental shift in the behavior of network applications is impossible to avoid: the reservation of resources before the application starts. In the first place, a network cannot deliver finite latency and practically zero packet loss to an arbitrarily high offered load. Secondly, achieving practically zero packet loss for DetNet flows means that DetNet nodes have to dedicate buffer resources to specific DetNet flows or to classes of DetNet flows. The requirements of each reservation have to be translated into the parameters that control each DetNet system's queuing, shaping, and scheduling functions, and they have to be delivered to the DetNet nodes and end systems.
DetNetは、アプリケーションが必要とする変更を最小限に抑えて専用デジタルネットワークからインターネットプロトコルネットワークに移行できるように努めていますが、ネットワークアプリケーションの動作の根本的な変化の1つは回避できません。アプリケーションの前にリソースを予約することです。開始します。そもそも、ネットワークは有限のレイテンシを提供できず、提供された任意の負荷に対してパケット損失を実質的にゼロにすることができません。第2に、DetNetフローのパケット損失が実質的にゼロになることは、DetNetノードが特定のDetNetフローまたはDetNetフローのクラスにバッファリソースを割り当てる必要があることを意味します。各予約の要件は、各DetNetシステムのキューイング、シェーピング、およびスケジューリング機能を制御するパラメーターに変換する必要があり、DetNetノードおよびエンドシステムに配信する必要があります。
All nodes in a DetNet domain are expected to support the data behavior required to deliver a particular DetNet service. If a node itself is not DetNet service aware, the DetNet nodes that are adjacent to them must ensure that the node that is non-DetNet aware is provisioned to appropriately support the DetNet service. For example, a TSN node (as defined by IEEE 802.1) may be used to interconnect DetNet-aware nodes, and these DetNet nodes can map DetNet flows to 802.1 TSN flows. As another example, an MPLS-TE or MPLS-TP (Transport Profile) domain may be used to interconnect DetNet-aware nodes, and these DetNet nodes can map DetNet flows to TE LSPs, which can provide the QoS requirements of the DetNet service.
DetNetドメイン内のすべてのノードは、特定のDetNetサービスを提供するために必要なデータ動作をサポートすることが期待されています。ノード自体がDetNetサービスに対応していない場合、それらに隣接するDetNetノードは、DetNet非対応のノードがDetNetサービスを適切にサポートするようにプロビジョニングされていることを確認する必要があります。たとえば、（IEEE 802.1で定義されている）TSNノードを使用して、DetNet対応ノードを相互接続できます。これらのDetNetノードは、DetNetフローを802.1 TSNフローにマップできます。別の例として、MPLS-TEまたはMPLS-TP（トランスポートプロファイル）ドメインは、DetNet対応ノードを相互接続するために使用でき、これらのDetNetノードは、DetNetフローをTE LSPにマッピングでき、DetNetサービスのQoS要件を提供できます。
The presence in the network of intermediate nodes or subnets that are not fully capable of offering DetNet services complicates the ability of the intermediate nodes and/or controller to allocate resources, as extra buffering must be allocated at points downstream from the non-DetNet intermediate node for a DetNet flow. This extra buffering may increase latency and/or jitter.
DetNetサービスを完全に提供できない中間ノードまたはサブネットのネットワーク内に存在すると、中間ノードやコントローラーがリソースを割り当てる機能が複雑になります。非DetNet中間ノードの下流に追加のバッファーを割り当てる必要があるためです。 DetNetフローの場合。この追加のバッファリングにより、待ち時間やジッターが増加する可能性があります。
Traffic Engineering Architecture and Signaling (TEAS) [TEAS] defines traffic-engineering architectures for generic applicability across packet and nonpacket networks. From a TEAS perspective, Traffic Engineering (TE) refers to techniques that enable operators to control how specific traffic flows are treated within their networks.
トラフィックエンジニアリングアーキテクチャおよびシグナリング（TEAS）[TEAS]は、パケットおよび非パケットネットワーク全体での一般的な適用性のためのトラフィックエンジニアリングアーキテクチャを定義します。 TEASの観点から、トラフィックエンジニアリング（TE）とは、オペレーターがネットワーク内で特定のトラフィックフローを処理する方法を制御できるようにする技術を指します。
Because of its very nature of establishing explicit optimized paths, DetNet can be seen as a new, specialized branch of TE, and it inherits its architecture with a separation into planes.
明示的に最適化されたパスを確立するという性質上、DetNetはTEの新しい特殊なブランチと見なすことができ、プレーンに分離されたアーキテクチャを継承します。
The DetNet architecture is thus composed of three planes: a (User) Application Plane, a Controller Plane, and a Network Plane. This echoes the composition of Figure 1 of "Software-Defined Networking (SDN): Layers and Architecture Terminology" [RFC7426] and the controllers identified in [RFC8453] and [RFC7149].
したがって、DetNetアーキテクチャは、（ユーザー）アプリケーションプレーン、コントローラプレーン、およびネットワークプレーンの3つのプレーンで構成されます。これは、「Software-Defined Networking（SDN）：Layers and Architecture Terminology」[RFC7426]の図1の構成と、[RFC8453]と[RFC7149]で識別されるコントローラーを反映しています。
Per [RFC7426], the Application Plane includes both applications and services. In particular, the Application Plane incorporates the User Agent, a specialized application that interacts with the end user and operator and performs requests for DetNet services via an abstract Flow Management Entity (FME), which may or may not be collocated with (one of) the end systems.
[RFC7426]によると、アプリケーションプレーンにはアプリケーションとサービスの両方が含まれています。特に、アプリケーションプレーンにはユーザーエージェントが組み込まれています。これは、エンドユーザーおよびオペレーターとやり取りし、（いずれか）と同じ場所にあるかどうかに関係なく、抽象的なフロー管理エンティティ（FME）を介してDetNetサービスの要求を実行します。エンドシステム。
At the Application Plane, a management interface enables the negotiation of flows between end systems. An abstraction of the flow called a Traffic Specification (TSpec) provides the representation. This abstraction is used to place a reservation over the (Northbound) Service Interface and within the Application Plane. It is associated with an abstraction of location, such as IP addresses and DNS names, to identify the end systems and possibly specify DetNet nodes.
アプリケーションプレーンでは、管理インターフェイスによってエンドシステム間のフローのネゴシエーションが可能になります。トラフィック仕様（TSpec）と呼ばれるフローの抽象化が表現を提供します。この抽象化は、（ノースバウンド）サービスインターフェース上およびアプリケーションプレーン内で予約を行うために使用されます。これは、IPアドレスやDNS名などの場所の抽象化に関連付けられており、エンドシステムを識別し、場合によってはDetNetノードを指定します。
The Controller Plane corresponds to the aggregation of the Control and Management Planes in [RFC7426], though Common Control and Measurement Plane (CCAMP) (as defined by the CCAMP Working Group [CCAMP]) makes an additional distinction between management and measurement. When the logical separation of the Control, Measurement, and other Management entities is not relevant, the term "Controller Plane" is used for simplicity to represent them all, and the term "Controller Plane Function (CPF)" refers to any device operating in that plane, whether it is a Path Computation Element (PCE) [RFC4655], a Network Management Entity (NME), or a distributed control protocol. The CPF is a core element of a controller, in charge of computing deterministic paths to be applied in the Network Plane.
コントローラプレーンは[RFC7426]の制御プレーンと管理プレーンの集約に対応しますが、共通制御および測定プレーン（CCAMP）（CCAMPワーキンググループ[CCAMP]で定義）は、管理と測定をさらに区別します。制御、測定、およびその他の管理エンティティの論理的な分離が関係ない場合、用語「コントローラプレーン」は、それらすべてを簡単に表すために使用され、「コントローラプレーン機能（CPF）」という用語は、その平面、それがパス計算要素（PCE）[RFC4655]、ネットワーク管理エンティティ（NME）、または分散制御プロトコルであるかどうか。 CPFはコントローラーのコアエレメントであり、ネットワークプレーンで適用される確定的パスの計算を担当します。
A (Northbound) Service Interface enables applications in the Application Plane to communicate with the entities in the Controller Plane as illustrated in Figure 7.
図7に示すように、（ノースバウンド）サービスインターフェイスを使用すると、アプリケーションプレーンのアプリケーションがコントローラープレーンのエンティティと通信できます。
One or more CPFs collaborate to implement the requests from the FME as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. The CPFs place each flow along a deterministic arrangement of DetNet nodes so as to respect per-flow constraints such as security and latency, and to optimize the overall result for metrics such as an abstract aggregated cost. The deterministic arrangement can typically be more complex than a direct arrangement and include redundant paths with one or more packet replication and elimination points. Scaling to larger networks is discussed in Section 4.9.
1つ以上のCPFが連携して、FMEからの要求をフローごと、ホップごとの動作として実装し、個々のフローごとにDetNetノードにインストールします。 CPFは、セキュリティやレイテンシなどのフローごとの制約を尊重し、抽象的な集計コストなどのメトリックの全体的な結果を最適化するように、DetNetノードの確定的な配置に沿って各フローを配置します。確定的配置は、通常、直接配置よりも複雑であり、1つ以上のパケット複製および除去ポイントを持つ冗長パスを含むことができます。より大きなネットワークへのスケーリングについては、セクション4.9で説明します。
The Network Plane represents the network devices and protocols as a whole, regardless of the layer at which the network devices operate. It includes the Data Plane and Operational Plane (e.g., OAM) aspects.
ネットワークプレーンは、ネットワークデバイスが動作するレイヤーに関係なく、ネットワークデバイスとプロトコル全体を表します。これには、データプレーンと運用プレーン（OAMなど）の側面が含まれます。
The Network Plane comprises the Network Interface Cards (NICs) in the end systems, which are typically IP hosts, and DetNet nodes, which are typically IP routers and MPLS switches.
ネットワークプレーンは、通常はIPホストであるエンドシステムのネットワークインターフェイスカード（NIC）と、通常はIPルーターおよびMPLSスイッチであるDetNetノードで構成されます。
A Southbound (Network) Interface enables the entities in the Controller Plane to communicate with devices in the Network Plane as illustrated in Figure 7. This interface leverages and extends TEAS to describe the physical topology and resources in the Network Plane.
サウスバウンド（ネットワーク）インターフェイスを使用すると、図7に示すように、コントローラープレーンのエンティティがネットワークプレーンのデバイスと通信できます。このインターフェイスは、TEASを活用および拡張して、ネットワークプレーンの物理トポロジとリソースを記述します。
End End System System
エンドエンドシステムシステム
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
CPF CPF CPF CPF
CPF CPF CPF CPF
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
DetNet DetNet DetNet DetNet Node Node Node Node NIC NIC DetNet DetNet DetNet DetNet Node Node Node Node
でｔねｔ でｔねｔ でｔねｔ でｔねｔ ので ので ので ので にＣ にＣ でｔねｔ でｔねｔ でｔねｔ でｔねｔ ので ので ので ので
Figure 7: Northbound and Southbound Interfaces
図7：ノースバウンドとサウスバウンドのインターフェース
The DetNet nodes (and possibly the end systems' NICs) expose their capabilities and physical resources to the controller (the CPF) and update the CPFs with their dynamic perception of the topology across the Southbound Interface. In return, the CPFs set the per-flow paths up, providing a Flow Characterization that is more tightly coupled to the DetNet node operation than a TSpec.
DetNetノード（および場合によってはエンドシステムのNIC）は、それらの機能と物理リソースをコントローラー（CPF）に公開し、サウスバウンドインターフェイス全体のトポロジーの動的認識でCPFを更新します。代わりに、CPFはフローごとのパスを設定し、TSpecよりもDetNetノードの操作により密接に結合されたフローの特性を提供します。
At the Network Plane, DetNet nodes may exchange information regarding the state of the paths, between adjacent DetNet nodes and possibly with the end systems, and forward packets within constraints associated to each flow, or, when unable to do so, perform a last-resort operation such as drop or declassify.
ネットワークプレーンでは、DetNetノードは、隣接するDetNetノード間で、場合によってはエンドシステムとの間でパスの状態に関する情報を交換し、各フローに関連付けられた制約内でパケットを転送するか、そうできない場合は最後のドロップや機密解除などのリゾート操作。
This document focuses on the Southbound interface and the operation of the Network Plane.
このドキュメントでは、サウスバウンドインターフェイスとネットワークプレーンの操作に焦点を当てています。
DetNet achieves bounded delivery latency by reserving bandwidth and buffer resources at each DetNet node along the path of the DetNet flow. The reservation itself is not sufficient, however. Implementors and users of a number of proprietary and standard real-time networks have found that standards for specific data-plane techniques are required to enable these assurances to be made in a multivendor network. The fundamental reason is that latency variation in one DetNet system results in the need for extra buffer space in the next-hop DetNet system(s), which in turn increases the worst-case per-hop latency.
DetNetは、DetNetフローのパスに沿った各DetNetノードで帯域幅とバッファリソースを予約することにより、制限された配信レイテンシを実現します。ただし、予約自体では不十分です。多数の独自仕様および標準のリアルタイムネットワークの実装者とユーザーは、これらの保証をマルチベンダーネットワークで作成できるようにするには、特定のデータプレーン技術の標準が必要であることを発見しました。基本的な理由は、1つのDetNetシステムでレイテンシが変動すると、ネクストホップのDetNetシステムで追加のバッファスペースが必要になるため、最悪の場合のホップごとのレイテンシが増加するためです。
Standard queuing and transmission-selection algorithms allow TE (Section 4.4) to compute the latency contribution of each DetNet node to the end-to-end latency, to compute the amount of buffer space required in each DetNet node for each incremental DetNet flow, and most importantly, to translate from a flow specification to a set of values for the managed objects that control each relay or end system. For example, the IEEE 802.1 WG has specified (and is specifying) a set of queuing, shaping, and scheduling algorithms that enable each DetNet node, and/or a central controller, to compute these values. These algorithms include:
標準のキューイングおよび伝送選択アルゴリズムにより、TE（4.4節）は、エンドツーエンドレイテンシに対する各DetNetノードのレイテンシの寄与を計算し、各DetNetノードで必要なバッファスペースの量を各増分DetNetフローに対して計算し、最も重要なことは、フロー仕様から、各リレーまたはエンドシステムを制御する管理対象オブジェクトの値のセットに変換することです。たとえば、IEEE 802.1 WGは、各DetNetノードや中央コントローラーがこれらの値を計算できるようにする一連のキューイング、シェーピング、およびスケジューリングアルゴリズムを指定しています（指定しています）。これらのアルゴリズムは次のとおりです。
* A credit-based shaper [IEEE802.1Qav] (incorporated to [IEEE802.1Q]).
* クレジットベースのシェーパー[IEEE802.1Qav]（[IEEE802.1Q]に組み込まれています）。
* Time-gated queues governed by a rotating time schedule based on synchronized time [IEEE802.1Qbv] (incorporated to [IEEE802.1Q]).
* 同期された時間[IEEE802.1Qbv]（[IEEE802.1Q]に組み込まれている）に基づくローテーションタイムスケジュールによって管理されるタイムゲーティングキュー。
* Synchronized double (or triple) buffers driven by synchronized time ticks. [IEEE802.1Qch] (incorporated to [IEEE802.1Q]).
* 同期された時間ティックによって駆動される同期されたダブル（またはトリプル）バッファー。 [IEEE802.1Qch]（[IEEE802.1Q]に組み込まれています）。
* Preemption of an Ethernet packet in transmission by a packet with a more stringent latency requirement, followed by the resumption of the preempted packet [IEEE802.1Qbu] (incorporated to [IEEE802.1Q]) [IEEE802.3br] (incorporated to [IEEE802.3]).
* より厳しいレイテンシ要件を持つパケットによる送信中のイーサネットパケットのプリエンプション、それに続くプリエンプトされたパケットの再開[IEEE802.1Qbu]（[IEEE802.1Q]に組み込まれている）[IEEE802.3br]（[IEEE802。 3]）。
While these techniques are currently embedded in Ethernet [IEEE802.3] and bridging standards, we can note that they are all, except perhaps for packet preemption, equally applicable to media other than Ethernet and to routers as well as bridges. Other media may have their own methods (see, e.g., [TSCH-ARCH] and [RFC7554]). Further techniques are defined by the IETF (e.g., [RFC8289] and [RFC8033]). DetNet may include such definitions in the future or may define how these techniques can be used by DetNet nodes.
これらの技術は現在イーサネット[IEEE802.3]とブリッジング標準に組み込まれていますが、パケットプリエンプションを除いて、イーサネット以外のメディアやルーターやブリッジにも同様に適用できることに注意してください。他のメディアには独自の方法がある場合があります（たとえば、[TSCH-ARCH]と[RFC7554]を参照）。 IETFにより、その他の手法が定義されています（[RFC8289]および[RFC8033]など）。 DetNetは、将来的にそのような定義を含めるか、DetNetノードがこれらの技術をどのように使用できるかを定義する可能性があります。
A service instance represents all the functions required on a DetNet node to allow the end-to-end service between the UNIs.
サービスインスタンスは、UNIT間のエンドツーエンドサービスを可能にするためにDetNetノードで必要なすべての機能を表します。
The DetNet network general reference model is shown in Figure 8 for a DetNet service scenario (i.e., between two DetNet-UNIs). In this figure, end systems ("A" and "B") are connected directly to the edge nodes of an IP/MPLS network ("PE1" and "PE2"). End systems participating in DetNet communication may require connectivity before setting up an App-flow that requires the DetNet service. Such a connectivity-related service instance and the one dedicated for DetNet service share the same access. Packets belonging to a DetNet flow are selected by a filter configured on the access ("F1" and "F2"). As a result, data-flow-specific access ("access-A + F1" and "access-B + F2") is terminated in the flow-specific service instance ("SI-1" and "SI-2"). A tunnel is used to provide connectivity between the service instances.
DetNetネットワークの一般的な参照モデルを、DetNetサービスシナリオ（2つのDetNet-UNI間）について図8に示します。この図では、エンドシステム（「A」と「B」）は、IP / MPLSネットワーク（「PE1」と「PE2」）のエッジノードに直接接続されています。 DetNet通信に参加しているエンドシステムは、DetNetサービスを必要とするApp-flowを設定する前に接続を必要とする場合があります。このような接続関連のサービスインスタンスとDetNetサービス専用のサービスインスタンスは、同じアクセスを共有します。 DetNetフローに属するパケットは、アクセスで構成されたフィルター（「F1」および「F2」）によって選択されます。その結果、データフロー固有のアクセス（「access-A + F1」および「access-B + F2」）は、フロー固有のサービスインスタンス（「SI-1」および「SI-2」）で終了します。トンネルは、サービスインスタンス間の接続を提供するために使用されます。
The tunnel is exclusively used for the packets of the DetNet flow between "SI-1" and "SI-2". The service instances are configured to implement DetNet functions and a flow-specific DetNet forwarding. The service instance and the tunnel may or may not be shared by multiple DetNet flows. Sharing the service instance by multiple DetNet flows requires properly populated forwarding tables of the service instance.
トンネルは、「SI-1」と「SI-2」の間のDetNetフローのパケットにのみ使用されます。サービスインスタンスは、DetNet機能とフロー固有のDetNet転送を実装するように構成されます。サービスインスタンスとトンネルは、複数のDetNetフローで共有される場合とされない場合があります。複数のDetNetフローでサービスインスタンスを共有するには、サービスインスタンスの転送テーブルを適切に設定する必要があります。
access-A access-B
<-----> <-------- tunnel ----------> <----->
+---------+ ___ _ +---------+
End system | +----+ | / \/ \_ | +----+ | End system
"A" -------F1+ | | / \ | | +F2----- "B"
| | +========+ IP/MPLS +=======+ | |
| |SI-1| | \__ Net._/ | |SI-2| |
| +----+ | \____/ | +----+ |
|PE1 | | PE2|
+---------+ +---------+
Figure 8: DetNet Network General Reference Model
図8：DetNetネットワークの一般的な参照モデル
The tunnel between the service instances may have some special characteristics. For example, in case of a DetNet L3 service, there are differences in the usage of the PW for DetNet traffic compared to the network model described in [RFC6658]. In the DetNet scenario, the PW is likely to be used exclusively by the DetNet flow, whereas [RFC6658] states:
サービスインスタンス間のトンネルには、いくつかの特別な特性があります。たとえば、DetNet L3サービスの場合、[RFC6658]で説明されているネットワークモデルと比較して、DetNetトラフィックのPWの使用法が異なります。 DetNetシナリオでは、PWはDetNetフローによって排他的に使用される可能性がありますが、[RFC6658]は次のように述べています。
| The packet PW appears as a single point-to-point link to the
| client layer. Network-layer adjacency formation and maintenance
| between the client equipments will follow the normal practice
| needed to support the required relationship in the client layer.
and
そして
| This packet pseudowire is used to transport all of the required | layer 2 and layer 3 protocols between LSR1 and LSR2.
|このパケット疑似配線は、必要なすべてのパケットを転送するために使用されます。 LSR1とLSR2間のレイヤー2およびレイヤー3プロトコル。
Further details are network technology specific and can be found in [DETNET-FRAMEWORK].
詳細はネットワークテクノロジー固有であり、[DETNET-FRAMEWORK]にあります。
This section discusses what needs to be done at technology borders including Ethernet as one of the technologies. Flow identification for MPLS and IP Data Planes are described in [DETNET-MPLS] and [DETNET-IP], respectively.
このセクションでは、テクノロジーの1つとしてイーサネットを含むテクノロジーの境界で何をする必要があるかについて説明します。 MPLSおよびIPデータプレーンのフロー識別は、それぞれ[DETNET-MPLS]および[DETNET-IP]で説明されています。
A DetNet node may need to map specific flows to lower-layer flows (or Streams) in order to provide specific queuing and shaping services for specific flows. For example:
DetNetノードは、特定のフローに特定のキューイングおよびシェーピングサービスを提供するために、特定のフローを下位層のフロー（またはストリーム）にマップする必要がある場合があります。例えば：
* A non-IP, strictly L2 source end system X may be sending multiple flows to the same L2 destination end system Y. Those flows may include DetNet flows with different QoS requirements and may include non-DetNet flows.
* 非IPで厳密にL2のソースエンドシステムXは、同じL2の宛先エンドシステムYに複数のフローを送信している可能性があります。これらのフローには、QoS要件が異なるDetNetフローが含まれ、非DetNetフローが含まれる場合があります。
* A router may be sending any number of flows to another router. Again, those flows may include DetNet flows with different QoS requirements and may include non-DetNet flows.
* ルーターは、任意の数のフローを別のルーターに送信できます。この場合も、これらのフローには、異なるQoS要件を持つDetNetフローが含まれる場合があり、DetNet以外のフローが含まれる場合があります。
* Two routers may be separated by bridges. For these bridges to perform any required per-flow queuing and shaping, they must be able to identify the individual flows.
* 2つのルーターはブリッジで分離されている場合があります。これらのブリッジが必要なフローごとのキューイングとシェーピングを実行するには、個々のフローを識別できる必要があります。
* A Label Edge Router (LER) may have a Label Switched Path (LSP) set up for handling traffic destined for a particular IP address carrying only non-DetNet flows. If a DetNet flow to that same address is requested, a separate LSP may be needed in order for all of the Label Switch Routers (LSRs) along the path to the destination to give that flow special queuing and shaping.
* ラベルエッジルーター（LER）には、DetNet以外のフローのみを伝送する特定のIPアドレス宛てのトラフィックを処理するためのラベルスイッチドパス（LSP）が設定されている場合があります。同じアドレスへのDetNetフローが要求された場合、宛先へのパスに沿ったすべてのラベルスイッチルータ（LSR）がそのフローに特別なキューイングとシェーピングを提供するために、別のLSPが必要になる場合があります。
The need for a lower-layer node to be aware of individual higher-layer flows is not unique to DetNet. But, given the endless complexity of layering and relayering over tunnels that is available to network designers, DetNet needs to provide a model for flow identification that is better than packet inspection. That is not to say that packet inspection to Layer 4 or Layer 5 addresses will not be used or the capability standardized; however, there are alternatives.
下位層ノードが個々の上位層フローを認識する必要性は、DetNetに固有のものではありません。しかし、ネットワーク設計者が利用できるトンネルを介した階層化と中継の無限の複雑さを考えると、DetNetは、パケット検査よりも優れたフロー識別のモデルを提供する必要があります。つまり、レイヤ4またはレイヤ5アドレスへのパケット検査が使用されない、または機能が標準化されるわけではありません。ただし、代替手段があります。
A DetNet relay node can connect DetNet flows on different paths using different flow identification methods. For example:
DetNetリレーノードは、異なるフロー識別方法を使用して、異なるパス上のDetNetフローを接続できます。例えば：
* A single unicast DetNet flow passing from router A through a bridged network to router B may be assigned a TSN Stream identifier that is unique within that bridged network. The bridges can then identify the flow without accessing higher-layer headers. Of course, the receiving router must recognize and accept that TSN Stream.
* ルータAからブリッジネットワークを経由してルータBに渡る単一のユニキャストDetNetフローには、そのブリッジネットワーク内で一意のTSNストリーム識別子が割り当てられる場合があります。ブリッジは、上位層のヘッダーにアクセスせずにフローを識別できます。もちろん、受信側ルーターはそのTSNストリームを認識して受け入れる必要があります。
* A DetNet flow passing from LSR A to LSR B may be assigned a different label than that used for other flows to the same IP destination.
* LSR AからLSR Bに渡されるDetNetフローには、同じIP宛先への他のフローに使用されるものとは異なるラベルが割り当てられる場合があります。
In any of the above cases, it is possible that an existing DetNet flow can be an aggregate carrying multiple other DetNet flows (not to be confused with DetNet compound vs. member flows). Of course, this requires that the aggregate DetNet flow be provisioned properly to carry the aggregated flows.
上記のいずれの場合でも、既存のDetNetフローが他の複数のDetNetフローを運ぶ集合体になる可能性があります（DetNet複合フローとメンバーフローと混同しないでください）。もちろん、これには集約されたフローを伝送するために集約されたDetNetフローが適切にプロビジョニングされる必要があります。
Thus, rather than packet inspection, there is the option to export higher-layer information to the lower layer. The requirement to support one or the other method for flow identification (or both) is a complexity that is part of DetNet control models.
したがって、パケット検査ではなく、上位層の情報を下位層にエクスポートするオプションがあります。フロー識別のいずれか（または両方）の方法をサポートするための要件は、DetNet制御モデルの一部である複雑さです。
Forwarding of packets of DetNet flows over multiple technology domains may require that lower layers are aware of specific flows of higher layers. Such an "exporting of flow identification" is needed each time when the forwarding paradigm is changed on the forwarding path (e.g., two LSRs are interconnected by an L2 bridged domain, etc.). The three representative forwarding methods considered for DetNet are:
複数のテクノロジードメインにわたるDetNetフローのパケットの転送では、下位層が上位層の特定のフローを認識する必要がある場合があります。このような「フロー識別のエクスポート」は、転送パスで転送パラダイムが変更されるたびに必要です（たとえば、2つのLSRがL2ブリッジドメインによって相互接続されているなど）。 DetNetで考慮される3つの代表的な転送方法は次のとおりです。
* IP routing
* IPルーティング
* MPLS label switching
* MPLSラベルスイッチング
* Ethernet bridging
* イーサネットブリッジング
A packet with corresponding Flow-IDs is illustrated in Figure 9, which also indicates where each Flow-ID can be added or removed.
対応するFlow-IDを持つパケットを図9に示します。これは、各Flow-IDを追加または削除できる場所も示しています。
add/remove add/remove
Eth Flow-ID IP Flow-ID
| |
v v
+-----------------------------------------------------------+
| | | | |
| Eth | MPLS | IP | Application data |
| | | | |
+-----------------------------------------------------------+
^
|
add/remove
MPLS Flow-ID
Figure 9: Packet with Multiple Flow-IDs
図9：複数のFlow-IDを持つパケット
The additional (domain-specific) Flow-ID can be:
追加の（ドメイン固有の）Flow-IDは次のとおりです。
* created by a domain-specific function or
* ドメイン固有の関数によって作成された、または
* derived from the Flow-ID added to the App-flow.
* App-flowに追加されたFlow-IDから派生。
The Flow-ID must be unique inside a given domain. Note that the Flow-ID added to the App-flow is still present in the packet, but some nodes may lack the function to recognize it; that's why the additional Flow-ID is added.
Flow-IDは、特定のドメイン内で一意である必要があります。 App-flowに追加されたFlow-IDは引き続きパケットに存在しますが、ノードによってはそれを認識する機能がない場合があります。そのため、追加のFlow-IDが追加されます。
IP nodes and MPLS nodes are assumed to be configured to push such an additional (domain-specific) Flow-ID when sending traffic to an Ethernet switch (as shown in the examples below).
IPノードとMPLSノードは、トラフィックをイーサネットスイッチに送信するときに、このような追加の（ドメイン固有の）フローIDをプッシュするように構成されていると想定されます（以下の例に示すように）。
Figure 10 shows a scenario where an IP end system ("IP-A") is connected via two Ethernet switches ("ETH-n") to an IP router ("IP-1").
図10は、IPエンドシステム（「IP-A」）が2つのイーサネットスイッチ（「ETH-n」）を介してIPルーター（「IP-1」）に接続されているシナリオを示しています。
IP domain
<-----------------------------------------------
+======+ +======+
|L3-ID | |L3-ID |
+======+ /\ +-----+ +======+
/ \ Forward as | |
/IP-A\ per ETH-ID |IP-1 | Recognize
Push ------> +-+----+ | +---+-+ <----- ETH-ID
ETH-ID | +----+-----+ |
| v v |
| +-----+ +-----+ |
+------+ | | +---------+
+......+ |ETH-1+----+ETH-2| +======+
.L3-ID . +-----+ +-----+ |L3-ID |
+======+ +......+ +======+
|ETH-ID| .L3-ID . |ETH-ID|
+======+ +======+ +------+
|ETH-ID|
+======+
Ethernet domain
<---------------->
Figure 10: IP Nodes Interconnected by an Ethernet Domain
図10：イーサネットドメインによって相互接続されたIPノード
End system "IP-A" uses the original App-flow-specific ID ("L3-ID"), but as it is connected to an Ethernet domain, it has to push an Ethernet-domain-specific Flow-ID ("ETH-ID") before sending the packet to "ETH-1". Ethernet switch "ETH-1" can recognize the data flow based on the "ETH-ID", and it does forwarding toward "ETH-2". "ETH-2" switches the packet toward the IP router. "IP-1" must be configured to receive the Ethernet Flow-ID-specific multicast flow, but (as it is an L3 node) it decodes the data flow ID based on the "L3-ID" fields of the received packet.
エンドシステム「IP-A」は元のアプリフロー固有のID（「L3-ID」）を使用しますが、イーサネットドメインに接続されているため、イーサネットドメイン固有のフローID（「ETH」をプッシュする必要があります-ID "）パケットを" ETH-1 "に送信する前。イーサネットスイッチ「ETH-1」は「ETH-ID」に基づいてデータフローを認識でき、「ETH-2」への転送を行います。 「ETH-2」は、パケットをIPルーターに向けて切り替えます。 「IP-1」はイーサネットフローID固有のマルチキャストフローを受信するように構成する必要がありますが、（L3ノードであるため）受信したパケットの「L3-ID」フィールドに基づいてデータフローIDをデコードします。
Figure 11 shows a scenario where MPLS domain nodes ("PE-n" and "P-m") are connected via two Ethernet switches ("ETH-n").
図11は、MPLSドメインノード（「PE-n」と「P-m」）が2つのイーサネットスイッチ（「ETH-n」）を介して接続されているシナリオを示しています。
MPLS domain
<----------------------------------------------->
+=======+ +=======+
|MPLS-ID| |MPLS-ID|
+=======+ +-----+ +-----+ +=======+ +-----+
| | Forward as | | | |
|PE-1 | per ETH-ID | P-2 +-----------+ PE-2|
Push -----> +-+---+ | +---+-+ +-----+
ETH-ID | +-----+----+ | \ Recognize
| v v | +-- ETH-ID
| +-----+ +-----+ |
+---+ | | +----+
+.......+ |ETH-1+----+ETH-2| +=======+
.MPLS-ID. +-----+ +-----+ |MPLS-ID|
+=======+ +=======+
|ETH-ID | +.......+ |ETH-ID |
+=======+ .MPLS-ID. +-------+
+=======+
|ETH-ID |
+=======+
Ethernet domain
<---------------->
Figure 11: MPLS Nodes Interconnected by an Ethernet Domain
図11：イーサネットドメインによって相互接続されたMPLSノード
"PE-1" uses the MPLS-specific ID ("MPLS-ID"), but as it is connected to an Ethernet domain, it has to push an Ethernet-domain-specific Flow-ID ("ETH-ID") before sending the packet to "ETH-1". Ethernet switch "ETH-1" can recognize the data flow based on the "ETH-ID", and it does forwarding toward "ETH-2". "ETH-2" switches the packet toward the MPLS node ("P-2"). "P-2" must be configured to receive the Ethernet Flow-ID-specific multicast flow, but (as it is an MPLS node) it decodes the data flow ID based on the "MPLS-ID" fields of the received packet.
「PE-1」はMPLS固有のID（「MPLS-ID」）を使用しますが、イーサネットドメインに接続されているため、イーサネットドメイン固有のフローID（「ETH-ID」）をプッシュする必要があります。パケットを「ETH-1」に送信します。イーサネットスイッチ「ETH-1」は「ETH-ID」に基づいてデータフローを認識でき、「ETH-2」への転送を行います。 「ETH-2」は、パケットをMPLSノード（「P-2」）に向けて切り替えます。 「P-2」はイーサネットフローID固有のマルチキャストフローを受信するように設定する必要がありますが、（MPLSノードであるため）受信したパケットの「MPLS-ID」フィールドに基づいてデータフローIDをデコードします。
One can appreciate from the above example that, when the means used for DetNet flow identification is altered or exported, the means for encoding the sequence number information must similarly be altered or exported.
上記の例から、DetNetフローの識別に使用される手段が変更またはエクスポートされる場合、シーケンス番号情報をエンコードする手段も同様に変更またはエクスポートする必要があることが理解できます。
Provisioning of DetNet requires knowledge about:
DetNetのプロビジョニングには、以下に関する知識が必要です。
* Details of the DetNet system's capabilities that are required in order to accurately allocate that DetNet system's resources, as well as other DetNet systems' resources. This includes, for example, which specific queuing and shaping algorithms are implemented (Section 4.5), the number of buffers dedicated for DetNet allocation, and the worst-case forwarding delay and misordering.
* そのDetNetシステムのリソースと他のDetNetシステムのリソースを正確に割り当てるために必要なDetNetシステムの機能の詳細。これには、たとえば、実装されている特定のキューイングおよびシェーピングアルゴリズム（4.5節）、DetNet割り当て専用のバッファー数、および最悪の場合の転送遅延と順序の誤りが含まれます。
* The actual state of a DetNet node's DetNet resources.
* DetNetノードのDetNetリソースの実際の状態。
* The identity of the DetNet system's neighbors and the characteristics of the link(s) between the DetNet systems, including the latency of the links (in nanoseconds).
* リンクの待ち時間（ナノ秒単位）を含む、DetNetシステムのネイバーのIDと、DetNetシステム間のリンクの特性。
Reservations for individual DetNet flows require considerable state information in each DetNet node, especially when adequate fault mitigation (Section 3.3.2) is required. The DetNet Data Plane, in order to support larger numbers of DetNet flows, must support the aggregation of DetNet flows. Such aggregated flows can be viewed by the DetNet nodes' Data Plane largely as individual DetNet flows. Without such aggregation, the per-relay system may limit the scale of DetNet networks. Example techniques that may be used include MPLS hierarchy and IP DiffServ Code Points (DSCPs).
個々のDetNetフローを予約するには、特に適切な障害軽減（セクション3.3.2）が必要な場合、各DetNetノードでかなりの状態情報が必要です。多数のDetNetフローをサポートするには、DetNetデータプレーンがDetNetフローの集約をサポートする必要があります。そのような集約されたフローは、DetNetノードのデータプレーンによって、主に個別のDetNetフローとして表示できます。そのような集約がなければ、リレーごとのシステムは、DetNetネットワークの規模を制限する可能性があります。使用できるテクニックの例には、MPLS階層とIP DiffServコードポイント（DSCP）が含まれます。
Standards providing similar capabilities for bridged networks (only) have been and are being generated in the IEEE 802 LAN/MAN Standards Committee. The present architecture describes an abstract model that can be applicable both at Layer 2 and Layer 3, and over links not defined by IEEE 802.
ブリッジネットワークにのみ同様の機能を提供する標準（のみ）は、IEEE 802 LAN / MAN標準委員会で作成され、作成されています。現在のアーキテクチャは、レイヤ2とレイヤ3の両方で、またIEEE 802で定義されていないリンクを介して適用できる抽象モデルを記述しています。
DetNet-enabled end systems and DetNet nodes can be interconnected by sub-networks, i.e., Layer 2 technologies. These sub-networks will provide DetNet compatible service for support of DetNet traffic. Examples of sub-network technologies include MPLS TE, TSN as defined by IEEE 802.1, and a point-to-point OTN link. Of course, multilayer DetNet systems may be possible too, where one DetNet appears as a sub-network and provides service to a higher-layer DetNet system.
DetNet対応のエンドシステムとDetNetノードは、サブネットワーク、つまりレイヤー2テクノロジーで相互接続できます。これらのサブネットワークは、DetNetトラフィックをサポートするためのDetNet互換サービスを提供します。サブネットワークテクノロジーの例には、MPLS TE、IEEE 802.1で定義されているTSN、ポイントツーポイントOTNリンクなどがあります。もちろん、1つのDetNetがサブネットワークとして表示され、上位層のDetNetシステムにサービスを提供する多層DetNetシステムも可能です。
Security considerations for DetNet are described in detail in [DETNET-SECURITY]. This section considers exclusively security considerations that are specific to the DetNet architecture.
DetNetのセキュリティに関する考慮事項は、[DETNET-SECURITY]で詳細に説明されています。このセクションでは、DetNetアーキテクチャに固有のセキュリティの考慮事項のみを検討します。
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. A DetNet may be implemented using MPLS and/or IP (including both v4 and v6) technologies and thus inherits the security properties of those technologies at both the Data Plane and the Controller Plane.
DetNetに固有のセキュリティの側面は、DetNetの特定のQoS側面を提供することを目的とするものです。これは、主に非常に低いパケット損失率と限られたエンドツーエンドの配信遅延でデータフローを配信することです。 DetNetはMPLSやIP（v4とv6の両方を含む）テクノロジを使用して実装できるため、データプレーンとコントローラプレーンの両方でこれらのテクノロジのセキュリティプロパティを継承します。
Security considerations for DetNet are constrained (compared to, for example, the open Internet) because DetNet is defined to operate only within a single administrative domain (see Section 1). The primary considerations are to secure the request and control of DetNet resources, maintain confidentiality of data traversing the DetNet, and provide the availability of the DetNet QoS.
DetNetは単一の管理ドメイン内でのみ動作するように定義されているため（セクション1を参照）、DetNetのセキュリティに関する考慮事項は制限されています（たとえば、オープンインターネットと比較して）。主な考慮事項は、DetNetリソースの要求と制御を保護し、DetNetを通過するデータの機密性を維持し、DetNet QoSの可用性を提供することです。
To secure the request and control of DetNet resources, authentication and authorization can be used for each device connected to a DetNet domain, most importantly to network controller devices. Control of a DetNet network may be centralized or distributed (within a single administrative domain). In the case of centralized control, precedent for security considerations as defined for Abstraction and Control of Traffic Engineered Networks (ACTN) can be found in Section 9 of [RFC8453]. In the case of distributed control protocols, DetNet security is expected to be provided by the security properties of the protocols in use. In any case, the result is that manipulation of administratively configurable parameters is limited to authorized entities.
DetNetリソースの要求と制御を保護するために、DetNetドメインに接続されている各デバイス、最も重要なのはネットワークコントローラーデバイスに認証と承認を使用できます。 DetNetネットワークの制御は、集中化または分散（単一の管理ドメイン内）することができます。集中管理の場合、トラフィックエンジニアリングネットワーク（ACTN）の抽象化と制御で定義されているセキュリティ上の考慮事項の前例は、[RFC8453]のセクション9に記載されています。分散制御プロトコルの場合、DetNetセキュリティは、使用中のプロトコルのセキュリティプロパティによって提供されることが期待されています。いずれにせよ、結果として、管理上構成可能なパラメーターの操作は許可されたエンティティーに制限されます。
To maintain confidentiality of data traversing the DetNet, 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 by MACSec [IEEE802.1AE] for Ethernet (Layer 2) flows.
DetNetを通過するデータの機密性を維持するために、アプリケーションフローは、基盤となるテクノロジーによって提供されるあらゆる手段を通じて保護できます。たとえば、IPフローにはIPsec [RFC4301]、イーサネット（レイヤー2）フローにはMACSec [IEEE802.1AE]によって提供される暗号化を使用できます。
DetNet flows are identified on a per-flow basis, which may provide attackers with additional information about the data flows (when compared to networks 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の固有のプロパティです。
To provide uninterrupted availability of the DetNet QoS, 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 traffic admission control applied at the input of a DetNet domain as described in Section 3.2.1 and through the fault-mitigation methods described in Section 3.3.2. To prevent DetNet packets from being delayed by an entity external to a DetNet domain, DetNet technology definition can allow for the mitigation of man-in-the-middle attacks, for example, through use of authentication and authorization of devices within the DetNet domain.
DetNet QoSの中断のない可用性を提供するために、DoS攻撃および遅延攻撃に対するプロビジョニングを行うことができます。 DoS攻撃から保護するために、悪意のあるデバイスまたは誤動作しているデバイスによる過剰なトラフィックを、たとえば、セクション3.2.1で説明されているように、DetNetドメインの入力に適用されたトラフィックアドミッションコントロールを使用して、障害を防止または軽減できます。セクション3.3.2で説明されている緩和方法。 DetNetドメイン外部のエンティティによってDetNetパケットが遅延するのを防ぐために、DetNetテクノロジー定義では、たとえば、DetNetドメイン内のデバイスの認証と承認を使用することにより、中間者攻撃を軽減することができます。
Because DetNet mechanisms or applications that rely on DetNet can make heavy use of methods that require precise time synchronization, the accuracy, availability, and integrity of time synchronization is of critical importance. Extensive discussion of this topic can be found in [RFC7384].
DetNetに依存するDetNetメカニズムまたはアプリケーションは、正確な時刻同期を必要とするメソッドを頻繁に使用する可能性があるため、時刻同期の精度、可用性、および整合性は非常に重要です。このトピックの広範な議論は[RFC7384]で見つけることができます。
DetNet use cases are known to have widely divergent security requirements. The intent of this section is to provide a baseline for security considerations that are common to all DetNet designs and implementations, without burdening individual designs with specifics of security infrastructure that may not be germane to the given use case. Designers and implementors of DetNet systems are expected to take use-case-specific considerations into account in their DetNet designs and implementations.
DetNetのユースケースには、さまざまなセキュリティ要件があることが知られています。このセクションの目的は、特定のユースケースに密接に関係しないセキュリティインフラストラクチャの詳細で個々の設計に負担をかけることなく、すべてのDetNet設計と実装に共通するセキュリティの考慮事項のベースラインを提供することです。 DetNetシステムの設計者と実装者は、DetNetの設計と実装において、ユースケース固有の考慮事項を考慮する必要があります。
DetNet provides a QoS, and the generic considerations for such mechanisms apply. In particular, such markings allow for an attacker to correlate flows or to select particular types of flow for more detailed inspection.
DetNetはQoSを提供し、そのようなメカニズムの一般的な考慮事項が適用されます。特に、このようなマーキングにより、攻撃者はフローを相関させたり、より詳細な検査のために特定のタイプのフローを選択したりできます。
However, the requirement for every (or almost every) node along the path of a DetNet flow to identify DetNet flows may present an additional attack surface for privacy should the DetNet paradigm be found useful in broader environments.
ただし、DetNetフローを特定するためのDetNetフローのパスに沿ったすべて（またはほぼすべて）のノードの要件は、DetNetパラダイムがより広い環境で有用であると判明した場合、プライバシーに対する追加の攻撃面をもたらす可能性があります。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[BUFFERBLOAT] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the Internet", DOI 10.1145/2063176.2063196, Communications of the ACM, Volume 55, Issue 1, January 2012, <https://doi.org/10.1145/2063176.2063196>.
[BUFFERBLOAT] Gettys、J。およびK. Nichols、「Bufferbloat：Dark Buffers in the Internet」、DOI 10.1145 / 2063176.2063196、Communications of the ACM、Volume 55、Issue 1、2012年1月、<https://doi.org/ 10.1145 / 2063176.2063196>。
[CCAMP] IETF, "Common Control and Measurement Plane (ccamp)", October 2019, <https://datatracker.ietf.org/wg/ccamp/charter/>.
[CCAMP] IETF、「Common Control and Measurement Plane（ccamp）」、2019年10月、<https://datatracker.ietf.org/wg/ccamp/charter/>。
[DETNET-FRAMEWORK] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane Framework", Work in Progress, Internet-Draft, draft-ietf-detnet-data-plane-framework-02, 13 September 2019, <https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-02>.
[DETNET-FRAMEWORK] Varga、B.、Farkas、J.、Berger、L.、Fedyk、D.、Malis、A.、Bryant、S.、J。Korhonen、「DetNet Data Plane Framework」、Work in Progress 、Internet-Draft、draft-ietf-detnet-data-plane-framework-02、2019年9月13日、<https://tools.ietf.org/html/draft-ietf-detnet-data-plane-framework-02> 。
[DETNET-IP] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", Work in Progress, Internet-Draft, draft-ietf-detnet-ip-01, 1 July 2019, <https://tools.ietf.org/html/draft-ietf-detnet-ip-01>.
[DETNET-IP] Varga、B.、Farkas、J.、Berger、L.、Fedyk、D.、Malis、A.、Bryant、S.、J。Korhonen、「DetNet Data Plane：IP」、Work in Progress、Internet-Draft、draft-ietf-detnet-ip-01、2019年7月1日、<https://tools.ietf.org/html/draft-ietf-detnet-ip-01>。
[DETNET-MPLS] Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., Bryant, S., and J. Korhonen, "DetNet Data Plane: MPLS", Work in Progress, Internet-Draft, draft-ietf-detnet-mpls-01, 1 July 2019, <https://tools.ietf.org/html/draft-ietf-detnet-mpls-01>.
[DETNET-MPLS] Varga、B.、Farkas、J.、Berger、L.、Fedyk、D.、Malis、A.、Bryant、S.、J。Korhonen、「DetNet Data Plane：MPLS」、Work in Progress、Internet-Draft、draft-ietf-detnet-mpls-01、2019年7月1日、<https://tools.ietf.org/html/draft-ietf-detnet-mpls-01>。
[DETNET-SECURITY] Mizrahi, T., Grossman, E., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-05, 29 August 2019, <https://tools.ietf.org/html/draft-ietf-detnet-security-05>.
[DETNET-SECURITY]ミズラヒ、T。、グロスマン、E。、ハッカー、A。、ダス、S。、ダウデル、J。、オースタッド、H。、スタントン、K。、およびN.フィン、「確定的ネットワーキング（DetNet ）セキュリティに関する考慮事項」、Work in Progress、Internet-Draft、draft-ietf-detnet-security-05、2019年8月29日、<https://tools.ietf.org/html/draft-ietf-detnet-security-05> 。
[IEC-62439-3] IEC, "Industrial communication networks - High availability automation networks - Part 3: Parallel Redundancy Protocol (PRP) and High-availability Seamless Redundancy (HSR)", TC 65 / SC 65C, IEC 62439-3:2016, March 2016, <https://webstore.iec.ch/publication/24447>.
[IEC-62439-3] IEC、「産業通信ネットワーク-高可用性オートメーションネットワーク-パート3：並列冗長プロトコル（PRP）および高可用性シームレス冗長（HSR）」、TC 65 / SC 65C、IEC 62439-3： 2016年3月、<https://webstore.iec.ch/publication/24447>。
[IEEE802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security", IEEE 802.1AE-2018, <https://ieeexplore.ieee.org/document/8585421>.
[IEEE802.1AE] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Media Access Control（MAC）Security」、IEEE 802.1AE-2018、<https://ieeexplore.ieee.org/document/8585421>。
[IEEE802.1BA] IEEE, "IEEE Standard for Local and metropolitan area networks--Audio Video Bridging (AVB) Systems", IEEE 802.1BA-2011, <https://ieeexplore.ieee.org/document/6032690>.
[IEEE802.1BA] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-オーディオビデオブリッジング（AVB）システム」、IEEE 802.1BA-2011、<https://ieeexplore.ieee.org/document/6032690>。
[IEEE802.1CB] IEEE, "IEEE Standard for Local and metropolitan area networks--Frame Replication and Elimination for Reliability", DOI 10.1109/IEEESTD.2017.8091139, IEEE 802.1CB-2017, October 2019, <https://ieeexplore.ieee.org/document/8091139>.
[IEEE802.1CB] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE規格-信頼性のためのフレームレプリケーションおよび除去」、DOI 10.1109 / IEEESTD.2017.8091139、IEEE 802.1CB-2017、2019年10月、<https://ieeexplore.ieee .org / document / 8091139>。
[IEEE802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks", IEEE 802.1Q-2018, <https://ieeexplore.ieee.org/document/8403927>.
[IEEE802.1Q] IEEE、「IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks」、IEEE 802.1Q-2018、<https://ieeexplore.ieee.org/document/8403927>。
[IEEE802.1Qav] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks Amendment 12: Forwarding and Queuing Enhancements for Time-Sensitive Streams", IEEE 802.1Qav-2009, <https://ieeexplore.ieee.org/document/5375704>.
[IEEE802.1Qav] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Virtual Bridged Local Area Networks Amendment 12：Forwarding and Queuing Enhancements for Time-Sensitive Streams」、IEEE 802.1Qav-2009、<https://ieeexplore.ieee .org / document / 5375704>。
[IEEE802.1Qbu] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks -- Amendment 26: Frame Preemption", IEEE 802.1Qbu-2016, <https://ieeexplore.ieee.org/document/7553415>.
[IEEE802.1Qbu] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks-Amendment 26：Frame Preemption」、IEEE 802.1Qbu-2016、<https://ieeexplore.ieee.org/document/ 7553415>。
[IEEE802.1Qbv] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic", IEEE 802.1Qbv-2015, <https://ieeexplore.ieee.org/document/7440741>.
[IEEE802.1Qbv] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks-Amendment 25：Enhancements for Scheduled Traffic」、IEEE 802.1Qbv-2015、<https://ieeexplore.ieee.org/document / 7440741>。
[IEEE802.1Qch] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 29: Cyclic Queuing and Forwarding", IEEE 802.1Qch-2017, <https://ieeexplore.ieee.org/document/7961303>.
[IEEE802.1Qch] IEEE、「IEEE Standard for Local and Metropolitan Area Network--Bridges and Bridged Networks--Amendment 29：Cyclic Queuing and Forwarding」、IEEE 802.1Qch-2017、<https://ieeexplore.ieee.org/ document / 7961303>。
[IEEE802.1TSNTG] IEEE, "Time-Sensitive Networking (TSN) Task Group", <https://1.ieee802.org/tsn/>.
[IEEE802.1TSNTG] IEEE、「Time-Sensitive Networking（TSN）Task Group」、<https://1.ieee802.org/tsn/>。
[IEEE802.3] IEEE, "IEEE Standard for Ethernet", IEEE 802.3-2018, <https://ieeexplore.ieee.org/document/8457469>.
[IEEE802.3] IEEE、「IEEE Standard for Ethernet」、IEEE 802.3-2018、<https://ieeexplore.ieee.org/document/8457469>。
[IEEE802.3br] IEEE, "IEEE Standard for Ethernet Amendment 5: Specification and Management Parameters for Interspersing Express Traffic", IEEE 802.3br, <https://ieeexplore.ieee.org/document/7900321>.
[IEEE802.3br] IEEE、「IEEE Standard for Ethernet Amendment 5：Specification and Management Parameters for Interspersing Express Traffic」、IEEE 802.3br、<https://ieeexplore.ieee.org/document/7900321>。
[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.、and S. Jamin、 "Resource ReSerVation Protocol（RSVP）-Version 1 Functional Specification"、RFC 2205、DOI 10.17487 / RFC2205、1997年9月、<https://www.rfc-editor.org/info/rfc2205>。
[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.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<https://www.rfc-editor.org/info/rfc2475>。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, DOI 10.17487/RFC2914, September 2000, <https://www.rfc-editor.org/info/rfc2914>.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、DOI 10.17487 / RFC2914、2000年9月、<https://www.rfc-editor.org/info/rfc2914>。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[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. Swallow、「RSVP-TE：Extensions for RSVP for LSP Tunnels」、RFC 3209、DOI 10.17487 / RFC3209、2001年12月、<https://www.rfc-editor.org/info/rfc3209>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <https://www.rfc-editor.org/info/rfc3550>。
[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>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P。、およびJ. Ash、「A Path Computation Element（PCE）-Based Architecture」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：// www.rfc-editor.org/info/rfc4655>。
[RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, DOI 10.17487/RFC6372, September 2011, <https://www.rfc-editor.org/info/rfc6372>.
[RFC6372] Sprecher、N.、Ed。 A.ファレル編、「MPLSトランスポートプロファイル（MPLS-TP）サバイバビリティフレームワーク」、RFC 6372、DOI 10.17487 / RFC6372、2011年9月、<https://www.rfc-editor.org/info/rfc6372>。
[RFC6658] Bryant, S., Ed., Martini, L., Swallow, G., and A. Malis, "Packet Pseudowire Encapsulation over an MPLS PSN", RFC 6658, DOI 10.17487/RFC6658, July 2012, <https://www.rfc-editor.org/info/rfc6658>.
[RFC6658]ブライアント、S。、編、マティーニ、L。、スワロー、G。、およびA.マリ、「MPLS PSNを介したパケット疑似回線カプセル化」、RFC 6658、DOI 10.17487 / RFC6658、2012年7月、<https： //www.rfc-editor.org/info/rfc6658>。
[RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined Networking: A Perspective from within a Service Provider Environment", RFC 7149, DOI 10.17487/RFC7149, March 2014, <https://www.rfc-editor.org/info/rfc7149>.
[RFC7149] Boucadair、M。およびC. Jacquenet、「ソフトウェア定義ネットワーキング：サービスプロバイダー環境内からの展望」、RFC 7149、DOI 10.17487 / RFC7149、2014年3月、<https：//www.rfc-editor。 org / info / rfc7149>。
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7384]ミズラヒ、T。、「パケット交換ネットワークにおけるタイムプロトコルのセキュリティ要件」、RFC 7384、DOI 10.17487 / RFC7384、2014年10月、<https://www.rfc-editor.org/info/rfc7384>。
[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。、編、Pentikousis、K。、編、Denazis、S.、Hadi Salim、J.、Meyer、D.、O。Koufopavlou、「ソフトウェア定義ネットワーキング（SDN）：レイヤーand Architecture Terminology」、RFC 7426、DOI 10.17487 / RFC7426、2015年1月、<https://www.rfc-editor.org/info/rfc7426>。
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement", RFC 7554, DOI 10.17487/RFC7554, May 2015, <https://www.rfc-editor.org/info/rfc7554>.
[RFC7554] Watteyne、T。、編、Palattella、M。、およびL. Grieco、「モノのインターネット（IoT）でのIEEE 802.15.4eタイムスロットチャネルホッピング（TSCH）の使用：問題ステートメント」、RFC 7554 、DOI 10.17487 / RFC7554、2015年5月、<https://www.rfc-editor.org/info/rfc7554>。
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF Recommendations Regarding Active Queue Management", BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.
[RFC7567]ベイカー、F。、エド。およびG.フェアハースト編、「アクティブキュー管理に関するIETFの推奨事項」、BCP 197、RFC 7567、DOI 10.17487 / RFC7567、2015年7月、<https://www.rfc-editor.org/info/rfc7567>。
[RFC7813] Farkas, J., Ed., Bragg, N., Unbehagen, P., Parsons, G., Ashwood-Smith, P., and C. Bowers, "IS-IS Path Control and Reservation", RFC 7813, DOI 10.17487/RFC7813, June 2016, <https://www.rfc-editor.org/info/rfc7813>.
[RFC7813] Farkas、J.、Ed。、Bragg、N.、Unbehagen、P.、Parsons、G.、Ashwood-Smith、P。、およびC. Bowers、「IS-IS Path Control and Reservation」、RFC 7813 、DOI 10.17487 / RFC7813、2016年6月、<https://www.rfc-editor.org/info/rfc7813>。
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, "Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.
[RFC8033]パン、R、ナタラジャン、P、ベイカー、F、Gホワイト、2017年2月、<https://www.rfc-editor.org/info/rfc8033>。
[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、「MPLS-TP Shared-Ring Protection（MSRP）Mechanism for Ring Topology」、RFC 8227、DOI 10.17487 / RFC8227、2017年8月、<https://www.rfc-editor.org/info/rfc8227>。
[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. Iyengar, Ed., "Controlled Delay Active Queue Management", RFC 8289, DOI 10.17487/RFC8289, January 2018, <https://www.rfc-editor.org/info/rfc8289>.
[RFC8289] Nichols、K.、Jacobson、V.、McGregor、A。、編、およびJ. Iyengar、編、「Controlled Delay Active Queue Management」、RFC 8289、DOI 10.17487 / RFC8289、2018年1月、<https ：//www.rfc-editor.org/info/rfc8289>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C。、編、Previdi、S。、編、Ginsberg、L.、Decraene、B.、Litkowski、S。、およびR. Shakir、「Segment Routing Architecture」、RFC 8402、DOI 10.17487 / RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、Ed。 Y.リー、編、「TEネットワークの抽象化と制御のフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https://www.rfc-editor.org/info/rfc8453> 。
[RFC8557] Finn, N. and P. Thubert, "Deterministic Networking Problem Statement", RFC 8557, DOI 10.17487/RFC8557, May 2019, <https://www.rfc-editor.org/info/rfc8557>.
[RFC8557] Finn、N。およびP. Thubert、「Deterministic Networking Problem Statement」、RFC 8557、DOI 10.17487 / RFC8557、2019年5月、<https://www.rfc-editor.org/info/rfc8557>。
[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.
[RFC8578] Grossman、E.、Ed。、「Deterministic Networking Use Cases」、RFC 8578、DOI 10.17487 / RFC8578、2019年5月、<https://www.rfc-editor.org/info/rfc8578>。
[TEAS] IETF, "Traffic Engineering Architecture and Signaling (teas)", October 2019, <https://datatracker.ietf.org/doc/charter-ietf-teas/>.
[TEAS] IETF、「Traffic Engineering Architecture and Signaling（teas）」、2019年10月、<https://datatracker.ietf.org/doc/charter-ietf-teas/>。
[TSCH-ARCH] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, Internet-Draft, draft-ietf-6tisch-architecture-26, 27 August 2019, <https://tools.ietf.org/html/draft-ietf-6tisch-architecture-26>.
[TSCH-ARCH] Thubert、P。、「IEEE 802.15.4のTSCHモードを介したIPv6のアーキテクチャ」、作業中、インターネットドラフト、draft-ietf-6tisch-architecture-26、2019年8月27日、<https ：//tools.ietf.org/html/draft-ietf-6tisch-architecture-26>。
Acknowledgements
謝辞
The authors wish to thank Lou Berger, David Black, Stewart Bryant, Rodney Cummings, Ethan Grossman, Craig Gunther, Marcel Kiessling, Rudy Klecka, Jouni Korhonen, Erik Nordmark, Shitanshu Shah, Wilfried Steiner, George Swallow, Michael Johas Teener, Pat Thaler, Thomas Watteyne, Patrick Wetterwald, Karl Weber, and Anca Zamfir for their various contributions to this work.
著者は、ルー・バーガー、デビッド・ブラック、スチュワート・ブライアント、ロドニー・カミングス、イーサン・グロスマン、クレイグ・ガンター、マルセル・キースリング、ルディ・クレカ、ジョウニー・コロホネン、エリック・ノードマーク、シタンシュ・シャー、ウィルフリード・スタイナー、ジョージ・スワロー、マイケル・ジョハス・ティーンナー、パット・ターラーに感謝します、Thomas Watteyne、Patrick Wetterwald、Karl Weber、Anca Zamfirの各氏によるこの作品への貢献。
Authors' Addresses
著者のアドレス
Norman Finn Huawei 3101 Rio Way Spring Valley, California 91977 United States of America
Norman Finn Huawei 3101 Rio Way Spring Valley、California 91977アメリカ合衆国
Phone: +1 925 980 6430
Email: nfinn@nfinnconsulting.com
Pascal Thubert Cisco Systems Batiment T3 Village d'Entreprises Green Side, 400, Avenue de Roumanille 06410 Biot - Sophia Antipolis France
Pascal Thubert Cisco Systems Batiment T3 Village d'Entreprises Green Side、400、Avenue de Roumanille 06410ビオ-ソフィアアンティポリスフランス
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Balázs Varga Ericsson Budapest Magyar tudosok korutja 11 1117 Hungary
BalázsVarga Ericssonブダペストハンガリーの科学者の時代11 1117ハンガリー
Email: balazs.a.varga@ericsson.com
János Farkas Ericsson Budapest Magyar tudosok korutja 11 1117 Hungary
JánosFarkas Ericssonブダペストハンガリーの科学者の時代11 1117ハンガリー
Email: janos.farkas@ericsson.com