Internet Engineering Task Force (IETF) G. Mirsky
Request for Comments: 9634 Ericsson
Category: Informational M. Chen
ISSN: 2070-1721 Huawei
D. Black
Dell EMC
October 2024
This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane.
このドキュメントでは、IPデータプレーンを使用する決定論的ネットワークネットワークにおける既存のIP操作、管理、およびメンテナンスプロトコルの使用とメカニズムについて説明します。
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/rfc9634.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9634で取得できます。
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
2. Conventions Used in This Document
2.1. Terminology
3. Active OAM for DetNet Networks with the IP Data Plane
3.1. Mapping Active OAM and IP DetNet Flows
3.2. Active OAM Using IP-in-UDP Encapsulation
3.3. Active OAM Using DetNet-in-UDP Encapsulation
3.4. The Application of Y.1731/G.8013 Using GRE-in-UDP
Encapsulation
4. Active OAM for DetNet IP Interworking with OAM for Non-IP
DetNet Domains
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Authors' Addresses
[RFC8655] introduces and explains the Deterministic Networking (DetNet) architecture.
[RFC8655]は、決定論的ネットワーク（DETNET）アーキテクチャを導入して説明します。
Operations, Administration, and Maintenance (OAM) protocols are used to detect and localize defects in the network as well as to monitor network performance. Some OAM functions (e.g., failure detection) work in the network proactively, while others (e.g., defect localization) are usually performed on demand. These tasks are achieved by a combination of active and hybrid OAM methods, as defined in [RFC7799].
操作、管理、およびメンテナンス（OAM）プロトコルは、ネットワークの欠陥を検出およびローカライズし、ネットワークのパフォーマンスを監視するために使用されます。一部のOAM関数（障害検出など）は、ネットワークで積極的に機能しますが、通常はオンデマンドで実行されます。これらのタスクは、[RFC7799]で定義されているように、アクティブOAMメソッドとハイブリッドOAMメソッドの組み合わせによって達成されます。
[RFC9551] lists the OAM functional requirements for DetNet and defines the principles for OAM use within DetNet networks utilizing the IP data plane. The functional requirements can be compared against current OAM tools to identify gaps and potential enhancements required to enable proactive and on-demand path monitoring and service validation.
[RFC9551]は、DETNETのOAM機能要件をリストし、IPデータプレーンを利用してDetnetネットワーク内でOAM使用の原則を定義します。機能要件は、現在のOAMツールと比較して、プロアクティブでオンデマンドのパス監視とサービス検証を可能にするために必要なギャップと潜在的な強化を特定できます。
This document discusses the use of existing IP OAM protocols and mechanisms in DetNet networks that use the IP data plane.
このドキュメントでは、IPデータプレーンを使用するデットネットネットワークでの既存のIP OAMプロトコルとメカニズムの使用について説明します。
The term "DetNet OAM" as used in this document means "a set of OAM protocols, methods, and tools for Deterministic Networking".
このドキュメントで使用されている「Detnet OAM」という用語は、「決定論的ネットワークのためのOAMプロトコル、方法、およびツールのセット」を意味します。
DetNet:
detnet：
Deterministic Networking
決定論的ネットワーキング
OAM:
OAM:
Operations, Administration, and Maintenance
運用、管理、およびメンテナンス
ICMP:
ICMP：
Internet Control Message Protocol
インターネット制御メッセージプロトコル
Underlay Network or Underlay Layer:
アンダーレイネットワークまたはアンダーレイレイヤー：
The network that provides connectivity between DetNet nodes. MPLS networks providing Label Switched Path (LSP) connectivity between DetNet nodes are an example of the DetNet IP network underlay layer.
デットネットノード間の接続を提供するネットワーク。DETNETノード間のラベルスイッチ付きパス（LSP）接続を提供するMPLSネットワークは、Detnet IP Network Underlayレイヤーの例です。
DetNet Node:
Detnetノード：
A node that is an actor in the DetNet domain. DetNet domain edge nodes and nodes that perform the Packet Replication, Elimination, and Ordering Functions within the domain are examples of a DetNet node.
Detnetドメインのアクターであるノード。ドメイン内のパケットレプリケーション、排除、および順序付け関数を実行するDETNETドメインエッジノードとノードは、デットネットノードの例です。
OAM protocols and mechanisms act within the data plane of the particular networking layer. Thus, it is critical that the data plane encapsulation support OAM mechanisms and enable them to be configured so that DetNet OAM packets follow the same path (unidirectional or bidirectional) through the network and receive the same forwarding treatment in the DetNet forwarding sub-layer as the DetNet flow being monitored.
OAMプロトコルとメカニズムは、特定のネットワークレイヤーのデータプレーン内で機能します。したがって、データプレーンのカプセル化がOAMメカニズムをサポートし、それらを構成できるようにすることが重要です。監視されているディットネットのフロー。
The DetNet data plane encapsulation in a transport network with IP encapsulations is specified in Section 6 of [RFC8939]. For the IP underlay network, DetNet flows are identified by the ordered match to the provisioned information set that, among other elements, includes the IP protocol type, source port number, and destination port number. Active IP OAM protocols like Bidirectional Forwarding Detection (BFD) [RFC5880] or the Simple Two-way Active Measurement Protocol (STAMP) [RFC8762] use UDP transport and the well-known UDP port numbers as the respective destination ports. For BFD, the UDP destination port is specific to the BFD variant, e.g., multihop BFD uses port 4784 [RFC5883].
[RFC8939]のセクション6では、IPカプセルを備えた輸送ネットワークでのDETNETデータプレーンのカプセル化を指定しています。IP Underlayネットワークの場合、DETNETフローは、IPプロトコルタイプ、ソースポート番号、および宛先ポート番号を含む要素の中でも、プロビジョニングされた情報セットへの順序付けられた一致によって識別されます。双方向転送検出（BFD）[RFC5880]または単純な双方向アクティブ測定プロトコル（スタンプ）[RFC8762]などのアクティブなIP OAMプロトコルは、UDPトランスポートとよく知られているUDPポート番号をそれぞれの宛先ポートとして使用します。BFDの場合、UDP宛先ポートはBFDバリアントに固有のものです。たとえば、MultiHop BFDはポート4784 [RFC5883]を使用します。
Thus, a DetNet node must be able to associate an IP DetNet flow with the particular test session to ensure that test packets experience the same treatment as the DetNet flow packets. For example, in a network where path selection and DetNet functionality are based on 3-tuples (destination and source IP addresses in combination with the Differentiated Services Code Point value), that association can be achieved by having the OAM traffic use the same 3-tuple as the monitored IP DetNet flow. In such a scenario, an IP OAM session between the same pair of IP nodes would share the network treatment with the monitored IP DetNet flow regardless of whether ICMP, BFD, or STAMP is used.
したがって、デットネットノードは、テストパケットがデットネットフローパケットと同じトリートメントを経験するように、IP Detnetフローを特定のテストセッションに関連付けることができる必要があります。たとえば、パスの選択とデットネットの機能が3タプル（差別化されたサービスコードポイント値と組み合わせた宛先およびソースIPアドレス）に基づいているネットワークでは、OAMトラフィックに同じ3-を使用することでその関連を達成できます。監視対象のIPデットネットフローとしてのタプル。このようなシナリオでは、同じペアのIPノード間のIP OAMセッションは、ICMP、BFD、またはスタンプが使用されているかどうかに関係なく、監視されたIPデットネットフローとネットワーク処理を共有します。
In IP networks, the majority of on-demand failure detection and localization is achieved through the use of ICMP, utilizing Echo Request and Echo Reply messages, along with a set of defined error messages such as Destination Unreachable, which provide detailed information through assigned code points. [RFC0792] and [RFC4443] define ICMP for IPv4 and IPv6 networks, respectively. To utilize ICMP effectively for these purposes within DetNet, DetNet nodes must establish the association of ICMP traffic between DetNet nodes with IP DetNet traffic. This entails ensuring that such ICMP traffic traverses the same interfaces and receives QoS treatment that is identical to the monitored DetNet IP flow. Failure to do so may result in ICMP being unable to detect and localize failures specific to the DetNet IP data plane.
IPネットワークでは、ECHOリクエストとエコー応答メッセージを使用して、ICMPの使用を通じてオンデマンドの障害検出とローカリゼーションの大部分が達成され、宛先の到達可能なエラーメッセージのセットがあります。ポイント。[RFC0792]および[RFC4443]は、それぞれIPv4およびIPv6ネットワークのICMPを定義します。DetNet内でこれらの目的のためにICMPを効果的に利用するには、DETNETノードは、DETNETノード間のIP DETNETトラフィック間のICMPトラフィックの関連を確立する必要があります。これには、このようなICMPトラフィックが同じインターフェイスを通過し、監視されているDetnet IPフローと同一のQoS処理を受けることを保証することを伴います。そうしないと、ICMPがDetnet IPデータプレーンに固有の障害を検出およびローカライズすることができなくなる可能性があります。
IP OAM protocols are used to detect failures (e.g., BFD [RFC5880]) and performance degradation (e.g., STAMP [RFC8762]) that affect an IP DetNet flow. For active OAM to be useful, it is essential to ensure that specially constructed OAM packets traverse the same set of nodes and links and receive the same network QoS treatment as the monitored data flow, e.g., a DetNet flow. When the UDP destination port number used by the OAM protocol is assigned by IANA, judicious selection of the UDP source port may help achieve co-routedness of OAM with the monitored IP DetNet flow in multipath environments, e.g., Link Aggregation Group or Equal Cost Multipath, via the use of a UDP source port value that results in the OAM traffic and the monitored IP DetNet flow hashing to the same path based on the packet header hashes used for path selection. This does assume that forwarding equipment along the multipath makes consistent hashing decisions, which might not always be true in a heterogeneous environment. (That also applies to the encapsulation techniques described in Sections 3.2 and 3.3.) To ensure the accuracy of OAM results in detecting failures and monitoring the performance of IP DetNet, it is essential that test packets not only traverse the same path as the monitored IP DetNet flow but also receive the same treatment by the nodes, e.g., shaping, filtering, policing, and availability of the pre-allocated resources, as experienced by the IP DetNet packet. That correlation between the particular IP OAM session and the monitored IP DetNet flow can be achieved by using DetNet provisioning information (e.g., [RFC9633]). Each IP OAM protocol session is presented as a DetNet application with related service and forwarding sub-layers. The forwarding sub-layer of the IP OAM session is identical to the forwarding sub-layer of the monitored IP DetNet flow, except for information in the "ip-header" grouping item as defined in [RFC9633].
IP OAMプロトコルは、IP Detnet Flowに影響を与える障害（例：BFD [RFC5880]）とパフォーマンスの低下（例：スタンプ[RFC8762]）を検出するために使用されます。アクティブなOAMが役立つためには、特別に構築されたOAMパケットが同じノードとリンクのセットを通過し、監視対象のデータフロー、たとえばデットネットフローと同じネットワークQoSトリートメントを受信することを確認することが不可欠です。OAMプロトコルで使用されているUDP宛先ポート番号がIANAによって割り当てられている場合、UDPソースポートの賢明な選択は、マルチパス環境で監視されているIPデットネットフローを備えたOAMの協力を達成するのに役立つ場合があります。、OAMトラフィックをもたらすUDPソースポート値の使用と、パス選択に使用されるパケットヘッダーハッシュに基づいて、同じパスへの監視対象のIPデットネットフローハッシュを使用します。これは、マルチパスに沿った転送機器が一貫したハッシュ決定を行うことを前提としています。（これは、セクション3.2および3.3で説明されているカプセル化手法にも適用されます。）OAMの精度を確保するために、障害が検出され、IPデットネットのパフォーマンスが監視されます。Detnet Flowだけでなく、IP Detnetパケットが経験したのと同じように、ノード、たとえば、形状、フィルタリング、ポリシング、および事前に割り当てられたリソースの可用性などの同じ処理も受け取ります。特定のIP OAMセッションと監視対象のIP Detnetフローとの相関は、DetNet Provisioning情報（[RFC9633]など）を使用して実現できます。各IP OAMプロトコルセッションは、関連するサービスおよび転送サブレイヤーを備えたデットネットアプリケーションとして提示されます。IP OAMセッションの転送サブレイヤーは、[RFC9633]で定義されている「IP-Header」グループ化アイテムの情報を除き、監視対象のIPデットネットフローの転送サブレイヤーと同一です。
As described above, active IP OAM is realized through several protocols. Some protocols use UDP transport, while ICMP is a network-layer protocol. The amount of operational work mapping IP OAM protocols to the monitored DetNet flow can be reduced by using an IP/UDP tunnel [RFC2003] to carry IP test packets. Then, to ensure that OAM packets traverse the same set of nodes and links, the IP/UDP tunnel must be mapped to the monitored DetNet flow. Note that in such a case, the DetNet domain for the test packet is seen as a single IP link. As a result, transit DetNet IP nodes cannot be traced using the usual traceroute procedure, and a modification of the traceroute may be required.
上記のように、アクティブなIP OAMはいくつかのプロトコルを通じて実現されます。一部のプロトコルではUDPトランスポートを使用していますが、ICMPはネットワーク層プロトコルです。IP OAMプロトコルを監視対象のディットネットフローにマッピングする運用作業の量は、IP/UDPトンネル[RFC2003]を使用してIPテストパケットを運ぶことで削減できます。次に、OAMパケットが同じノードとリンクのセットを横断するようにするために、IP/UDPトンネルを監視対象のディットネットフローにマッピングする必要があります。このような場合、テストパケットのDetNetドメインは単一のIPリンクと見なされることに注意してください。その結果、Transit Detnet IPノードは、通常のトレーサーアウト手順を使用して追跡することはできず、Tracerouteの変更が必要になる場合があります。
Active OAM in IP DetNet can be realized using DetNet-in-UDP encapsulation. Using a DetNet-in-UDP tunnel between IP DetNet nodes ensures that active OAM test packets follow the same path through the network as the monitored IP DetNet flow packets and receive the same forwarding treatment in the DetNet forwarding sub-layer (see Section 4.1.2 of [RFC8655]) as the IP DetNet flow being monitored.
IP DetnetのアクティブOAMは、DetNet-in-UDPカプセル化を使用して実現できます。IP DetNetノード間のDetnet-in-UDPトンネルを使用すると、アクティブなOAMテストパケットが監視されているIP Detnetフローパケットと同じパスに従い、デットネット転送サブレイヤーで同じ転送処理を受けることが保証されます（セクション4.1を参照してください。[RFC8655]の2）IPデットネットフローが監視されているとき。
[RFC9566] describes how DetNet with the MPLS-over-UDP/IP data plane [RFC9025] can be used to support Packet Replication, Elimination, and Ordering Functions (PREOF) to potentially lower packet loss, improve the probability of on-time packet delivery, and ensure in-order packet delivery in IP DetNet's service sub-layer. To ensure that an active OAM test packet follows the path of the monitored DetNet flow in the DetNet service sub-layer, the encapsulation shown in Figure 1 is used.
[RFC9566]は、MPLS-Over-UDP/IPデータプレーン[RFC9025]を使用したDetnet [RFC9025]を使用して、パケットの複製、排除、および順序付け関数（Preof）をサポートして、パケット損失を潜在的に低下させる方法を説明しています。IP Detnetのサービスサブレイヤーでの配信、およびIP Detnetのサブレイヤーでの順序パケット配信を確保します。アクティブなOAMテストパケットが、Detnet Serviceサブレイヤーの監視されたDetnet Flowのパスに従うことを確認するために、図1に示すカプセル化が使用されます。
+---------------------------------+
| |
| DetNet App-Flow |
| (original IP) Packet |
| |
+---------------------------------+ <--\
| DetNet ACH | |
+---------------------------------+ +--> PREOF-capable
| Service-ID (S-Label) | | DetNet IP data
+---------------------------------+ | plane encapsulation
| UDP Header | |
+---------------------------------+ |
| IP Header | |
+---------------------------------+ <--/
| Data-Link |
+---------------------------------+
| Physical |
+---------------------------------+
Figure 1: DetNet Associated Channel Header Format
図1：デトネット関連チャネルヘッダー形式
* DetNet ACH - the DetNet Associated Channel Header as defined in [RFC9546].
* DetNet ACH -[RFC9546]で定義されているDetNet Associated Channel Header。
* PREOF - Packet Replication, Elimination, and Ordering Functions used in the DetNet service sub-layer as defined in [RFC8655].
* PREOF- [RFC8655]で定義されているDetnet Serviceサブレイヤーで使用されるパケットの複製、除去、および順序機能。
[RFC8086] has defined the method of encapsulating GRE (Generic Routing Encapsulation) headers in UDP. GRE-in-UDP encapsulation can be used for IP DetNet OAM, as it eases the task of mapping an OAM test session to a particular IP DetNet flow that is identified by an N-tuple. Matching a GRE-in-UDP tunnel to the monitored IP DetNet flow enables the use of Y.1731/G.8013 [ITU.Y1731] as a comprehensive toolset of OAM. The Protocol Type field in the GRE header must be set to 0x8902, assigned by IANA to the IEEE 802.1ag Connectivity Fault Management (CFM) protocol / ITU-T Recommendation Y.1731. Y.1731/G.8013 supports the necessary functions required for IP DetNet OAM, i.e., continuity checks, one-way packet loss, and packet delay measurements.
[RFC8086]は、UDPでGRE（汎用ルーティングカプセル化）ヘッダーをカプセル化する方法を定義しています。GRE-in-udpカプセル化は、n-tupleによって識別される特定のIPデットネットフローにOAMテストセッションをマッピングするタスクを容易にするため、IP Detnet OAMに使用できます。GRE-in-udpトンネルを監視されているIPデットネットフローに一致させると、y.1731/g.8013 [itu.y1731]をOAMの包括的なツールセットとして使用することができます。GREヘッダーのプロトコルタイプフィールドは、IANAによってIEEE 802.1AG接続障害管理（CFM）プロトコル / ITU-T推奨Y.1731に割り当てられた0x8902に設定する必要があります。Y.1731/G.8013は、IP DetNet OAM、つまり連続性チェック、一元配置パケット損失、パケット遅延測定に必要な必要な機能をサポートしています。
A domain in which the IP data plane provides DetNet service could be used in conjunction with a Time-Sensitive Networking (TSN) network and a DetNet domain with the MPLS data plane to deliver end-to-end service. In such scenarios, the ability to detect defects and monitor performance using OAM is essential. [RFC9546] identifies two OAM interworking models -- peering and tunneling. Interworking between DetNet domains with IP and MPLS data planes is analyzed in Section 4.2 of [RFC9546]. In addition, OAM interworking requirements and recommendations that apply between a DetNet domain with the MPLS data plane and an adjacent TSN network also apply between a DetNet domain with the IP data plane and an adjacent TSN network.
IPデータプレーンがDetNetサービスを提供するドメインは、時間に敏感なネットワーキング（TSN）ネットワークおよびMPLSデータプレーンを備えたDetnetドメインと組み合わせて使用して、エンドツーエンドサービスを提供できます。このようなシナリオでは、OAMを使用して欠陥を検出し、パフォーマンスを監視する機能が不可欠です。[RFC9546]は、ピアリングとトンネルの2つのOAMインターワーキングモデルを識別します。[RFC9546]のセクション4.2で、IPおよびMPLSデータプレーンを使用したDetNetドメイン間のインターワーキングを分析します。さらに、MPLSデータプレーンと隣接するTSNネットワークを備えたDetnetドメイン間に適用されるOAMインターワーキング要件と推奨事項は、IPデータプレーンと隣接するTSNネットワークを使用してDetnetドメイン間に適用されます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document describes the applicability of the existing Fault Management and Performance Monitoring IP OAM protocols. It does not raise any security concerns or issues in addition to those common to networking or already documented in [RFC0792], [RFC4443], [RFC5880], and [RFC8762] for the referenced DetNet and OAM protocols.
このドキュメントでは、既存の障害管理とパフォーマンス監視IP OAMプロトコルの適用性について説明します。参照されたデトネットおよびOAMプロトコルについては、ネットワーキングに共通しているか、[RFC0792]、[RFC4443]、[RFC5880]、および[RFC8762]に既に文書化されているものに加えて、セキュリティの懸念や問題を提起しません。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, DOI 10.17487/RFC0792, September 1981,
<https://www.rfc-editor.org/info/rfc792>.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
DOI 10.17487/RFC2003, October 1996,
<https://www.rfc-editor.org/info/rfc2003>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
March 2017, <https://www.rfc-editor.org/info/rfc8086>.
[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>.
[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>.
[RFC9025] Varga, B., Ed., Farkas, J., Berger, L., Malis, A., and S.
Bryant, "Deterministic Networking (DetNet) Data Plane:
MPLS over UDP/IP", RFC 9025, DOI 10.17487/RFC9025, April
2021, <https://www.rfc-editor.org/info/rfc9025>.
[RFC9546] Mirsky, G., Chen, M., and B. Varga, "Operations,
Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet) with the MPLS Data Plane", RFC 9546,
DOI 10.17487/RFC9546, February 2024,
<https://www.rfc-editor.org/info/rfc9546>.
[RFC9633] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li,
"Deterministic Networking (DetNet) YANG Data Model",
RFC 9633, DOI 10.17487/RFC9633, October 2024,
<https://www.rfc-editor.org/info/rfc9633>.
[ITU.Y1731]
ITU-T, "Operation, administration and maintenance (OAM)
functions and mechanisms for Ethernet-based networks",
ITU-T Recommendation G.8013/Y.1731, June 2023.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[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>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC9551] Mirsky, G., Theoleyre, F., Papadopoulos, G., Bernardos,
CJ., Varga, B., and J. Farkas, "Framework of Operations,
Administration, and Maintenance (OAM) for Deterministic
Networking (DetNet)", RFC 9551, DOI 10.17487/RFC9551,
March 2024, <https://www.rfc-editor.org/info/rfc9551>.
[RFC9566] Varga, B., Farkas, J., and A. Malis, "Deterministic
Networking (DetNet) Packet Replication, Elimination, and
Ordering Functions (PREOF) via MPLS over UDP/IP",
RFC 9566, DOI 10.17487/RFC9566, April 2024,
<https://www.rfc-editor.org/info/rfc9566>.
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Mach(Guoyi) Chen
Huawei
Email: mach.chen@huawei.com
David Black
Dell EMC
176 South Street
Hopkinton, MA 01748
United States of America
Email: david.black@dell.com