Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 9551 Ericsson
Category: Informational F. Theoleyre
ISSN: 2070-1721 CNRS
G. Papadopoulos
IMT Atlantique
CJ. Bernardos
UC3M
B. Varga
J. Farkas
Ericsson
March 2024
Deterministic Networking (DetNet), as defined in RFC 8655, aims to provide bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. This document's primary purpose is to detail the specific requirements of the Operations, Administration, and Maintenance (OAM) recommended to maintain a deterministic network. The document will be used in future work that defines the applicability of and extension of OAM protocols for a deterministic network. With the implementation of the OAM framework in DetNet, an operator will have a real-time view of the network infrastructure regarding the network's ability to respect the Service Level Objective (SLO), such as packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.
RFC 8655で定義されている決定論的ネットワーキング（DETNET）は、ネットワークインフラストラクチャの上に境界のあるエンドツーエンドのレイテンシを提供することを目的としています。このドキュメントの主な目的は、決定論的ネットワークを維持するために推奨される運用、管理、およびメンテナンスの特定の要件を詳述することです。このドキュメントは、決定論的ネットワークのOAMプロトコルの適用性と拡張を定義する将来の作業で使用されます。DETNETでOAMフレームワークを実装すると、オペレーターは、パケット遅延、遅延変動、パケットロス比など、サービスレベルの目標（SLO）を尊重するネットワークの能力に関するネットワークインフラストラクチャのリアルタイムビューを持ちます。、各デットネットフローに割り当てられます。
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/rfc9551.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9551で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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ライセンステキストを含める必要があります。
1. Introduction
1.1. Definitions
1.2. Requirements Language
2. Role of OAM in DetNet
3. Operation
3.1. Information Collection
3.2. Continuity Check
3.3. Connectivity Verification
3.4. Route Tracing
3.5. Fault Verification/Detection
3.6. Fault Localization and Characterization
3.7. Use of Hybrid OAM in DetNet
4. Administration
4.1. Collection of Metrics
4.2. Worst-Case Metrics
5. Maintenance
5.1. Replication/Elimination
5.2. Resource Reservation
6. Requirements
6.1. For the DetNet Forwarding Sub-layer
6.2. For the DetNet Service Sub-layer
7. IANA Considerations
8. Security Considerations
9. Privacy Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
Deterministic Networking (DetNet) [RFC8655] has proposed to provide a bounded end-to-end latency on top of the network infrastructure, comprising both Layer 2 bridged and Layer 3 routed segments. That work encompasses the data plane, OAM, time synchronization, management, control, and security aspects.
決定論的ネットワーキング（DETNET）[RFC8655]は、ネットワークインフラストラクチャの上に境界のあるエンドツーエンドのレイテンシを提供することを提案しました。その作業には、データプレーン、OAM、時間同期、管理、制御、セキュリティの側面が含まれます。
Operations, Administration, and Maintenance (OAM) tools are of primary importance for IP networks [RFC7276]. DetNet OAM should provide a toolset for fault detection, localization, and performance measurement.
運用、管理、およびメンテナンス（OAM）ツールは、IPネットワーク[RFC7276]にとって最も重要です。DetNet OAMは、障害検出、ローカリゼーション、およびパフォーマンス測定のためのツールセットを提供する必要があります。
This document's primary purpose is to detail the specific requirements of the OAM features recommended to maintain a deterministic/reliable network. Specifically, it investigates the requirements for a deterministic network that supports critical flows.
このドキュメントの主な目的は、決定論的/信頼できるネットワークを維持するために推奨されるOAM機能の特定の要件を詳述することです。具体的には、重要なフローをサポートする決定論的ネットワークの要件を調査します。
In this document, the term "OAM" will be used according to its definition specified in [RFC6291]. DetNet is expected to implement an OAM framework to maintain a real-time view of the network infrastructure, and its ability to respect the Service Level Objectives (SLOs), such as in-order packet delivery, packet delay, delay variation, and packet-loss ratio, assigned to each DetNet flow.
このドキュメントでは、[OAM]という用語は、[RFC6291]で指定された定義に従って使用されます。DETNETは、ネットワークインフラストラクチャのリアルタイムビューを維持するためのOAMフレームワークを実装することが期待されています。また、オーダーパケット配信、パケット遅延、遅延変動、パケットなどのサービスレベルの目標（SLO）を尊重する能力（SLO） - 各デットネットフローに割り当てられた損失率。
This document lists the OAM functional requirements for a DetNet domain. The list can further be used for gap analysis of available OAM tools to identify:
このドキュメントには、DETNETドメインのOAM機能要件がリストされています。このリストは、利用可能なOAMツールのギャップ分析にさらに使用できます。
* possible enhancements of existing tools, or
* 既存のツールの可能な強化、または
* whether new OAM tools are required to support proactive and on-demand path monitoring and service validation.
* プロアクティブおよびオンデマンドパスの監視とサービスの検証をサポートするために、新しいOAMツールが必要かどうか。
This document uses definitions, particularly of a DetNet flow, provided in Section 2.1 of [RFC8655]. The following terms are used throughout this document as defined below:
このドキュメントでは、特に[RFC8655]のセクション2.1に記載されているディットネットフローの定義を使用しています。以下に定義されているように、このドキュメント全体で次の用語が使用されます。
DetNet OAM domain:
Detnet OAMドメイン：
a DetNet network used by the monitored DetNet flow. A DetNet OAM domain (also referred to in this document as "OAM domain") may have Maintenance End Points (MEPs) on its edge and Maintenance Intermediate Points (MIPs) within.
監視対象のディットネットフローで使用されるデットネットネットワーク。DETNET OAMドメイン（このドキュメントでは「OAMドメイン」とも呼ばれます）には、そのエッジとメンテナンス中間点（MIP）にメンテナンスエンドポイント（MEP）があります。
DetNet OAM instance:
DetNet OAMインスタンス：
a function that monitors a DetNet flow for defects and/or measures its performance metrics. Within this document, the shorter version "OAM instance" is used interchangeably.
欠陥のディットネットフローを監視し、そのパフォーマンスメトリックを測定する関数。このドキュメント内では、短いバージョン「OAMインスタンス」が同じ意味で使用されます。
Maintenance End Point (MEP):
メンテナンスエンドポイント（MEP）：
an OAM instance that is capable of generating OAM test packets in the particular sub-layer of the DetNet OAM domain.
Detnet OAMドメインの特定のサブレイヤーでOAMテストパケットを生成できるOAMインスタンス。
Maintenance Intermediate Point (MIP):
メンテナンス中間点（MIP）：
an OAM instance along the DetNet flow in the particular sub-layer of the DetNet OAM domain. An active MIP MUST respond to an OAM message generated by the MEP at its sub-layer of the same DetNet OAM domain.
DETNET OAMドメインの特定のサブレイヤーのデットネットフローに沿ったOAMインスタンス。アクティブなMIPは、同じデットネットOAMドメインのサブレイヤーでMEPによって生成されたOAMメッセージに応答する必要があります。
Control and management plane:
コントロールおよび管理プレーン：
the control and management planes are used to configure and control the network. Relative to a DetNet flow, the control and/or management plane can be out of band.
制御および管理プレーンは、ネットワークの構成と制御に使用されます。ディットネットの流れと比較して、コントロールおよび/または管理プレーンはバンド外にすることができます。
Active measurement methods:
アクティブな測定方法：
(as defined in [RFC7799]) these methods modify a DetNet flow by injecting specially constructed test packets [RFC2544].
（[RFC7799]で定義されているように）これらの方法は、特別に構築されたテストパケット[RFC2544]を注入することにより、デットネットフローを変更します。
Passive measurement methods:
受動的測定方法：
(as defined in [RFC7799]) these methods infer information by observing unmodified existing flows.
（[RFC7799]で定義されているように）これらの方法は、変更されていない既存のフローを観察することにより情報を推測します。
Hybrid measurement methods:
ハイブリッド測定方法：
(as defined in [RFC7799]) the combination of elements of both active and passive measurement methods.
（[rfc7799]で定義されているように）アクティブ測定方法とパッシブ測定方法の両方の要素の組み合わせ。
In-band OAM:
インバンドOAM：
an active OAM method that is in band within the monitored DetNet OAM domain when it traverses the same set of links and interfaces receiving the same QoS and Packet Replication, Elimination, and Ordering Functions (PREOF) treatment as the monitored DetNet flow.
監視対象のデットネットフローと同じQoSとパケットの複製、排除、および順序機能（Preof）処理を受信する同じリンクとインターフェイスのセットを横断するときに、監視対象のDetnet OAMドメイン内のバンドにあるアクティブなOAMメソッド。
Out-of-band OAM:
バンド外のOAM：
an active OAM method whose path through the DetNet domain may not be topologically identical to the path of the monitored DetNet flow, its test packets may receive different QoS and/or PREOF treatment, or both.
Detnetドメインを通るパスが監視されているDetnet Flowの経路とトポロジカルに同一ではないアクティブなOAMメソッド、そのテストパケットは異なるQoSおよび/またはPREOF処理、またはその両方を受け取る場合があります。
On-path telemetry:
オンパステレメトリー：
on-path telemetry can be realized as a hybrid OAM method. The origination of the telemetry information is inherently in band as packets in a DetNet flow are used as triggers. Collection of the on-path telemetry information can be performed using in-band or out-of-band OAM methods.
オンパステレメトリは、ハイブリッドOAMメソッドとして実現できます。テレメトリー情報の発信は、デットネットの流れのパケットがトリガーとして使用されるため、本質的にバンドにあります。オンパステレメトリー情報のコレクションは、帯域または帯域外のOAMメソッドを使用して実行できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The requirements language is used in Sections 1.1 and 6, and applies to the implementations of DetNet OAM.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。要件言語はセクション1.1および6で使用され、Detnet OAMの実装に適用されます。
DetNet networks are expected to provide communications with predictable low packet delay, packet loss, and packet misordering. Most critical applications will define a set of SLOs to be required for the DetNet flows they generate.
Detnet Networksは、予測可能な低パケット遅延、パケット損失、およびパケットの誤用を伴う通信を提供することが期待されています。ほとんどの重要なアプリケーションは、生成するデットフローに必要なスロスのセットを定義します。
To respect strict guarantees, DetNet can use an orchestrator able to monitor and maintain the network. Typically, a Software-Defined Network (SDN) controller places DetNet flows in the deployed network based on their SLOs. Thus, resources have to be provisioned a priori for the regular operation of the network.
厳格な保証を尊重するために、DetNetはネットワークを監視および維持できるオーケストレーターを使用できます。通常、ソフトウェア定義ネットワーク（SDN）コントローラーは、SLOに基づいて展開されたネットワークにデットネットフローを配置します。したがって、ネットワークの定期的な操作のために、リソースに先験的にプロビジョニングする必要があります。
Most of the existing OAM tools can be used in DetNet networks, but they can only cover some aspects of deterministic networking. Fulfilling strict guarantees is essential for DetNet flows, resulting in new DetNet-specific functionalities that must be covered with OAM. Filling these gaps is inevitable and needs accurate consideration of DetNet specifics. Similar to DetNet flows, their OAM also needs careful end-to-end engineering.
既存のOAMツールのほとんどは、Detnet Networksで使用できますが、決定論的ネットワークのいくつかの側面のみをカバーできます。Detnet Flowsには厳格な保証を履行することが不可欠であり、OAMで覆われている必要がある新しいDetnet固有の機能をもたらします。これらのギャップを埋めることは避けられず、Detnetの詳細を正確に考慮する必要があります。Detnet Flowsと同様に、OAMは慎重なエンドツーエンドエンジニアリングも必要です。
For example, appropriate placing of MEPs along the path of a DetNet flow is not always a trivial task and may require proper design together with the design of the service component of a given DetNet flow.
たとえば、Detnet Flowの経路に沿ったMEPを適切に配置することは、必ずしも些細なタスクではなく、特定のDETNETフローのサービスコンポーネントの設計とともに適切な設計が必要になる場合があります。
There are several DetNet-specific challenges for OAM. Bounded network characteristics (e.g., delay, loss) are inseparable service parameters; therefore, Performance Monitoring (PM) OAM is a key topic for DetNet. OAM tools are needed to monitor each SLO without impacting the DetNet flow characteristics. A further challenge is strict resource allocation. Resources used by OAM must be considered and allocated to avoid disturbing DetNet flows.
OAMにはいくつかのDetnet固有の課題があります。制限されたネットワーク特性（例：遅延、損失）は、分離不可能なサービスパラメーターです。したがって、パフォーマンス監視（PM）OAMは、デットネットの重要なトピックです。Detnet Flow特性に影響を与えることなく、各SLOを監視するにはOAMツールが必要です。さらなる課題は、厳格なリソース割り当てです。OAMが使用するリソースは、乱れたデットネットフローを避けるために考慮および割り当てる必要があります。
The DetNet Working Group has defined two sub-layers:
デットネットワーキンググループは、2つのサブレイヤーを定義しました。
The DetNet service sub-layer at which a DetNet service (e.g., service protection) is provided.
Detnet Service Sub-LayerがDetnet Service（サービス保護など）が提供されます。
The DetNet forwarding sub-layer, which optionally provides resource allocation for DetNet flows over paths provided by the underlying network.
デットネット転送サブレイヤー。これは、基礎となるネットワークが提供するパス上のデットネットフローのリソース割り当てをオプションで提供します。
OAM mechanisms exist for the DetNet forwarding sub-layer, but the service sub-layer requires new OAM procedures. These new OAM functions must allow, for example, recognizing/discovering DetNet relay nodes, getting information about their configuration, and checking their operation or status.
Detnet ForwardingサブレイヤーにはOAMメカニズムが存在しますが、サービスサブレイヤーには新しいOAM手順が必要です。これらの新しいOAM関数は、たとえば、デットネットリレーノードの認識/発見、その構成に関する情報の取得、および操作またはステータスの確認を許可する必要があります。
DetNet service sub-layer functions use a sequence number for PREOF, which creates a challenge for inserting OAM packets in the DetNet flow.
DETNETサービスサブレイヤー関数PREOFにシーケンス番号を使用します。これにより、DetNet FlowにOAMパケットを挿入するための課題が生じます。
Fault tolerance also assumes that multiple paths could be provisioned to maintain an end-to-end circuit by adapting to the existing conditions. The DetNet Controller Plane, e.g., central controller/ orchestrator, controls the PREOF on a node. OAM is expected to support monitoring and troubleshooting PREOF on a particular node and within the domain.
また、フォールトトレランスは、既存の条件に適応することにより、エンドツーエンドの回路を維持するために複数のパスをプロビジョニングできることも想定しています。セントラルコントローラー/オーケストレーターなどのデットネットコントローラープレーンは、ノード上のプリオフを制御します。OAMは、特定のノードおよびドメイン内での監視とトラブルシューティングの前提をサポートすることが期待されています。
Note that a distributed architecture of the DetNet Control Plane can also control PREOF in those scenarios where DetNet solutions involve more than one single central controller.
Detnet Control Planeの分散アーキテクチャは、Detnet Solutionsが複数の中央コントローラーを含むシナリオでもPreofを制御できることに注意してください。
The DetNet forwarding sub-layer is based on preexisting technologies and has much better coverage regarding OAM. However, the forwarding sub-layer is terminated at DetNet relay nodes, so the end-to-end OAM state of forwarding may be created only based on the status of multiple forwarding sub-layer segments serving a given DetNet flow (e.g., in case of DetNet MPLS, there may be no end-to-end LSP below the DetNet pseudowire).
ディットネット転送サブレイヤーは、既存のテクノロジーに基づいており、OAMに関してはるかに優れたカバレッジを持っています。ただし、転送サブレイヤーはDetnet Relayノードで終了するため、エンドツーエンドのOAM転送状態は、特定のデットネットフローを提供する複数の転送サブレイヤーセグメントのステータスに基づいてのみ作成できます（たとえば、たとえば、Detnet MPLSのうち、Detnet Pseudowireの下にエンドツーエンドのLSPがない場合があります）。
OAM features will enable DetNet with robust operation both for forwarding and routing purposes.
OAM機能により、転送とルーティングの両方で堅牢な操作を備えたデットネットが可能になります。
It is worth noting that the test and data packets are expected to follow the same path, i.e., connectivity verification has to be conducted in band without impacting data traffic. It is expected that test packets share fate with the monitored data traffic without introducing congestion in normal network conditions.
テストとデータパケットが同じパスをたどることが期待されることは注目に値します。つまり、データトラフィックに影響を与えることなく、バンドで接続の検証を実施する必要があります。テストパケットは、通常のネットワーク条件で混雑を導入することなく、監視されたデータトラフィックと運命を共有することが期待されています。
Information about the state of the network can be collected using several mechanisms. Some protocols, e.g., the Simple Network Management Protocol (SNMP), poll for updated data. Other protocols, such as YANG-Push [RFC8641], can be used to set up subscriptions for the data defined in the YANG data models to be published periodically or when the underlying data changes. Either way, information is collected and sent using the DetNet Controller Plane.
ネットワークの状態に関する情報は、いくつかのメカニズムを使用して収集できます。いくつかのプロトコル、たとえば、単純なネットワーク管理プロトコル（SNMP）、更新されたデータの投票。Yang-Push [RFC8641]などの他のプロトコルを使用して、定期的に公開されるYangデータモデルで定義されたデータのサブスクリプションをセットアップすることができます。いずれにせよ、情報が収集され、デットネットコントローラープレーンを使用して送信されます。
Also, we can characterize methods of transporting OAM information relative to the path of data. For instance, OAM information may be transported in band or out of band relative to the DetNet flow. In the case of the former, the telemetry information uses resources allocated for the monitored DetNet flow. If an in-band method of transporting telemetry is used, the amount of generated information needs to be carefully analyzed, and additional resources must be reserved. [RFC9197] defines the in-band transport mechanism where telemetry information is collected in the data packet on which information is generated. Two tracing methods are described:
また、データのパスに対するOAM情報を輸送する方法を特徴付けることができます。たとえば、OAM情報は、ディットネットの流れに比べて、バンドまたはバンド外で輸送される場合があります。前者の場合、テレメトリー情報は、監視対象のディットネットフローに割り当てられたリソースを使用します。テレメトリーの輸送方法を使用する場合、生成された情報の量を慎重に分析する必要があり、追加のリソースを予約する必要があります。[RFC9197]は、情報が生成されるデータパケットでテレメトリ情報が収集されるバンド輸送メカニズムを定義します。2つのトレース方法について説明します。
* end-to-end, i.e., from the ingress and egress nodes, and
* エンドツーエンド、すなわち、イングレスと出口ノードから、そして
* hop-by-hop, i.e., like end-to-end with additional information from transit nodes.
* ホップバイホップ、つまり、トランジットノードからの追加情報を備えたエンドツーエンドのように。
[RFC9326] and [HYBRID-TWO-STEP] are examples of out-of-band telemetry transport. In the former case, information is transported by each node traversed by the data packet of the monitored DetNet flow in a specially constructed packet. In the latter, information is collected in a sequence of follow-up packets that traverse the same path as the data packet of the monitored DetNet flow. In both methods, transport of the telemetry can avoid using resources allocated for the DetNet domain.
[RFC9326]および[Hybrid-Two-Step]は、帯域外のテレメトリー輸送の例です。前者の場合、情報は、特別に構築されたパケットで監視されているデットネットフローのデータパケットによって移動された各ノードによって輸送されます。後者では、情報は、監視されているディットネットフローのデータパケットと同じパスを横断する一連のフォローアップパケットで収集されます。どちらの方法でも、テレメトリの輸送は、デットネットドメインに割り当てられたリソースの使用を避けることができます。
A continuity check is used to monitor the continuity of a path, i.e., that there exists a way to deliver packets between MEP A and MEP B. The continuity check detects a network failure in one direction: from the MEP transmitting test packets to the remote egress MEP. The continuity check in a DetNet OAM domain monitors the DetNet forwarding sub-layer; thus, it is not affected by a PREOF that operates at the DetNet service sub-layer ([RFC8655]).
連続性チェックは、パスの連続性、つまりMEP AとMEP Bの間にパケットを配信する方法が存在することを監視するために使用されます。連続性チェックは、一方向のネットワーク障害を検出します。出力MEP。Detnet OAMドメインの連続性チェックは、Detnet Forwardingサブレイヤーを監視します。したがって、Detnet Service Sub-Layer（[RFC8655]）で動作するPREOFの影響を受けません。
In addition to the Continuity Check, DetNet solutions have to verify connectivity. This verification considers an additional constraint: the absence of misconnection. The misconnection error state is entered after several consecutive test packets from other DetNet flows are received. The definition of the conditions for entry and exit of a misconnection error state is outside the scope of this document. Connectivity verification in a DetNet OAM domain monitors the DetNet forwarding sub-layer; thus, it is not affected by PREOF that operates at the DetNet service sub-layer ([RFC8655]).
連続性チェックに加えて、DetNet Solutionsは接続を検証する必要があります。この検証は、追加の制約、つまり誤解がないことを考慮しています。誤接続エラー状態は、他のDetnetフローからいくつかの連続したテストパケットを受信した後に入力されます。誤接続エラー状態のエントリと出口の条件の定義は、このドキュメントの範囲外です。Detnet OAMドメインの接続検証は、Detnet Forwardingサブレイヤーを監視します。したがって、Detnet Serviceサブレイヤー（[RFC8655]）で動作するのはPREOFの影響を受けません。
Ping and traceroute are two ubiquitous tools that help localize and characterize a failure in the network using an echo request/reply mechanism. They help to identify a subset of the routers in the path. However, to be predictable, resources are reserved per flow in DetNet. Thus, DetNet needs to define route tracing tools able to trace the route for a specific flow. Also, tracing can be used for the discovery of the Path Maximum Transmission Unit (PMTU) or location of elements of PREOF for the particular route in the DetNet domain.
PingとTracerouteは、エコーリクエスト/返信メカニズムを使用してネットワークの障害をローカライズおよび特徴付けるのに役立つ2つのユビキタスツールです。それらは、パス内のルーターのサブセットを識別するのに役立ちます。ただし、予測可能になるために、リソースはデットネットのフローごとに予約されています。したがって、DETNETは、特定のフローのルートをトレースできるルートトレースツールを定義する必要があります。また、トレースは、パス最大透過ユニット（PMTU）の発見または、DETNETドメインの特定のルートのPREOF要素の場所の発見に使用できます。
DetNet is not expected to use Equal-Cost Multipath (ECMP) [RFC8939]. As a result, DetNet OAM in an ECMP environment is outside the scope of this document.
DetNetは、等しいコストマルチパス（ECMP）[RFC8939]を使用することは期待されていません。その結果、ECMP環境のDETNET OAMは、このドキュメントの範囲外です。
DetNet expects to operate fault-tolerant networks. Thus, mechanisms able to detect faults before they impact network performance are needed.
DetNetは、フォールトトレラントネットワークの運用を期待しています。したがって、ネットワークパフォーマンスに影響を与える前に障害を検出できるメカニズムが必要です。
The network has to detect when a fault has occurred, i.e., the network has deviated from its expected behavior. Fault detection can be based on proactive OAM protocols like continuity check or on-demand methods like ping. While the network must report an alarm, the cause may not be identified precisely. Examples of such alarms are significant degradation of the end-to-end reliability or when a buffer overflow occurs.
ネットワークは、障害がいつ発生したかを検出する必要があります。つまり、ネットワークは予想される動作から逸脱しています。障害検出は、連続性チェックなどのプロアクティブなOAMプロトコルまたはPingなどのオンデマンド方法に基づいています。ネットワークはアラームを報告する必要がありますが、原因は正確に特定されない場合があります。このようなアラームの例は、エンドツーエンドの信頼性の有意な分解またはバッファオーバーフローが発生したときです。
The ability to localize a network defect and provide its characterization are necessary elements of network operation.
ネットワークの欠陥をローカライズし、その特性評価を提供する機能は、ネットワーク操作の必要な要素です。
Fault localization:
障害のローカリゼーション：
a process of deducing the location of a network failure from a set of observed failure indications. For example, this might be achieved by tracing the route of the DetNet flow in which the network failure was detected. Another method of fault localization can correlate reports of failures from a set of interleaved sessions monitoring path continuity.
観測された障害指示のセットからネットワーク障害の位置を推測するプロセス。たとえば、これは、ネットワーク障害が検出されたデットネットフローのルートをトレースすることで達成される場合があります。障害のローカリゼーションの別の方法は、障害の報告を、一連のインターリーブセッションの監視パスの連続性から相関させることができます。
Fault characterization:
障害の特性評価：
a process of identifying the root cause of the problem. For instance, misconfiguration or malfunction of PREOF elements can be the cause of erroneous packet replication or extra packets being flooded in the DetNet domain.
問題の根本原因を特定するプロセス。たとえば、PREOF要素の誤った構成または誤動作は、誤ったパケットレプリケーションまたはDetnetドメインに浸水している追加パケットの原因となる可能性があります。
Hybrid OAM methods are used in performance monitoring and defined in [RFC7799] as follows:
ハイブリッドOAMメソッドは、パフォーマンス監視で使用され、次のように[RFC7799]で定義されています。
Hybrid Methods are Methods of Measurement that use a combination of Active Methods and Passive Methods.
ハイブリッド方法は、アクティブな方法と受動的方法の組み合わせを使用する測定方法です。
A hybrid measurement method can produce metrics as close to measured using a passive measurement method. The passive methods measure metrics closest to the network's actual conditions. A hybrid method, even if it alters something in a data packet, even if that is as little as the value of a designated field in the packet encapsulation, is considered an approximation of a passive measurement method. One example of such a hybrid measurement method is the Alternate-Marking Method (AMM) described in [RFC9341]. As with all on-path telemetry methods, AMM in a DetNet domain with the IP data plane is, by design, in band with respect to the monitored DetNet flow. Because the marking is applied to a data flow, measured metrics are directly applicable to the DetNet flow. AMM minimizes the additional load on the DetNet domain by using nodal collection and computation of performance metrics optionally in combination with using out-of-band telemetry collection for further network analysis.
ハイブリッド測定方法は、パッシブ測定方法を使用して測定に近いメトリックを生成できます。パッシブ方法は、ネットワークの実際の条件に最も近いメトリックを測定します。ハイブリッドメソッドは、たとえそれがデータパケットで何かを変更しても、パケットカプセル化の指定されたフィールドの値と同じくらい少なかったとしても、パッシブ測定方法の近似と見なされます。このようなハイブリッド測定方法の1つの例は、[RFC9341]で説明されている代替マーク法（AMM）です。すべてのオンパステレメトリメソッドと同様に、IPデータプレーンを備えたDetnetドメインのAMMは、設計上、監視対象のディットネットフローに関してバンドです。マーキングはデータフローに適用されるため、測定されたメトリックはデットネットフローに直接適用できます。AMMは、ノーダルコレクションとパフォーマンスメトリックの計算をオプションで使用して、帯域外のテレメトリーコレクションを使用してさらなるネットワーク分析を使用することにより、DETNETドメインの追加負荷を最小限に抑えます。
The ability to expose a collection of metrics to support an operator's decision-making is essential. The following performance metrics are useful:
オペレーターの意思決定をサポートするためにメトリックのコレクションを公開する能力が不可欠です。次のパフォーマンスメトリックは有用です：
Queuing Delay:
キューイングの遅延：
the time elapsed between enqueuing a packet and its transmission to the next hop.
パケットをエンキューするまでの間、次のホップへの送信の間に経過しました。
Buffer occupancy:
バッファー占有率：
the number of packets present in the buffer for each of the existing flows.
既存のフローごとにバッファーに存在するパケットの数。
Per DetNet flow:
デットネットのフローごと：
a metric reflecting end-to-end performance for a given flow. Each of the paths has to be isolated in a multipath routing environment.
特定のフローのエンドツーエンドパフォーマンスを反映するメトリック。各パスは、マルチパスルーティング環境で分離する必要があります。
Per-path:
パスごと：
detection of a misbehaving path or paths when multiple paths are used for the service protection.
サービス保護に複数のパスが使用されている場合の誤動作パスまたはパスの検出。
Per-device:
デバイスごと：
detection of a misbehaving device.
不正行為デバイスの検出。
It is important to optimize the volume and frequency of statistics/ measurement collection, whether the mechanisms are distributed, centralized, or both. Periodic and event-triggered collection information characterizing the state of a network is an example of mechanisms to achieve the optimization.
メカニズムが分布、集中化されている、またはその両方であろうと、統計/測定収集の量と頻度を最適化することが重要です。ネットワークの状態を特徴付ける周期的およびイベントトリガーされたコレクション情報は、最適化を実現するメカニズムの例です。
DetNet aims to enable real-time communications on top of a heterogeneous multi-hop architecture. To make correct decisions, the DetNet Controller Plane [RFC8655] needs timely information about packet losses/delays for each flow and each hop of the paths. In other words, just the average end-to-end statistics are not enough. The collected information must be sufficient to allow a system to predict the worst-case scenario.
DetNetは、異種のマルチホップアーキテクチャに加えて、リアルタイム通信を有効にすることを目指しています。正しい決定を下すには、Detnet Controller Plane [RFC8655]には、各フローとパスの各ホップのパケット損失/遅延に関するタイムリーな情報が必要です。言い換えれば、平均エンドツーエンドの統計では十分ではありません。収集された情報は、システムが最悪のシナリオを予測できるようにするのに十分でなければなりません。
Service protection (provided by the DetNet Service sub-layer) is designed to mitigate simple network failures more rapidly than the expected response time of the DetNet Controller Plane. In the face of events that impact network operation (e.g., link up/down, device crash/reboot, flows starting and ending), the DetNet Controller Plane needs to perform repair and reoptimization actions in order to permanently ensure SLOs of all active flows with minimal waste of resources. The Controller Plane is expected to be able to continuously retrieve the state of the network, to evaluate conditions and trends about the relevance of a reconfiguration, quantifying the following:
サービス保護（Detnet Service Sub-Layerが提供）は、Detnetコントローラープレーンの予想される応答時間よりも迅速に単純なネットワーク障害を軽減するように設計されています。ネットワーク操作に影響を与えるイベント（例：リンクアップ/ダウン、デバイスのクラッシュ/再起動、フローの開始と終了）に直面して、Detnet Controller Planeは、すべてのアクティブフローのSLOSを永久に確保するために修理および再最適化アクションを実行する必要があります。リソースの最小限の無駄。コントローラープレーンは、ネットワークの状態を継続的に取得し、再構成の関連性に関する条件と傾向を評価し、次のものを定量化できることが期待されています。
the cost of the suboptimality:
亜最適性のコスト：
resources may not be used optimally (i.e., a better path exists).
リソースを最適に使用することはできません（つまり、より良いパスが存在します）。
the reconfiguration cost:
再構成コスト：
the DetNet Controller Plane needs an ability to trigger some reconfigurations. For this transient period, resources may be twice reserved, and control packets have to be transmitted.
Detnet Controller Planeには、再構成をトリガーする機能が必要です。この一時的な期間の場合、リソースは2回予約され、制御パケットを送信する必要があります。
Thus, reconfiguration may only be triggered if the gain is significant.
したがって、ゲインが重要な場合にのみ、再構成がトリガーされる場合があります。
When multiple paths are reserved between two MEPs, packet replication may be used to introduce redundancy and alleviate transmission errors and collisions. For instance, in Figure 1, the source device S transmits a packet to devices A and B to reach the destination node R.
複数のパスが2つのMEPの間に予約されている場合、パケットレプリケーションを使用して冗長性を導入し、送信エラーと衝突を軽減できます。たとえば、図1では、ソースデバイスがパケットをデバイスAとBに送信して、宛先ノードRに到達します。
===> (A) => (C) => (E) ===
// \\// \\// \\
source (S) //\\ //\\ (R) (root)
\\ // \\ // \\ //
===> (B) => (D) => (F) ===
Figure 1: Packet Replication and Elimination Functions
図1：パケットの複製と排除関数
Because the quality of service associated with a path may degrade, the network has to provision additional resources along the path.
パスに関連付けられているサービスの品質は低下する可能性があるため、ネットワークはパスに沿って追加のリソースを提供する必要があります。
According to [RFC8655], DetNet functionality is divided into forwarding and service sub-layers. The DetNet forwarding sub-layer includes DetNet transit nodes and may allocate resources for a DetNet flow over paths provided by the underlay network. The DetNet service sub-layer includes DetNet relay nodes and provides a DetNet service (e.g., service protection). This section lists general requirements for DetNet OAM as well as requirements in each of the DetNet sub-layers of a DetNet domain.
[RFC8655]によると、DetNet機能は転送およびサービスサブレイヤーに分割されています。Detnet Forwardingサブレイヤーには、DETNETトランジットノードが含まれており、アンダーレイネットワークが提供するパス上のデットネットフローのリソースを割り当てる場合があります。Detnet Serviceサブレイヤーには、Detnet Relayノードが含まれており、Detnet Service（サービス保護など）を提供します。このセクションには、DetNet OAMの一般的な要件と、Detnet Domainの各Detnetサブレイヤーの要件をリストします。
1. It MUST be possible to initiate a DetNet OAM session from a MEP located at a DetNet node towards a MEP or MEPs downstream from that DetNet node within the given domain at a particular DetNet sub-layer.
1. 特定のDETNETサブレイヤーの特定のドメイン内のそのデットネットノードからDETNETノードまたはMEPの下流にあるMEPまたはMEPに向けて、MEPからMEPからDetNet OAMセッションを開始することが可能である必要があります。
2. It MUST be possible to initiate a DetNet OAM session using any of the DetNet Controller Plane solutions, e.g., a centralized controller.
2. Detnet Controller Plane Solutions、例えば中央コントローラーを使用して、Detnet OAMセッションを開始することができなければなりません。
3. DetNet OAM MUST support proactive OAM monitoring and measurement methods.
3. DetNet OAMは、プロアクティブなOAM監視および測定方法をサポートする必要があります。
4. DetNet OAM MUST support on-demand OAM monitoring and measurement methods.
4. DetNet OAMは、オンデマンドOAMの監視および測定方法をサポートする必要があります。
5. DetNet OAM MUST support unidirectional OAM methods, continuity checks, connectivity verification, and performance measurements.
5. DETNET OAMは、一方向のOAMメソッド、連続性チェック、接続性の確認、およびパフォーマンス測定をサポートする必要があります。
6. DetNet OAM MUST support bidirectional DetNet flows, but it is not required to support bidirectional OAM methods for bidirectional DetNet flows. DetNet OAM test packets used for monitoring and measurements of a bidirectional DetNet flow MUST be in band in both directions.
6. DetNet OAMは双方向のディットネットフローをサポートする必要がありますが、双方向DETNETフローの双方向OAMメソッドをサポートする必要はありません。監視に使用されるDETNET OAMテストパケットは、双方向のディットネットの流れの測定と測定値が両方向にバンドにある必要があります。
7. DetNet OAM MUST support proactive monitoring of a DetNet device's reachability for a given DetNet flow.
7. DETNET OAMは、特定のデットネットフローに対するDETNETデバイスの到達可能性の積極的な監視をサポートする必要があります。
8. DetNet OAM MUST support hybrid performance measurement methods.
8. DETNET OAMは、ハイブリッドパフォーマンス測定方法をサポートする必要があります。
9. Calculated performance metrics MUST include, but are not limited to, throughput, packet-loss, out-of-order, delay, and delay-variation metrics. [RFC6374] provides detailed information on performance measurement and performance metrics.
9. 計算されたパフォーマンスメトリックは、スループット、パケットロス、オーダーアウトオブオブ、遅延、および遅延変動メトリックを含める必要がありますが、これらに限定されません。[RFC6374]は、パフォーマンスの測定とパフォーマンスメトリックに関する詳細情報を提供します。
DetNet OAM MUST support:
Detnet OAMはサポートする必要があります。
1. PMTU discovery.
1. PMTUディスカバリー。
2. Remote Defect Indication (RDI) notification to the DetNet OAM instance performing continuity checking.
2. 継続性チェックを実行するDetnet OAMインスタンスへのリモート欠陥表示（RDI）通知。
3. the monitoring of levels of resources allocated for a particular DetNet flow. Such resources include, but are not limited to, buffer utilization and scheduler transmission calendar.
3. 特定のディットネットフローに割り当てられたリソースのレベルの監視。このようなリソースには、バッファ使用率とスケジューラ送信カレンダーが含まれますが、これらに限定されません。
4. the monitoring of any subset of paths traversed through the DetNet domain by a DetNet flow.
4. パスのサブセットの監視は、デットネットフローによってデットネットドメインを通過しました。
The OAM functions for the DetNet service sub-layer allow, for example, the recognizing/discovery of DetNet relay nodes, the gathering of information about their configuration, and the checking of their operation or status.
Detnet ServiceサブレイヤーのOAM機能により、たとえば、Detnet Relayノードの認識/発見、構成に関する情報の収集、および操作またはステータスのチェックが許可されます。
The requirements on OAM for a DetNet relay node are that DetNet OAM MUST:
Detnet RelayノードのOAMの要件は、Detnet OAMが必要なことです。
1. provide OAM functions for the DetNet service sub-layer.
1. Detnet ServiceサブレイヤーにOAM関数を提供します。
2. support the discovery of DetNet relay nodes in a DetNet network.
2. Detnet NetworkでのDetnet Relayノードの発見をサポートします。
3. support the discovery of PREOF locations in the domain.
3. ドメイン内のPreofロケーションの発見をサポートします。
4. support the collection of information specific to the DetNet service sub-layer (configuration/operation/status) from DetNet relay nodes.
4. Detnet RelayノードからDetNet Serviceサブレイヤー（構成/操作/ステータス）に固有の情報の収集をサポートします。
5. support exercising functionality of PREOF in the domain.
5. ドメイン内のPREOFの運動機能をサポートします。
6. work for DetNet data planes: MPLS and IP.
6. DETNETデータプレーンの作業：MPLSおよびIP。
7. support a defect notification mechanism, like Alarm Indication Signal. Any DetNet relay node providing service for a given DetNet flow MAY originate a defect notification addressed to any subset of DetNet relay nodes along that flow.
7. アラーム表示信号などの欠陥通知メカニズムをサポートします。特定のDETNETフローにサービスを提供するDETNETリレーノードは、そのフローに沿ってDetnet Relayノードのサブセットに宛てられた欠陥通知を発生する場合があります。
8. be able to measure metrics (e.g. delay) inside a collection of OAM sessions, specially for complex DetNet flows, with PREOF features.
8. OAMセッションのコレクション内のメトリック（遅延など）を測定することができます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document lists the OAM requirements for a DetNet domain and does not raise any security concerns or issues in addition to ones common to networking and those specific to DetNet that are discussed in Section 9 of [RFC9055]. Furthermore, the analysis of OAM security concerns in Section 6 of [RFC7276] also applies to DetNet OAM, including the use of OAM for network reconnaissance.
このドキュメントには、DETNETドメインのOAM要件がリストされており、ネットワークに共通するものと[RFC9055]セクション9で説明されているDetNetに特有のセキュリティの懸念や問題を提起しません。さらに、[RFC7276]のセクション6におけるOAMセキュリティの懸念の分析は、ネットワーク偵察へのOAMの使用を含むDetNet OAMにも適用されます。
Privacy considerations of DetNet discussed in Section 13 of [RFC9055] are also applicable to DetNet OAM. If any privacy mechanism is used for the monitored DetNet flow, then the same privacy method MUST be applied to the active DetNet OAM used to monitor the flow.
[RFC9055]のセクション13で議論されているDetNetのプライバシーに関する考慮事項も、DetNet OAMに適用できます。監視対象のディットネットフローにプライバシーメカニズムが使用されている場合、フローの監視に使用されるアクティブなDETNET OAMに同じプライバシー方法を適用する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
[HYBRID-TWO-STEP]
Mirsky, G., Lingqiang, W., Zhui, G., Song, H., and P.
Thubert, "Hybrid Two-Step Performance Measurement Method",
Work in Progress, Internet-Draft, draft-ietf-ippm-hybrid-
two-step-00, 4 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
hybrid-two-step-00>.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544,
DOI 10.17487/RFC2544, March 1999,
<https://www.rfc-editor.org/info/rfc2544>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011,
<https://www.rfc-editor.org/info/rfc6291>.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/info/rfc8641>.
[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>.
[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>.
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
Ed., "Data Fields for In Situ Operations, Administration,
and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
and T. Zhou, "Alternate-Marking Method", RFC 9341,
DOI 10.17487/RFC9341, December 2022,
<https://www.rfc-editor.org/info/rfc9341>.
The authors express their appreciation and gratitude to Pascal Thubert for the review, insightful questions, and helpful comments.
著者は、レビュー、洞察に満ちた質問、そして有益なコメントについて、パスカル・ザールバートに感謝と感謝を表明します。
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Fabrice Theoleyre
CNRS
ICube Lab, Pole API
300 boulevard Sebastien Brant - CS 10413
67400 Illkirch - Strasbourg
France
Phone: +33 368 85 45 33
Email: fabrice.theoleyre@cnrs.fr
URI: https://fabrice.theoleyre.cnrs.fr/
Georgios Papadopoulos
IMT Atlantique
Office B00 - 102A
2 Rue de la Châtaigneraie
35510 Cesson-Sévigné - Rennes
France
Phone: +33 299 12 70 04
Email: georgios.papadopoulos@imt-atlantique.fr
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Balazs Varga
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: balazs.a.varga@ericsson.com
Janos Farkas
Ericsson
Budapest
Magyar Tudosok krt. 11.
1117
Hungary
Email: janos.farkas@ericsson.com