[要約] RFC 9320はDetNetのBounded Latencyに関するタイミングモデルと、エンドツーエンドの遅延とバックログ境界を計算する方法論を提供しています。この方法論は、管理・制御プレーンやリソース予約アルゴリズムによって使用され、DetNetサービスにおいて遅延を制限し、混雑損失をゼロにすることを目的としています。
Internet Engineering Task Force (IETF) N. Finn
Request for Comments: 9320 Huawei Technologies Co. Ltd
Category: Informational J.-Y. Le Boudec
ISSN: 2070-1721 E. Mohammadpour
EPFL
J. Zhang
Huawei Technologies Co. Ltd
B. Varga
Ericsson
November 2022
Deterministic Networking (DetNet) Bounded Latency
決定論的ネットワーキング（DETNET）境界レイテンシ
Abstract
概要
This document presents a timing model for sources, destinations, and Deterministic Networking (DetNet) transit nodes. Using the model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing methods. The methodology can be used by the management and control planes and by resource reservation algorithms to provide bounded latency and zero congestion loss for the DetNet service.
このドキュメントでは、ソース、目的地、および決定論的ネットワーキング（DETNET）トランジットノードのタイミングモデルを提示します。このモデルを使用して、さまざまなキューイング方法のエンドツーエンドのレイテンシとバックログの境界を計算する方法を提供します。方法論は、管理および制御プレーンとリソース予約アルゴリズムによって使用して、DetNetサービスの境界レイテンシとゼロの混雑損失を提供できます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9320.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9320で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Terminology and Definitions
3. DetNet Bounded Latency Model
3.1. Flow Admission
3.1.1. Static Latency Calculation
3.1.2. Dynamic Latency Calculation
3.2. Relay Node Model
4. Computing End-to-End Delay Bounds
4.1. Non-queuing Delay Bound
4.2. Queuing Delay Bound
4.2.1. Per-Flow Queuing Mechanisms
4.2.2. Aggregate Queuing Mechanisms
4.3. Ingress Considerations
4.4. Interspersed DetNet-Unaware Transit Nodes
5. Achieving Zero Congestion Loss
6. Queuing Techniques
6.1. Queuing Data Model
6.2. Frame Preemption
6.3. Time-Aware Shaper
6.4. Credit-Based Shaper with Asynchronous Traffic Shaping
6.4.1. Delay Bound Calculation
6.4.2. Flow Admission
6.5. Guaranteed Service
6.6. Cyclic Queuing and Forwarding
7. Example Application on DetNet IP Network
8. Security Considerations
9. IANA considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Contributors
Authors' Addresses
The ability for IETF Deterministic Networking (DetNet) or IEEE 802.1 Time-Sensitive Networking [IEEE8021TSN] to provide the DetNet services of bounded latency and zero congestion loss depends upon
IETF決定論的ネットワーキング（detNet）またはIEEE 802.1時間依存ネットワーキング[IEEE8021TSN]が境界レイテンシとゼロの混雑損失のデットネットサービスを提供する能力は、
A. configuring and allocating network resources for the exclusive use of DetNet flows;
A.デットネットフローを排他的に使用するためのネットワークリソースの構成と割り当て。
B. identifying, in the data plane, the resources to be utilized by any given packet; and
B.データプレーンで、特定のパケットによって利用されるリソースを識別します。と
C. the detailed behavior of those resources, especially transmission queue selection, so that latency bounds can be reliably assured.
C.これらのリソースの詳細な動作、特にトランスミッションキュー選択。
As explained in [RFC8655], DetNet flows are notably characterized by
[RFC8655]で説明されているように、Detnet Flowsは特に特徴付けられます
1. a maximum bandwidth, guaranteed either by the transmitter or by strict input metering, and
1. 送信機または厳密な入力計量によって保証された最大帯域幅、および
2. a requirement for a guaranteed worst-case end-to-end latency.
2. 保証された最悪のエンドツーエンドのレイテンシの要件。
That latency guarantee, in turn, provides the opportunity for the network to supply enough buffer space to guarantee zero congestion loss. In this document, it is assumed that the paths of DetNet flows are fixed. Before the transmission of a DetNet flow, it is possible to calculate end-to-end latency bounds and the amount of buffer space required at each hop to ensure zero congestion loss; this can be used by the applications identified in [RFC8578].
そのレイテンシ保証は、ネットワークがゼロの渋滞損失を保証するのに十分なバッファースペースを提供する機会を提供します。このドキュメントでは、ディットネットフローの経路が固定されていると想定されています。デットネットの流れが送信される前に、膨大なホップで必要なエンドツーエンドのレイテンシ境界と、混雑損失がゼロを確保するために必要なバッファースペースの量を計算することができます。これは、[RFC8578]で特定されたアプリケーションで使用できます。
This document presents a timing model for sources, destinations, and the DetNet transit nodes; using this model, it provides a methodology to compute end-to-end latency and backlog bounds for various queuing mechanisms that can be used by the management and control planes to provide DetNet qualities of service. The methodology used in this document accounts for the possibility of packet reordering within a DetNet node. The bounds on the amount of packet reordering is out of the scope of this document and can be found in [PacketReorderingBounds]. Moreover, this document references specific queuing mechanisms, mentioned in [RFC8655], as proofs of concept that can be used to control packet transmission at each output port and achieve the DetNet quality of service (QoS).
このドキュメントでは、ソース、目的地、およびデットネットトランジットノードのタイミングモデルを提示します。このモデルを使用して、管理機と制御プレーンで使用できるさまざまなキューイングメカニズムのエンドツーエンドのレイテンシとバックログの境界を計算する方法を提供します。このドキュメントで使用される方法論は、デットネットノード内でパケットの再注文の可能性を説明しています。パケットの並べ替えの量の範囲は、このドキュメントの範囲外であり、[packetreordingbounds]に記載されています。さらに、このドキュメントは、[RFC8655]で言及されている特定のキューイングメカニズムを参照して、各出力ポートでのパケット伝送を制御し、Detnet Quality of Service（QOS）を達成するために使用できる概念の証明として参照しています。
Using the model presented in this document, it is possible for an implementer, user, or standards development organization to select a set of queuing mechanisms for each device in a DetNet network and to select a resource reservation algorithm for that network so that those elements can work together to provide the DetNet service. Section 7 provides an example application of the timing model introduced in this document on a DetNet IP network with a combination of different queuing mechanisms.
このドキュメントに示されているモデルを使用して、実装者、ユーザー、または標準開発組織が、デットネットネットワーク内の各デバイスのキューイングメカニズムのセットを選択し、そのネットワークのリソース予約アルゴリズムを選択して、それらの要素ができるようにする可能性があります。協力して、デットネットサービスを提供します。セクション7では、さまざまなキューイングメカニズムの組み合わせで、このドキュメントでこのドキュメントで導入されたタイミングモデルの例を適用します。
This document does not specify any resource reservation protocol or control plane function. It does not describe all of the requirements for that protocol or control plane function. It does describe requirements for such resource reservation methods and for queuing mechanisms that, if met, will enable them to work together.
このドキュメントでは、リソース予約プロトコルまたはコントロールプレーン機能を指定しません。そのプロトコルまたはコントロールプレーン機能のすべての要件を説明するものではありません。このようなリソース予約方法と、満たされた場合、それらが協力できるようにするキューイングメカニズムの要件を説明しています。
This document uses the terms defined in [RFC8655]. Moreover, the following terms are used in this document:
このドキュメントでは、[RFC8655]で定義されている用語を使用します。さらに、このドキュメントでは、次の用語が使用されています。
T-SPEC TrafficSpecification, as defined in Section 5.5 of [RFC9016].
[RFC9016]のセクション5.5で定義されているT-Spec TrafficsPecification。
arrival curve An arrival curve function alpha(t) is an upper bound on the number of bits seen at an observation point within any time interval t.
到着曲線到着曲線関数アルファ（t）は、いつでも間隔at内の観測点で見られるビットの数の上限です。
CQF Cyclic Queuing and Forwarding.
CQF周期的なキューイングと転送。
CBS Credit-Based Shaper.
CBSクレジットベースのシェーパー。
TSN Time-Sensitive Networking.
TSN時間に敏感なネットワーキング。
PREOF A collective name for Packet Replication, Elimination, and Ordering Functions.
パケットレプリケーション、排除、および順序付け機能の集合名。
POF A Packet Ordering Function is 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 Edgeノード、Detnet Relayノード、またはENDシステムによって実装できます。
This document assumes that the following paradigm is used to admit DetNet flows:
このドキュメントは、次のパラダイムがデットネットフローを認めるために使用されることを前提としています。
1. Perform any configuration required by the DetNet transit nodes in the network for aggregates of DetNet flows. This configuration is done beforehand and not tied to any particular DetNet flow.
1. デットネットフローの集合体に対して、ネットワーク内のDetNet Transitノードで必要な構成を実行します。この構成は事前に実行され、特定のデットネットフローに結び付けられていません。
2. Characterize the new DetNet flow, particularly in terms of required bandwidth.
2. 特に必要な帯域幅の観点から、新しいデットネットフローを特徴付けます。
3. Establish the path that the DetNet flow will take through the network from the source to the destination(s). This can be a point-to-point or a point-to-multipoint path.
3. Detnet Flowがソースから宛先までネットワークを通過するパスを確立します。これは、ポイントツーポイントまたはポイントツーマルチポイントパスです。
4. Compute the worst-case end-to-end latency for the DetNet flow using one of the methods below (Sections 3.1.1 and 3.1.2). In the process, determine whether sufficient resources are available for the DetNet flow to guarantee the required latency and to provide zero congestion loss.
4. 以下の方法のいずれかを使用して、デットネットフローの最悪のエンドツーエンドのレイテンシを計算します（セクション3.1.1および3.1.2）。その過程で、必要なレイテンシを保証し、渋滞の損失をゼロにするために、デットネットフローに十分なリソースが利用可能かどうかを判断します。
5. Assuming that the resources are available, commit those resources to the DetNet flow. This may require adjusting the parameters that control the filtering and/or queuing mechanisms at each hop along the DetNet flow's path.
5. リソースが利用可能であると仮定すると、これらのリソースをDetnet Flowにコミットします。これには、Detnet Flowのパスに沿った各ホップでフィルタリングおよび/またはキューイングメカニズムを制御するパラメーターを調整する必要があります。
This paradigm can be implemented using peer-to-peer protocols or using a central controller. In some situations, a lack of resources can require backtracking and recursing through the above list.
このパラダイムは、ピアツーピアプロトコルまたはセントラルコントローラーを使用して実装できます。状況によっては、リソースが不足しているため、上記のリストをバックトラッキングと再発する必要があります。
Issues, such as service preemption of a DetNet flow in favor of another, when resources are scarce, are not considered here. Also not addressed is the question of how to choose the path to be taken by a DetNet flow.
リソースが不足している場合、他の人を支持するデットネットフローのサービスの先制などの問題は、ここでは考慮されません。また、ディットネットの流れがとるパスを選択する方法の問題も対処されていません。
The static problem: Given a network and a set of DetNet flows, compute an end-to-end latency bound (if computable) for each DetNet flow and compute the resources, particularly buffer space, required in each DetNet transit node to achieve zero congestion loss.
静的問題：ネットワークと一連のデットネットフローを与えられた場合、各デットネットの流れのエンドツーエンドのレイテンシバウンド（計算可能な場合）を計算し、リソース、特にバッファースペースを計算します。損失。
In this calculation, all of the DetNet flows are known before the calculation commences. This problem is of interest to relatively static networks or static parts of larger networks. It provides bounds on latency and buffer size. The calculations can be extended to provide global optimizations, such as altering the path of one DetNet flow in order to make resources available to another DetNet flow with tighter constraints.
この計算では、計算が始まる前にすべてのディットネットフローが知られています。この問題は、比較的静的なネットワークまたは大規模なネットワークの静的部分にとって興味深いものです。レイテンシとバッファサイズの境界を提供します。計算を拡張して、1つのデットネットフローのパスを変更して、より厳しい制約で別のディットネットフローにリソースを利用できるようにするなど、グローバルな最適化を提供することができます。
This calculation may be more difficult to perform than the dynamic calculation (Section 3.1.2) because the DetNet flows passing through one port on a DetNet transit node affect each other's latency. The effects can even be circular, from node A to B to C and back to A. On the other hand, the static calculation can often accommodate queuing methods, such as transmission selection by strict priority, that are unsuitable for the dynamic calculation.
この計算は、ディットネットトランジットノードの1つのポートを通過するデットネットが互いの遅延に影響するため、動的計算（セクション3.1.2）よりも実行するのが難しい場合があります。効果は、ノードAからB、C、C、Aに戻ることでさえ循環することもあります。一方、静的計算は、動的計算には適さない、厳密な優先度による伝送選択などのキューイング方法に対応できます。
The dynamic problem: Given a network whose maximum capacity for DetNet flows is bounded by a set of static configuration parameters applied to the DetNet transit nodes and given just one DetNet flow, compute the worst-case end-to-end latency that can be experienced by that flow, no matter what other DetNet flows (within the network's configured parameters) might be created or deleted in the future. Also, compute the resources, particularly buffer space, required in each DetNet transit node to achieve zero congestion loss.
動的な問題：デットネットフローの最大容量が、デットネットトランジットノードに適用され、1つのデットネットフローのみが与えられた一連の静的構成パラメーターに制限されているネットワークを考えると、経験できる最悪のエンドツーエンドのレイテンシを計算しますそのフローによって、他のどのディットネットフローが（ネットワークの構成されたパラメーター内）に関係なく、将来作成または削除される可能性があります。また、各デットネットトランジットノードで必要なリソース、特にバッファースペースを計算して、渋滞損失がゼロに達する。
This calculation is dynamic, in the sense that DetNet flows can be added or deleted at any time, with a minimum of computation effort and without affecting the guarantees already given to other DetNet flows.
この計算は、デットネットフローがいつでも追加または削除されるという意味で、最小限の計算努力で、他のデットネットフローに既に与えられた保証に影響を与えることなく、動的です。
Dynamic latency calculation can be done based on the static one described in Section 3.1.1; when a new DetNet flow is created or deleted, the entire calculation for all DetNet flows is repeated. If an already-established DetNet flow would be pushed beyond its latency requirements by the new DetNet flow request, then the new DetNet flow request can be refused or some other suitable action can be taken.
動的遅延計算は、セクション3.1.1で説明した静的なものに基づいて実行できます。新しいDetnet Flowが作成または削除されると、すべてのDetnetフローの計算全体が繰り返されます。既に確立されたDetnetフローが新しいDetnet Flowリクエストによってレイテンシの要件を超えてプッシュされる場合、新しいDetnet Flowリクエストを拒否するか、他の適切なアクションを実行できます。
The choice of queuing methods is critical to the applicability of the dynamic calculation. Some queuing methods (e.g., CQF, Section 6.6) make it easy to configure bounds on the network's capacity and to make independent calculations for each DetNet flow. Some other queuing methods (e.g., strict priority with the credit-based shaper defined in Section 8.6.8.2 of [IEEE8021Q]) can be used for dynamic DetNet flow creation but yield poorer latency and buffer space guarantees than when that same queuing method is used for static DetNet flow creation (Section 3.1.1).
キューイング方法の選択は、動的計算の適用性にとって重要です。いくつかのキューイング方法（例：CQF、セクション6.6）により、ネットワークの容量の境界を簡単に構成し、各デットネットフローの独立した計算を行うことができます。他のいくつかのキューイング方法（例えば、[IEEE8021Q]のセクション8.6.8.2で定義されているクレジットベースのシェーパーの厳格な優先順位）は、ダイナミックディットネットの流れの作成に使用できますが、同じキューイング方法が使用される場合よりも低いレイテンシとバッファースペース保証を得ることができます。静的デットネットの流れの作成の場合（セクション3.1.1）。
A model for the operation of a DetNet transit node is required in order to define the latency and buffer calculations. In Figure 1, we see a breakdown of the per-hop latency experienced by a packet passing through a DetNet transit node in terms that are suitable for computing both hop-by-hop latency and per-hop buffer requirements.
レイテンシとバッファの計算を定義するために、DETNETトランジットノードの操作のモデルが必要です。図1には、ホップバイホップレイテンシとホップごとのバッファー要件の両方を計算するのに適した用語で、デットネットトランジットノードを通過するパケットが経験するホップごとの遅延の内訳が表示されます。
DetNet transit node A DetNet transit node B
+-------------------------+ +------------------------+
| Queuing | | Queuing |
| Regulator subsystem | | Regulator subsystem |
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
-->+ | | | | | | | | | + +------>+ | | | | | | | | | + +--->
| +-+-+-+-+ +-+-+-+-+ | | +-+-+-+-+ +-+-+-+-+ |
| | | |
+-------------------------+ +------------------------+
|<->|<------>|<------->|<->|<---->|<->|<------>|<------>|<->|<--
2,3 4 5 6 1 2,3 4 5 6 1 2,3
1: Output delay 4: Processing delay
2: Link delay 5: Regulation delay
3: Frame preemption delay 6: Queuing subsystem delay
Figure 1: Timing Model for DetNet or TSN
図1：DetNetまたはTSNのタイミングモデル
In Figure 1, we see two DetNet transit nodes that are connected via a link. In this model, the only queues that we deal with explicitly are attached to the output port; other queues are modeled as variations in the other delay times (e.g., an input queue could be modeled as either a variation in the link delay (2) or the processing delay (4)). There are six delays that a packet can experience from hop to hop.
図1には、リンクを介して接続されている2つのDETNETトランジットノードが表示されます。このモデルでは、私たちが扱う唯一のキューが明示的に出力ポートに接続されています。他のキューは、他の遅延時間の変動としてモデル化されます（たとえば、入力キューは、リンク遅延（2）または処理遅延（4）の変動のいずれかとしてモデル化できます）。パケットがホップからホップまで体験できる6つの遅延があります。
1. Output delay
1. 出力遅延
This is the time taken from the selection of a packet for output from a queue to the transmission of the first bit of the packet on the physical link. If the queue is directly attached to the physical port, output delay can be a constant. However, in many implementations, a multiplexed connection separates the queuing mechanism from a multi-port Network Interface Card (NIC). This causes variations in the output delay that are hard for the forwarding node to predict or control.
これは、キューから出力用のパケットの選択から、物理リンク上のパケットの最初のビットの送信までの時間です。キューが物理ポートに直接接続されている場合、出力遅延は定数になります。ただし、多くの実装では、多重化された接続がキューイングメカニズムをマルチポートネットワークインターフェイスカード（NIC）から分離します。これにより、転送ノードが予測または制御するのが難しい出力遅延の変動が発生します。
2. Link delay
2. リンク遅延
This is the time taken from the transmission of the first bit of the packet to the reception of the last bit, assuming that the transmission is not suspended by a frame preemption event. This delay has two components: the first-bit-out to first-bit-in delay and the first-bit-in to last-bit-in delay that varies with packet size. The former is typically constant. However, a virtual "link" could exhibit a variable link delay.
これは、パケットの最初のビットの送信から、フレームプリエンプションイベントによって送信が吊り下げられていないと仮定して、最後のビットの受信までの時間です。この遅延には2つのコンポーネントがあります。ファーストビットアウトからファーストビットインの遅延と、パケットサイズによって変化する最初のビットインからラストビットインの遅延です。前者は通常一定です。ただし、仮想の「リンク」は可変リンク遅延を示す可能性があります。
3. Frame preemption delay
3. フレームプリエンプション遅延
If the packet is interrupted in order to transmit another packet or packets (e.g., frame preemption, as in [IEEE8023], clause 99), an arbitrary delay can result.
別のパケットまたはパケットを送信するためにパケットが中断された場合（たとえば、[IEEE8023]、節99のようにフレームの先制）、任意の遅延が生じる可能性があります。
4. Processing delay
4. 処理遅延
This delay covers the time from the reception of the last bit of the packet to the time the packet is enqueued in the regulator (queuing subsystem if there is no regulator), as shown in Figure 1. This delay can be variable and depends on the details of the operation of the forwarding node.
この遅延は、図1に示すように、パケットの最後のビットからパケットの受信からパケットがレギュレータに囲まれている時間（レギュレータがない場合はキューイングシステム）に囲まれている時間をカバーします。この遅延は可変であり、転送ノードの操作の詳細。
5. Regulator queuing delay
5. レギュレータキューイング遅延
A regulator, also known as shaper in [RFC2475], delays some or all of the packets in a traffic stream in order to bring the stream into compliance with an arrival curve; an arrival curve 'alpha(t)' is an upper bound on the number of bits observed within any interval t. The regulator delay is the time spent from the insertion of the last bit of a packet into a regulation queue until the time the packet is declared eligible according to its regulation constraints. We assume that this time can be calculated based on the details of regulation policy. If there is no regulation, this time is zero.
[RFC2475]でもシェイパーとしても知られるレギュレータは、到着曲線のコンプライアンスにストリームを導入するために、トラフィックストリームの一部またはすべてのパケットを遅らせます。到着曲線「アルファ（t）」は、任意の間隔t内で観察されるビットの数の上限です。レギュレーターの遅延は、レギュレーションキューにパケットの最後のビットを挿入してから、パケットが規制の制約に従って適格であると宣言されるまでの時間です。この時間は、規制ポリシーの詳細に基づいて計算できると仮定します。規制がない場合、今回はゼロです。
6. Queuing subsystem delay
6. キューイングサブシステムの遅延
This is the time spent for a packet from being declared eligible until being selected for output on the next link. We assume that this time is calculable based on the details of the queuing mechanism. If there is no regulation, this time is from the insertion of the packet into a queue until it is selected for output on the next link.
これは、パケットに費やされた時間であり、次のリンクで出力のために選択されているまで適格であると宣言されるまでです。この時間は、キューイングメカニズムの詳細に基づいて計算可能であると仮定します。規制がない場合、今回は、次のリンクの出力用に選択されるまで、パケットのキューへの挿入からです。
Not shown in Figure 1 are the other output queues that we presume are also attached to that same output port as the queue shown, and against which this shown queue competes for transmission opportunities.
図1には、表示されているキューと同じ出力ポートにも取り付けられていると思われる他の出力キューには示されていません。
In this analysis, the measurement is from the point at which a packet is selected for output in a node to the point at which it is selected for output in the next downstream node (i.e., the definition of a "hop"). In general, any queue selection method that is suitable for use in a DetNet network includes a detailed specification as to exactly when packets are selected for transmission. Any variations in any of the delay times 1-4 result in a need for additional buffers in the queue. If all delays 1-4 are constant, then any variation in the time at which packets are inserted into a queue depends entirely on the timing of packet selection in the previous node. If delays 1-4 are not constant, then additional buffers are required in the queue to absorb these variations. Thus:
この分析では、測定は、ノードの出力用のパケットが選択されているポイントから、次のダウンストリームノードの出力用に選択されるポイント（つまり、「ホップ」の定義）です。一般に、デットネットネットワークでの使用に適したキュー選択方法には、送信用にパケットがいつ選択されるかについての詳細な仕様が含まれています。遅延時間1〜4のいずれかのバリエーションが、キューに追加のバッファーが必要になります。すべての遅延1-4が一定の場合、パケットがキューに挿入される時間の変動は、前のノードでのパケット選択のタイミングに完全に依存します。遅延1-4が一定でない場合、これらのバリエーションを吸収するには、キューに追加のバッファが必要です。したがって：
* Variations in the output delay (1) require buffers to absorb that variation in the next hop, so the output delay variations of the previous hop (on each input port) must be known in order to calculate the buffer space required on this hop.
* 出力遅延（1）の変動では、次のホップでその変動を吸収するバッファーが必要なため、このホップに必要なバッファースペースを計算するために、前のホップ（各入力ポート）の出力遅延変動を把握する必要があります。
* Variations in the processing delay (4) require additional output buffers in the queues of that same DetNet transit node. Depending on the details of the queuing subsystem delay (6) calculations, these variations need not be visible outside the DetNet transit node.
* 処理遅延（4）の変動には、同じDETNETトランジットノードのキューに追加の出力バッファーが必要です。キューイングサブシステムの遅延（6）計算の詳細に応じて、これらのバリエーションは、デットネットトランジットノードの外側に表示する必要はありません。
End-to-end latency bounds can be computed using the delay model in Section 3.2. Here, it is important to be aware that, for several queuing mechanisms, the end-to-end latency bound is less than the sum of the per-hop latency bounds. An end-to-end latency bound for one DetNet flow can be computed as
セクション3.2の遅延モデルを使用して、エンドツーエンドのレイテンシ境界を計算できます。ここでは、いくつかのキューイングメカニズムについて、エンドツーエンドのレイテンシバウンドがホップごとのレイテンシ境界の合計よりも小さいことに注意することが重要です。1つのデットネットフローにバインドされたエンドツーエンドのレイテンシは、
end_to_end_delay_bound = non_queuing_delay_bound + queuing_delay_bound
end_to_end_delay_bound = non_queuing_delay_bound queuing_delay_bound
The two terms in the above formula are computed as follows.
上記の式の2つの用語は、次のように計算されます。
First, at the h-th hop along the path of this DetNet flow, obtain an upper-bound per-hop_non_queuing_delay_bound[h] on the sum of the bounds over delays 1, 2, 3, and 4 of Figure 1. These upper bounds are expected to depend on the specific technology of the DetNet transit node at the h-th hop but not on the T-SPEC of this DetNet flow [RFC9016]. Then, set non_queuing_delay_bound = the sum of per-hop_non_queuing_delay_bound[h] over all hops h.
まず、このデットネットの流れのパスに沿ったH-Thhホップで、上限パーバウンドPER-HOP_NON_QUEUING_DELAY_BOUND [H]を取得します。H-Th HOPでのDETNETトランジットノードの特定のテクノロジーに依存することが期待されていますが、このデットネットフロー[RFC9016]のT-Specには依存しません。次に、non_queuing_delay_bound = per-hop_non_queuing_delay_bound [h]の合計をすべてのホップhで設定します。
Second, compute queuing_delay_bound as an upper bound to the sum of the queuing delays along the path. The value of queuing_delay_bound depends on the information on the arrival curve of this DetNet flow and possibly of other flows in the network, as well as the specifics of the queuing mechanisms deployed along the path of this DetNet flow. Note that arrival curve of the DetNet flow at the source is immediately specified by the T-SPEC of this flow. The computation of queuing_delay_bound is described in Section 4.2 as a separate section.
次に、パスに沿ったキューイングの遅延の合計の上限としてqueuing_delay_boundを計算します。queuing_delay_boundの値は、このデットネットフローの到着曲線と、場合によってはネットワーク内の他のフローの情報、およびこのデットネットフローの経路に沿って展開されたキューイングメカニズムの詳細に依存します。ソースでのデットネットフローの到着曲線は、このフローのT-Specによってすぐに指定されることに注意してください。queuing_delay_boundの計算は、セクション4.2で別のセクションとして説明されています。
For several queuing mechanisms, queuing_delay_bound is less than the sum of upper bounds on the queuing delays (5 and 6) at every hop. This occurs with (1) per-flow queuing and (2) aggregate queuing with regulators, as explained in Sections 4.2.1, 4.2.2, and 6. For other queuing mechanisms, the only available value of queuing_delay_bound is the sum of the per-hop queuing delay bounds.
いくつかのキューイングメカニズムでは、Queuing_delay_boundは、すべてのホップでキューイングの遅延（5および6）の上限の合計よりも少ない。これは、セクション4.2.1、4.2.2、および6で説明されているように、（1）あたりのキューイングと（2）調節因子との凝集キューイングで発生します。ホップごとのキューイングの遅延境界。
The computation of per-hop queuing delay bounds must account for the fact that the arrival curve of a DetNet flow is no longer satisfied at the ingress of a hop, since burstiness increases as one flow traverses one DetNet transit node. If a regulator is placed at a hop, an arrival curve of a DetNet flow at the entrance of the queuing subsystem of this hop is the one configured at the regulator (also called shaping curve in [NetCalBook]); otherwise, an arrival curve of the flow can be derived using the delay jitter of the flow from the last regulation point (the last regulator in the path of the flow if there is any, otherwise the source of the flow) to the ingress of the hop; more formally, assume a DetNet flow has an arrival curve at the last regulation point equal to 'alpha(t)' and the delay jitter from the last regulation point to the ingress of the hop is 'V'. Then, the arrival curve at the ingress of the hop is 'alpha(t+V)'.
1つのフローが1つのデットネットトランジットノードを横断すると破裂が増加するため、ホップごとのキューイングの遅延境界の計算は、ホップの侵入でデットネットフローの到着曲線がもはや満たされないという事実を説明する必要があります。レギュレーターがホップに配置されている場合、このホップのキューイングサブシステムの入り口にあるデットネットフローの到着曲線は、レギュレータで構成されたものです（[netcalbook]の形状曲線とも呼ばれます）。それ以外の場合は、フローの到着曲線は、最後のレギュレーションポイント（フローの経路にある最後のレギュレータ）から、フローの供給源がある場合、フローのパスの最後のレギュレータ）を使用して導出できます。ホップ;より正式には、ディットネットの流れが「アルファ（t）」に等しい最後のレギュレーションポイントに到着曲線があり、最後のレギュレーションポイントからホップの侵入までの遅延ジッターが「V」であると仮定します。次に、ホップの侵入の到着曲線は「アルファ（T V）」です。
For example, consider a DetNet flow with T-SPEC "Interval: tau,
MaxPacketsPerInterval: K, MaxPayloadSize: L" at the source. Then, a
leaky-bucket arrival curve for such flow at the source is alpha(t)=r
* t+ b, t>0; alpha(0)=0, where r is the rate and b is the bucket
size, computed as
r = K * (L+L') / tau,
r = k *（l l '） / tau、
b = K * (L+L').
b = k *（l l '）。
where L' is the size of any added networking technology-specific encapsulation (e.g., MPLS label(s), UDP, or IP headers). Now, if the flow has a delay jitter of 'V' from the last regulation point to the ingress of a hop, an arrival curve at this point is r * t + b + r * V, implying that the burstiness is increased by r*V. More detailed information on arrival curves is available in [NetCalBook].
ここで、L 'は、追加されたネットワーク技術固有のカプセル化のサイズです（例：MPLSラベル、UDP、またはIPヘッダーなど）。これで、フローに最後のレギュレーションポイントからホップの侵入まで「V」の遅延ジッターがある場合、この時点での到着曲線はr * t b r * vです。到着曲線に関する詳細情報は[netcalbook]で入手できます。
With such mechanisms, each flow uses a separate queue inside every node. The service for each queue is abstracted with a guaranteed rate and a latency. For every DetNet flow, a per-node latency bound, as well as an end-to-end latency bound, can be computed from the traffic specification of this DetNet flow at its source and from the values of rates and latencies at all nodes along its path. An instance of per-flow queuing is Guaranteed Service [RFC2212], for which the details of latency bound calculation are presented in Section 6.5.
このようなメカニズムを使用すると、各フローはすべてのノード内に個別のキューを使用します。各キューのサービスは、保証されたレートとレイテンシで抽象化されます。すべてのデットネットフローについて、ノードごとのレイテンシバウンド、およびエンドツーエンドのレイテンシバウンドは、そのソースでのこのデットネットフローのトラフィック仕様と、沿ったすべてのノードでのレートとレイテンシーの値から計算できます。その道。流量あたりのキューイングのインスタンスは保証されたサービス[RFC2212]であり、レイテンシバウンド計算の詳細はセクション6.5に示されています。
With such mechanisms, multiple flows are aggregated into macro-flows and there is one FIFO queue per macro-flow. A practical example is the credit-based shaper defined in Section 8.6.8.2 of [IEEE8021Q], where a macro-flow is called a "class". One key issue in this context is how to deal with the burstiness cascade; individual flows that share a resource dedicated to a macro-flow may see their burstiness increase, which may in turn cause increased burstiness to other flows downstream of this resource. Computing delay upper bounds for such cases is difficult and, in some conditions, impossible [CharnyDelay] [BennettDelay]. Also, when bounds are obtained, they depend on the complete configuration and must be recomputed when one flow is added (i.e., the dynamic calculation in Section 3.1.2).
このようなメカニズムを使用すると、複数のフローがマクロフローに集約され、マクロフローごとに1つのFIFOキューがあります。実用的な例は、[IEEE8021Q]のセクション8.6.8.2で定義されているクレジットベースのシェーパーで、マクロフローは「クラス」と呼ばれます。この文脈における重要な問題の1つは、バーストネスカスケードに対処する方法です。マクロフローに特化したリソースを共有する個々のフローは、彼らの破裂が増加する可能性があります。そのような場合のコンピューティング遅延上限は困難であり、いくつかの条件では不可能[Charnydelay] [Bennettdelay]。また、境界が取得されると、それらは完全な構成に依存し、1つのフローを追加すると再計算する必要があります（つまり、セクション3.1.2の動的計算）。
A solution to deal with this issue for the DetNet flows is to reshape them at every hop. This can be done with per-flow regulators (e.g., leaky-bucket shapers), but this requires per-flow queuing and defeats the purpose of aggregate queuing. An alternative is the interleaved regulator, which reshapes individual DetNet flows without per-flow queuing [SpechtUBS] [IEEE8021Qcr]. With an interleaved regulator, the packet at the head of the queue is regulated based on its (flow) regulation constraints; it is released at the earliest time at which this is possible without violating the constraint. One key feature of a per-flow or interleaved regulator is that it does not increase worst-case latency bounds [LeBoudecTheory]. Specifically, when an interleaved regulator is appended to a FIFO subsystem, it does not increase the worst-case delay of the latter. In Figure 1, when the order of packets from the output of a queuing subsystem at node A to the entrance of a regulator at node B is preserved, then the regulator does not increase the worst-case latency bounds. This is made possible if all the systems are FIFO or a DetNet Packet Ordering Function (POF) is implemented just before the regulator. This property does not hold if packet reordering occurs from the output of a queuing subsystem to the entrance of the next downstream interleaved regulator, e.g., at a non-FIFO switching fabric.
この問題に対処するための解決策は、すべてのホップでそれらを再構築することです。これは、フローごとのレギュレーター（漏れやすいバケットシェイパーなど）で行うことができますが、これにはフローごとのキューイングが必要であり、キューイングの目的を打ち負かします。別の方法は、インターリーブレギュレーターであり、フローごとのキューイングをせずに個々のデットネットフローを再形成します[spechtubs] [IEEE8021QCR]。インターリーブレギュレーターを使用すると、キューの頭のパケットは、その（フロー）規制の制約に基づいて規制されています。制約に違反することなくこれが可能である最も早い時期にリリースされます。流量またはインターリーブレギュレーターの重要な特徴の1つは、最悪のレイテンシ境界を増加させないことです[leboudectheory]。具体的には、インターリーブレギュレーターがFIFOサブシステムに追加される場合、後者の最悪の遅延は増加しません。図1では、ノードAのキューイングシステムの出力からノードBのレギュレータの入り口へのパケットの順序が保存されている場合、レギュレータは最悪のケースの遅延境界を増加させません。これは、すべてのシステムがFIFOまたはディットネットパケット順序関数（POF）がレギュレーターの直前に実装されている場合に可能になります。このプロパティは、キューイングサブシステムの出力から次のダウンストリームインターリーブレギュレーターの入り口、たとえば、非FIFOスイッチングファブリックでの入り口に発生した場合、このプロパティは保持されません。
Figure 2 shows an example of a network with 5 nodes, an aggregate queuing mechanism, and interleaved regulators, as in Figure 1. An end-to-end delay bound for DetNet flow f, traversing nodes 1 to 5, is calculated as follows:
図2は、図1のように、5つのノード、凝集キューイングメカニズム、およびインターリーブレギュレーターを備えたネットワークの例を示しています。
end_to_end_latency_bound_of_flow_f = C12 + C23 + C34 + S4
In the above formula, Cij is a bound on the delay of the queuing subsystem in node i and interleaved regulator of node j, and S4 is a bound on the delay of the queuing subsystem in node 4 for DetNet flow f. In fact, using the delay definitions in Section 3.2, Cij is a bound on a sum of delays 1, 2, 3, and 6 of node i and delays 4 and 5 of node j. Similarly, S4 is a bound on sum of delays 1, 2, 3, and 6 of node 4. A practical example of the queuing model and delay calculation is presented Section 6.4.
上記の式では、CIJはノードIのキューイングシステムとノードJのインターリーブレギュレーターの遅延にバインドされており、S4は、デトネットフローfのノード4のキューイングシステムの遅延にバインドされています。実際、セクション3.2の遅延定義を使用して、CIJは、ノードIの遅延1、2、3、および6の合計とノードJの遅延4および5の合計にバインドされています。同様に、S4は、ノード4の遅延1、2、3、および6の合計にバインドされています。キューイングモデルと遅延計算の実用的な例については、セクション6.4を示します。
f
----------------------------->
+---+ +---+ +---+ +---+ +---+
| 1 |---| 2 |---| 3 |---| 4 |---| 5 |
+---+ +---+ +---+ +---+ +---+
\__C12_/\__C23_/\__C34_/\_S4_/
Figure 2: End-to-End Delay Computation Example
図2：エンドツーエンド遅延計算の例
If packet reordering does not occur, the end-to-end latency bound calculation provided here gives a tighter latency upper bound than would be obtained by adding the latency bounds of each node in the path of a DetNet flow [TSNwithATS].
パケットの並べ替えが発生しない場合、ここで提供されるエンドツーエンドのレイテンシバウンド計算は、デットネットフロー[TSNWITHATS]のパスに各ノードのレイテンシ境界を追加することで得られるよりも緊密なレイテンシの上限を与えます。
A sender can be a DetNet node that uses exactly the same queuing methods as its adjacent DetNet transit node so that the latency and buffer bounds calculations at the first hop are indistinguishable from those at a later hop within the DetNet domain. On the other hand, the sender may be DetNet unaware; in which case, some conditioning of the DetNet flow may be necessary at the ingress DetNet transit node. The ingress conditioning typically consists of the regulators described in Section 3.2.
送信者は、最初のホップでのレイテンシとバッファーの計算がデットネットドメイン内の後のホップでのレイテン性とバッファーの計算が区別できないように、隣接するデットネットトランジットノードとまったく同じキューイングメソッドを使用するデットネットノードにすることができます。一方、送信者は気付かないことがあります。その場合、Ingress Detnet Transitノードでは、Detnet Flowのいくつかのコンディショニングが必要になる場合があります。侵入条件付けは通常、セクション3.2で説明されているレギュレーターで構成されています。
It is sometimes desirable to build a network that has both DetNet-aware transit nodes and DetNet-unaware transit nodes and for a DetNet flow to traverse an island of DetNet-unaware transit nodes while still allowing the network to offer delay and congestion loss guarantees. This is possible under certain conditions.
デットネットに認識されたトランジットノードとデトネットに不名誉なトランジットノードの両方を備えたネットワークを構築することが望ましい場合があります。これは特定の条件下で可能です。
In general, when passing through a DetNet-unaware island, the island may cause delay variation in excess of what would be caused by DetNet nodes. That is, the DetNet flow might be "lumpier" after traversing the DetNet-unaware island. DetNet guarantees for delay and buffer requirements can still be calculated and met if and only if the following are true:
一般に、Detnet-Unaware島を通過すると、島はDetnetノードによって引き起こされるものを超える遅延変動を引き起こす可能性があります。つまり、Detnet-Unaware Islandを横断した後、Detnet Flowは「不安定」になる可能性があります。遅延およびバッファーの要件のためのDetNet保証は、以下が真である場合にのみ計算し、満たすことができます。
1. The latency variation across the DetNet-unaware island must be bounded and calculable.
1. Detnet-Unaware島全体の潜伏期のバリエーションは、境界と計算可能でなければなりません。
2. An ingress conditioning function (Section 4.3) is required at the reentry to the DetNet-aware domain. This will, at least, require some extra buffering to accommodate the additional delay variation and thus further increases the latency bound.
2. 侵入条件付け関数（セクション4.3）は、detnet-awareドメインへの再突入時に必要です。これには、少なくとも、追加の遅延の変動に対応するためにいくつかの追加バッファリングが必要であり、したがって、レイテンシバウンドがさらに増加します。
The ingress conditioning is exactly the same problem as that of a sender at the edge of the DetNet domain. The requirement for bounds on the latency variation across the DetNet-unaware island is typically the most difficult to achieve. Without such a bound, it is obvious that DetNet cannot deliver its guarantees, so a DetNet-unaware island that cannot offer bounded latency variation cannot be used to carry a DetNet flow.
イングレスコンディショニングは、デットネットドメインの端にある送信者の問題とまったく同じ問題です。Detnet-Unaware島全体の潜伏期のバリエーションの境界の要件は、通常、達成が最も困難です。このような境界がなければ、Detnetがその保証を提供できないことは明らかです。そのため、境界のあるレイテンシのバリエーションを提供できないDetnet-Unawareの島は、Detnet Flowを運ぶために使用できません。
When the input rate to an output queue exceeds the output rate for a sufficient length of time, the queue must overflow. This is congestion loss, and this is what DetNet seeks to avoid.
出力キューへの入力率が十分な時間の出力率を超える場合、キューはオーバーフローする必要があります。これは混雑の損失であり、これがDetnetが回避しようとしているものです。
To avoid congestion losses, an upper bound on the backlog present in the regulator and queuing subsystem of Figure 1 must be computed during resource reservation. This bound depends on the set of flows that use these queues, the details of the specific queuing mechanism, and an upper bound on the processing delay (4). The queue must contain the packet in transmission, plus all other packets that are waiting to be selected for output. A conservative backlog bound that applies to all systems can be derived as follows.
うっ血損失を回避するには、レギュレーターに存在するバックログの上限と図1のキューイングシステムをリソースの予約中に計算する必要があります。このバウンドは、これらのキューを使用するフローのセット、特定のキューイングメカニズムの詳細、および処理遅延の上限に依存します（4）。キューには、送信のパケットに加えて、出力のために選択されるのを待っている他のすべてのパケットが含まれている必要があります。すべてのシステムに適用される保守的なバックログバインドは、次のように導出できます。
The backlog bound is counted in data units (bytes or words of multiple bytes) that are relevant for buffer allocation. For every flow or an aggregate of flows, we need one buffer space for the packet in transmission, plus space for the packets that are waiting to be selected for output.
バックログ結合は、バッファの割り当てに関連するデータ単位（複数のバイトのバイトまたは単語）でカウントされます。フローまたはフローの骨材ごとに、送信中のパケット用のバッファースペースが1つ、出力用に選択されるのを待っているパケット用のスペースが必要です。
Let
させて
* total_in_rate be the sum of the line rates of all input ports that send traffic to this output port. The value of total_in_rate is in data units (e.g., bytes) per second.
* Total_in_rateこの出力ポートにトラフィックを送信するすべての入力ポートのラインレートの合計。Total_in_rateの値は、データ単位（たとえば、バイト）に1秒あたりです。
* nb_input_ports be the number of input ports that send traffic to this output port.
* nb_input_portsこの出力ポートにトラフィックを送信する入力ポートの数。
* max_packet_length be the maximum packet size for packets that may be sent to this output port. This is counted in data units.
* max_packet_lengthこの出力ポートに送信される可能性のあるパケットの最大パケットサイズです。これはデータユニットでカウントされます。
* max_delay456 be an upper bound, in seconds, on the sum of the processing delay (4) and the queuing delays (5 and 6) for any packet at this output port.
* MAX_DELAY456この出力ポートのパケットの処理遅延（4）とキューイングの遅延（5および6）の合計の上で、数秒で上限になります。
Then, a bound on the backlog of traffic in the queue at this output port is
次に、この出力ポートのキューのトラフィックのバックログにバインドされています
backlog_bound = (nb_input_ports * max_packet_length) +
(total_in_rate * max_delay456)
The above bound is over the backlog caused by the traffic entering the queue from the input ports of a DetNet node. If the DetNet node also generates packets (e.g., creation of new packets or replication of arriving packets), the bound must accordingly incorporate the introduced backlog.
上記のバウンドは、デットネットノードの入力ポートからキューに入るトラフィックが原因となるバックログの上にあります。Detnetノードがパケット（たとえば、新しいパケットの作成や到着パケットの複製）も生成する場合、バウンドには導入されたバックログを組み込む必要があります。
In this section, we present a general queuing data model, as well as some examples of queuing mechanisms. For simplicity of latency bound computation, we assume a leaky-bucket arrival curve for each DetNet flow at the source. Also, at each DetNet transit node, the service for each queue is abstracted with a minimum guaranteed rate and a latency [NetCalBook].
このセクションでは、一般的なキューイングデータモデルとキューイングメカニズムの例をいくつか紹介します。レイテンシバウンド計算を簡単にするために、ソースの各デットネットフローの漏れやすいバケット到着曲線を想定しています。また、各デットネットトランジットノードでは、各キューのサービスは最小保証レートとレイテンシ[NetCalbook]で抽象化されます。
Sophisticated queuing mechanisms are available in Layer 3 (L3) (e.g., see [RFC7806] for an overview). In general, we assume that "Layer 3" queues, shapers, meters, etc., are precisely the "regulators" shown in Figure 1. The "queuing subsystems" in this figure are FIFO. They are not the province solely of bridges; they are an essential part of any DetNet transit node. As illustrated by numerous implementation examples, some of the "Layer 3" mechanisms described in documents, such as [RFC7806], are often integrated in an implementation, with the "Layer 2" mechanisms also implemented in the same node. An integrated model is needed in order to successfully predict the interactions among the different queuing mechanisms needed in a network carrying both DetNet flows and non-DetNet flows.
洗練されたキューイングメカニズムは、レイヤー3（L3）（たとえば、概要については[RFC7806]を参照）で利用できます。一般に、「レイヤー3」キュー、シェイパー、メーターなどが、まさに図1に示す「規制当局」であると想定しています。この図の「キューイングシステム」はFIFOです。彼らは橋だけの州ではありません。これらは、Detnet Transitノードの重要な部分です。多数の実装例に示されているように、[RFC7806]などのドキュメントで説明されている「レイヤー3」メカニズムの一部は、多くの場合、実装に統合され、「レイヤー2」メカニズムも同じノードに実装されています。統合されたモデルが、デットネットフローと非デトネットフローの両方を運ぶネットワークで必要なさまざまなキューイングメカニズム間の相互作用を正常に予測するために必要です。
Figure 3 shows the general model for the flow of packets through the queues of a DetNet transit node. The DetNet packets are mapped to a number of regulators. Here, we assume that the Packet Replication, Elimination, and Ordering Functions (PREOF) are performed before the DetNet packets enter the regulators. All packets are assigned to a set of queues. Packets compete for the selection to be passed to queues in the queuing subsystem. Packets again are selected for output from the queuing subsystem.
図3は、ディットネットトランジットノードのキューを介したパケットの流れの一般的なモデルを示しています。Detnetパケットは、多くの規制当局にマッピングされます。ここでは、ディットネットパケットがレギュレーターに入る前に、パケットの複製、排除、および順序機能（PREOF）が実行されると想定しています。すべてのパケットは一連のキューに割り当てられます。パケットは、キューイングサブシステムのキューに渡されるために選択を競います。パケットは、キューイングサブシステムからの出力用に再度選択されます。
|
+--------------------------------V----------------------------------+
| Queue assignment |
+--+------+----------+---------+-----------+-----+-------+-------+--+
| | | | | | | |
+--V-+ +--V-+ +--V--+ +--V--+ +--V--+ | | |
|Flow| |Flow| |Flow | |Flow | |Flow | | | |
| 0 | | 1 | ... | i | | i+1 | ... | n | | | |
| reg| | reg| | reg | | reg | | reg | | | |
+--+-+ +--+-+ +--+--+ +--+--+ +--+--+ | | |
| | | | | | | |
+--V------V----------V--+ +--V-----------V--+ | | |
| Trans. selection | | Trans. select. | | | |
+----------+------------+ +-----+-----------+ | | |
| | | | |
+--V--+ +--V--+ +--V--+ +--V--+ +--V--+
| out | | out | | out | | out | | out |
|queue| |queue| |queue| |queue| |queue|
| 1 | | 2 | | 3 | | 4 | | 5 |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | |
+----------V----------------------V--------------V-------V-------V--+
| Transmission selection |
+---------------------------------+---------------------------------+
|
V
Figure 3: IEEE 802.1Q Queuing Model: Data Flow
図3：IEEE 802.1Qキューイングモデル：データフロー
Some relevant mechanisms are hidden in this figure and are performed in the queue boxes:
いくつかの関連するメカニズムはこの図に隠されており、キューボックスで実行されます。
* discarding packets because a queue is full
* キューがいっぱいであるため、パケットを破棄します
* discarding packets marked "yellow" by a metering function in preference to discarding "green" packets [RFC2697]
* 「グリーン」パケットを破棄することを好む計量関数によって「黄色」とマークされたパケットの破棄[RFC2697]
Ideally, neither of these actions are performed on DetNet packets. Full queues for DetNet packets occur only when a DetNet flow is misbehaving, and the DetNet QoS does not include "yellow" service for packets in excess of a committed rate.
理想的には、これらのアクションはどちらもDetnetパケットで実行されません。Detnetパケットの完全なキューは、Detnet Flowが誤動作している場合にのみ発生し、Detnet QOにはコミットレートを超えるパケットの「黄色」サービスは含まれていません。
The queue assignment function can be quite complex, even in a bridge [IEEE8021Q], because of the introduction of per-stream filtering and policing ([IEEE8021Q], clause 8.6.5.1). In addition to the Layer 2 priority expressed in the 802.1Q VLAN tag, a DetNet transit node can utilize the information from the non-exhaustive list below to assign a packet to a particular queue:
キューの割り当て関数は、ストリームごとのフィルタリングとポリシングの導入（[IEEE8021Q]、条項8.6.5.1）の導入により、ブリッジ[IEEE8021Q]であっても非常に複雑です。802.1Q VLANタグで表されたレイヤー2の優先度に加えて、Detnet Transitノードは以下の非網羅的なリストから情報を利用して、特定のキューにパケットを割り当てることができます。
* input port
* 入力ポート
* selector based on a rotating schedule that starts at regular, time-synchronized intervals and has nanosecond precision
* 定期的な時間と同級の間隔から始まり、ナノ秒の精度がある回転スケジュールに基づくセレクター
* MAC addresses, VLAN ID, IP addresses, Layer 4 port numbers, and Differentiated Services Code Point (DSCP) [RFC8939] [RFC8964]
* Macアドレス、VLAN ID、IPアドレス、レイヤー4ポート番号、および差別化されたサービスコードポイント（DSCP）[RFC8939] [RFC8964]
* the queue assignment function can contain metering and policing functions
* キューの割り当て関数には、メータリングおよびポリシング機能を含めることができます
* MPLS and/or pseudowire labels [RFC6658]
* MPLSおよび/またはPSEUDOWIREラベル[RFC6658]
The "Transmission selection" function decides which queue is to transfer its oldest packet to the output port when a transmission opportunity arises.
「送信選択」関数は、送信機会が発生したときに最も古いパケットを出力ポートに転送するキューを決定します。
In [IEEE8021Q] and [IEEE8023], the transmission of a frame can be interrupted by one or more "express" frames; then, the interrupted frame can continue transmission. The frame preemption is modeled as consisting of two MAC/PHY stacks: one for packets that can be interrupted and one for packets that can interrupt the interruptible packets. Only one layer of frame preemption is supported -- a transmitter cannot have more than one interrupted frame in progress. DetNet flows typically pass through the interrupting MAC. For those DetNet flows with T-SPEC, latency bounds can be calculated by the methods provided in the following sections that account for the effect of frame preemption, according to the specific queuing mechanism that is used in DetNet nodes. Best-effort queues pass through the interruptible MAC and can thus be preempted.
[IEEE8021Q]および[IEEE8023]では、フレームの送信は、1つ以上の「Express」フレームによって中断される可能性があります。その後、中断されたフレームは送信を継続できます。フレームプリエンプションは、2つのMac/Phyスタックで構成されるものとしてモデル化されています。1つは中断できるパケット用、もう1つは中断可能なパケットを中断できるパケット用です。フレームプリエンプションの1層のみがサポートされています。トランスミッターは、進行中の複数の中断されたフレームを持つことはできません。通常、ディットネットフローは、中断するMacを通過します。T-Specを使用したこれらのDetnetフローについては、Detnetノードで使用される特定のキューイングメカニズムに従って、フレームプリエンプションの効果を説明する次のセクションで提供されているメソッドによってレイテンシ境界を計算できます。中断可能なMacを通過するベストエフォルトのキューは、したがって、先制することができます。
In [IEEE8021Q], the notion of time-scheduling queue gates is described in Section 8.6.8.4. On each node, the transmission selection for packets is controlled by time-synchronized gates; each output queue is associated with a gate. The gates can be either open or closed. The states of the gates are determined by the gate control list (GCL). The GCL specifies the opening and closing times of the gates. The design of the GCL must satisfy the requirement of latency upper bounds of all DetNet flows; therefore, those DetNet flows that traverse a network that uses this kind of shaper must have bounded latency if the traffic and nodes are conformant.
[IEEE8021Q]では、タイムスケジューリングキューゲートの概念については、セクション8.6.8.4で説明しています。各ノードでは、パケットの送信選択は、時間と同時にされたゲートによって制御されます。各出力キューはゲートに関連付けられています。ゲートは開いているか閉じていることができます。ゲートの状態は、ゲート制御リスト（GCL）によって決定されます。GCLは、ゲートの開閉時間を指定します。GCLの設計は、すべてのデットネットフローの潜伏性上限の要件を満たす必要があります。したがって、トラフィックとノードが適合している場合、この種のシェーパーを使用するネットワークを横断するこれらのディットネットフローは、境界レイテンシを持つ必要があります。
Note that scheduled traffic service relies on a synchronized network and coordinated GCL configuration. Synthesis of the GCL on multiple nodes in a network is a scheduling problem considering all DetNet flows traversing the network, which is a nondeterministic polynomial-time hard (NP-hard) problem [Sch8021Qbv]. Also, at the time of writing, scheduled traffic service supports no more than eight traffic queues, typically using up to seven priority queues and at least one best effort.
スケジュールされたトラフィックサービスは、同期されたネットワークと調整されたGCL構成に依存していることに注意してください。ネットワーク内の複数のノードでのGCLの合成は、ネットワークを通過するすべてのデットネットフローを考慮したスケジューリング問題です。また、執筆時点では、スケジュールされた交通サービスは8つのトラフィックキュー以下をサポートし、通常は最大7つの優先キューと少なくとも1つの最善の努力を使用します。
In this queuing model, it is assumed that the DetNet nodes are FIFO. We consider the four traffic classes (Definition 3.268 of [IEEE8021Q]): control-data traffic (CDT), class A, class B, and best effort (BE) in decreasing order of priority. Flows of classes A and B are DetNet flows that are less critical than CDT (such as studio audio and video traffic, as in IEEE 802.1BA Audio-Video-Bridging). This model is a subset of Time-Sensitive Networking, as described next.
このキューイングモデルでは、ディットネットノードがFIFOであると想定されています。4つのトラフィッククラス（[IEEE8021Q]の定義3.268）を考慮します。コントロールデータトラフィック（CDT）、クラスA、クラスB、および優先順位の低下に最適な努力（BE）。クラスAとBのフローは、CDTよりも重要ではないデットネットフローです（IEEE 802.1BAオーディオビデオブリッジングのように、スタジオオーディオやビデオトラフィックなど）。このモデルは、次に説明されているように、時間に敏感なネットワーキングのサブセットです。
Based on the timing model described in Figure 1, contention occurs only at the output port of a DetNet transit node; therefore, the focus of the rest of this subsection is on the regulator and queuing subsystem in the output port of a DetNet transit node. The input flows are identified using the information in (Section 5.1 of [RFC8939]). Then, they are aggregated into eight macro-flows based on their service requirements; we refer to each macro-flow as a class. The output port performs aggregate scheduling with eight queues (queuing subsystems): one for CDT, one for class A flows, one for class B flows, and five for BE traffic denoted as BE0-BE4. The queuing policy for each queuing subsystem is FIFO. In addition, each node output port also performs per-flow regulation for class A and B flows using an interleaved regulator (IR). This regulation is called asynchronous traffic shaping [IEEE8021Qcr]. Thus, at each output port of a node, there is one interleaved regulator per input port and per class; the interleaved regulator is mapped to the regulator depicted in Figure 1. The detailed picture of scheduling and regulation architecture at a node output port is given by Figure 4. The packets received at a node input port for a given class are enqueued in the respective interleaved regulator at the output port. Then, the packets from all the flows, including CDT and BE flows, are enqueued in a queuing subsystem; there is no regulator for CDT and BE flows.
図1で説明したタイミングモデルに基づいて、競合は、デットネットトランジットノードの出力ポートでのみ発生します。したがって、このサブセクションの残りの部分の焦点は、デットネットトランジットノードの出力ポートのレギュレーターとキューイングサブシステムにあります。入力フローは、[RFC8939]のセクション5.1）の情報を使用して識別されます。次に、サービス要件に基づいて8つのマクロフローに集約されます。各マクロフローをクラスと呼びます。出力ポートは、8つのキュー（キューイングサブシステム）を備えた集約スケジューリングを実行します。1つはCDT用、1つはクラスAフロー用、1つはクラスBフロー用、5つはBE0-BE4として示されるトラフィックです。各キューイングサブシステムのキューイングポリシーはFIFOです。さらに、各ノード出力ポートは、インターリーブレギュレーター（IR）を使用して、クラスAおよびBフローのフローごとの規制も実行します。この規制は、非同期トラフィック形成[IEEE8021QCR]と呼ばれます。したがって、ノードの各出力ポートに、入力ポートとクラスごとに1つのインターリーブレギュレーターがあります。インターリーブレギュレーターは、図1に示すレギュレータにマッピングされます。ノード出力ポートのスケジューリングおよび規制アーキテクチャの詳細な画像を図4で示します。出力ポートのレギュレータ。次に、CDTやBEフローを含むすべてのフローからのパケットがキューイングサブシステムに囲まれています。 CDTのレギュレーターはありません。
+--+ +--+ +--+ +--+
| | | | | | | |
|IR| |IR| |IR| |IR|
| | | | | | | |
+-++XXX++-+ +-++XXX++-+
| | | |
| | | |
+---+ +-v-XXX-v-+ +-v-XXX-v-+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | |Class| |Class| |Class| |Class| |Class|
|CDT| | Class A | | Class B | | BE4 | | BE3 | | BE2 | | BE1 | | BE0 |
| | | | | | | | | | | | | | | |
+-+-+ +----+----+ +----+----+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | | | |
| +-v-+ +-v-+ | | | | |
| |CBS| |CBS| | | | | |
| +-+-+ +-+-+ | | | | |
| | | | | | | |
+-v--------v-----------v---------v-------V-------v-------v-------v--+
| Strict Priority selection |
+--------------------------------+----------------------------------+
|
V
Figure 4: The Architecture of an Output Port inside a Relay Node with Interleaved Regulators (IRs) and a Credit-Based Shaper (CBS)
図4：インターリーブレギュレーター（IRS）とクレジットベースのシェーパー（CBS）を備えたリレーノード内の出力ポートのアーキテクチャ
Each of the queuing subsystems for classes A and B contains a credit-based shaper (CBS). The CBS serves a packet from a class according to the available credit for that class. As described in Section 8.6.8.2 and Annex L.1 of [IEEE8021Q], the credit for each class A or B increases based on the idle slope (as guaranteed rate) and decreases based on the sendslope (typically equal to the difference between the guaranteed and the output link rates), both of which are parameters of the CBS. The CDT and BE0-BE4 flows are served by separate queuing subsystems. Then, packets from all flows are served by a transmission selection subsystem that serves packets from each class based on its priority. All subsystems are non-preemptive. Guarantees for class A and B traffic can be provided only if CDT is bounded. It is assumed that the CDT has a leaky-bucket arrival curve with two parameters: r_h as rate and b_h as bucket size. That is, the amount of bits entering a node within a time interval t is bounded by r_h * t + b_h.
クラスAとBのキューイングシステムのそれぞれには、クレジットベースのシェーパー（CBS）が含まれています。 CBSは、そのクラスで利用可能なクレジットに従って、クラスからのパケットを提供します。 [IEEE8021Q]のセクション8.6.8.2および付録L.1で説明されているように、各クラスAまたはBのクレジットは、アイドル勾配（保証レートとして）に基づいて増加し、Sendslopeに基づいて減少します（通常、違いに等しいです。保証付きリンクレート）、どちらもCBSのパラメーターです。 CDTおよびBE0-BE4フローは、個別のキューイングシステムによって提供されます。次に、すべてのフローからのパケットは、その優先度に基づいて各クラスのパケットを提供するトランスミッション選択サブシステムによって提供されます。すべてのサブシステムは非寛容です。 CDTが制限されている場合にのみ、クラスAおよびBトラフィックの保証を提供できます。 CDTの2つのパラメーターを備えた漏れやすいバケット到着曲線があると想定されています：R_Hはレートとして、B_Hはバケットサイズとしてです。つまり、時間間隔t内でノードに入るビットの量は、r_h * t b_hで囲まれています。
Additionally, it is assumed that the class A and B flows are also regulated at their source according to a leaky-bucket arrival curve. At the source, the traffic satisfies its regulation constraint, i.e., the delay due to interleaved regulator at the source is ignored.
さらに、クラスAおよびBフローも、漏れやすいバケットの到着曲線に従ってソースで調節されると想定されています。ソースでは、トラフィックは規制の制約を満たしています。つまり、ソースでのインターリーブレギュレーターによる遅延は無視されます。
At each DetNet transit node implementing an interleaved regulator, packets of multiple flows are processed in one FIFO queue. The packet at the head of the queue is regulated based on its leaky-bucket parameters. It is released at the earliest time at which this is possible without violating the constraint.
インターリーブレギュレーターを実装する各デットネットトランジットノードで、複数のフローのパケットが1つのFIFOキューで処理されます。キューの頭のパケットは、その漏れやすいバケットパラメーターに基づいて規制されています。制約に違反することなくこれが可能である最も早い時期にリリースされます。
The regulation parameters for a flow (leaky-bucket rate and bucket size) are the same at its source and at all DetNet transit nodes along its path in the case where all clocks are perfect. However, in reality, there is clock non-ideality throughout the DetNet domain, even with clock synchronization. This phenomenon causes inaccuracy in the rates configured at the regulators that may lead to network instability. To avoid instability, the rates are set as the source rates with some positive margin when configuring regulators. [ThomasTime] describes and provides solutions to this issue.
フロー（漏れやすいバケットレートとバケットサイズ）のレギュレーションパラメーターは、そのソースで同じであり、すべてのクロックが完璧な場合のその経路に沿ったすべてのデットネットトランジットノードで同じです。ただし、実際には、クロック同期がある場合でも、Detnetドメイン全体にクロック非理想性があります。この現象は、ネットワークの不安定性につながる可能性のあるレギュレーターで構成されたレートの不正確さを引き起こします。不安定性を回避するために、レートは、レギュレーターを構成する際にある程度のマージンを持つソースレートとして設定されます。[Thomastime]は、この問題の解決策を説明し、提供します。
A delay bound of the queuing subsystem ((4) in Figure 1) of a given DetNet node for a flow of class A or B can be computed if the following condition holds:
次の条件が保持されている場合、クラスAまたはBのフローの特定のDETNETノードのキューイングサブシステム（（4）の（4））の遅延境界（（4））を計算できます。
The sum of leaky-bucket rates of all flows of this class at this transit node <= R, where R is given below for every class
このトランジットノード<= rでのこのクラスのすべてのフローの漏れの多いバケット率の合計。
If the condition holds, the delay bounds for a flow of class X (A or B) is d_X and calculated as:
条件が当てはまる場合、クラスx（aまたはb）のフローの遅延境界線はd_xであり、次のように計算されます。
d_X = T_X + (b_t_X-L_min_X)/R_X - L_min_X/c
where L_min_X is the minimum packet lengths of class X (A or B); c is the output link transmission rate; and b_t_X is the sum of the b term (bucket size) for all the flows of the class X. Parameters R_X and T_X are calculated as follows for class A and B, separately.
ここで、L_MIN_XはクラスX（AまたはB）の最小パケット長です。Cは出力リンク伝送速度です。B_T_Xは、クラスXのすべてのフローのB項（バケットサイズ）の合計です。パラメーターR_XとT_Xは、クラスAとBの次のように別々に計算されます。
If the flow is of class A:
フローがクラスAの場合：
R_A = I_A * (c-r_h)/ c
r_a = i_a *（c-r_h）/ c
T_A = (L_nA + b_h + r_h * L_n/c)/(c-r_h)
where I_A is the idle slope for class A; L_nA is the maximum packet length of class B and BE packets; L_n is the maximum packet length of classes A, B, and BE; and r_h is the rate and b_h is the bucket size of CDT leaky-bucket arrival curve.
ここで、I_AはクラスAのアイドルスロープです。L_NAはクラスBの最大パケット長であり、BEパケットです。L_Nは、クラスa、b、およびbeの最大パケット長です。R_Hはレートであり、B_HはCDT漏れの多いバケット到着曲線のバケットサイズです。
If the flow is of class B:
フローがクラスBの場合：
R_B = I_B * (c-r_h)/ c
r_b = i_b *（c-r_h）/ c
T_B = (L_BE + L_A + L_nA * I_A/(c_h-I_A) + b_h + r_h * L_n/
c)/(c-r_h)
where I_B is the idle slope for class B; L_A is the maximum packet length of class A; and L_BE is the maximum packet length of class BE.
ここで、I_BはクラスBのアイドルスロープです。L_AはクラスAの最大パケット長です。l_beはクラスの最大パケット長です。
Then, as discussed in Section 4.2.2, an interleaved regulator does not increase the delay bound of the upstream queuing subsystem; therefore, an end-to-end delay bound for a DetNet flow of class X (A or B) is the sum of d_X_i for all node i in the path of the flow, where d_X_i is the delay bound of queuing subsystem in node i, which is computed as above. According to the notation in Section 4.2.2, the delay bound of the queuing subsystem in a node i and interleaved regulator in node j, i.e., Cij, is:
次に、セクション4.2.2で説明したように、インターリーブレギュレーターは、上流のキューイングサブシステムの遅延境界を増加させません。したがって、クラスX（aまたはb）のデットネットフローにバインドされたエンドツーエンドの遅延は、フローのパス内のすべてのノードIのD_X_Iの合計です。ここで、D_X_IはノードIのキューイングシステムのキューイングシステムの遅延境界です、上記のように計算されます。セクション4.2.2の表記によると、ノードIのキューイングサブシステムとノードJのインターリーブレギュレーター、つまりCIJの遅延境界は次のとおりです。
Cij = d_X_i
More information of delay analysis in such a DetNet transit node is described in [TSNwithATS].
このようなDetnet Transitノードの遅延分析の詳細については、[tsnwithats]で説明されています。
The delay bound calculation requires some information about each node. For each node, it is required to know the idle slope of the CBS for each class A and B (I_A and I_B), as well as the transmission rate of the output link (c). Besides, it is necessary to have the information on each class, i.e., maximum packet length of classes A, B, and BE. Moreover, the leaky-bucket parameters of CDT (r_h, b_h) must be known. To admit a flow or flows of classes A and B, their delay requirements must be guaranteed not to be violated. As described in Section 3.1, the two problems (static and dynamic) are addressed separately. In either of the problems, the rate and delay must be guaranteed. Thus,
遅延バウンド計算には、各ノードに関する情報が必要です。各ノードについて、各クラスAとB（I_AおよびI_B）のCBSのアイドルスロープ、および出力リンクの伝送速度（C）を知る必要があります。その上、各クラスに関する情報、つまりクラスa、b、およびbeの最大パケット長さを持っている必要があります。さらに、CDT（R_H、B_H）の漏れやすいバケットパラメーターを知っている必要があります。クラスAとBのフローまたはフローを認めるには、その遅延要件が違反しないように保証する必要があります。セクション3.1で説明したように、2つの問題（静的および動的）に個別に対処されます。どちらの問題でも、レートと遅延を保証する必要があります。したがって、
The static admission control: The leaky-bucket parameters of all class A or B flows are known; therefore, for each flow f of either class A or B, a delay bound can be calculated. The computed delay bound for every flow of class A or B must not be more than its delay requirement. Moreover, the sum of the rate of each flow (r_f) must not be more than the rate allocated to each class (R). If these two conditions hold, the configuration is declared admissible.
静的な入場制御：すべてのクラスAまたはBフローの漏れやすいバケットパラメーターが知られています。したがって、クラスAまたはBの各フローfについて、遅延境界を計算できます。クラスAまたはBのすべてのフローにバインドされた計算された遅延は、遅延要件を超えてはなりません。さらに、各フロー（R_F）のレートの合計は、各クラス（R）に割り当てられたレートを超えてはなりません。これらの2つの条件が成立した場合、構成は許容されると宣言されます。
The dynamic admission control: For dynamic admission control, we allocate a static value for rate (R) and a maximum bucket size (b_t) to every node and each class A or B. In addition, for every node and each class A or B, two counters are maintained: R_acc is equal to the sum of the leaky-bucket rates of all flows of this class already admitted at this node; at all times, we must have:
動的な入場制御：動的な入場制御のために、すべてのノードと各クラスAまたはBに、レート（R）と最大バケットサイズ（B_T）の静的値を割り当てます。、2つのカウンターが維持されます。R_ACCは、このノードですでに認められているこのクラスのすべてのフローの漏れやすいバケット率の合計に等しくなります。常に、私たちは持っている必要があります：
R_acc <= R, (Eq. 1)
r_acc <= r、（eq。1）
b_acc is equal to the sum of the bucket sizes of all flows of this class already admitted at this node; at all times, we must have:
B_ACCは、このノードですでに認められているこのクラスのすべてのフローのバケットサイズの合計に等しくなります。常に、私たちは持っている必要があります：
b_acc <= b_t. (Eq. 2)
b_acc <= b_t。（式2）
A new class A or B flow is admitted at this node if Eqs. (1) and (2) continue to be satisfied after adding its leaky-bucket rate and bucket size to R_acc and b_acc. A class A or B flow is admitted in the network if it is admitted at all nodes along its path. When this happens, all variables R_acc and b_acc along its path must be incremented to reflect the addition of the flow. Similarly, when a class A or B flow leaves the network, all variables R_acc and b_acc along its path must be decremented to reflect the removal of the flow.
EQSの場合、このノードで新しいクラスAまたはBの流れが認められます。（1）および（2）漏れやすいバケットレートとバケットサイズをR_ACCとB_ACCに追加した後、引き続き満足しています。クラスAまたはBの流れは、パスに沿ったすべてのノードで認められている場合、ネットワークで認められます。これが発生すると、流れの追加を反映するために、そのパスに沿ったすべての変数R_ACCとB_ACCを増分する必要があります。同様に、クラスAまたはBフローがネットワークを離れると、流れの除去を反映するために、そのパスに沿ったすべての変数R_ACCとB_ACCを減らす必要があります。
The choice of the static values of R and b_t at all nodes and classes must be done in a prior configuration phase: R controls the bandwidth allocated to this class at this node, and b_t affects the delay bound and the buffer requirement. The value of R must be set such that
すべてのノードとクラスでのRとB_Tの静的値の選択は、以前の構成フェーズで行う必要があります。Rは、このノードでこのクラスに割り当てられた帯域幅を制御し、B_Tは遅延結合要件とバッファー要件に影響します。Rの値は、そのように設定する必要があります
R <= I_X*(c-r_h)/c
where I_X is the idleslope of credit-based shaper for class X={A,B}, c is the transmission rate of the output link, and r_h is the leaky-bucket rate of the CDT class.
ここで、I_Xはクラスx = {a、b}のクレジットベースのシェーパーのアイドロープであり、cは出力リンクの伝送速度、r_hはcdtクラスの漏れやすいバケットレートです。
The Guaranteed Service is defined in [RFC2212]. The flow, at the source, has a leaky-bucket arrival curve with two parameters: r as rate and b as bucket size, i.e., the amount of bits entering a node within a time interval t is bounded by r * t + b.
保証されたサービスは[RFC2212]で定義されています。ソースのフローには、2つのパラメーターを備えた漏れやすいバケット到着曲線があります。rレート、bバケツサイズとしてのb、つまり、時間間隔t内でノードに入るビットの量はr * t bで境界を付けます。
If a resource reservation on a path is applied, a node provides a guaranteed rate R and maximum service latency of T. This can be interpreted in a way that the bits might have to wait up to T before being served with a rate greater or equal to R. The delay bound of the flow traversing the node is T + b / R.
パス上のリソース予約が適用されている場合、ノードはTの保証レートrと最大サービスレイテンシを提供します。これは、ビットがより大きいまたは等しいレートで提供される前にtまで待つ必要がある方法で解釈できます。Rにノードを通過するフローの遅延境界はT B / Rです。
Consider a Guaranteed Service [RFC2212] path including a sequence of nodes, where the i-th node provides a guaranteed rate R_i and maximum service latency of T_i. Then, the end-to-end delay bound for a flow on this can be calculated as sum(T_i) + b / min(R_i).
ITHノードのシーケンスを含む保証されたサービス[RFC2212]パスを検討してください。ここでは、i番目のノードは保証レートR_IとT_Iの最大サービスレイテンシを提供します。次に、これのフローにバインドされたエンドツーエンドの遅延は、合計（T_I）b / min（R_I）として計算できます。
The provided delay bound is based on a simple case of Guaranteed Service, where only a guaranteed rate and maximum service latency and a leaky-bucket arrival curve are available. If more information about the flow is known, e.g., the peak rate, the delay bound is more complicated; the details are available in [RFC2212] and Section 1.4.1 of [NetCalBook].
提供された遅延バウンドは、保証されたサービスの単純なケースに基づいており、保証レートと最大サービスレイテンシと漏れやすいバケット到着曲線のみが利用可能です。フローに関する詳細情報がわかっている場合、たとえばピークレート、遅延境界はより複雑です。詳細は[rfc2212]および[netcalbook]のセクション1.4.1で入手できます。
Annex T of [IEEE8021Q] describes Cyclic Queuing and Forwarding (CQF), which provides bounded latency and zero congestion loss using the time-scheduled gates of Section 8.6.8.4 of [IEEE8021Q]. For a given class of DetNet flows, a set of two or more buffers is provided at the output queue layer of Figure 3. A cycle time T_c is configured for each class of DetNet flows c, and all of the buffer sets in a class of DetNet flows swap buffers simultaneously throughout the DetNet domain at that cycle rate, all in phase. In such a mechanism, the regulator, as mentioned in Figure 1, is not required.
[IEEE8021Q]の付録Tは、[IEEE8021Q]のセクション8.6.8.4の時間計算されたゲートを使用して、境界潜時とゼロの混雑損失を提供する周期的なキューイングと転送（CQF）について説明しています。DETNETフローの特定のクラスでは、図3の出力キューレイヤーで2つ以上のバッファーのセットが提供されます。ディットネットフローCの各クラスの各クラスに対して、サイクルタイムT_Cが構成され、すべてのバッファーセットがクラスのセットが設定されています。Detnet Flows Swap Buffersは、そのサイクルレートでDetnetドメイン全体で、すべてフェーズでバッファーを介してバッファーを同時にフローします。このようなメカニズムでは、図1に記載されているように、レギュレーターは必要ありません。
In the case of two-buffer CQF, each class of DetNet flows c has two buffers, namely buffer1 and buffer2. In a cycle (i) when buffer1 accumulates received packets from the node's reception ports, buffer2 transmits the already stored packets from the previous cycle (i-1). In the next cycle (i+1), buffer2 stores the received packets and buffer1 transmits the packets received in cycle (i). The duration of each cycle is T_c.
2バッファCQFの場合、Detnet Flows Cの各クラスには2つのバッファー、つまりBuffer1とBuffer2があります。サイクル（i）では、Buffer1がノードの受信ポートから受信したパケットを蓄積すると、Buffer2は既に保存されたパケットを前のサイクル（I-1）から送信します。次のサイクル（I 1）で、Buffer2は受信したパケットを保存し、Buffer1はサイクル（I）で受信したパケットを送信します。各サイクルの期間はT_Cです。
The cycle time T_c must be carefully chosen; it needs to be large enough to accommodate all the DetNet traffic, plus at least one maximum packet (or fragment) size from lower priority queues, which might be received within a cycle. Also, the value of T_c includes a time interval, called dead time (DT), which is the sum of delays 1, 2, 3, and 4 defined in Figure 1. The value of DT guarantees that the last packet of one cycle in a node is fully delivered to a buffer of the next node in the same cycle. A two-buffer CQF is recommended if DT is small compared to T_c. For a large DT, CQF with more buffers can be used, and a cycle identification label can be added to the packets.
サイクルタイムT_Cは慎重に選択する必要があります。すべてのデットネットトラフィックに対応するのに十分な大きさである必要があります。さらに、サイクル内で受信される可能性のある優先度の低いキューから少なくとも1つの最大パケット（またはフラグメント）サイズが必要です。また、T_Cの値には、Dead Time（DT）と呼ばれる時間間隔が含まれます。これは、図1で定義されている遅延1、2、3、および4の合計です。DTの値は、1つのサイクルの最後のパケットが1つのサイクルの最後のパケットを保証します。ノードは、同じサイクルで次のノードのバッファーに完全に配信されます。DTがT_Cに比べて小さい場合は、2バッファCQFをお勧めします。大きなDTの場合、より多くのバッファーを備えたCQFを使用でき、サイクル識別ラベルをパケットに追加できます。
The per-hop latency is determined by the cycle time T_c: a packet transmitted from a node at a cycle (i) is transmitted from the next node at cycle (i+1). Then, if the packet traverses h hops, the maximum latency experienced by the packet is from the beginning of cycle (i) to the end of cycle (i+h); also, the minimum latency is from the end of cycle (i), before the DT, to the beginning of cycle (i+h). Then, the maximum latency is:
ホップごとのレイテンシは、サイクルタイムT_Cによって決定されます。サイクル（i）でノードから送信されるパケットは、サイクル（I 1）の次のノードから送信されます。次に、パケットがHホップを通過する場合、パケットが経験する最大遅延は、サイクル（i）の開始からサイクルの終わり（i h）までです。また、最小レイテンシーは、サイクルの終了（i）からDTの前、サイクルの開始（I H）までです。次に、最大遅延は次のとおりです。
(h+1) T_c
（H 1）T_C
and the minimum latency is:
そして、最小レイテンシーは次のとおりです。
(h-1) T_c + DT.
（H-1）T_C DT。
Ingress conditioning (Section 4.3) may be required if the source of a DetNet flow does not itself employ CQF. Since there are no per-flow parameters in the CQF technique, per-hop configuration is not required in the CQF forwarding nodes.
Detnet Flowのソース自体がCQFを使用しない場合、侵入コンディショニング（セクション4.3）が必要になる場合があります。CQF手法には流量ごとのパラメーターがないため、CQF転送ノードではホップごとの構成は必要ありません。
This section provides an example application of the timing model presented in this document to control the admission of a DetNet flow on a DetNet-enabled IP network. Consider Figure 5, taken from Section 3 of [RFC8939], which shows a simple IP network:
このセクションでは、このドキュメントに示されているタイミングモデルの適用の例を示し、Detnet対応のIPネットワーク上のDetnet Flowの入場を制御します。[RFC8939]のセクション3から取られた図5を考えてみましょう。これは、単純なIPネットワークを示しています。
* End system 1 implements Guaranteed Service [RFC2212], as in Section 6.5, between itself and relay node 1.
* END System 1は、セクション6.5のように、それ自体とリレーノード1の間の保証されたサービス[RFC2212]を実装します。
* Sub-network 1 is a TSN network. The nodes in sub-network 1 implement credit-based shapers with asynchronous traffic shaping, as in Section 6.4.
* サブネットワーク1はTSNネットワークです。セクション6.4のように、サブネットワーク1のノードは、非同期トラフィックシェーピングを備えたクレジットベースのシェイパーを実装します。
* Sub-network 2 is a TSN network. The nodes in sub-network 2 implement Cyclic Queuing and Forwarding with two buffers, as in Section 6.6.
* サブネットワーク2はTSNネットワークです。サブネットワーク2のノードは、セクション6.6のように、2つのバッファーで周期的なキューイングと転送を実装します。
* The relay nodes 1 and 2 implement credit-based shapers with asynchronous traffic shaping, as in Section 6.4. They also perform the aggregation and mapping of IP DetNet flows to TSN streams (Section 4.4 of [RFC9023]).
* リレーノード1および2は、セクション6.4のように、非同期トラフィックシェーピングを備えたクレジットベースのシェイパーを実装します。また、TSNストリームへのIP Detnetフローの集約とマッピングも実行します（[RFC9023]のセクション4.4）。
DetNet IP Relay Relay DetNet IP
End System Node 1 Node 2 End System
1 2
+----------+ +----------+
| Appl. |<------------ End-to-End Service ----------->| Appl. |
+----------+ ............ ........... +----------+
| Service |<-: Service :-- DetNet flow --: Service :->| Service |
+----------+ +----------+ +----------+ +----------+
|Forwarding| |Forwarding| |Forwarding| |Forwarding|
+--------.-+ +-.------.-+ +-.---.----+ +-------.--+
: Link : \ ,-----. / \ ,-----. /
+......+ +----[ Sub- ]----+ +-[ Sub- ]-+
[Network] [Network]
`--1--' `--2--'
|<--------------------- DetNet IP --------------------->|
|<--- d1 --->|<--------------- d2_p --------------->|<-- d3_p -->|
Figure 5: A Simple DetNet-Enabled IP Network, Taken from RFC 8939
図5：RFC 8939から取得した簡単なDetNet対応IPネットワーク
Consider a fully centralized control plane for the network of Figure 5, as described in Section 3.2 of [DETNET-CONTROL-PLANE]. Suppose end system 1 wants to create a DetNet flow with a traffic specification destined to end system 2 with end-to-end delay bound requirement D. Therefore, the control plane receives a flow establishment request and calculates a number of valid paths through the network (Section 3.2 of [DETNET-CONTROL-PLANE]). To select a proper path, the control plane needs to compute an end-to-end delay bound at every node of each selected path p.
[Detnet-Control-Plane]のセクション3.2で説明されているように、図5のネットワークの完全に集中型のコントロールプレーンを検討してください。エンドシステム1が、エンドツーエンドの遅延バウンド要件Dを備えたエンドシステム2を使用してトラフィック仕様を備えたデットネットフローを作成したいと考えています。（[DetNet-Control-Plane]のセクション3.2）。適切なパスを選択するには、制御プレーンが選択した各パスpのすべてのノードでバインドされたエンドツーエンドの遅延を計算する必要があります。
The end-to-end delay bound is d1 + d2_p + d3_p, where d1 is the delay bound from end system 1 to the entrance of relay node 1, d2_p is the delay bound for path p from relay node 1 to the entrance of the first node in sub-network 2, and d3_p is the delay bound of path p from the first node in sub-network 2 to end system 2. The computation of d1 is explained in Section 6.5. Since the relay node 1, sub-network 1, and relay node 2 implement aggregate queuing, we use the results in Sections 4.2.2 and 6.4 to compute d2_p for the path p. Finally, d3_p is computed using the delay bound computation of Section 6.6. Any path p, such that d1 + d2_p + d3_p <= D, satisfies the delay bound requirement of the flow. If there is no such path, the control plane may compute a new set of valid paths and redo the delay bound computation or reject the DetNet flow.
エンドツーエンドの遅延バウンドはD1 D2_P D3_Pです。ここで、D1はエンドシステム1からリレーノード1の入り口までの遅延です。D2_Pはリレーノード1から最初のノードの入り口までのパスPの遅延バインドされていますサブネットワーク2、およびD3_Pは、サブネットワーク2の最初のノードからシステム2へのパスPの遅延境界Pです。D1の計算については、セクション6.5で説明します。リレーノード1、サブネットワーク1、リレーノード2が集計キューイングを実装するため、セクション4.2.2および6.4の結果を使用して、パスpのD2_Pを計算します。最後に、D3_Pはセクション6.6の遅延結合計算を使用して計算されます。D1 D2_P D3_P <= DなどのパスPは、フローの遅延結合要件を満たします。そのようなパスがない場合、コントロールプレーンは、新しい有効なパスのセットを計算し、遅延結合計算をやり直すか、デットネットの流れを拒否することができます。
As soon as the control plane selects a path that satisfies the delay bound constraint, it allocates and reserves the resources in the path for the DetNet flow (Section 4.2 of [DETNET-CONTROL-PLANE]).
制御プレーンが遅延結合制約を満たすパスを選択するとすぐに、Detnet Flow（[Detnet-Control-Plane]のセクション4.2）のパス内のリソースを割り当てて留保します。
Detailed security considerations for DetNet are cataloged in [RFC9055], and more general security considerations are described in [RFC8655].
DETNETの詳細なセキュリティ上の考慮事項は[RFC9055]でカタログ化されており、[RFC8655]でより一般的なセキュリティ上の考慮事項が記載されています。
Security aspects that are unique to DetNet are those whose aim is to provide the specific QoS aspects of DetNet, specifically bounded end-to-end delivery latency and zero congestion loss. Achieving such loss rates and bounded latency may not be possible in the face of a highly capable adversary, such as the one envisioned by the Internet Threat Model of BCP 72 [RFC3552], which can arbitrarily drop or delay any or all traffic. In order to present meaningful security considerations, we consider a somewhat weaker attacker who does not control the physical links of the DetNet domain but may have the ability to control or change the behavior of some resources within the boundary of the DetNet domain.
Detnetに固有のセキュリティの側面は、Detnetの特定のQoS側面、特に境界線から端までの配信レイテンシとゼロの混雑損失を提供することを目的とするものです。このような損失率と境界潜時を達成することは、BCP 72 [RFC3552]のインターネット脅威モデルによって想定されているものなど、非常に有能な敵に直面しても不可能であり、任意のトラフィックまたはすべてのトラフィックを任意にドロップまたは遅延させる可能性があります。意味のあるセキュリティ上の考慮事項を提示するために、Detnetドメインの物理的リンクを制御しないが、Detnetドメインの境界内のいくつかのリソースの動作を制御または変更する能力を持つ可能性のあるやや弱い攻撃者を考慮します。
Latency bound calculations use parameters that reflect physical quantities. If an attacker finds a way to change the physical quantities, unknown to the control and management planes, the latency calculations fail and may result in latency violation and/or congestion losses. An example of such attacks is to make some traffic sources under the control of the attacker send more traffic than their assumed T-SPECs. This type of attack is typically avoided by ingress conditioning at the edge of a DetNet domain. However, it must be insured that such ingress conditioning is done per flow and that the buffers are segregated such that if one flow exceeds its T-SPEC, it does not cause buffer overflow for other flows.
レイテンシバウンド計算は、物理量を反映するパラメーターを使用します。攻撃者が、制御プレーンと管理プレーンに不明な物理量を変更する方法を見つけた場合、潜伏期の計算が失敗し、遅延違反および/または混雑損失をもたらす可能性があります。このような攻撃の例は、攻撃者の制御下にあるいくつかの交通源を、想定されるT-Specよりも多くのトラフィックを送ることです。このタイプの攻撃は、通常、Detnetドメインの端でのイングレスコンディショニングによって回避されます。ただし、そのような侵入コンディショニングはフローごとに行われ、バッファーが分離されているため、1つのフローがT-Specを超えても、他のフローにバッファオーバーフローを引き起こさないように保証する必要があります。
Some queuing mechanisms require time synchronization and operate correctly only if the time synchronization works correctly. In the case of CQF, the correct alignments of cycles can fail if an attack against time synchronization fools a node into having an incorrect offset. Some of these attacks can be prevented by cryptographic authentication as in Annex K of [IEEE1588] for the Precision Time Protocol (PTP). However, the attacks that change the physical latency of the links used by the time synchronization protocol are still possible even if the time synchronization protocol is protected by authentication and cryptography [DelayAttack]. Such attacks can be detected only by their effects on latency bound violations and congestion losses, which do not occur in normal DetNet operation.
一部のキューイングメカニズムには、時間同期が必要であり、時間同期が正しく機能する場合にのみ正しく動作します。CQFの場合、タイム同期に対する攻撃がノードをだまして誤ったオフセットを持っている場合、サイクルの正しいアライメントが失敗する可能性があります。これらの攻撃のいくつかは、精密時間プロトコル（PTP）の[IEEE1588]の付属書Kのように暗号化認証によって防ぐことができます。ただし、時間同期プロトコルが認証と暗号化によって保護されている場合でも、時間同期プロトコルで使用されるリンクの物理的遅延を変更する攻撃は依然として可能です[DelayAttack]。このような攻撃は、通常のデットネット操作では発生しない潜伏境界違反と輻輳損失に対する影響によってのみ検出できます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[IEEE8021Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018, <https://ieeexplore.ieee.org/document/8403927>.
[IEEE8021Q] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ブリッジおよびブリッジネットワーク」、IEEE STD 802.1Q-2018、DOI 10.1109/IEEESTD.2018.8403927、2018年7月、<https://ieeexplore.org/document/8403927>。
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, DOI 10.17487/RFC2212, September 1997, <https://www.rfc-editor.org/info/rfc2212>.
[RFC2212] Shenker、S.、Partridge、C。、およびR. Guerin、「保証されたサービス品質の仕様」、RFC 2212、DOI 10.17487/RFC2212、1997年9月、<https://www.rfc-editor.org/info/rfc2212>。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>.
[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、DOI 10.17487/RFC2475、12月1998、<https://www.rfc-editor.org/info/rfc2475>。
[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] Bryant、S.、Ed。、Ed。、Martini、L.、Swallow、G.、およびA. Malis、「MPLS PSNを介したPacket Pseudowireカプセル化」、RFC 6658、DOI 10.17487/RFC6658、2012年7月、<HTTPS：//www.rfc-editor.org/info/rfc6658>。
[RFC7806] Baker, F. and R. Pan, "On Queuing, Marking, and Dropping", RFC 7806, DOI 10.17487/RFC7806, April 2016, <https://www.rfc-editor.org/info/rfc7806>.
[RFC7806] Baker、F。and R. Pan、「キューイング、マーキング、ドロップについて」、RFC 7806、DOI 10.17487/RFC7806、2016年4月、<https://www.rfc-editor.org/info/RFC7806>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B。、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487/RFC8655、2019年10月、<https：//www.rfc-editor.org/info/rfc8655>。
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
[RFC8939] Varga、B.、Ed。、Farkas、J.、Berger、L.、Fedyk、D.、およびS. Bryant、「決定論的ネットワーキング（DetNet）データプレーン：IP」、RFC 8939、DOI 10.17487/RFC89399、2020年11月、<https://www.rfc-editor.org/info/rfc8939>。
[RFC8964] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., Bryant, S., and J. Korhonen, "Deterministic Networking (DetNet) Data Plane: MPLS", RFC 8964, DOI 10.17487/RFC8964, January 2021, <https://www.rfc-editor.org/info/rfc8964>.
[RFC8964] Varga、B.、Ed。、Farkas、J.、Berger、L.、Malis、A.、Bryant、S。、およびJ. Korhonen、「決定論的ネットワーキング（DetNet）データプレーン：MPLS」、RFC 8964、doi 10.17487/rfc8964、2021年1月、<https://www.rfc-editor.org/info/rfc8964>。
[RFC9016] Varga, B., Farkas, J., Cummings, R., Jiang, Y., and D. Fedyk, "Flow and Service Information Model for Deterministic Networking (DetNet)", RFC 9016, DOI 10.17487/RFC9016, March 2021, <https://www.rfc-editor.org/info/rfc9016>.
[RFC9016] Varga、B.、Farkas、J.、Cummings、R.、Jiang、Y.、およびD. Fedyk、「決定論的ネットワーキングのフローおよびサービス情報モデル（detNet）、RFC 9016、DOI 10.17487/RFC9016、2021年3月、<https://www.rfc-editor.org/info/rfc9016>。
[BennettDelay] Bennett, J. C. R., Benson, K., Charny, A., Courtney, W. F., and J.-Y. Le Boudec, "Delay jitter bounds and packet scale rate guarantee for expedited forwarding", DOI 10.1109/TNET.2002.801404, August 2002, <https://dl.acm.org/citation.cfm?id=581870>.
[Bennettdelay] Bennett、J。C。R.、Benson、K.、Charny、A.、Courtney、W。F。、およびJ.-Y。Le Boudec、「迅速な転送のためのジッター境界とパケットスケールレート保証」、DOI 10.1109/TNET.2002.801404、2002年8月、<https://dl.acm.org/citation.cfm？dl.id = 581870>。
[CharnyDelay] Charny, A. and J.-Y. Le Boudec, "Delay Bounds in a Network with Aggregate Scheduling", DOI 10.1007/3-540-39939-9_1, September 2002, <https://link.springer.com/ chapter/10.1007/3-540-39939-9_1>.
[Charnydelay] Charny、A。およびJ.-Y。Le Boudec、「集計スケジューリングを備えたネットワークの遅延境界」、DOI 10.1007/3-540-39939-9_1、2002年9月、<https://link.springer.com/章/10.1007/3-540-39939-9_1>。
[DelayAttack] Barreto, S., Suresh, A., and J. L. Boudec, "Cyber-attack on packet-based time synchronization protocols: The undetectable Delay Box", DOI 10.1109/I2MTC.2016.7520408, May 2016, <https://ieeexplore.ieee.org/document/7520408>.
[DelayAttack] Barreto、S.、Suresh、A。、およびJ. L. Boudec、「パケットベースの時間同期プロトコルのサイバー攻撃：検出不可能な遅延ボックス」、DOI 10.1109/I2MTC.2016.7520408、2016年5月、<https：///////////ieeexplore.ieee.org/document/7520408>。
[DETNET-CONTROL-PLANE] Malis, A., Geng, A., Ed., Chen, M., Qin, F., and B. Varga, "Deterministic Networking (DetNet) Controller Plane Framework", Work in Progress, Internet-Draft, draft-ietf-detnet-controller-plane-framework-02, 28 June 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-detnet-controller-plane-framework-02>.
[Detnet-Control-Plane] Malis、A.、Geng、A.、Ed。、Chen、M.、Qin、F.、およびB. Varga、「決定論的ネットワーキング（Detnet）コントローラー平面フレームワーク」、進行中の作業、Internet-Draft、Draft-ITETF-Detnet-Controller-Plane-Framework-02、2022年6月28日、<https://datatracker.ietf.org/doc/html/draft-ietf-detnet-contnet-controller-plane-framework-0202>。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://ieeexplore.ieee.org/document/4579760>.
[IEEE1588] IEEE、「ネットワーク化された測定および制御システムの精密クロック同期プロトコルのIEEE標準」、IEEE STD 1588-2008、DOI 10.1109/IEEESTD.2008.4579760、2008年7月、<https://4579760>。
[IEEE8021Qcr] IEEE 802.1, "802.1Qcr-2020 - IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks Amendment 34:Asynchronous Traffic Shaping", November 2020, <https://ieeexplore.ieee.org/document/9253013>.
[IEEE8021QCR] IEEE 802.1、 "802.1QCR-2020-ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - ブリッジとブリッジネットワークの修正34：非同期トラフィックシェーピング"9253013>。
[IEEE8021TSN] IEEE 802.1, "802.1 Time-Sensitive Networking (TSN) Task Group", <https://1.ieee802.org/tsn/>.
[IEEE8021TSN] IEEE 802.1、 "802.1時間依存ネットワーキング（TSN）タスクグループ"、<https://1.ieee802.org/tsn/>。
[IEEE8023] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018, DOI 10.1109/IEEESTD.2018.8457469, August 2018, <http://ieeexplore.ieee.org/document/8457469>.
[IEEE8023] IEEE、「イーサネットのIEEE標準」、IEEE STD 802.3-2018、DOI 10.1109/IEEESTD.2018.8457469、2018年8月、<http://ieeexplore.ieeee.org/document/8457469>
[LeBoudecTheory] Le Boudec, J.-Y., "A Theory of Traffic Regulators for Deterministic Networks With Application to Interleaved Regulators", DOI 10.1109/TNET.2018.2875191, November 2018, <https://ieeexplore.ieee.org/document/8519761>.
[Leboudectheory] Le Boudec、J.-Y。、「インターリーブ規制当局への適用を伴う決定論的ネットワークの交通規制当局の理論」、DOI 10.1109/TNET.2018.2875191、2018年11月、<https：//ieeexplore.ieee.org/document/8519761>。
[NetCalBook] Le Boudec, J.-Y. and P. Thiran, "Network Calculus: A Theory of Deterministic Queuing Systems for the Internet", Springer Science & Business Media, vol. 2050, 2001, <https://leboudec.github.io/netcal/latex/netCalBook.pdf>.
[NetCalbook] Le Boudec、J.-Y。およびP. Thiran、「ネットワーク計算：インターネットの決定論的キューイングシステムの理論」、Springer Science＆Business Media、Vol。2050、2001、<https://leboudec.github.io/netcal/latex/netcalbook.pdf>。
[PacketReorderingBounds] Mohammadpour, E. and J.-Y. Le Boudec, "On Packet Reordering in Time-Sensitive Networks", DOI 10.1109/TNET.2021.3129590, December 2021, <https://ieeexplore.ieee.org/document/9640523>.
[PacketreOrderingBounds] Mohammadpour、E。およびJ.-Y。Le Boudec、「時間に敏感なネットワークでのパケットの並べ替えについて」、doi 10.1109/tnet.2021.3129590、2021年12月、<https://ieeexplore.ieee.org/document/9640523>。
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999, <https://www.rfc-editor.org/info/rfc2697>.
[RFC2697] Heinanen、J。およびR. Guerin、「単一レート3色マーカー」、RFC 2697、DOI 10.17487/RFC2697、1999年9月、<https://www.rfc-editor.org/info/rfc2697>
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487/RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/RFC3552>。
[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。、「決定論的ネットワーキングユースケース」、RFC 8578、DOI 10.17487/RFC8578、2019年5月、<https://www.rfc-editor.org/info/rfc8578>
[RFC9023] Varga, B., Ed., Farkas, J., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP over IEEE 802.1 Time-Sensitive Networking (TSN)", RFC 9023, DOI 10.17487/RFC9023, June 2021, <https://www.rfc-editor.org/info/rfc9023>.
[RFC9023] Varga、B.、Ed。、Farkas、J.、Malis、A。、およびS. Bryant、「決定論的ネットワーキング（DetNet）データプレーン：IEEE Over IEEE 802.1時間依存ネットワーキング（TSN）」、RFC 9023、doi 10.17487/rfc9023、2021年6月、<https://www.rfc-editor.org/info/rfc9023>。
[RFC9055] Grossman, E., Ed., Mizrahi, T., and A. Hacker, "Deterministic Networking (DetNet) Security Considerations", RFC 9055, DOI 10.17487/RFC9055, June 2021, <https://www.rfc-editor.org/info/rfc9055>.
[RFC9055] Grossman、E.、Ed。、Mizrahi、T。、およびA. Hacker、「決定論的ネットワーキング（DetNet）セキュリティ上の考慮事項」、RFC 9055、DOI 10.17487/RFC9055、2021年6月、<https：//ww.rfc-editor.org/info/rfc9055>。
[Sch8021Qbv] Craciunas, S., Oliver, R., Chmelik, M., and W. Steiner, "Scheduling Real-Time Communication in IEEE 802.1Qbv Time Sensitive Networks", DOI 10.1145/2997465.2997470, October 2016, <https://dl.acm.org/doi/10.1145/2997465.2997470>.
[Sch8021qbv] Craciunas、S.、Oliver、R.、Chmelik、M.、およびW. Steiner、「IEEE 802.1QBVのリアルタイム通信のスケジューリングタイム敏感なネットワーク」、DOI 10.1145/29974655.2997470、2016年10月、<https：/<https//dl.acm.org/doi/10.1145/2997465.2997470>。
[SpechtUBS] Specht, J. and S. Samii, "Urgency-Based Scheduler for Time-Sensitive Switched Ethernet Networks", DOI 10.1109/ECRTS.2016.27, July 2016, <https://ieeexplore.ieee.org/abstract/document/7557870>.
[Spechtubs] Specht、J。and S. Samii、「時間に敏感なスイッチングイーサネットネットワークの緊急ベースのスケジューラ」、DOI 10.1109/ECRTS.2016.27、2016年7月、<https://ieeexplore.ieee.org/abstract/document/7557870>。
[ThomasTime] Thomas, L. and J.-Y. Le Boudec, "On Time Synchronization Issues in Time-Sensitive Networks with Regulators and Nonideal Clocks", DOI 10.1145/3393691.339420, June 2020, <https://dl.acm.org/doi/10.1145/3393691.3394206>.
[トーマスタイム]トーマス、L。およびJ.-Y。Le Boudec、「規制当局と非理想的な時計を伴う時間依存ネットワークの時間的に同期する問題」、DOI 10.1145/3393691.339420、2020年6月、<https://dl.acm.org/doi/10.1145/3393691.3394206>。
[TSNwithATS] Mohammadpour, E., Stai, E., Mohiuddin, M., and J.-Y. Le Boudec, "Latency and Backlog Bounds in Time-Sensitive Networking with Credit Based Shapers and Asynchronous Traffic Shaping", DOI 10.1109/ITC30.2018.10053, September 2018, <https://ieeexplore.ieee.org/document/8493026>.
[Tsnwithats] Mohammadpour、E.、Stai、E.、Mohiuddin、M。、およびJ.-Y。Le Boudec、「クレジットベースのシェイパーと非同期トラフィックシェーピングによる時間依存のネットワーキングにおけるレイテンシとバックログの境界」、DOI 10.1109/ITC30.2018.10053、2018年9月、<https://ieeexplore.ieee.org/document/8493026>。
Acknowledgments
謝辞
We would like to thank Lou Berger, Tony Przygienda, John Scudder, Watson Ladd, Yoshifumi Nishida, Ralf Weber, Robert Sparks, Gyan Mishra, Martin Duke, Éric Vyncke, Lars Eggert, Roman Danyliw, and Paul Wouters for their useful feedback on this document.
ルー・ベルガー、トニー・プリギエンダ、ジョン・スカッダー、ワトソン・ラッド、ヨシフミ・西、ラルフ・ウェーバー、ロバート・スパークス、ギャン・ミシュラ、マーティン・デューク、エリック・ヴィンケ、ラース・エガート、ロマン・ダニリウ、ポール・ウーターズがこれに役立つフィードバックをしてくれたことに感謝します。資料。
Contributors
貢献者
RFC 7322 limits the number of authors listed on the front page to a maximum of 5. The editor wishes to thank and acknowledge the following author for contributing text to this document:
RFC 7322は、フロントページにリストされている著者の数を最大5に制限します。編集者は、このドキュメントにテキストを提供してくれた次の著者に感謝し、認めたいと考えています。
Janos Farkas Ericsson Email: janos.farkas@ericsson.com
Janos Farkas Ericssonメール：janos.farkas@ericsson.com
Authors' Addresses
著者のアドレス
Norman Finn Huawei Technologies Co. Ltd 3101 Rio Way Spring Valley, California 91977 United States of America Phone: +1 925 980 6430 Email: nfinn@nfinnconsulting.com
Norman Finn Huawei Technologies Co. Ltd 3101 Rio Way Spring Valley、California 91977アメリカ合衆国電話：1 925 980 6430メール：nfinn@nfinnconsulting.com
Jean-Yves Le Boudec EPFL IC Station 14 CH-1015 Lausanne Switzerland Email: jean-yves.leboudec@epfl.ch
jean-yves le boudec epfl ic station 14 ch-1015ローザンヌスイスメールメール：jean-yves.leboudec@epfl.ch
Ehsan Mohammadpour EPFL IC Station 14 CH-1015 Lausanne Switzerland Email: ehsan.mohammadpour@epfl.ch
Ehsan Mohammadpour epfl IC Station 14 CH-1015 Lausanne Switzerlandメール：ehsan.mohammadpour@epfl.ch
Jiayi Zhang Huawei Technologies Co. Ltd Q27, No.156 Beiqing Road Beijing 100095 China Email: zhangjiayi11@huawei.com
Jiayi Zhang Huawei Technologies Co. Ltd Q27、No.156Beiqing Road Beijing 100095 China Email：Zhangjiayi11@huawei.com
Balázs Varga Ericsson Budapest Konyves Kálmán krt. 11/B 1097 Hungary Email: balazs.a.varga@ericsson.com
バラズ・バルガ・エリクソン・ブダペスト・コニューブス・カルマン・クルト。11/b 1097ハンガリーメール：balazs.a.varga@ericsson.com