[要約] RFC 9016は、決定論的ネットワーキング（DetNet）のためのフローとサービス情報モデルに関する文書です。この文書の目的は、データフローの確実な配信を保証するための情報モデルを提供することにあります。利用場面としては、産業オートメーション、車載ネットワーク、オーディオビジュアルストリーミングなど、遅延が厳しく制御された環境での使用が想定されています。
Internet Engineering Task Force (IETF) B. Varga
Request for Comments: 9016 J. Farkas
Category: Informational Ericsson
ISSN: 2070-1721 R. Cummings
National Instruments
Y. Jiang
Huawei
D. Fedyk
LabN Consulting
March 2021
Flow and Service Information Model for Deterministic Networking (DetNet)
決定論的ネットワーキングのための流れとサービス情報モデル（DetNet）
Abstract
概要
This document describes the flow and service information model for Deterministic Networking (DetNet). These models are defined for IP and MPLS DetNet data planes.
この文書では、決定論的ネットワーキング（DetNet）のフローおよびサービス情報モデルについて説明します。これらのモデルは、IPおよびMPLS 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/rfc9016.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9016で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Goals
1.2. Non-Goals
2. Terminology
2.1. Terms Used in This Document
2.2. Abbreviations
2.3. Naming Conventions
3. DetNet Domain and Its Modeling
3.1. DetNet Service Overview
3.2. Reference Points Used in Modeling
3.3. Information Elements
4. App-Flow-Related Parameters
4.1. App-Flow Characteristics
4.2. App-Flow Requirements
5. DetNet Flow-Related Parameters
5.1. Management ID of the DetNet Flow
5.2. Payload Type of the DetNet Flow
5.3. Format of the DetNet Flow
5.4. Identification and Specification of DetNet Flows
5.4.1. DetNet MPLS Flow Identification and Specification
5.4.2. DetNet IP Flow Identification and Specification
5.5. Traffic Specification of the DetNet Flow
5.6. Endpoints of the DetNet Flow
5.7. Rank of the DetNet Flow
5.8. Status of the DetNet Flow
5.9. Requirements of the DetNet Flow
5.9.1. Minimum Bandwidth of the DetNet Flow
5.9.2. Maximum Latency of the DetNet Flow
5.9.3. Maximum Latency Variation of the DetNet Flow
5.9.4. Maximum Loss of the DetNet Flow
5.9.5. Maximum Consecutive Loss of the DetNet Flow
5.9.6. Maximum Misordering Tolerance of the DetNet Flow
5.10. BiDir Requirement of the DetNet Flow
6. DetNet Service-Related Parameters
6.1. Management ID of the DetNet Service
6.2. Delivery Type of the DetNet Service
6.3. Delivery Profile of the DetNet Service
6.3.1. Minimum Bandwidth of the DetNet Service
6.3.2. Maximum Latency of the DetNet Service
6.3.3. Maximum Latency Variation of the DetNet Service
6.3.4. Maximum Loss of the DetNet Service
6.3.5. Maximum Consecutive Loss of the DetNet Service
6.3.6. Maximum Misordering Tolerance of the DetNet Service
6.4. Connectivity Type of the DetNet Service
6.5. BiDir Requirement of the DetNet Service
6.6. Rank of the DetNet Service
6.7. Status of the DetNet Service
7. Flow-Specific Operations
7.1. Join Operation
7.2. Leave Operation
7.3. Modify Operation
8. Summary
9. IANA Considerations
10. Security Considerations
11. References
11.1. Normative References
11.2. Informative References
Authors' Addresses
Deterministic Networking (DetNet) provides a capability to carry specified unicast or multicast data flows for real-time applications with extremely low packet loss rates and assured maximum end-to-end delivery latency. A description of the general background and concepts of DetNet can be found in [RFC8655].
決定論的ネットワーキング（DetNet）は、極めて低いパケット損失率を持つリアルタイムアプリケーションのために指定されたユニキャストまたはマルチキャストデータフローを伝送する機能を提供します。Detnetの一般的な背景と概念の説明は[RFC8655]にあります。
This document describes the DetNet flow and service information model. For reference, [RFC3444] describes the rationale behind information models in general. This document describes the flow and service information models for operators and users to understand DetNet services and for implementors as a guide to the functionality required by DetNet services.
この文書では、Detnet Flowとサービス情報モデルについて説明します。参考のため、[RFC3444]は一般的な情報モデルの背後にある根拠を説明しています。このドキュメントでは、Detnet Servicesが必要とする機能のガイドとしてDetnet Servicesと実装者のためのインプリールを理解するためのフローとサービス情報モデルについて説明します。
The DetNet architecture treats the DetNet-related data plane functions decomposed into two sub-layers: a service sub-layer and a forwarding sub-layer. The service sub-layer is used to provide DetNet service protection and reordering. The forwarding sub-layer provides resource allocation (to ensure low loss, assured latency, and limited out-of-order delivery) and leverages traffic engineering mechanisms.
DetNetアーキテクチャは、Detnet関連データプレーン機能を2つのサブレイヤに分解しています。サービスサブレイヤと転送サブレイヤー。サービスサブレイヤはDetnetサービス保護と並べ替えを提供するために使用されます。転送サブレイヤーは、リソース割り当て（低損失、保証された待ち時間、および限られた順序配信を確実にするため）を提供し、トラフィックエンジニアリングメカニズムを活用します。
DetNet service utilizes IP or MPLS, and DetNet is currently defined for IP and MPLS networks, as shown in Figure 1, which is a reprint of Figure 2 from [RFC8938]. IEEE 802.1 Time-Sensitive Networking (TSN) utilizes Ethernet and is defined over Ethernet networks. A DetNet flow includes one or more application-level flow (App-flow) as payload. App-flows can be Ethernet, MPLS, or IP flows, which impacts which header fields are utilized to identify a flow. DetNet flows are identified by the DetNet encapsulation of App-flow(s) (e.g., MPLS labels, IP 6-tuples, etc.). In some scenarios, App-flow and DetNet flow look similar on the wire (e.g., Layer 3 (L3) App-flow over a DetNet IP network).
Detnet ServiceはIPまたはMPLSを利用し、図1に示すように、IPネットワークとMPLSネットワークに対してDetnetは現在定義されています。これは[RFC8938]から図2の再印刷です。IEEE 802.1時間依存ネットワーキング（TSN）はイーサネットを利用し、イーサネットネットワークを介して定義されます。DetNetフローには、ペイロードとして1つ以上のアプリケーションレベルのフロー（App-Flow）が含まれます。App-Flowsは、イーサネット、MPLS、またはIPフローになります。これは、フローを識別するためにどのヘッダーフィールドを使用するかに影響を与えます。DetNetフローは、アプリフローのDetNetカプセル化（例えば、MPLSラベル、IP 6-タプルなど）によって識別されます。いくつかのシナリオでは、アプリフローとDetnetフローはワイヤ上で似ています（例えば、DetNet IPネットワーク上のレイヤ3（L3）アプリフロー）。
+-----+
| TSN |
+-------+ +-+-----+-+
| DN IP | | DN MPLS |
+--+--+----+----+ +-+---+-----+-+
| TSN | DN MPLS | | TSN | DN IP |
+-----+---------+ +-----+-------+
Figure 1: DetNet Service Examples as per Data Plane Framework
図1：データプレーンフレームワークごとのDetNetサービスの例
As shown in Figure 1 and as described in [RFC8938], a DetNet flow can be treated as an App-flow, e.g., at DetNet flow aggregation or in a sub-network that interconnects DetNet nodes.
図1に示すように[RFC8938]に記載されているように、DetNetフローは、アプリケーションフローとして、例えばDetNet Net Flow集約またはDetNetノードを相互接続するサブネットワークとして扱うことができます。
The DetNet flow and service information model provided by this document contains both DetNet-flow- and App-flow-specific information in an integrated fashion.
この文書によって提供されるDetNetフローとサービス情報モデルには、統合的な方法でDetnet-Flow、App-Flow固有の情報の両方が含まれています。
In a given network scenario, three information models can be distinguished:
特定のネットワークシナリオでは、3つの情報モデルを区別できます。
* Flow information models that describe characteristics of data flows. These models describe, in detail, all relevant aspects of a flow that are needed to support the flow properly by the network between the source and the destination(s).
* データフローの特性を記述するフロー情報モデル。これらのモデルは、詳細には、ソースと宛先との間のネットワークによって適切にフローをサポートするために必要なフローのすべての関連態様を説明している。
* Service information models that describe characteristics of services being provided for data flows over a network. These models can be treated as an information model that is network operator independent.
* サービスの特性を記述するサービス情報モデルはネットワーク上で流れる。これらのモデルは、ネットワーク事業者に依存しない情報モデルとして扱うことができます。
* Configuration information models that describe, in detail, the settings required on network nodes to provide proper service to a data flow.
* データフローに適切なサービスを提供するためにネットワークノードで必要な設定を詳細に説明する構成情報モデル。
Service and flow information models are used between the user and the network operator. Configuration information models are used between the management/control plane entity of the network and the network nodes. They are shown in Figure 2.
ユーザーとネットワーク事業者の間でサービスとフロー情報モデルが使用されます。構成情報モデルは、ネットワークの管理/制御プレーンエンティティとネットワークノードとの間で使用される。それらを図2に示す。
User Network Operator
flow/service
/\ info model +---+
/ \ <---------------> | X | management/control
---- +-+-+ plane entity
^
| configuration
| info model
+------------+
v | |
+-+ | v network
+-+ v +-+ nodes
+-+ +-+
+-+
Figure 2: Usage of Information Models (Flow, Service, and Configuration)
図2：情報モデルの使用法（フロー、サービス、および構成）
The DetNet flow and service information model is based on [RFC8655] and the concept of the data model specified by [IEEE8021Qcc]. In addition to the TSN data model, [IEEE8021Qcc] also specifies configuration of TSN features (e.g., traffic scheduling specified by [IEEE8021Qbv]). The common architecture and flow information model allow configured features to be consistent in certain deployment scenarios, e.g., when the network that provides the DetNet service includes both L3 and L2 network segments.
Detnet Flowとサービス情報モデルは[RFC8655]と[IEEE8021QCC]で指定されたデータモデルの概念に基づいています。TSNデータモデルに加えて、[IEEE8021QCC]はTSN機能の構成（例えば、[IEEE8021QBV]で指定されたトラフィックスケジューリング）も指定します。一般的なアーキテクチャとフロー情報モデルでは、Detnetサービスを提供するネットワークにL3とL2の両方のネットワークセグメントの両方が含まれている場合、設定された機能とフロー情報モデルを使用できます。
As expressed in the DetNet WG Charter [IETFDetNet], the DetNet WG collaborates with IEEE 802.1 TSN in order to define a common architecture for both Layers 2 and 3. This is beneficial for several reasons, e.g., in order to simplify implementations and maintain consistency across diverse networks. The flow and service information models are also aligned for those reasons. Therefore, the DetNet flow and service information models described in this document are based on [IEEE8021Qcc], which is an amendment to [IEEE8021Q].
Detnet WG Charter [IETFDetnet]で表現されているように、Detnet WGは、レイヤ2と3の両方の共通アーキテクチャを定義するためにIEEE 802.1 TSNと共同で、実装を簡素化し、一貫性を維持するために、いくつかの理由で有益である。多様なネットワーク間で。それらの理由から、フローおよびサービス情報モデルも整列しています。したがって、この文書に記載されているDetnet Flow and Service Informationモデルは、[IEEE8021Q]の修正である[IEEE8021QCC]に基づいています。
This document specifies flow and service information models only.
このドキュメントはフローおよびサービス情報モデルのみを指定します。
This document does not specify flow data models or DetNet configuration. Therefore, the goals of this document differ from the goals of [IEEE8021Qcc], which also specifies the TSN data model and configuration of certain TSN features.
この文書では、フローデータモデルやDetnet構成は指定されていません。したがって、この文書の目的は[IEEE8021QCC]の目的とは異なり、TSNデータモデルと特定のTSN機能の構成も指定します。
The DetNet-specific YANG data model is described in [DETNET-YANG].
Detnet固有のヤンデータモデルは[Detnet-Yang]に記載されています。
This document uses the terminology established in the DetNet architecture [RFC8655] and the DetNet data plane framework [RFC8938]. The reader is assumed to be familiar with these documents and any terminology defined therein. The DetNet <=> TSN dictionary of [RFC8655] is used to perform translation from [IEEE8021Qcc] to this document.
この文書では、Detnetアーキテクチャ[RFC8655]とDetNet Data Plane Framework [RFC8938]で設定されている用語を使用しています。リーダーは、これらの文書およびそこに定義された任意の用語に精通していると見なされます。[RFC8655]のDetnet <=> TSN辞書は、[IEEE8021QCC]からこの文書への変換を実行するために使用されます。
The following terminology is used in accordance with [RFC8655]:
[RFC8655]に従って、次の用語が使用されます。
App-flow The payload (data) carried over a DetNet service.
アプリフローDetnetサービスを介して伝送されるペイロード（データ）。
DetNet flow A sequence of packets that conform uniquely to a flow identifier and to which the DetNet service is to be provided. It includes any DetNet headers added to support the DetNet service and forwarding sub-layers.
DetNet Flowフロー識別子とDetNetサービスを提供するものと一意に適合するパケットのシーケンス。Detnetサービスと転送サブレイヤーをサポートするために追加されたDetnetヘッダーが追加されています。
The following terminology is introduced in this document:
この文書では、次の用語が紹介されています。
Source Reference point for an App-flow, where the flow starts.
フローが開始されるアプリフローのソース参照ポイント。
Destination Reference point for an App-flow, where the flow terminates.
フローが終了するアプリフローの宛先参照ポイント。
DN Ingress Reference point for the start of a DetNet flow. Networking technology-specific encapsulation may be added here to the served App-flow(s).
DNの入力基準点DetNetフローの開始の点。ネットワーク技術固有のカプセル化は、サービスを提供したアプリフローに追加されてもよい。
DN Egress Reference point for the end of a DetNet flow. Networking technology-specific encapsulation may be removed here from the served App-flow(s).
DENTNETフローの終わりのDN出力基準点。ネットワーク技術固有のカプセル化は、ここでサービス提供されたアプリフローから削除されることがあります。
The following abbreviations are used in this document:
この文書では、次の略語が使用されています。
DetNet Deterministic Networking
Detnet決定論的ネットワーキング
DN DetNet
DN Detnet
MPLS Multiprotocol Label Switching
MPLSマルチプロトコルラベルスイッチング
PSN Packet Switched Network
PSNパケット交換ネットワーク
TSN Time-Sensitive Networking
TSNの時間依存ネットワーキング
The following naming conventions were used for naming information model components in this document. It is recommended that extensions of the model use the same conventions.
この文書の情報モデルコンポーネントの命名には、次の命名規則が使用されていました。モデルの拡張機能は同じ規則を使用することをお勧めします。
* Descriptive names are used.
* 記述名が使用されています。
* Names start with uppercase letters.
* 名前は大文字で始まります。
* Composed names use capital letters for the first letter of each component. All other letters are lowercase, even for abbreviations. Exceptions are made for abbreviations containing a mixture of lowercase and capital letters, such as IPv6. Example composed names are SourceMacAddress and DestinationIPv6Address.
* 構成された名前は、各コンポーネントの最初の文字に大文字を使用します。略語の場合でも、他のすべての文字は小文字です。例外は、IPv6などの小文字と大文字の混合物を含む略語に対して行われます。構成された名前の例はSourceMacAddressとDestinationIPv6Addressです。
The DetNet service can be defined as a service that provides a capability to carry a unicast or a multicast data flow for an application with constrained requirements on network performance, e.g., low packet loss rate and/or latency.
DetNetサービスは、ネットワーク性能、例えばパケット損失率および/または待ち時間に関する制約付き要件を有するアプリケーションのためのユニキャストまたはマルチキャストデータフローを伝送する機能を提供するサービスとして定義することができる。
Figures 5 and 8 in [RFC8655] show the DetNet service-related reference points and main components.
[RFC8655]の図5と8はDetnetサービス関連の基準点と主要コンポーネントを示しています。
From a service-design perspective, a fundamental question is the location of the service/flow endpoints, i.e., where the service/flow starts and ends.
サービス設計の観点からは、基本的な質問は、サービス/フローエンドポイントの場所、すなわちサービス/フローが開始され終了することです。
App-flow-specific reference points are the source (where it starts) and the destination (where it terminates). Similarly, a DetNet flow has reference points termed "DN Ingress" (where a DetNet flow starts) and "DN Egress" (where a DetNet flow ends). These reference points may coexist in the same node (e.g., in a DetNet IP end system). DN Ingress and DN Egress reference points are intermediate reference points for a served App-flow.
アプリフロー固有の基準ポイントは、ソース（起動する場所）と宛先（終了）です。同様に、DETNETフローには、「DN入力」（DETNETフローが開始されている場合）と「DN出力」（DETNETフローが終了した場合）と呼ばれる基準点があります。これらの基準点は、（例えば、DetNet IPエンドシステムで）同じノードに共存することがある。DN入力とDNの出力基準点は、提供されたアプリフローの中間基準点です。
In this document, all reference points are assumed to be packet-based reference points. A DN Ingress may add and a DN Egress may remove networking technology-specific encapsulation to/from the served App-flow(s) (e.g., MPLS label(s), UDP, and IP headers).
この文書では、すべての参照点はパケットベースの基準点であると仮定されています。DN入力は追加することができ、DN出力は、サービングされたアプリフロー（例えば、MPLSラベル、UDP、およびIPヘッダ）への/からのネットワーク技術固有のカプセル化を除去することができる。
The DetNet flow information model and the service information model rely on three groups of information elements:
Detnet Flow情報モデルとサービス情報モデルは、3つのグループの情報要素に依存しています。
App-flow-related parameters: These describe the App-flow characteristics (e.g., identification, encapsulation, traffic specification, endpoints, status, etc.) and the App-flow service expectations (e.g., delay, loss, etc.).
アプリフロー関連のパラメータ：これらは、アプリフロー特性（例えば、識別、カプセル化、トラフィック仕様、エンドポイント、ステータスなど）およびアプリフローサービスの期待（例えば、遅延、損失など）を記載している。
DetNet flow-related parameters: These describe the DetNet flow characteristics (e.g., identification, format, traffic specification, endpoints, rank, etc.).
DetNetフロー関連のパラメータ：Detnetフロー特性（例えば、識別、フォーマット、トラフィック仕様、エンドポイント、ランクなど）を記述します。
DetNet service-related parameters: These describe the expected service characteristics (e.g., delivery type, connectivity delay/ loss, status, rank, etc.).
DetNetサービス関連のパラメータ：これらは予想されるサービス特性（例えば、配信タイプ、接続性遅延/損失、ステータス、ランクなど）を記述します。
In the information model, a DetNet flow contains one or more (aggregated) App-flows (N:1 mapping). During DetNet aggregation, the aggregated DetNet flows are treated simply as App-flows and the aggregate is the DetNet flow, which provides N:1 mapping. Similarly, there is an aggregated many-to-one relationship for the DetNet flow(s) to the DetNet service.
情報モデルでは、Detnet Flowには1つ以上の（集約された）App-Flows（N：1マッピング）が含まれています。Detnet集約の間、集約されたDetnetフローは簡単にApp-Flowsとして扱われ、集計はDetnet Flowです。これはN：1マッピングを提供します。同様に、DetnetフローにDetnetサービスへの多対1の関係が集約されています。
When DetNet service is required by time-/loss-sensitive application(s) running on an end system during communication with its peer(s), the resulting data exchange has various requirements on delay and/or loss parameters.
端末との通信中にエンドシステム上で実行されているタイム/損失依存アプリケーションによってDetNetサービスが必要な場合、結果のデータ交換には、遅延および/または損失パラメータに関するさまざまな要件があります。
App-flow characteristics are described by the following parameters:
アプリフロー特性は、次のパラメータで説明されています。
FlowID: a unique (management) identifier of the App-flow, which can be used to define the N:1 mapping of App-flows to a DetNet flow
flowId：アプリフローの一意の（管理）識別子。
FlowType: set by the encapsulation format of the flow, which can be Ethernet (TSN), MPLS, or IP
flowtype：イーサネット（TSN）、MPLS、またはIPにすることができるフローのカプセル化フォーマットによって設定されます。
DataFlowSpecification: a flow descriptor, defining which packets belongs to a flow, using specific packet header fields, such as src-addr, dst-addr, label, VLAN-ID, etc.
dataflowspecification：フロー記述子、SRC-ADDR、DST-ADDR、LABEL、VLAN-IDなどの特定のパケットヘッダーフィールドを使用して、どのパケットがフローに属しているかを定義します。
TrafficSpecification: a flow descriptor, defining traffic parameters, such as packet size, transmission time interval, and maximum packets per time interval
TrafficSpecification：パケットサイズ、送信時間間隔などのトラフィックパラメータを定義し、時間間隔ごとのトラフィックパラメータの定義
FlowEndpoints: delineates the start and end reference points of the
App-flow by pointing to the source interface/node and
destination interface(s)/node(s)
FlowStatus: indicates the status of the App-flow with respect to the establishment of the flow by the connected network, e.g., ready, failed, etc.
flowStatus：接続されているネットワークによるフローの確立に関して、例えば、準備ができた、失敗などを示すアプリケーションフローの状況を示します。
FlowRank: indicates the rank of this flow relative to other flows in the connected network
FlowRank：接続されているネットワーク内の他のフローに対するこのフローのランクを示します。
| Note: When defining the N:1 mapping of App-flows to a DetNet
| flow, the App-flows must have the same FlowType and different
| DataFlowSpecification parameters.
App-flow requirements are described by the following parameters:
アプリフロー要件は、次のパラメータで説明されています。
FlowRequirements: defines the attributes of the App-flow regarding bandwidth, latency, latency variation, loss, and misordering tolerance
FlowRequirede：帯域幅、待ち時間、遅延変動、損失、および誤った許容誤差に関するAPPフローの属性を定義します。
FlowBiDir: defines the data path requirement of the App-flow whether it must share the same data path and physical path for both directions through the network, e.g., to provide congruent paths in the two directions
FlowBidir：アプリケーションフローのデータパスの要件を定義して、ネットワークを介して同じデータパスと物理パスを共有しなければならないかどうか、例えば2つの方向に合同パスを提供する
The data model specified by [IEEE8021Qcc] describes data flows using TSN service as periodic flows with fixed packet size (i.e., Constant Bitrate (CBR) flows) or with variable packet size. The same concept is applied for flows using DetNet service.
[IEEE8021QCC]で指定されたデータモデルは、固定パケットサイズ（すなわち、定数ビットレート（CBR）フロー）または可変パケットサイズを有する周期的な流れとしてTSNサービスを使用したデータフローを説明している。Detnetサービスを使用したフローには同じ概念が適用されます。
Latency and loss parameters are correlated because the effect of late delivery can result in data loss for an application. However, not all applications require hard limits on both latency and loss. For example, some real-time applications allow graceful degradation if loss happens (e.g., sample-based data processing and media distribution). Some other applications may require high-bandwidth connections that make use of packet replication techniques that are economically challenging or even impossible. Some applications may not tolerate loss but are not delay sensitive (e.g., bufferless sensors). Time- or loss-sensitive applications may have somewhat special requirements, especially for loss (e.g., no loss over two consecutive communication cycles, very low outage time, etc.).
遅延配信の影響がアプリケーションのデータ損失をもたらす可能性があるため、レイテンシと損失のパラメータは相関しています。ただし、すべてのアプリケーションが待ち時間と損失の両方で厳密な制限を必要とするわけではありません。たとえば、損失が発生した場合には、リアルタイムアプリケーションの中にはグレースフルな劣化を可能にします（例えば、サンプルベースのデータ処理とメディアディストリビューション）。他のいくつかのアプリケーションは、経済的に挑戦的であるか不可能でさえも、パケット複製技術を利用する高帯域幅の接続を必要とし得る。いくつかの用途は損失を許容しないが遅延敏感（例えば、バッファレスセンサ）ではない。時間または損失に敏感なアプリケーションは、特に損失（例えば、2つの連続した通信サイクル、非常に低い停止時間などにわたって損失なし）のために多少特別な要件を有することがある。
DetNet flows have the following attributes:
Detnet Flowには、次の属性があります。
a. DnFlowID (Section 5.1) b. DnPayloadType (Section 5.2) c. DnFlowFormat (Section 5.3) d. DnFlowSpecification (Section 5.4) e. DnTrafficSpecification (Section 5.5) f. DnFlowEndpoints (Section 5.6) g. DnFlowRank (Section 5.7) h. DnFlowStatus (Section 5.8)
a. dnflowid（セクション5.1）b。DNPayLoadType（セクション5.2）c。DNFlowFormat（セクション5.3）d。dnflowspecification（セクション5.4）DNTrafficsPecification（セクション5.5）f。dnflowEndpoints（セクション5.6）g。dnflowrank（セクション5.7）dnflowStatus（セクション5.8）
DetNet flows have the following requirement attributes:
Detnet Flowsには、次の要件属性があります。
a. DnFlowRequirements (Section 5.9) b. DnFlowBiDir (Section 5.10)
a. DNFlowRequirements（セクション5.9）b。dnflowbidir（セクション5.10）
Flow attributes are described in the following sections.
フロー属性については、以下のセクションで説明します。
A unique (management) identifier is needed for each DetNet flow within the DetNet domain. It is specified by DnFlowID. It can be used to define the N:1 mapping of DetNet flows to a DetNet service.
Detnetドメイン内の各DetNetフローには、一意の（管理）識別子が必要です。dnflowidで指定されています。DetNetサービスへのDetNetフローのN：1マッピングを定義するために使用できます。
The DnPayloadType attribute is set according to the encapsulated App-flow format. The attribute can be Ethernet, MPLS, or IP.
DNPAYLOADTYPE属性は、カプセル化されたアプリフローフォーマットに従って設定されます。属性は、イーサネット、MPLS、またはIPです。
The DnFlowFormat attribute is set according to the DetNet PSN technology. The attribute can be MPLS or IP.
DNFlowFormat属性はDetNet PSNテクノロジに従って設定されています。属性はMPLSまたはIPにすることができます。
Identification options for DetNet flows at the Ingress/Egress and within the DetNet domain are specified as follows; see Section 5.4.1 for DetNet MPLS flows and Section 5.4.2 for DetNet IP flows.
入力/出力およびDetNetドメイン内のDetNet Netフローの識別オプションは次のように指定されています。Detnet MPLSフローおよびDetNet IPフローのセクション5.4.2については、セクション5.4.1を参照してください。
The identification of DetNet MPLS flows within the DetNet domain is based on the MPLS context in the service information model. The attributes are specific to the MPLS forwarding paradigm within the DetNet domain [RFC8964]. DetNet MPLS flows can be identified and specified by the following attributes:
Detnetドメイン内のDetnet MPLSフローの識別は、サービス情報モデル内のMPLSコンテキストに基づいています。属性は、Detnetドメイン内のMPLS転送パラダイム（RFC8964]に固有のものです。Detnet MPLSフローは、次の属性で識別して指定できます。
a. SLabel b. FLabelStack
a. スラベルb。フラベルスタック
DetNet IP flows can be identified and specified by the following attributes [RFC8939]:
Detnet IPフローは、次の属性で識別して指定できます。[RFC8939]：
a. SourceIpAddress b. DestinationIpAddress c. IPv6FlowLabel d. Dscp e. Protocol f. SourcePort g. DestinationPort h. IPSecSpi
a. SourceIpAddress b。destinationipddress c。IPv6FlowLabel D。dscp e。プロトコルF。SourcePort g。宛先ポートipsecspi
The IP 6-tuple that is used for DetNet IP flow identification consists of items a, b, d, e, f, and g. Items c and h are additional attributes that can be used for DetNet flow identification in addition to the 6-tuple. The 6-tuple and use of wild cards for these attributes are specified in [RFC8939].
Detnet IPフロー識別に使用されるIP 6タプルは、項目A、B、D、E、F、およびGで構成されています。項目CとHは、6タプルに加えてDetNetフロー識別に使用できる追加の属性です。これらの属性のための6タプルとワイルドカードの使用は[RFC8939]に指定されています。
The DnTrafficSpecification attributes specify how the DN Ingress transmits packets for the DetNet flow. This is effectively the promise/request of the DN Ingress to the network. The network uses this traffic specification to allocate resources and adjust queue parameters in network nodes.
DNTrafficSpecification属性は、DNの入力がDetNetフローのパケットを送信する方法を指定します。これは実質的にネットワークへのDN入力の約束/要求です。ネットワークは、このトラフィック仕様を使用してリソースを割り当て、ネットワークノードでキューパラメータを調整します。
TrafficSpecification has the following attributes:
TrafficSpecificationには、次の属性があります。
a. Interval: the period of time in which the traffic specification is specified
a. 間隔：トラフィック指定が指定されている期間
b. MaxPacketsPerInterval: the maximum number of packets that the Ingress will transmit in one Interval
b. MaxPacketSperInterval：入力が1つの間隔で送信するパケットの最大数
c. MaxPayloadSize: the maximum payload size that the Ingress will transmit
c. MaxPayLoadSize：入力が送信する最大ペイロードサイズ
d. MinPayloadSize: the minimum payload size that the Ingress will transmit
d. MinPayLoadSize：入力が送信する最小ペイロードサイズ
e. MinPacketsPerInterval: the minimum number of packets that the Ingress will transmit in one Interval
e. MinPacketSperInterval：入力が1つの間隔で送信するパケットの最小数
These attributes can be used to describe any type of traffic (e.g., CBR, Variable Bitrate (VBR), etc.) and can be used during resource allocation to represent worst-case scenarios. Intervals are specified as an integer number of nanoseconds. PayloadSizes are specified in octets.
これらの属性は、任意の種類のトラフィック（例えば、CBR、可変ビットレート（VBR）などを記述するために使用でき、最悪のシナリオを表すためにリソース割り当て中に使用できます。間隔は整数のナノ秒数として指定されます。ペイロード化はオクテットで指定されています。
Flows exceeding the traffic specification (i.e., having more traffic than defined by the maximum attributes) may receive a different network behavior than the DetNet network has been engineered for. Excess traffic due to malicious or malfunctioning devices can be prevented or mitigated (e.g., through the use of existing mechanisms, such as policing and shaping).
トラフィック仕様を超えるフロー（すなわち、最大属性で定義されたより多くのトラフィックを有する）は、DetNetネットワークが設計されているものとは異なるネットワーク動作を受信することができる。悪意のあるまたは故障した装置による過剰な交通量を防止または軽減することができる（例えば、ポリシングおよび整形などの既存のメカニズムの使用を通して）。
When MinPayloadSize and MinPacketsPerInterval parameters are used, all packets less than the MinPayloadSize will be counted as being of the size MinPayloadSize during packet processing when packet size matters, e.g., when policing; all flows having less than MinPacketsPerInterval will be counted as having MinPacketsPerInterval when the number of packets per interval matters, e.g., during resource reservation. However, flows having less than MinPacketsPerInterval may result in a different network behavior than the DetNet network has been engineered for. MinPayloadSize and MinPacketsPerInterval parameters, for example, may be used when engineering the latency bounds of a DetNet flow when Packet Ordering Function (POF) is applied to the given DetNet flow.
MinPayLoadSizeとMinPacketSperIntervalパラメータを使用すると、パケットサイズが重要な場合は、パケットの処理中に、Packet PaySizeよりも小さいすべてのパケットが、PACKED SIZEの場合、例えばポリシングのときにカウントされます。MinPacketSperIntervalより少ないすべてのフローは、間隔ごとのパケット数が重要な場合、例えばリソース予約中に、MinPacketSperIntervalを持つものとしてカウントされます。ただし、MinPacketSperIntervalより少ないフローは、Detnetネットワークが設計されているものとは異なるネットワーク動作をもたらす可能性があります。MinPayLoadSizeとMinPacketSperIntervalパラメータは、例えば、パケット順序付け関数（POF）が所与のDETNETフローに適用されたときにDetNetフローの待ち時間の範囲をエンジニアリングするときに使用され得る。
Further optional attributes can be considered to achieve more efficient resource allocation. Such optional attributes might be worth for flows with soft requirements (i.e., the flow is only loss sensitive or only delay sensitive but not both delay and loss sensitive). Possible options about how to extend DnTrafficSpecification attributes is for further discussion.
さらなるオプションの属性は、より効率的なリソース割り当てを達成すると考えることができます。そのようなオプションの属性は、ソフト要件を持つフローの価値があるかもしれません（すなわち、フローは損失に敏感であるだけ、または遅延に敏感ではなく遅延と損失に敏感ではないだけではありません）。DNTrafficSpecification属性を拡張する方法についての可能なオプションは、さらなる議論のためのものです。
The DnFlowEndpoints attribute defines the start and end reference points of the DetNet flow by pointing to the ingress interface/node and egress interface(s)/node(s). Depending on the network scenario, it defines an interface or a node. Interface can be defined, for example, if the App-flow is a TSN Stream, and it is received over a well-defined User-to-Network Interface (UNI). For example, for App-flows with MPLS encapsulation, defining an ingress node is more common when a per-platform label space is used.
dnflowEndpoints属性は、入力インタフェース/ノードと出力インタフェース/ノードを指すことによって、DetNetフローの開始点と終了の基準点を定義します。ネットワークシナリオによっては、インターフェイスまたはノードを定義します。たとえば、アプリフローがTSNストリームである場合は、インターフェイスを定義でき、明確に定義されたユーザー間インターフェイス（UNI）を介して受信できます。たとえば、MPLSカプセル化を備えたApp-Flowsの場合、プラットフォームごとのラベルスペースを使用すると、入力ノードを定義することが一般的です。
The DnFlowRank attribute provides the rank of this flow relative to other flows in the DetNet domain. Rank (range: 0-255) is used by the DetNet domain to decide which flows can and cannot exist when network resources reach their limit. Rank is used to help to determine which flows can be bumped (i.e., removed from node configuration thereby releasing its resources) if, for example, a port of a node becomes oversubscribed (e.g., due to network reconfiguration). DnFlowRank value 0 is the highest priority.
dnflowrank属性は、DetNetドメイン内の他のフローに対するこのフローのランクを提供します。ランク（範囲：0~255）は、ネットワークリソースがそれらの制限に達するときにどのフローができるか存在できないかを決定するためにDetnetドメインによって使用されます。例えば、ノードのポートがオーバーサブスクライブされた場合（例えば、ネットワーク再構成のために）どのフローをバンプ化することができるか（すなわち、それによってそのリソースを解放すること）を決定するのを助けるためにランクが使用される。dnflowrank値0が最も優先されます。
The DnFlowStatus attribute provides the status of the DetNet flow with respect to the establishment of the flow by the DetNet domain.
dnflowStatus属性は、DetNetドメインによるフローの確立に関してDetnetフローのステータスを提供します。
DnFlowStatus includes the following attributes:
DNFlowStatusには、次の属性が含まれています。
a. DnIngressStatus is an enumeration for the status of the flow's Ingress reference point:
a. DningRessStatusは、フローの入力基準点のステータスの列挙です。
None: No Ingress. Ready: Ingress is ready. Failed: Ingress failed. OutOfService: Administratively blocked.
なし：入力はありません。準備完了：入力準備ができています。失敗しました：入力に失敗しました。OutofService：管理上ブロックされました。
b. DnEgressStatus is an enumeration for the status of the flow's Egress reference points:
b. DNEGressStatusは、フローの出力基準点のステータスの列挙です。
None: No Egress. Ready: All Egresses are ready. PartialFailed: One or more Egress is ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready. Failed: All Egresses failed. OutOfService: All Egresses are administratively blocked.
なし：差しからない。準備完了：すべての出所は準備ができています。パーシャルフェイル：1つ以上の出力が準備ができて、1つ以上の出力が失敗しました。入り込みの準備ができている場合は、Detnet Flowを使用できます。失敗しました：すべての電源が失敗しました。OUTOFSERVICE：すべての出口は管理上ブロックされています。
c. FailureCode is a nonzero code that specifies the error if the DetNet flow encounters a failure (e.g., packet replication and elimination is requested but not possible or DnIngressStatus is Failed, DnEgressStatus is Failed, or DnEgressStatus is PartialFailed).
c. FailureCodeは、Detnet Flowが障害に遭遇した場合（例えば、パケットの複製と除去が要求されていますが、DneGressStatusが失敗した場合、またはDNEGressStatusが失敗した場合、またはDNEGressStatusが失敗した場合、DNEGressStatusが失敗した場合、またはDNEGressStatusが障害が発生した場合、DNEGressStatusが障害が発生した場合、またはDNEGressStatusが失敗する）。
Defining FailureCodes for DetNet is out of scope for this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.
Detnetのフェールコードの定義はこの文書の範囲外です。[IEEE8021QCC]の表46-1に、TSN障害コードについて説明します。
The DnFlowRequirements attribute specifies requirements to ensure the service level desired for the DetNet flow.
dnflowRequirements属性は、Detnetフローに必要なサービスレベルを確実にするための要件を指定します。
DnFlowRequirements includes the following attributes:
DNFlowRequirementsには、次の属性が含まれています。
a. MinBandwidth (Section 5.9.1) b. MaxLatency (Section 5.9.2) c. MaxLatencyVariation (Section 5.9.3) d. MaxLoss (Section 5.9.4) e. MaxConsecutiveLossTolerance (Section 5.9.5) f. MaxMisordering (Section 5.9.6)
a. Minbandwidth（セクション5.9.1）b。MAXLatency（セクション5.9.2）c。maxlatencyvariation（セクション5.9.3）d。MAXLOSS（セクション5.9.4）MaxConseCutivelosStrerance（セクション5.9.5）f。マックスマイクロメング（5.9.6セクション）
MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet flow. MinBandwidth is specified in octets per second.
MinBandWidthは、Detnetフローに対して保証されている必要がある最小帯域幅です。Minbandwidthは毎秒オクテットで指定されています。
MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow. MaxLatency is specified as an integer number of nanoseconds.
MAXLatencyは、Detnet Flowの単一パケットの入力から出力への最大待ち時間です。maxLatencyは、整数のナノ秒数として指定されます。
MaxLatencyVariation is the difference between the minimum and the maximum end-to-end, one-way latency. MaxLatencyVariation is specified as an integer number of nanoseconds.
MaxLatencyVariationは、最小と最大エンドツーエンドの一方向の待ち時間の差です。MaxLatencyVariationは、整数のナノ秒数として指定されています。
MaxLoss defines the maximum Packet Loss Rate (PLR) requirement for the DetNet flow between the Ingress and Egress(es) and the loss measurement interval.
MAXLOSSは、入力と出力（ES）と損失測定間隔との間のDetNetフローに対する最大パケット損失率（PLR）要件を定義します。
Some applications have special loss requirements, such as MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured, for example, based on sequence number.
一部のアプリケーションには、MaxConsecutivelosStreranceなどの特別な損失要件があります。最大連続損失許容誤差パラメータは、損失を許容できる連続パケットの最大数を表します。最大連続損失許容誤差は、例えばシーケンス番号に基づいて測定することができる。
MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The value zero for the maximum allowed misordering indicates that in-order delivery is required; misordering cannot be tolerated.
MaxMisOrderingは、順不同で受信できるパケットの最大数を表します。最大許容誤符号化の値ゼロは、注文配信が必要であることを示しています。誤解は許容できません。
The maximum allowed misordering can be measured, for example, based on sequence numbers. When a packet arrives at the egress after a packet with a higher sequence number, the difference between the sequence number values cannot be bigger than "MaxMisordering + 1".
最大許容誤順序付けは、例えばシーケンス番号に基づいて測定することができる。シーケンス番号が高いパケットの後にパケットが出力に到着すると、シーケンス番号値の差は「MaxOdering 1」よりも大きくすることはできません。
The DnFlowBiDir attribute defines the requirement that the flow and the corresponding reverse direction flow must share the same path (links and nodes) through the routed or switch network in the DetNet domain, e.g., to provide congruent paths in the two directions that share fate and path characteristics.
dnflowbidir属性は、FateとFateを共有する2つの方向に合同パスを提供するために、DetNetドメイン内のルーテットまたはスイッチネットワークを介して、フローと対応する逆方向フローが同じパス（リンクとノード）を共有する必要があるという要件を定義します。パス特性
The DetNet service has the following attributes:
Detnetサービスには、次の属性があります。
a. DnServiceID (Section 6.1) b. DnServiceDeliveryType (Section 6.2) c. DnServiceDeliveryProfile (Section 6.3) d. DNServiceConnectivity (Section 6.4) e. DnServiceBiDir (Section 6.5) f. DnServiceRank (Section 6.6) g. DnServiceStatus (Section 6.7)
a. DNServiceID（セクション6.1）b。DNServiceDeliveryType（セクション6.2）c。DNServiceDeLiveryProfile（セクション6.3）d。DNServiceConnectivity（6.4項）DNServiceBidir（6.5項）f。DNServiceRank（セクション6.6）DNServiceStatus（6.7項）
Service attributes are described in the following sections.
サービス属性については、以下のセクションで説明します。
The DnServiceId attribute is a unique (management) identifier for each DetNet service within the DetNet domain. It can be used to define the many-to-one mapping of DetNet flows to a DetNet service.
DNServiceID属性は、Detnetドメイン内の各DetNetサービスの一意の（管理）識別子です。DetNetサービスへのDetNetフローの多対1マッピングを定義するために使用できます。
The DnServiceDeliveryType attribute is set according to the payload of the served DetNet flow (i.e., the encapsulated App-flow format). The attribute can be Ethernet, MPLS, or IP.
DNServiceDeliveryType属性は、提供されているDetnetフローのペイロード（すなわち、カプセル化されたアプリフローフォーマット）に従って設定される。属性は、イーサネット、MPLS、またはIPです。
The DnServiceDeliveryProfile attribute specifies the delivery profile to ensure proper serving of the DetNet flow.
DNServiceELiveryProfile属性は、Detnet Flowを適切に提供するように配信プロファイルを指定します。
DnServiceDeliveryProfile includes the following attributes:
DNServiceDeliveryProfileには、次の属性が含まれています。
a. MinBandwidth (Section 6.3.1) b. MaxLatency (Section 6.3.2) c. MaxLatencyVariation (Section 6.3.3) d. MaxLoss (Section 6.3.4) e. MaxConsecutiveLossTolerance (Section 6.3.5) f. MaxMisordering (Section 6.3.6)
a. MinbandWidth（6.3.1項）b。maxLatency（6.3.2項）c。MAXLatencyVariation（6.3.3項）D。MAXLOSS（6.3.4項）MAXCONSECUTIVELOSSTRERANCE（セクション6.3.5）f。マクシマスオーダー（セクション6.3.6）
MinBandwidth is the minimum bandwidth that has to be guaranteed for the DetNet service. MinBandwidth is specified in octets per second and excludes additional DetNet header (if any).
MinBandwidthはDetnetサービスに対して保証されている必要がある最小帯域幅です。MinBandwidthは1秒あたりのオクテットで指定され、追加のDetnetヘッダー（もしあれば）を除外します。
MaxLatency is the maximum latency from Ingress to Egress(es) for a single packet of the DetNet flow. MaxLatency is specified as an integer number of nanoseconds.
MAXLatencyは、Detnet Flowの単一パケットの入力から出力への最大待ち時間です。maxLatencyは、整数のナノ秒数として指定されます。
MaxLatencyVariation is the difference between the minimum and the maximum end-to-end, one-way latency. MaxLatencyVariation is specified as an integer number of nanoseconds.
MaxLatencyVariationは、最小と最大エンドツーエンドの一方向の待ち時間の差です。MaxLatencyVariationは、整数のナノ秒数として指定されています。
MaxLoss defines the maximum Packet Loss Rate (PLR) parameter for the DetNet service between the Ingress and Egress(es) of the DetNet domain.
MAXLOSS DetNetドメインの入力と出力（ES）の間のDetNetサービスの最大パケット損失率（PLR）パラメータを定義します。
Some applications have a special loss requirement, such as MaxConsecutiveLossTolerance. The maximum consecutive loss tolerance parameter describes the maximum number of consecutive packets whose loss can be tolerated. The maximum consecutive loss tolerance can be measured, for example, based on sequence number.
一部のアプリケーションには、MaxConsecutivelosStreranceなどの特別な損失要件があります。最大連続損失許容誤差パラメータは、損失を許容できる連続パケットの最大数を表します。最大連続損失許容誤差は、例えばシーケンス番号に基づいて測定することができる。
MaxMisordering describes the tolerable maximum number of packets that can be received out of order. The maximum allowed misordering can be measured, for example, based on sequence number. The value zero for the maximum allowed misordering indicates that in-order delivery is required; misordering cannot be tolerated.
MaxMisOrderingは、順不同で受信できるパケットの最大数を表します。最大許容誤式は、例えばシーケンス番号に基づいて測定することができる。最大許容誤符号化の値ゼロは、注文配信が必要であることを示しています。誤解は許容できません。
Two connectivity types are distinguished: point-to-point (p2p) and point-to-multipoint (p2mp). Connectivity type p2mp may be created by a forwarding function (e.g., p2mp LSP). (Note that from a service perspective, mp2mp connectivity can be treated as a superposition of p2mp connections.)
2つの接続タイプが区別されます。ポイントツーポイント（P2P）とポイントツーマルチポイント（P2MP）。接続タイプP2MPは、転送関数（例えば、P2MP LSP）によって作成されてもよい。（サービスの観点からは、MP2MP接続をP2MP接続の重ね合わせとして扱うことができます。）
The DnServiceBiDir attribute defines the requirement that the flow and the corresponding reverse direction flow must share the same path (links and nodes) through the routed or switch network in the DetNet domain, e.g., to provide congruent paths in the two directions that share fate and path characteristics.
DNServiceBidir属性は、Fateを共有する2つの方向に合同パスを提供するために、DetNetドメイン内のルーテッドネットワークまたはスイッチネットワークを介して、フローと対応する逆方向フローが同じパス（リンクとノード）を共有する必要があるという要件を定義します。パス特性
The DnServiceRank attribute provides the rank of a service instance relative to other services in the DetNet domain. DnServiceRank (range: 0-255) is used by the network in case of network resource limitation scenarios. DnServiceRank value 0 is the highest priority.
DNServiceRank属性は、DetNetドメイン内の他のサービスとの関連のサービスインスタンスのランクを提供します。ネットワークリソース制限シナリオの場合、ネットワークによってDNServiceRank（範囲：0~255）が使用されています。DNServiceRank値0が最も優先されます。
The DnServiceStatus information group includes elements that specify the status of the service-specific state of the DetNet domain. This information group informs the user whether or not the service is ready for use.
DNServiceStatus情報グループには、DetNetドメインのサービス固有の状態のステータスを指定する要素が含まれています。この情報グループは、サービスが使用の準備ができているかどうかをユーザーに通知します。
DnServiceStatus includes the following attributes:
DNServiceStatusには、次の属性が含まれています。
a. DnServiceIngressStatus is an enumeration for the status of the service's Ingress:
a. DNServiceIngressStatusは、サービスの入力ステータスの列挙です。
None: No Ingress. Ready: Ingress is ready. Failed: Ingress failed. OutOfService: Administratively blocked.
なし：入力はありません。準備完了：入力準備ができています。失敗しました：入力に失敗しました。OutofService：管理上ブロックされました。
b. DnServiceEgressStatus is an enumeration for the status of the service's Egress:
b. DNServiceEgressStatusは、サービスの出力のステータスの列挙です。
None: No Egress. Ready: All Egresses are ready. PartialFailed: One or more Egress is ready, and one or more Egress failed. The DetNet flow can be used if the Ingress is Ready. Failed: All Egresses failed. OutOfService: Administratively blocked.
なし：差しからない。準備完了：すべての出所は準備ができています。パーシャルフェイル：1つ以上の出力が準備ができて、1つ以上の出力が失敗しました。入り込みの準備ができている場合は、Detnet Flowを使用できます。失敗しました：すべての電源が失敗しました。OutofService：管理上ブロックされました。
c. DnServiceFailureCode is a nonzero code that specifies the error if the DetNet service encounters a failure (e.g., packet replication and elimination is requested but not possible or DnServiceIngressStatus is Failed, DnServiceEgressStatus is Failed, or DnServiceEgressStatus is PartialFailed).
c. DNServiceFailureCodeは、Detnetサービスが障害が発生した場合（例えば、パケットの複製と除去が要求されていますが、DNServiceIngRessStatusに失敗した場合、DNServiceEgressStatusが失敗した場合、またはDNServiceEgressStatusが失敗した場合、またはDNServiceEgressStatusが失敗する、またはDNServiceEgressStatusが失敗した場合、またはDNServiceEgressStatusが失敗する、またはDNServiceEgressStatusが失敗した場合、DNServiceEgressStatusが失敗しています）。
Defining DnServiceFailureCodes for DetNet service is out of scope for this document. Table 46-1 of [IEEE8021Qcc] describes TSN failure codes.
DetNetサービスのDNServiceFailureCodeの定義はこの文書の範囲外です。[IEEE8021QCC]の表46-1に、TSN障害コードについて説明します。
The DetNet flow information model relies on three high-level information groups:
Detnet Flow情報モデルは、3つの高レベルの情報グループに依存しています。
DnIngress: The DnIngress information group includes elements that specify the source for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.
DNINGRESS：DNINGRESS情報グループには、単一のDetnetフローのソースを指定する要素が含まれています。この情報グループは、DetNetサービスのユーザからネットワークに適用される。
DnEgress: The DnEgress information group includes elements that specify the destination for a single DetNet flow. This information group is applied from the user of the DetNet service to the network.
DNEGRESS：DNEGRESS情報グループには、単一のDetnetフローの宛先を指定する要素が含まれています。この情報グループは、DetNetサービスのユーザからネットワークに適用される。
DnFlowStatus: The DnFlowStatus information group includes elements that specify the status of the flow in the network. This information group is applied from the network to the user of the DetNet service. This information group informs the user whether or not the DetNet flow is ready for use.
dnflowStatus：DNFlowStatus情報グループには、ネットワーク内のフローのステータスを指定する要素が含まれています。この情報グループは、ネットワークからDetNetサービスのユーザに適用される。この情報グループは、DetNetフローが使用可能になっているかどうかをユーザーに通知します。
There are three possible operations for each DetNet flow with respect to its DetNet service at a DN Ingress or a DN Egress (similar to App-flows at a source or a destination):
DN入力またはDN出力（ソースまたは宛先でのアプリフローと同様）で、DetNetサービスに関して各DETNETフローに対して3つの可能な操作があります。
Join: DN Ingress/DN Egress intends to join the flow. Leave: DN Ingress/DN Egress intends to leave the flow. Modify: DN Ingress/DN Egress intends to change the flow.
結合：DN入力/ DNの出力はフローに参加するつもりです。去る：DN入力/ DNの出力はフローを残すつもりです。変更：DN入力/ DN出力はフローを変更するつもりです。
For the join operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification are included within the DnIngress or DnEgress information groups. For the join operation, the DnServiceRequirements groups can be included.
結合操作では、DNFlowSpecification、DNFlowRank、DNFlowDpoint、およびDNTrafficSpecificationは、DNINGRESSまたはDNEGRESS情報グループ内に含まれます。結合操作の場合は、DNServiceRequirementsグループを含めることができます。
For the leave operation, the DnFlowSpecification and DnFlowEndpoint are included within the DnIngress or DnEgress information groups.
休暇操作の場合、DNFlowSpecificationとDNFlowEndpointはDningressまたはDNEGressの情報グループ内に含まれています。
For the modify operation, the DnFlowSpecification, DnFlowRank, DnFlowEndpoint, and DnTrafficSpecification are included within the DnIngress or DnEgress information group. For the join operation, the DnServiceRequirements groups can be included.
変更操作では、DNFlowSpecification、DNFlowRank、DnFlowDpoint、およびDNTrafficSpecificationは、DngressまたはDNEGressの情報グループに含まれています。結合操作の場合は、DNServiceRequirementsグループを含めることができます。
The Modify operation can be considered to address cases when a flow is slightly changed, e.g., only MaxPayloadSize (Section 5.5) has been changed. The advantage of having a Modify is that it allows initiation of a change of flow spec while leaving the current flow operating until the change is accepted. If there is no linkage between the Join and the Leave, then while figuring out whether the new flow spec can be supported, the controller entity has to assume that the resources committed to the current flow are in use. By using Modify, the controller entity knows that the resources supporting the current flow can be available for supporting the altered flow. Modify is considered to be an optional operation due to possible controller plane limitations.
変更操作は、フローがわずかに変化した場合の場合には、例えばMaxPayLoadSize（セクション5.5）のみが変更された場合に対処することができます。修正を有する利点は、変化が受け入れられるまで電流の流れを動作させながら流れの変化の変化を開始することを可能にすることである。結合と休暇の間にリンケージがない場合は、新しいフロー仕様をサポートできるかどうかを説明しながら、コントローラエンティティは、現在のフローにコミットされているリソースが使用されていると仮定しなければなりません。変更を使用することによって、コントローラエンティティは、現在のフローをサポートするリソースが変更されたフローをサポートするために利用可能であることを知っている。変更可能なコントローラプレーンの制限によるオプションの操作であると見なされます。
This document describes the DetNet flow information model and the service information model for DetNet IP networks and DetNet MPLS networks. These models are used as input for creating the DetNet-specific YANG module.
この文書では、Detnet IPネットワークとDetnet MPLSネットワークのDetnet Flow情報モデルとサービス情報モデルについて説明します。これらのモデルは、DetNet固有のYANGモジュールを作成するための入力として使用されます。
This document has no IANA actions.
この文書にはIANAの行動がありません。
The external interfaces of the DetNet domain need to be subject to appropriate confidentiality. Additionally, knowledge of which flows/ services are provided to a customer or delivered by a network operator may supply information that can be used in a variety of security attacks. Security considerations for DetNet are described in detail in [DETNET-SECURITY]. General security considerations are described in [RFC8655]. This document discusses modeling the information, not how it is exchanged.
DetNetドメインの外部インタフェースは適切な機密性を受ける必要があります。さらに、どのフロー/サービスが顧客に提供されているか、またはネットワーク事業者によって提供される知識は、さまざまなセキュリティ攻撃で使用できる情報を提供することができる。Detnetのセキュリティ上の考慮事項は[Detnet-Security]で詳しく説明しています。一般的なセキュリティ上の考慮事項は[RFC8655]に記載されています。この文書では、交換される方法ではなく、情報のモデル化について説明します。
[IEEE8021Qcc] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks -- Amendment 31: Stream Reservation Protocol (SRP) Enhancements and Performance Improvements", DOI 10.1109/IEEESTD.2018.8514112, IEEE 802.1Qcc-2018, October 2013, <https://ieeexplore.ieee.org/document/8514112/>.
[IEEE8021QCC] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE規格 - ブリッジとブリッジネットワーク - 修正31：ストリーム予約プロトコル（SRP）の機能強化とパフォーマンスの向上」、DOI 10.1109 / IEEESTD.2018.8514112、IEEE 802.1QCC-2018、2013年10月、<https://ieeexplore.ieee.org/document/8514112/>。
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, <https://www.rfc-editor.org/info/rfc8655>.
[RFC8655] Finn、N.、Thubert、P.、Varga、B.、およびJ. Farkas、「決定論的ネットワーキングアーキテクチャ」、RFC 8655、DOI 10.17487 / RFC8655、2019年10月、<https：//www.rfc-編集者.org / info / rfc8655>。
[RFC8939] Varga, B., Ed., Farkas, J., Berger, L., Fedyk, D., and S. Bryant, "Deterministic Networking (DetNet) Data Plane: IP", RFC 8939, DOI 10.17487/RFC8939, November 2020, <https://www.rfc-editor.org/info/rfc8939>.
[RFC8939]バラジャ、B、ED。、Farkas、J.、Berger、L.、Fedyk、D.、およびS.Bryant、「決定論的ネットワーキング（DECTINAL）データプレーン：IP」、RFC 8939、DOI 10.17487 / RFC8939、2020年11月、<https：//www.rfc-editor.org/info/rfc8939>。
[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、「決定論的ネットワーキング（Detnetisticネットワーキング（Detnet）データプレーン：MPLS」、RFC 8964、DOI 10.17487 / RFC8964、2021年1月、<https://www.rfc-editor.org/info/rfc8964>。
[DETNET-SECURITY] Grossman, E., Mizrahi, T., and A. J. Hacker, "Deterministic Networking (DetNet) Security Considerations", Work in Progress, Internet-Draft, draft-ietf-detnet-security-16, 2 March 2021, <https://tools.ietf.org/html/draft-ietf-detnet-security-16>.
[Detnet-Security] Grossman、E.、Mizrahi、T.、AJ Hacker、「決定論的ネットワーキング（Detnetistic Networking（Detnetic Integracting（Detnetic Inter）セキュリティ上の考慮事項、インターネットドラフト、Draft-IETF-Detnet-Security-16,23 3月2日<https：//tools.ietf.org/html/draft-ietf-detnet-security-16>。
[DETNET-YANG] Geng, X., Chen, M., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) YANG Model", Work in Progress, Internet-Draft, draft-ietf-detnet-yang-11, 19 February 2021, <https://tools.ietf.org/html/draft-ietf-detnet-yang-11>.
[Detnet-Yang] Geng、X.、Chen、M.、Ryoo、Y.、Fedyk、D.、Rahman、R.、およびZ. Li、 "Decectionistic Networking（Detnet）Yang Model"、進行中、インターネット--draft、draft-ietf-detnet-yang-11、<https://tools.ietf.org/html/draft-ietf-detnet-yang-11>。
[IEEE8021Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", DOI 10.1109/IEEESTD.2018.8403927, IEEE 802.1Q-2018, July 2018, <https://ieeexplore.ieee.org/document/8403927>.
[IEEE8021Q] IEEE、「地元の地域と首都圏のネットワークのIEEE規格」、DOI 10.1109 / IEEEESTD.2018.8403927、IEEE 802.1Q-2018、2018年7月、<https：//ieeexplore.ieee.org/document/ 8403927>。
[IEEE8021Qbv] IEEE, "IEEE Standard for Local and metropolitan area networks -- Bridges and Bridged Networks - Amendment 25: Enhancements for Scheduled Traffic", DOI 10.1109/IEEESTD.2016.8613095, IEEE 802.1Qbv-2015, March 2016, <https://ieeexplore.ieee.org/document/8613095>.
[IEEE8021QBV] IEEE、「地元および首都圏ネットワークのIEEE規格 - ブリッジとブリッジネットワーク - 改正25：スケジュールされた交通の強化」、DOI 10.1109 / IEEESTD.2016.8613095、IEEE 802.1QBV-2015、2016年3月、<https：// ieeexplore.ieee.org/document/8613095>。
[IETFDetNet] IETF, "Deterministic Networking (detnet)", <https://datatracker.ietf.org/wg/detnet/charter/>.
[IETFDETNET] IETF、「決定論的ネットワーキング（detnet）」、<https://datatracker.ietf.org/wg/detnet/charter/>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444] PRAS、A.およびJ.Schoenwaelder、「情報モデルとデータモデルの違い」、RFC 3444、DOI 10.17487 / RFC3444、2003年1月、<https：//www.rfc-editor.org/info/RFC3444>。
[RFC8938] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S. Bryant, "Deterministic Networking (DetNet) Data Plane Framework", RFC 8938, DOI 10.17487/RFC8938, November 2020, <https://www.rfc-editor.org/info/rfc8938>.
[RFC8938] Varga、B.、Ed。、Farkas、J.、Berger、L.、Malis、A.、およびS.ブライアント、「決定論的ネットワーキング（DetnetInstring）データプレーンフレームワーク」、RFC 8938、DOI 10.17487 / RFC8938、2020年11月、<https：//www.rfc-editor.org/info/rfc8938>。
Authors' Addresses
著者の住所
Balázs Varga Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary
BalázsVarga Ericsson Budapest Magyar Tudosok Krt。11. 1117ハンガリー
Email: balazs.a.varga@ericsson.com
János Farkas Ericsson Budapest Magyar Tudosok krt. 11. 1117 Hungary
JánosFarkas Ericsson Budapest Magyar Tudosok Krt。11. 1117ハンガリー
Email: janos.farkas@ericsson.com
Rodney Cummings National Instruments Bldg. C 11500 N. Mopac Expwy Austin, TX 78759-3504 United States of America
Rodney Cummings National Instruments Bldg。C 11500 N. MOPAC EXPWYオースティン、TX 78759-3504アメリカ合衆国
Email: rodney.cummings@ni.com
Yuanlong Jiang Huawei Bantian, Longgang district Shenzhen 518129 China
Yuanlong Jiang Huawei Bantian、Longgang District深セン518129中国
Email: jiangyuanlong@huawei.com
Don Fedyk LabN Consulting, L.L.C.
Don Fedyk Labn Consulting、L.L.c。
Email: dfedyk@labn.net