[要約] RFC 8557は、Deterministic Networking（DN）の問題を明確にするための文書であり、DNの目的は、ネットワーク上のトラフィックの時間的な振る舞いを予測可能にすることです。
Internet Engineering Task Force (IETF) N. Finn
Request for Comments: 8557 Huawei Technologies Co. Ltd
Category: Informational P. Thubert
ISSN: 2070-1721 Cisco
May 2019
Deterministic Networking Problem Statement
確定的ネットワーキング問題ステートメント
Abstract
概要
This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties.
このホワイトペーパーでは、さまざまな業界で、決定論的な特性を持つ特徴付けられたフローのマルチホップパスを確立する必要性について説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補であるとは限りません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8557.
このドキュメントの現在の状態、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8557で入手できます。
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
2. On Deterministic Networking .....................................4
3. Problem Statement ...............................................6
3.1. Supported Topologies .......................................6
3.2. Flow Characterization ......................................6
3.3. Centralized Path Computation and Installation ..............7
3.4. Distributed Path Setup .....................................8
3.5. Duplicated Data Format .....................................8
4. Security Considerations .........................................9
5. IANA Considerations .............................................9
6. Informative References .........................................10
Acknowledgments ...................................................11
Authors' Addresses ................................................11
"Deterministic Networking Use Cases" [RFC8578] illustrates that beyond the classical case of Industrial Automation and Control Systems (IACSs) there are in fact multiple industries with strong, and relatively similar, needs for deterministic network services with latency guarantees and ultra-low packet loss.
「確定的ネットワーキングユースケース」[RFC8578]は、産業オートメーションおよび制御システム（IACS）の従来のケースを超えて、レイテンシの保証と超低パケットを備えた確定的ネットワークサービスのニーズが強い、比較的似ている複数の業界があることを示しています。損失。
The generalization of the needs for more deterministic networks has led to the IEEE 802.1 Audio Video Bridging (AVB) Task Group becoming the Time-Sensitive Networking (TSN) [IEEE-802.1TSNTG] Task Group (TG), with a much-expanded constituency from the industrial and vehicular markets.
より確定的なネットワークのニーズの一般化により、IEEE 802.1オーディオビデオブリッジング（AVB）タスクグループは、時間依存型ネットワーキング（TSN）[IEEE-802.1TSNTG]タスクグループ（TG）となり、その構成要素は大幅に拡張されました。産業および車両市場から。
Along with this expansion, the networks considered here are becoming larger and structured, requiring deterministic forwarding beyond the LAN boundaries. For instance, an IACS segregates the network along the broad lines of the Purdue Enterprise Reference Architecture (PERA) [ISA95], typically using deterministic LANs for Purdue level 2 control systems, whereas public infrastructures such as electricity automation require deterministic properties over the wide area. Implementers have come to realize that the convergence of IT and Operation Technology (OT) networks requires Layer 3, as well as Layer 2, capabilities.
この拡張に伴い、ここで検討されているネットワークはより大きく構造化されており、LANの境界を越えた確定的な転送が必要です。たとえば、IACSはネットワークをPurdueエンタープライズリファレンスアーキテクチャ（PERA）[ISA95]の幅広いラインに沿って分離します。通常、Purdueレベル2制御システムに確定LANを使用しますが、電力オートメーションなどの公共インフラストラクチャは広域にわたる確定プロパティを必要とします。実装者は、ITおよび運用技術（OT）ネットワークの収束にはレイヤー3とレイヤー2の機能が必要であることを理解するようになりました。
While the initial user base has focused almost entirely on Ethernet physical media and Ethernet-based bridging protocols from several Standards Development Organizations (SDOs), the need for Layer 3, as expressed above, must not be confined to Ethernet and Ethernet-like media. While such media must be encompassed by any useful Deterministic Networking (DetNet) architecture, cooperation between the IETF and other SDOs must not be limited to the IEEE or the IEEE 802 organizations. Furthermore, while both completed and ongoing work in other SDOs, and in IEEE 802 in particular, provides an obvious starting point for a DetNet architecture, we must not assume that these other SDOs' work confines the space in which the DetNet architecture progresses.
初期のユーザーベースは、ほぼ完全にイーサネット物理メディアといくつかの標準開発機関（SDO）からのイーサネットベースのブリッジングプロトコルに焦点を当てていましたが、上記のように、レイヤー3の必要性はイーサネットとイーサネットのようなメディアに限定されてはなりません。このようなメディアは、有用な決定論的ネットワーキング（DetNet）アーキテクチャに含まれる必要がありますが、IETFと他のSDO間の連携は、IEEEまたはIEEE 802組織に限定されません。さらに、他のSDO、特にIEEE 802での完了した作業と進行中の作業の両方が、DetNetアーキテクチャの明白な出発点を提供しますが、これらの他のSDOの作業がDetNetアーキテクチャが進む空間を制限していると想定してはなりません。
The properties of deterministic networks will have specific requirements for the use of routed networks to support these applications, and a new model must be proposed to integrate this determinism in IT implementations. The proposed model should enable a fully scheduled operation orchestrated by a central controller and may support a more distributed operation with (probably lesser) capabilities. At any rate, the model should not compromise the ability of a network to keep carrying the sorts of traffic that is already carried today in conjunction with new, more deterministic flows. Note: "Deterministic Networking Architecture" [DetNet-Arch] was produced by the DetNet Working Group to describe that model.
確定的ネットワークのプロパティには、これらのアプリケーションをサポートするためにルーティングされたネットワークを使用するための特定の要件があり、この確定性をIT実装に統合する新しいモデルを提案する必要があります。提案されたモデルは、中央コントローラーによって調整された完全にスケジュールされた操作を可能にする必要があり、（おそらく少ない）機能でより分散された操作をサポートします。いずれにせよ、モデルは、新しい、より確定的なフローと組み合わせて、今日すでに伝送されている種類のトラフィックを伝送し続けるネットワークの機能を損なうべきではありません。注：「確定的ネットワーキングアーキテクチャ」[DetNet-Arch]は、そのモデルを説明するためにDetNetワーキンググループによって作成されました。
At the time of this writing, it is expected that
この記事の執筆時点では、
o once the abstract model is agreed upon, the IETF will specify (1) the signaling elements to be used to establish a path and (2) the tagging elements to be used to identify the flows that are to be forwarded along that path
o 抽象モデルが合意されると、IETFは、（1）パスを確立するために使用されるシグナリング要素と、（2）そのパスに沿って転送されるフローを識別するために使用されるタグ付け要素を指定します
o the IETF will specify the necessary protocols or protocol additions, based on relevant IETF technologies, to implement the selected model
o IETFは、関連するIETFテクノロジーに基づいて、選択されたモデルを実装するために必要なプロトコルまたはプロトコルの追加を指定します
A desirable outcome of the work is the ability to establish a multi-hop path over the IP or MPLS network for a particular flow with given timing and precise throughput requirements and to carry this particular flow along the multi-hop path with such characteristics as low latency and ultra-low jitter, reordering and/or replication and elimination of packets over non-congruent paths for a higher delivery ratio, and/or zero congestion loss, regardless of the amount of other flows in the network.
作業の望ましい結果は、所定のタイミングと正確なスループット要件を備えた特定のフローに対してIPまたはMPLSネットワークを介してマルチホップパスを確立し、この特定のフローを低などの特性を持つマルチホップパスに沿って伝送する機能です。ネットワーク内の他のフローの量に関係なく、より高い配信率、および/または輻輳損失ゼロのために、遅延および超低ジッター、再配列および/または複製および非合同パス上のパケットの排除。
Depending on the network capabilities and the current state, requests to establish a path by an end node or a network management entity may be granted or rejected, an existing path may be moved or removed, and DetNet flows exceeding their contract may face packet declassification and drop.
ネットワーク機能と現在の状態に応じて、エンドノードまたはネットワーク管理エンティティによるパスの確立要求が許可または拒否され、既存のパスが移動または削除され、契約を超えるDetNetフローがパケットの機密解除と落とす。
The Internet is not the only digital network that has grown dramatically over the last 30-40 years. Video and audio entertainment, as well as control systems for machinery, manufacturing processes, and vehicles, are also ubiquitous and are now based almost entirely on digital technologies. Over the past 10 years, engineers in these fields have come to realize that significant advantages in both cost and the ability to accelerate growth can be obtained by basing all of these disparate digital technologies on packet networks.
過去30〜40年で劇的に成長したデジタルネットワークはインターネットだけではありません。ビデオとオーディオのエンターテイメント、および機械、製造プロセス、車両の制御システムもユビキタスであり、ほぼ完全にデジタル技術に基づいています。過去10年間、これらの分野のエンジニアは、これらの異種デジタルテクノロジーをすべてパケットネットワークに置くことで、コストと成長を加速する能力の両方で大きな利点が得られることに気づきました。
The goals of Deterministic Networking are to (1) enable the migration of applications with critical timing and reliability issues that currently use special-purpose fieldbus technologies (High-Definition Multimedia Interface (HDMI), Controller Area Network (CAN bus), PROFIBUS [PROFIBUS], etc. ... even RS-232!) to packet technologies in general and to IP in particular and (2) support both these new applications and existing packet network applications over the same physical network. In other words, a deterministic network is backwards compatible with (capable of transporting) statistically multiplexed traffic while preserving the properties of the accepted deterministic flows.
確定的ネットワーキングの目標は、（1）現在特殊用途のフィールドバス技術（高解像度マルチメディアインターフェイス（HDMI）、コントローラーエリアネットワーク（CANバス）、PROFIBUS [PROFIBUS]を使用している重要なタイミングと信頼性の問題があるアプリケーションの移行を可能にすることです。 ]など... RS-232にも対応！）パケットテクノロジー全般、特にIPに対応し、（2）これらの新しいアプリケーションと既存のパケットネットワークアプリケーションの両方を同じ物理ネットワーク上でサポートします。つまり、確定的ネットワークは、受け入れられた確定的フローのプロパティを維持しながら、統計的に多重化されたトラフィックと下位互換性があります（トランスポート可能）。
[RFC8578] indicates that applications in multiple fields need some or all of a suite of features that includes:
[RFC8578]は、複数の分野のアプリケーションが、以下を含む一連の機能の一部またはすべてを必要とすることを示しています。
1. Time synchronization of all host and network nodes (routers and/or bridges), accurate to something between 10 nanoseconds and 10 microseconds, depending on the application.
1. すべてのホストおよびネットワークノード（ルーターまたはブリッジ、あるいはその両方）の時刻同期。アプリケーションに応じて、10ナノ秒から10マイクロ秒の間で正確です。
2. Support for deterministic packet flows that:
2. 次の確定的パケットフローのサポート：
* Can be unicast or multicast.
* ユニキャストまたはマルチキャストにすることができます。
* Need absolute guarantees of minimum and maximum latency end to end across the network; sometimes a tight jitter is required as well.
* ネットワーク全体のエンドツーエンドの最小および最大遅延の絶対的な保証が必要です。時々、タイトなジッタも必要になります。
* Need a packet loss ratio beyond the classical range for a particular medium, in the range of 10^-9 to 10^-12 or better on Ethernet and on the order of 10^-5 in wireless sensor mesh networks.
* イーサネットでは10 ^ -9〜10 ^ -12以上の範囲で、ワイヤレスセンサーメッシュネットワークでは10 ^ -5程度の、特定の媒体の従来の範囲を超えるパケット損失率が必要です。
* Can, in total, absorb more than half of the network's available bandwidth (that is, massive over-provisioning is ruled out as a solution).
* 全体として、ネットワークの利用可能な帯域幅の半分以上を吸収できます（つまり、大規模なオーバープロビジョニングはソリューションとして除外されます）。
* Cannot suffer throttling, congestion feedback, or any other network-imposed transmission delay, although the flows can be meaningfully characterized by either (1) a fixed, repeating transmission schedule or (2) a maximum bandwidth and packet size.
* フローは、（1）繰り返しの固定送信スケジュール、または（2）最大帯域幅とパケットサイズのいずれかで有意義に特徴付けられますが、スロットリング、輻輳フィードバック、またはその他のネットワークによって課される送信遅延を受けることはありません。
3. Multiple methods for scheduling, shaping, limiting, and otherwise controlling the transmission of critical packets at each hop through the network data plane.
3. ネットワークデータプレーンを介した各ホップでの重要なパケットの送信をスケジューリング、シェーピング、制限、およびその他の方法で制御するための複数の方法。
4. Robust defenses against misbehaving hosts, routers, or bridges, in both the data plane and the control plane, with guarantees that a critical flow within its guaranteed resources cannot be affected by other flows, whatever the pressures on the network. For more on the specific threats against DetNet, see "Deterministic Networking (DetNet) Security Considerations" [DetNet-Security].
4. データプレーンとコントロールプレーンの両方で、ホスト、ルーター、またはブリッジの誤動作に対する堅牢な防御。保証されたリソース内のクリティカルフローが、ネットワークへの圧力に関係なく他のフローの影響を受けないことが保証されます。 DetNetに対する特定の脅威の詳細については、「確定的ネットワーク（DetNet）のセキュリティに関する考慮事項」[DetNet-Security]を参照してください。
5. One or more methods for reserving resources in bridges and routers to carry these flows.
5. これらのフローを伝送するためにブリッジとルーターのリソースを予約する1つ以上の方法。
Time-synchronization techniques need not be addressed by an IETF working group; there are a number of standards available for this purpose, including IEEE 1588 [IEEE-1588], IEEE 802.1AS [IEEE-8021AS], and more.
時間同期技術は、IETFワーキンググループが対処する必要はありません。 IEEE 1588 [IEEE-1588]、IEEE 802.1AS [IEEE-8021AS]など、この目的で利用できる多くの標準があります。
The needs related to multicast, latency, loss ratio, and throttling avoidance exist because the algorithms employed by the applications demand it. They are not simply the transliteration of fieldbus needs to a packet-based fieldbus simulation; they also reflect fundamental mathematics of the control of a physical system.
アプリケーションで使用されるアルゴリズムが要求するため、マルチキャスト、レイテンシ、損失率、およびスロットリング回避に関連するニーズが存在します。これらは、フィールドバスのニーズをパケットベースのフィールドバスシミュレーションに変換するだけではありません。また、物理システムの制御に関する基本的な数学を反映しています。
With classical forwarding of latency-sensitive and loss-sensitive packets across a network, interactions among different critical flows introduce fundamental uncertainties in delivery schedules. The details of the queuing, shaping, and scheduling algorithms employed by each bridge or router to control the output sequence on a given port affect the detailed makeup of the output stream, e.g., how finely a given flow's packets are mixed among those of other flows.
遅延の影響を受けやすいパケットや損失の影響を受けやすいパケットをネットワーク経由で転送する従来の方法では、さまざまな重要なフロー間の相互作用により、配信スケジュールに根本的な不確実性が生じます。各ブリッジまたはルーターが特定のポートの出力シーケンスを制御するために使用するキューイング、シェーピング、およびスケジューリングアルゴリズムの詳細は、出力ストリームの詳細な構成に影響を与えます。 。
This, in turn, has a strong effect on the buffer requirements, and hence the latency guarantees deliverable, by the next bridge or router along the path. For this reason, the IEEE 802.1 TSN TG has defined a new set of queuing, shaping, and scheduling algorithms that enable each bridge or router to compute the exact number of buffers to be allocated for each flow or class of flows.
これは、次に、バッファ要件に強い影響を及ぼします。したがって、パスに沿った次のブリッジまたはルーターによって、レイテンシが確実に配信可能になります。このため、IEEE 802.1 TSN TGは、各ブリッジまたはルーターが各フローまたはフローのクラスに割り当てられるバッファーの正確な数を計算できるようにする新しいキューイング、シェーピング、およびスケジューリングアルゴリズムのセットを定義しました。
Networking protocols commonly need robustness. Note that robustness plays a particularly important part in real-time control networks, where expensive equipment, and even lives, can be lost due to misbehaving equipment.
ネットワーキングプロトコルは通常、堅牢性を必要とします。堅牢性はリアルタイム制御ネットワークで特に重要な役割を果たすことに注意してください。そこでは、高価な機器、さらには生命さえもが、機器の誤動作によって失われる可能性があります。
Reserving resources before packet transmission is the one fundamental shift in the behavior of network applications that is impossible to avoid. 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 unthrottled (though bandwidth-limited) flows means that bridges and routers have to dedicate buffer resources to specific flows or classes of flows. The requirements of each reservation have to be translated into the parameters that control each host's, bridge's, and router's queuing, shaping, and scheduling functions and delivered to the hosts, bridges, and routers.
パケット送信前にリソースを予約することは、回避できないネットワークアプリケーションの動作における1つの根本的な変化です。そもそも、ネットワークは有限のレイテンシを提供できず、提供された任意の負荷に対してパケット損失を実質的にゼロにすることができません。第2に、抑制されていない（帯域幅は制限されていますが）フローのパケット損失を実質的にゼロにするには、ブリッジとルーターがバッファリソースを特定のフローまたはフローのクラス専用にする必要があります。各予約の要件は、各ホスト、ブリッジ、ルーターのキューイング、シェーピング、およびスケジューリング機能を制御するパラメーターに変換され、ホスト、ブリッジ、ルーターに配信される必要があります。
In some use cases, the end point that runs the application is involved in the Deterministic Networking operation -- for instance, by controlling certain aspects of its throughput, such as rate or precise time of emission. In such a case, the deterministic path is end to end from application host to application host.
一部のユースケースでは、アプリケーションを実行するエンドポイントが確定的ネットワーキング操作に関与します。たとえば、放出の速度や正確な時間など、スループットの特定の側面を制御します。このような場合、確定的なパスは、アプリケーションホストからアプリケーションホストへのエンドツーエンドです。
On the other end, the deterministic portion of a path may be a tunnel between an ingress point and an egress router. In any case, routers and switches in between should not need to be aware of whether the path is end to end or a tunnel.
もう一方の端では、パスの決定論的な部分は、入口ポイントと出口ルーター間のトンネルである場合があります。いずれの場合も、ルーターとその間のスイッチは、パスがエンドツーエンドであるかトンネルであるかを認識する必要はありません。
While it is clear that DetNet does not aim to set up deterministic paths over the global Internet, there is still a lack of clarity regarding the limits of a domain where a deterministic path can be set up. These limits may depend on the technology that is used to set the path up, whether it is centralized or distributed.
DetNetがグローバルインターネット上に確定的パスを設定することを目的としていないことは明らかですが、確定的パスを設定できるドメインの制限についてはまだ明確ではありません。これらの制限は、パスが一元化されているか分散されているかに関係なく、パスのセットアップに使用されるテクノロジーによって異なる場合があります。
Deterministic forwarding can only apply to flows with such well-defined characteristics as periodicity and burstiness. Before a path can be established to serve them, the expression of those characteristics, and how the network can serve them (for instance, in shaping and forwarding operations), must be specified.
確定的転送は、周期性やバースト性などの明確に定義された特性を持つフローにのみ適用できます。それらを提供するためのパスを確立する前に、それらの特性の表現、およびネットワークがそれらを提供する方法（たとえば、シェーピングおよび転送操作で）を指定する必要があります。
A centralized routing model, such as that provided with a Path Computation Element (PCE) (see [RFC4655]), enables global and per-flow optimizations. This type of model is attractive, but a number of issues remain to be solved -- in particular:
パス計算要素（PCE）（[RFC4655]を参照）で提供されるような集中ルーティングモデルは、グローバルおよびフローごとの最適化を可能にします。このタイプのモデルは魅力的ですが、解決すべき多くの問題が残っています-特に：
o whether and how the path computation can be installed by
o パス計算をインストールできるかどうか、またその方法
* an end device or
* エンドデバイスまたは
* a network management entity
* ネットワーク管理エンティティ
and
そして
o how the path is set up -- either
o パスの設定方法-どちらか
* by installing state at each hop with a direct interaction between the forwarding device and the PCE or
* 転送デバイスとPCEの間の直接の相互作用で各ホップに状態をインストールすることによって、または
* along a path by injecting a source-routed request at one end of the path, following classical Traffic Engineering (TE) models
* 従来のトラフィックエンジニアリング（TE）モデルに従って、パスの一方の端にソースルート要求を挿入することにより、パスに沿って
To enable a centralized model, DetNet should produce a description of the high-level interaction and data models to:
集中型モデルを有効にするには、DetNetは高レベルの相互作用とデータモデルの記述を生成して、次のことを行う必要があります。
o report the topology and device capabilities to the central controller
o トポロジーとデバイスの機能を中央コントローラーに報告する
o establish a direct interface between the centralized PCE and each device under its control in order to enable vertical signaling
o 垂直方向のシグナリングを可能にするために、集中型PCEとその制御下にある各デバイス間に直接インターフェイスを確立する
o request a path setup for a new flow with particular characteristics over the service interface and control it through its life cycle
o サービスインターフェースを介して特定の特性を持つ新しいフローのパス設定をリクエストし、そのライフサイクルを通じて制御する
o provide support for life-cycle management for a path (instantiate/modify/update/delete)
o パスのライフサイクル管理のサポートを提供（インスタンス化/変更/更新/削除）
o provide support for adaptability to cope with such various events as loss of a link
o リンクの喪失などのさまざまなイベントに対処するための適応性のサポートを提供します
o expose the status of the path to the end devices (User-Network Interfaces (UNIs))
o パスのステータスをエンドデバイスに公開する（ユーザーネットワークインターフェイス（UNI））
o provide additional reliability through redundancy, particularly with Packet Replication, Elimination, and Ordering Functions (PREOF), where redundant paths may deliver packets out of order and PREOF may need to correct the ordering
o 冗長パスによってパケットが順不同で配信され、PREOFが順序を修正する必要がある場合に、特にパケット複製、削除、順序付け機能（PREOF）を使用して、冗長性により追加の信頼性を提供します。
o indicate the flows and packet sequences in-band with the flows. This is needed for flows that require PREOF in order to isolate duplicates and reorder packets at the end of the sequence
o フローとフロー内のパケットシーケンスを示します。これは、シーケンスの最後で重複を分離してパケットを並べ替えるためにPREOFを必要とするフローに必要です。
Whether a distributed alternative without a PCE can be valuable could be studied as well. Such an alternative could, for instance, build upon Resource Reservation Protocol - TE (RSVP-TE) flows [RFC3209]. But the focus of the work should be to deliver the centralized approach first.
PCEを使用しない分散型の代替手段が価値があるかどうかも検討できます。そのような代替案は、たとえば、リソース予約プロトコル-TE（RSVP-TE）フローに基づいて構築できます[RFC3209]。しかし、作業の焦点は、最初に集中型のアプローチを提供することです。
To enable functionality similar to that of RSVP-TE, the following steps would take place:
RSVP-TEと同様の機能を有効にするには、次の手順を実行します。
1. Neighbors and their capabilities would be discovered and exposed to compute a path that would fit the DetNet constraints -- typically those of latency, time precision, and resource availability.
1. ネイバーとその機能が検出されて公開され、DetNetの制約（通常、遅延、時間の精度、リソースの可用性）に適合するパスが計算されます。
2. A constrained path would be calculated with an improved version of Constrained Shortest Path First (CSPF) that is aware of DetNet.
2. 制約付きパスは、DetNetを認識するConstrained Shortest Path First（CSPF）の改良バージョンで計算されます。
3. The path may be installed using a control protocol such as RSVP-TE, extended to enable flow identification and install new per-hop behavior such as Packet Replication, Elimination, and Ordering, and to reserve physical resources for the flow. In that case, traffic flows could be transported through an MPLS-TE tunnel, using the reserved resources for this flow at each hop.
3. パスは、RSVP-TEなどの制御プロトコルを使用してインストールされ、フローの識別を可能にし、パケットレプリケーション、除去、順序付けなどの新しいホップごとの動作をインストールし、フローの物理リソースを予約するために拡張されます。その場合、各ホップでこのフロー用に予約されたリソースを使用して、トラフィックフローをMPLS-TEトンネル経由で転送できます。
In some cases, the duplication and elimination of packets over non-congruent paths are required to achieve a sufficiently high delivery ratio to meet application needs. In these cases, a small number of packet formats and supporting protocols are required (preferably just one of each) to serialize the packets of a DetNet stream at one point in the network, replicate them at one or more points in the network, and discard duplicates at one or more other points in the network, including perhaps the destination host. Using an existing solution would be preferable to inventing a new one.
場合によっては、アプリケーションのニーズを満たすために十分に高い配信率を達成するために、合同ではないパス上のパケットの複製と排除が必要です。これらの場合、DetNetストリームのパケットをネットワーク内の1つのポイントでシリアル化し、ネットワーク内の1つ以上のポイントで複製して破棄するには、少数のパケットフォーマットとサポートプロトコル（できればそれぞれ1つずつ）が必要です。おそらく宛先ホストを含む、ネットワーク内の他の1つ以上のポイントで複製します。既存のソリューションを使用することは、新しいソリューションを発明するよりも望ましいでしょう。
Security in the context of Deterministic Networking has an added dimension; the time of delivery of a packet can be just as important as the contents of the packet itself. A man-in-the-middle attack, for example, can impose and then systematically adjust additional delays into a link, and thus disrupt or subvert a real-time application without having to crack any encryption methods employed. See [RFC7384] for an exploration of this issue in a related context.
確定的ネットワーキングのコンテキストにおけるセキュリティには、追加の側面があります。パケットの配信時間は、パケット自体の内容と同じくらい重要です。たとえば、man-in-the-middle攻撃は、追加の遅延をリンクに課し、体系的に調整することができるため、使用されている暗号化方法を解読することなく、リアルタイムアプリケーションを中断または破壊することができます。関連するコンテキストでのこの問題の詳細については、[RFC7384]を参照してください。
Typical control networks today rely on complete physical isolation to prevent rogue access to network resources. DetNet enables the virtualization of those networks over a converged IT/OT infrastructure. Doing so, DetNet introduces an additional risk of flows interacting and interfering with one another as they share physical resources such as Ethernet trunks and the radio spectrum. The requirement is that there is no possible data leak from and into a deterministic flow. Stated more generally, there is no possible influence whatsoever from the outside on a deterministic flow. The expectation is that physical resources are effectively associated with a given flow at a given point in time. In that model, the time-sharing of physical resources becomes transparent to the individual flows, as these flows have no clue regarding whether or not the resources are used by other flows at other times.
今日の一般的な制御ネットワークは、完全な物理的分離に依存して、ネットワークリソースへの不正アクセスを防止しています。 DetNetは、統合されたIT / OTインフラストラクチャ上でこれらのネットワークの仮想化を可能にします。そうすることで、DetNetは、イーサネットトランクや無線スペクトルなどの物理リソースを共有するため、フローが相互に干渉して干渉するという追加のリスクをもたらします。要件は、確定的フローとの間のデータリークの可能性がないことです。より一般的に述べると、決定論的なフローに外部からの影響はまったくあり得ません。予想されるのは、物理リソースが特定の時点で特定のフローに効果的に関連付けられることです。そのモデルでは、物理リソースのタイムシェアリングは個々のフローに対して透過的になります。これらのフローは、リソースが他の時に他のフローによって使用されているかどうかについての手がかりがないためです。
The overall security of a deterministic system must cover:
確定的システムの全体的なセキュリティは、以下をカバーする必要があります。
o the protection of the signaling protocol
o シグナリングプロトコルの保護
o the authentication and authorization of the controlling nodes, including plug-and-play participating end systems
o プラグアンドプレイ参加エンドシステムを含む、制御ノードの認証と承認
o the identification and shaping of the flows
o 流れの特定と形成
o the isolation of flows from leakage and other influences from any activity sharing physical resources
o 物理リソースを共有しているアクティビティからのリークやその他の影響からのフローの分離
The specific threats against DetNet are further discussed in [DetNet-Security].
DetNetに対する特定の脅威は、[DetNet-Security]でさらに説明されています。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
[DetNet-Arch] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", Work in Progress, draft-ietf-detnet-architecture-13, May 2019.
[DetNet-Arch] Finn、N.、Thubert、P.、Varga、B。、およびJ. Farkas、「Deterministic Networking Architecture」、Work in Progress、draft-ietf-detnet-architecture-13、2019年5月。
[DetNet-Security] Mizrahi, T., Grossman, E., Ed., Hacker, A., Das, S., Dowdell, J., Austad, H., Stanton, K., and N. Finn, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, draft-ietf-detnet-security-04, March 2019.
[DetNet-Security] Mizrahi、T.、Grossman、E.、Ed。、Hacker、A.、Das、S.、Dowdell、J.、Austad、H.、Stanton、K.、and N. Finn、 "Deterministicネットワーキング（DetNet）のセキュリティに関する考慮事項」、作業中、draft-ietf-detnet-security-04、2019年3月。
[IEEE-1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588-2008, <https://standards.ieee.org/ findstds/standard/1588-2008.html>.
[IEEE-1588] IEEE、「ネットワーク化された測定および制御システムの高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588-2008、<https://standards.ieee.org/ findstds / standard / 1588-2008.html >。
[IEEE-802.1TSNTG] IEEE Standards Association, "IEEE 802.1 Time-Sensitive Networking Task Group", <http://www.ieee802.org/1/pages/avbridges.html>.
[IEEE-802.1TSNTG] IEEE Standards Association、「IEEE 802.1 Time-Sensitive Networking Task Group」、<http://www.ieee802.org/1/pages/avbridges.html>。
[IEEE-8021AS] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE 802.1AS-2011, <http://www.ieee802.org/1/pages/802.1as.html>.
[IEEE-8021AS] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks」、IEEE 802.1AS-2011、<http://www.ieee802.org/1 /pages/802.1as.html>。
[ISA95] ANSI/ISA, "Enterprise-Control System Integration - Part 1: Models and Terminology", <https://www.isa.org/isa95/>.
[ISA95] ANSI / ISA、「Enterprise-Control System Integration-Part 1：Models and Terminology」、<https://www.isa.org/isa95/>。
[PROFIBUS] IEC, "PROFIBUS Standard - DP Specification (IEC 61158 Type 3)", <https://www.profibus.com/>.
[PROFIBUS] IEC、「PROFIBUS標準-DP仕様（IEC 61158タイプ3）」、<https://www.profibus.com/>。
[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>。
[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>。
[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>。
[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>。
Acknowledgments
謝辞
The authors wish to thank Lou Berger, Pat Thaler, Jouni Korhonen, Janos Farkas, Stewart Bryant, Andrew Malis, Ethan Grossman, Patrick Wetterwald, Subha Dhesikan, Matthew Miller, Erik Nordmark, George Swallow, Rodney Cummings, Ines Robles, Shwetha Bhandari, Rudy Klecka, Anca Zamfir, David Black, Thomas Watteyne, Shitanshu Shah, Kiran Makhijani, Craig Gunther, Warren Kumari, Wilfried Steiner, Marcel Kiessling, Karl Weber, Alissa Cooper, and Benjamin Kaduk for their various contributions to this work.
著者は、ルー・バーガー、パット・ターラー、ジューニ・コーホネン、ジャノス・ファルカス、スチュワート・ブライアント、アンドリュー・マリス、イーサン・グロスマン、パトリック・ウェッターヴァルト、スバ・デシカン、マシュー・ミラー、エリック・ノードマーク、ジョージ・スワロー、ロドニー・カミングス、イネス・ロブレス、シュウェサ・バンダリ、ルディクレカ、アンカザンフィア、デビッドブラック、トーマスワッテイン、シタンシュシャー、キランマヒジャーニ、クレイグガンター、ウォーレンクマリ、ウィルフリードシュタイナー、マルセルキースリング、カールウェーバー、アリッサクーパー、ベンジャミンカドゥック。
Authors' Addresses
著者のアドレス
Norman Finn Huawei Technologies Co. Ltd 3755 Avocado Blvd. PMB 436 La Mesa, California 91941 United States of America
Norman Finn Huawei Technologies Co. Ltd 3755 Avocado Blvd. PMB 436ラメーサ、カリフォルニア91941アメリカ合衆国
Phone: +1 925 980 6430
Email: norman.finn@mail01.huawei.com
Pascal Thubert Cisco Systems, Inc. Building D, 45 Allee des Ormes - BP1200 Mougins - Sophia Antipolis 06254 France
Pascal Thubert Cisco Systems、Inc.建物D、45 Allee des Ormes-BP1200ムージャン-ソフィアアンティポリス06254フランス
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com