[要約] RFC 9062は、Ethernet VPN (EVPN) の運用、管理、保守 (OAM) に関するフレームワークと要件を定義します。この文書の目的は、EVPN環境での効率的なネットワークトラブルシューティングとパフォーマンスモニタリングを支援することです。利用場面としては、データセンター間接続、メトロイーサネットサービス、および企業ネットワークの拡張が挙げられます。
Internet Engineering Task Force (IETF) S. Salam
Request for Comments: 9062 A. Sajassi
Category: Informational Cisco
ISSN: 2070-1721 S. Aldrin
Google
J. Drake
Juniper
D. Eastlake 3rd
Futurewei
June 2021
Framework and Requirements for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM)
イーサネットVPN（EVPN）オペレーション、管理、およびメンテナンスのためのフレームワークと要件（OAM）
Abstract
概要
This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and Provider Backbone Bridge EVPN (PBB-EVPN). The framework defines the layered OAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers.
このドキュメントでは、イーサネットVPN（EVPN）操作、管理、およびメンテナンス（OAM）の要件と参照フレームワークを指定します。この要件は、EVPNとプロバイダバックボーンブリッジEVPN（PBB-EVPN）のOAMの側面をカバーしています。このフレームワークは、EVPNサービス層、ネットワーク層、基礎となるパケット交換ネットワーク（PSN）トランスポート層、およびリンク層を網羅する層状OAMモデルを定義しますが、サービス層とネットワーク層に焦点を当てています。
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/rfc9062.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9062で入手できます。
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. Relationship to Other OAM Work
1.2. Specification of Requirements
1.3. Terminology
2. EVPN OAM Framework
2.1. OAM Layering
2.2. EVPN Service OAM
2.3. EVPN Network OAM
2.4. Transport OAM for EVPN
2.5. Link OAM
2.6. OAM Interworking
3. EVPN OAM Requirements
3.1. Fault Management Requirements
3.1.1. Proactive Fault Management Functions
3.1.1.1. Fault Detection (Continuity Check)
3.1.1.2. Defect Indication
3.1.1.2.1. Forward Defect Indication (FDI)
3.1.1.2.2. Reverse Defect Indication (RDI)
3.1.2. On-Demand Fault Management Functions
3.1.2.1. Connectivity Verification
3.1.2.2. Fault Isolation
3.2. Performance Management
3.2.1. Packet Loss
3.2.2. Packet Delay and Jitter
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Acknowledgements
Authors' Addresses
This document specifies the requirements and defines a reference framework for Ethernet VPN (EVPN) Operations, Administration, and Maintenance (OAM) [RFC6291]. In this context, we use the term "EVPN OAM" to loosely refer to the OAM functions required for and/or applicable to [RFC7432] and [RFC7623].
このドキュメントは要件を指定し、イーサネットVPN（EVPN）操作、管理、および保守（OAM）[RFC6291]の参照フレームワークを定義します。これに関連して、「EVPN OAM」という用語を使用して、[RFC7432]と[RFC7623]に必要なOAM機能を緩やかに参照します。
EVPN is a Layer 2 VPN (L2VPN) solution for multipoint Ethernet services with advanced multihoming capabilities that uses BGP for distributing Customer/Client Media Access Control (C-MAC) address reachability information over the core MPLS/IP network.
EVPNは、CORE MPLS / IPネットワーク経由で顧客/クライアントメディアアクセス制御（C-MAC）アドレスのアドレス到達可能性情報を使用する高度なマルチホーム機能を備えたマルチポイントイーサネットサービス用のレイヤ2 VPN（L2VPN）ソリューションです。
PBB-EVPN combines Provider Backbone Bridging (PBB) [IEEE-802.1Q] with EVPN in order to reduce the number of BGP MAC advertisement routes; provide client MAC address mobility using C-MAC [RFC7623] aggregation and Backbone MAC (B-MAC) [RFC7623] sub-netting; confine the scope of C-MAC learning to only active flows; offer per-site policies; and avoid C-MAC address flushing on topology changes.
PBB-EVPNは、BGP MAC広告経路の数を減らすために、プロバイダバックボーンブリッジング（PBB）[IEEE-802.1Q]をEVPNと組み合わせています。C-MAC [RFC7623]集約とバックボーンMAC（B-MAC）[RFC7623]サブネットを使用してクライアントMACアドレスモビリティを提供します。C-MAC学習の範囲をアクティブな流れだけに限定します。サイトごとのポリシーを申し出る。そして、トポロジの変化をフラッシュするC-MACアドレスを避けます。
This document focuses on the fault management and performance management aspects of EVPN OAM. It defines the layered OAM model encompassing the EVPN service layer, network layer, underlying Packet Switched Network (PSN) transport layer, and link layer but focuses on the service and network layers.
この文書はEVPN OAMの障害管理とパフォーマンス管理の側面に焦点を当てています。それは、EVPNサービス層、ネットワーク層、基礎となるパケット交換ネットワーク（PSN）トランスポート層、およびリンク層を包含する階層化OAMモデルを定義しますが、サービス層とネットワーク層に焦点を当てています。
This document leverages concepts and draws upon elements defined and/or used in the following documents:
この文書は概念を活用し、次の文書で定義および/または使用されている要素を描画します。
[RFC6136] specifies the requirements and a reference model for OAM as it relates to L2VPN services, pseudowires, and associated Packet Switched Network (PSN) tunnels. This document focuses on Virtual Private LAN Service (VPLS) and Virtual Private Wire Service (VPWS) solutions and services.
[RFC6136] L2VPNサービス、疑似回線、および関連するパケット交換ネットワーク（PSN）トンネルに関連するOAMの要件と参照モデルを指定します。このドキュメントは、仮想プライベートLANサービス（VPLS）およびバーチャルプライベートワイヤサービス（VPWS）ソリューションとサービスに焦点を当てています。
[RFC8029] defines mechanisms for detecting data plane failures in MPLS Label Switched Paths (LSPs), including procedures to check the correct operation of the data plane as well as mechanisms to verify the data plane against the control plane.
[RFC8029]データプレーンの正しい動作を確認するための手順を含むMPLSラベルスイッチパス（LSP）のデータプレーン障害を検出するためのメカニズムと、コントロールプレーンに対するデータプレーンを検証するメカニズムを含むメカニズムを定義します。
[IEEE-802.1Q] specifies the Ethernet Connectivity Fault Management (CFM) protocol, which defines the concepts of Maintenance Domains, Maintenance Associations, Maintenance End Points, and Maintenance Intermediate Points.
[IEEE-802.1Q]は、メンテナンスドメイン、メンテナンスアソシエーション、メンテナンスエンドポイント、メンテナンス中間点の概念を定義するイーサネット接続障害管理（CFM）プロトコルを指定します。
[Y.1731] extends Connectivity Fault Management in the following areas: it defines fault notification and alarm suppression functions for Ethernet and specifies mechanisms for Ethernet performance management, including loss, delay, jitter, and throughput measurement.
[Y.1731]接続障害管理を次の領域で拡張します。イーサネット用の障害通知とアラーム抑制機能を定義し、損失、遅延、ジッタ、およびスループット測定など、イーサネット性能管理のメカニズムを指定します。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following terminology, much of which is defined in [RFC6136]:
この文書は次の用語を使用しています。そのうちは、[RFC6136]で定義されています。
CE Customer Edge device; for example, a host, router, or switch.
CEカスタマーエッジデバイス。たとえば、ホスト、ルータ、またはスイッチです。
CFM Connectivity Fault Management [IEEE-802.1Q]
CFM接続障害管理[IEEE-802.1Q]
DF Designated Forwarder [RFC7432]
DF指定フォワーダ[RFC7432]
Down MEP A MEP that originates traffic away from and terminates traffic towards the core of the device in whose port it is logically located.
Down MEPは、トラフィックを離れて、そのポートのコアに向かってトラフィックを終了し、そのポートのコアに向かってトラフィックを終了します。
EVI An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN [RFC7432].
EVIのEVPNインスタンスは、そのEVPNに参加しているプロバイダーエッジ（PE）デバイスにまたがっています[RFC7432]。
L2VPN Layer 2 VPN
L2VPNレイヤ2 VPN
LOC Loss of continuity
継続的な損失の喪失
MA Maintenance Association; a set of MEPs belonging to the same Maintenance Domain (MD) established to verify the integrity of a single service instance [IEEE-802.1Q].
MAメンテナンス協会。単一のサービスインスタンス[IEEE-802.1Q]の整合性を検証するために確立された同じメンテナンスドメイン（MD）に属するMEPのセット。
MD Maintenance Domain; an OAM Domain that represents a region over which OAM frames can operate unobstructed [IEEE-802.1Q].
MDメンテナンスドメイン。OAMフレームを表す領域を表すOAMドメイン[IEEE-802.1Q]。
MEP Maintenance End Point; it is responsible for origination and termination of OAM frames for a given MA. A MEP is logically located in a device's port [IEEE-802.1Q].
MEPメンテナンス終了点特定のMAのOAMフレームの起源と終了について責任があります。MEPはデバイスのポート[IEEE-802.1Q]に論理的にあります。
MIP Maintenance Intermediate Point; it is located between peer MEPs and can process and respond to certain OAM frames but does not initiate them. A MIP is logically located in a device's port [IEEE-802.1Q].
MIPメンテナンス中間点。それはピアMEPSの間に位置し、特定のOAMフレームを処理し、それらを開始しません。MIPは装置のポート[IEEE-802.1Q]に論理的に見つけられます。
MP2P Multipoint to Point
PointのMP2Pマルチポイント
NMS Network Management Station [RFC6632]
NMSネットワーク管理ステーション[RFC6632]
P Provider network interior (non-edge) node
Pプロバイダネットワークインテリア（非エッジ）ノード
P2MP Point to Multipoint
P2MPはマルチポイントを指す
PBB Provider Backbone Bridge [RFC7623]
PBBプロバイダーバックボーンブリッジ[RFC7623]
PE Provider Edge network device
PEプロバイダエッジネットワークデバイス
Up MEP A MEP that originates traffic towards and terminates traffic from the core of the device in whose port it is logically located.
UP MEPは、そのポートのコアからのトラフィックを発生させ、そのポートの中核からのトラフィックを発生させ、そのポートのコアから終了します。
VPN Virtual Private Network
VPN仮想プライベートネットワーク
Multiple layers come into play for implementing an L2VPN service using the EVPN family of solutions as listed below. The focus of this document is the service and network layers.
以下にリストされているように、EVPNのソリューションを使用してL2VPNサービスを実装するために、複数のレイヤが再生されます。この文書の焦点はサービスとネットワーク層です。
* The service layer runs end to end between the sites or Ethernet segments that are being interconnected by the EVPN solution.
* サービス層は、EVPNソリューションによって相互接続されているサイトまたはイーサネットセグメント間の終わりを終了します。
* The network layer extends between the EVPN PE (Provider Edge) nodes and is mostly transparent to the P (provider network interior) nodes (except where flow entropy comes into play). It leverages MPLS for service (i.e., EVI) multiplexing and split-horizon functions.
* ネットワーク層はEVPN PE（Provider Edge）ノード間で延長され、主にP（プロバイダネットワーク内部）ノード（フローエントロピーが再生される場合を除く）が透過的です。MPLSのサービス（I..EVI）多重化およびスプリットホライズン関数を活用します。
* The transport layer is dictated by the networking technology of the PSN. It may be based on either MPLS LSPs or IP.
* トランスポート層はPSNのネットワーキング技術によって決定されます。MPLS LSPまたはIPに基づいている可能性があります。
* The link layer is dependent upon the physical technology used. Ethernet is a popular choice for this layer, but other alternatives are deployed (e.g., Packet over SONET (POS), Dense Wavelength Division Multiplexing (DWDM), etc.).
* リンク層は使用される物理技術に依存している。イーサネットはこの層のための一般的な選択ですが、他の選択肢が展開されます（例えば、SONET（POS）、高密度波長分割多重（DWDM）など）。
This layering extends to the set of OAM protocols that are involved in the ongoing maintenance and diagnostics of EVPN networks. Figure 1 below depicts the OAM layering and shows which devices have visibility into what OAM layer(s).
この階層化は、EVPNネットワークの継続的なメンテナンスと診断に関与しているOAMプロトコルのセットに及ぶ。以下の図1は、OAM階層化を示し、どの装置がどのようなOAM層に視認性を有するかを示す。
+---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+
o-------o----------- Service OAM -----------o-------o
o----------- Network OAM -----------o
o--------o--------o--------o--------o Transport OAM
o----o o----o o----o o----o o----o o----o Link OAM
Figure 1: OAM Layering
図1：OAM階層化
Service OAM and Network OAM mechanisms only have visibility to the PE nodes but not the P nodes. As such, they can be used to deduce whether the fault is in the customer's own network, the local CE-PE segment, the PE-PE segment, or the remote CE-PE segment(s). EVPN Transport OAM mechanisms can be used for fault isolation between the PEs and P nodes.
サービスOAMおよびネットワークOAMのメカニズムはPEノードに視認性を持ちますが、Pノードではありません。そのように、それらは、障害が顧客自身のネットワーク、ローカルCE-PEセグメント、PE-PEセグメント、またはリモートCE PEセグメントにあるかどうかを推測するために使用されます。EVPNトランスポートOAMメカニズムは、PESとPノード間の故障分離に使用できます。
Figure 2 below shows an example network where Ethernet domains are interconnected via EVPN using MPLS, and it shows the OAM mechanisms that are applicable at each layer. The details of the layers are described in the sections below.
以下の図2は、イーサネットドメインがMPLSを使用してEVPNを介して相互接続されている例示的なネットワークを示しており、各層に適用可能なOAMメカニズムを示しています。層の詳細は以下のセクションに記載されている。
+---+ +---+
+--+ | | +---+ +---+ +---+ | | +--+
|CE|----|PE |----| P |----| P |----| P |----|PE |----|CE|
+--+ | | +---+ +---+ +---+ | | +--+
+---+ +---+
o----o---------- CFM (Service OAM) ----------o----o
o-------- EVPN Network OAM ---------o
o--------o--------o--------o--------o MPLS OAM
o----o o----o o----o o----o o----o o----o 802.3 OAM
[IEEE-802.3]
Figure 2: EVPN OAM Example
図2：EVPN OAMの例
The EVPN Service OAM protocol depends on what service-layer technology is being interconnected by the EVPN solution. In the case of [RFC7432] and [RFC7623], the service layer is Ethernet; hence, the corresponding Service OAM protocol is Ethernet CFM [IEEE-802.1Q].
EVPNサービスOAMプロトコルは、どのサービス層技術がEVPNソリューションによって相互接続されているかによって異なります。[RFC7432]と[RFC7623]の場合、サービス層はイーサネットです。したがって、対応するサービスOAMプロトコルはイーサネットCFM [IEEE-802.1Q]です。
EVPN Service OAM is visible to the CEs and EVPN PEs but not to the P nodes. This is because the PEs operate at the Ethernet MAC layer in [RFC7432] and [RFC7623], whereas the P nodes do not.
EVPNサービスOAMは、CEとEVPN PEに見えますが、Pノードには表示されません。これは、PESが[RFC7432]と[RFC7623]のイーサネットMAC層で動作するため、Pノードはそうではありません。
The EVPN PE MUST support MIP functions in the applicable Service OAM protocol (for example, Ethernet CFM). The EVPN PE SHOULD support MEP functions in the applicable Service OAM protocol. This includes both Up and Down MEP functions.
EVPN PEは、該当するサービスOAMプロトコルのMIP機能をサポートしなければなりません（たとえば、イーサネットCFM）。EVPN PEは、該当するサービスOAMプロトコルのMEP機能をサポートする必要があります。これにはUPとDOWN MEP機能の両方が含まれます。
As shown in Figure 3, the MIP and MEP functions being referred to are logically located within the device's port operating at the customer level. (There could be MEPs/MIPs within PE ports facing the provider network, but they would not be relevant to EVPN Service OAM as the traffic passing through them will be encapsulated/tunneled, so any customer-level OAM messages will just be treated as data.) Down MEP functions are away from the core of the device while Up MEP functions are towards the core of the device (towards the PE forwarding mechanism in the case of a PE). OAM messages between the PE Up MEPs shown are a type of EVPN Network OAM, while such messages between the CEs or from a PE to its local CE or to the remote CE are Service OAMs.
図3に示すように、MIP関数とMEP関数は、顧客レベルで動作するデバイスのポート内に論理的に位置しています。（PEポート内のMEPS / MIPがプロバイダーネットワークに直面する可能性がありますが、それらを通過するトラフィックがカプセル化/トンネリングされるため、EVPNサービスOAMには関係ないため、顧客レベルのOAMメッセージはデータとして扱われます。。）DOWN MEP関数はデバイスのコアから離れていますが、UP MEP関数はデバイスのコアに向かっています（PEの場合はPE転送メカニズムに向かって）。示されているPEアップMEP間のOAMメッセージはEVPNネットワークOAMの一種であり、CES間のまたはPEからそのローカルCEへの、またはリモートCEへのそのようなメッセージはサービスOAMSである。
+-------+ +----------------+ +----------------+ +-------+
|+-----+| |+--------------+| |+--------------+| |+-----+|
|| CE || || PE || ... || PE || || CE ||
|+--+--+| |+---+--------+-+| |+-+--------+---+| |+--+--+|
| | | | | | | | | | | | | |
|+--+--+| |+---+-----+ . | | . +-----+---+| |+--+--+|
|| MEP || || | Up ^| . | ... | . | Up ^| || || MEP ||
||DownV|| ||MIP|MEP | . | | . |MEP |MIP|| ||DownV||
|+--+--+| || |DownV| . | | . |DownV| || |+--+--+|
| | | |+---+-----+ | | | | +-----+---+| | | |
+---|---+ +----|--------|--+ +--|--------|----+ +---|---+
| | | | | |
+------------+ +--- ... ---+ +------------+
Figure 3: CFM Details
図3：CFMの詳細
The EVPN PE MUST, by default, learn the MAC address of locally attached CE MEPs by snooping on CFM frames and advertising them to remote PEs as a MAC/IP Advertisement route. Some means to limit the number of MAC addresses that a PE will learn SHOULD be implemented.
EVPN PEは、デフォルトでは、CFMフレームをスヌーピングして、それらをMAC / IP広告ルートとして遠隔PEに広告することによってローカルに接続されたCE MEPSのMACアドレスを学びます。PEが学習するMACアドレスの数を制限することを意味します。
The EVPN PE SHOULD advertise any MEP/MIP local to the PE as a MAC/IP Advertisement route. Since these are not subject to mobility, they SHOULD be advertised with the static (sticky) bit set (see Section 15.2 of [RFC7432]).
EVPN PEは、MAC / IPアドバタイズメントルートとしてPEにローカルをローカルに宣伝する必要があります。これらはモビリティの影響を受けないため、静的（スティッキ）ビットセットでアドバタイズする必要があります（[RFC7432]のセクション15.2を参照）。
EVPN Network OAM is visible to the PE nodes only. This OAM layer is analogous to Virtual Circuit Connectivity Verification (VCCV) [RFC5085] in the case of VPLS/VPWS. It provides mechanisms to check the correct operation of the data plane as well as a mechanism to verify the data plane against the control plane. This includes the ability to perform fault detection and diagnostics on:
EVPNネットワークOAMはPEノードのみに表示されます。このOAM層は、VPLS / VPWSの場合、仮想回線接続検証（VCCV）[RFC5085]に類似している。それは、データプレーンの正しい動作をチェックするためのメカニズム、ならびにデータプレーンを制御プレーンに対して検証するためのメカニズムを提供する。これには、障害検出と診断を実行する機能が含まれます。
* the MP2P tunnels used for the transport of unicast traffic between PEs. EVPN allows for three different models of unicast label assignment: label per EVI, label per <ESI, Ethernet Tag>, and label per MAC address. In all three models, the label is bound to an EVPN Unicast Forwarding Equivalence Class (FEC). EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view.
* PE間のユニキャストトラフィックのトランスポートに使用されるMP2Pトンネル。EVPNでは、1つのユニキャストラベルの割り当て：EVIごとのラベル、<ESI、イーサネットタグ>、およびMACアドレスごとのラベルを参照してください。3つのモデルすべてで、ラベルはEVPNユニキャスト転送等価クラス（FEC）にバインドされています。EVPNネットワークOAMは、データプレーンの動作を確認し、制御プレーンビューに対する操作を確認するためのメカニズムを提供する必要があります。
* the MP2P tunnels used for aliasing unicast traffic destined to a multihomed Ethernet segment. The three label assignment models, discussed above, apply here as well. In all three models, the label is bound to an EVPN Aliasing FEC. EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view.
* MP2Pトンネルは、マルチホームイーサネットセグメント宛てのユニキャストトラフィックをエイリアシングするために使用されます。上述した3つのラベル割り当てモデルもここに適用されます。3つのモデルすべてで、ラベルはEVPNエイリアシングFECにバインドされています。EVPNネットワークOAMは、データプレーンの動作を確認し、制御プレーンビューに対する操作を確認するためのメカニズムを提供する必要があります。
* the multicast tunnels (either MP2P or P2MP) used for the transport of broadcast, unknown unicast, and multicast traffic between PEs. In the case of ingress replication, a label is allocated per EVI or per <EVI, Ethernet Tag> and is bound to an EVPN Multicast FEC. In the case of Label Switched Multicast (LSM) and, more specifically, aggregate inclusive trees, again, a label may be allocated per EVI or per <EVI, Ethernet Tag> and is bound to the tunnel FEC.
* ブロードキャスト、不明なユニキャスト、およびPE間のマルチキャストトラフィックのトランスポートに使用されるマルチキャストトンネル（MP2PまたはP2MP）。Ingressレプリケーションの場合、ラベルはEVIごとに、または<EVI、Ethernet Tag>ごとに割り当てられ、EVPNマルチキャストFECにバインドされます。ラベルスイッチマルチキャスト（LSM）の場合、より具体的には集約包括的なツリーが再び、ラベルはEVIごとに、または<EVI、イーサネットタグ>ごとに割り当てられ、トンネルFECにバインドされます。
* the correct operation of the Ethernet Segment Identifier (ESI) split-horizon filtering function. In EVPN, a label is allocated per multihomed Ethernet segment for the purpose of performing the access split-horizon enforcement. The label is bound to an EVPN Ethernet segment.
* イーサネットセグメント識別子（ESI）スプリットホライズンフィルタリング機能の正しい動作。EVPNでは、アクセススプリットホライズン施行を実行する目的で、マルチホームイーサネットセグメントごとにラベルが割り当てられます。ラベルはEVPNイーサネットセグメントにバインドされています。
* the correct operation of the Designated Forwarder (DF) [RFC7432] filtering function. EVPN Network OAM MUST provide mechanisms to check the operation of the data plane and verify that operation against the control plane view for the DF filtering function.
* 指定されたフォワーダ（DF）[RFC7432]フィルタ機能の正しい動作。EVPNネットワークOAMは、データプレーンの動作を確認するためのメカニズムを提供し、DFフィルタ機能の制御プレーンビューに対する操作を確認する必要があります。
EVPN Network OAM mechanisms MUST provide in-band monitoring capabilities. It is desirable, to the extent practical, for OAM test messages to share fate with data messages. Details of how to achieve this are beyond the scope of this document.
EVPNネットワークOAMメカニズムは、インバンドモニタリング機能を提供しなければなりません。AAMテストメッセージがデータメッセージとの運命を共有するために実用的には望ましい。これを達成する方法の詳細はこの文書の範囲を超えています。
EVPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring the data plane operation and data plane conformance to the state of the control plane.
EVPNネットワークOAMは、データプレーン操作およびデータプレーンの状態へのデータプレーンの状態を監視するという積極的およびオンデマンドの両方のメカニズムを提供する必要があります。
The Transport OAM protocol depends on the nature of the underlying transport technology in the PSN. MPLS OAM mechanisms [RFC8029] [RFC6425] as well as ICMP [RFC0792] and ICMPv6 [RFC4443] are applicable, depending on whether the PSN employs MPLS or IP transport, respectively. Furthermore, Bidirectional Forwarding Detection (BFD) mechanisms per [RFC5880], [RFC5881], [RFC5883], and [RFC5884] apply. Also, the BFD mechanisms pertaining to MPLS-TP LSPs per [RFC6428] are applicable.
トランスポートOAMプロトコルは、PSN内の基礎となる輸送技術の性質によって異なります。PSNがMPLSまたはIPトランスポートを使用するかどうかに応じて、MPLS OAMメカニズム[RFC6425] [RFC6425]、ICMP [RFC0792]とICMPv6 [RFC4443]が適用可能です。さらに、[RFC5880]、[RFC5881]、[RFC5883]、[RFC5884]、[RFC5884]の双方向転送検出（BFD）メカニズム。また、[RFC6428]あたりのMPLS-TP LSPに関するBFDメカニズムが適用されます。
Link OAM depends on the data-link technology being used between the PE and P nodes. For example, if Ethernet links are employed, then Ethernet Link OAM ([IEEE-802.3], Clause 57) may be used.
リンクOAMは、PEとPノードの間に使用されているデータリンク技術によって異なります。例えば、イーサネットリンクが使用されている場合、イーサネットリンクOAM（[IEEE-802.3]、57節）を使用することができる。
When interworking two networking domains, such as actual Ethernet and EVPN to provide an end-to-end emulated service, there is a need to identify the failure domain and location, even when a PE supports both the Service OAM mechanisms and the EVPN Network OAM mechanisms. In addition, scalability constraints may not allow the running of proactive monitoring, such as Ethernet Continuity Check Messages (CCMs) [IEEE-802.1Q], at a PE to detect the failure of an EVI across the EVPN domain. Thus, the mapping of alarms generated upon failure detection in one domain (e.g., actual Ethernet or EVPN network domain) to the other domain is needed. There are also cases where a PE may not be able to process Service OAM messages received from a remote PE over the PSN even when such messages are defined, as in the Ethernet case, thereby necessitating support for fault notification message mapping between the EVPN Network domain and the Service domain.
実際のイーサネットやEVPNなどの2つのネットワークドメインをインターワーキングしてエンドツーエンドエミュレートサービスを提供する場合、PEがサービスOAMメカニズムとEVPNネットワークOAMの両方をサポートしている場合でも、障害ドメインと場所を特定する必要があります。メカニズムさらに、スケーラビリティ制約は、EVPNドメイン全体のEVIの障害を検出するために、Ethernet連続性チェックメッセージ（CCMS）[IEEE-802.1Q]など、プロアクティブモニタリングの実行を許可しない可能性があります。したがって、1つのドメイン（例えば、実際のイーサネットまたはEVPNネットワークドメイン）内の故障検出時に生成されたアラームのマッピングが必要である。Ethernetケースのようにそのようなメッセージが定義されていても、PESがリモートPEから受信したサービスOAMメッセージをPSNに処理することができない場合があり、それによってEVPNネットワークドメイン間の障害通知メッセージマッピングのサポートを必要とする場合がある。そしてサービスドメイン。
OAM interworking is not limited, though, to scenarios involving disparate network domains. It is possible to perform OAM interworking across different layers in the same network domain. In general, alarms generated within an OAM layer, as a result of proactive fault detection mechanisms, may be injected into its client-layer OAM mechanisms. This allows the client-layer OAM to trigger event-driven (i.e., asynchronous) fault notifications. For example, alarms generated by the Link OAM mechanisms may be injected into the Transport OAM layer, and alarms generated by the Transport OAM mechanism may be injected into the Network OAM mechanism, and so on.
OAMインターワーキングは、異なるネットワークドメインを含むシナリオに限定されません。同じネットワークドメイン内の異なるレイヤー間でOAMインターワーキングを実行することが可能です。一般に、予防的な故障検出メカニズムの結果として、OAM層内で生成されたアラームをそのクライアント層OAMメカニズムに注入することができる。これにより、クライアント層OAMはイベント駆動源（すなわち非同期）障害通知をトリガすることができる。例えば、リンクOAMメカニズムによって生成されたアラームをトランスポートOAMレイヤに注入し、トランスポートOAMメカニズムによって生成されたアラームをネットワークOAM機構に注入してもよい。
EVPN OAM MUST support interworking between the Network OAM and Service OAM mechanisms. EVPN OAM MAY support interworking among other OAM layers.
EVPN OAMは、ネットワークOAMとサービスOAMメカニズム間のインターワーキングをサポートしている必要があります。EVPN OAMは他のOAM層間の相互作用をサポートすることができます。
This section discusses the EVPN OAM requirements pertaining to fault management and performance management.
このセクションでは、障害管理とパフォーマンス管理に関するEVPN OAMの要件について説明します。
The network operator configures proactive fault management functions to run periodically. Certain actions (for example, protection switchover or alarm indication signaling) can be associated with specific events, such as entering or clearing fault states.
ネットワーク演算子は、定期的に実行するように予防的な障害管理機能を構成します。特定のアクション（たとえば、保護切り替えまたはアラーム表示シグナリング）は、障害状態の入力やクリアなど、特定のイベントに関連付けることができます。
Proactive fault detection is performed by periodically monitoring the reachability between service end points, i.e., MEPs in a given MA, through the exchange of CCMs [IEEE-802.1Q]. The reachability between any two arbitrary MEPs may be monitored for:
予防故障検出は、CCMS [IEEE-802.1Q]の交換を通じて、サービスエンドポイント、すなわち特定のMA内のMEP間の到達可能性を定期的に監視することによって実行される。任意の2つの任意のMEP間の到達可能性を監視することができます。
* in-band, per-flow monitoring. This enables per-flow monitoring between MEPs. EVPN Network OAM MUST support fault detection with per-user flow granularity. EVPN Service OAM MAY support fault detection with per-user flow granularity.
* 帯域内、フローごとの監視。これにより、MEP間のフロー監視が可能になります。EVPNネットワークOAMは、ユーザーごとのフローの細分性を持つ障害検出をサポートしている必要があります。EVPNサービスOAMは、ユーザーごとのフローの細分性を持つ障害検出をサポートできます。
* a representative path. This enables a liveness check of the nodes hosting the MEPs, assuming that the loss of continuity (LOC) to the MEP is interpreted as a failure of the hosting node. This, however, does not conclusively indicate liveness of the path(s) taken by user data traffic. This enables node failure detection but not path failure detection through the use of a test flow. EVPN Network OAM and Service OAM MUST support fault detection using test flows.
* 代表的な道これにより、MEPへの連続性（LOC）の損失がホスティングノードの障害として解釈されると仮定して、MEPSをホストするノードの活性チェックを可能にします。しかしながら、これは、ユーザデータトラフィックによって撮影された経路の活性を決定的に示すものではない。これにより、ノード障害検出が可能ですが、テストフローを使用したパス障害検出は検出できます。EVPNネットワークOAMおよびService OAMはテストフローを使用した障害検出をサポートしている必要があります。
* all paths. For MPLS/IP networks with ECMP, the monitoring of all unicast paths between MEPs (on non-adjacent nodes) may not be possible since the per-hop ECMP hashing behavior may yield situations where it is impossible for a MEP to pick flow entropy characteristics that result in exercising the exhaustive set of ECMP paths. The monitoring of all ECMP paths between MEPs (on non-adjacent nodes) is not a requirement for EVPN OAM.
* すべてのパスECMPを備えたMPLS / IPネットワークの場合、HAPPERPPのハッシュ動作は、MEPがフローエントロピー特性をピックすることが不可能な状況をもたらす可能性があるため、MEP間のすべてのユニキャストパスの監視は不可能である可能性があります。それはECMP経路の徹底的なセットを行使することにつながります。MEP間のすべてのECMPパスの監視（非隣接ノード上）は、EVPN OAMの要件ではありません。
The fact that MPLS/IP networks do not enforce congruency between unicast and multicast paths means that the proactive fault detection mechanisms for EVPN networks MUST provide procedures to monitor the unicast paths independently of the multicast paths. This applies to EVPN Service OAM and Network OAM.
MPLS / IPネットワークがユニキャストパスとマルチキャストパス間の一致を執行しないという事実は、EVPNネットワークのための予防的障害検出メカニズムが、マルチキャストパスとは無関係にユニキャストパスを監視するための手順を提供しなければならないことを意味します。これはEVPNサービスOAMおよびネットワークOAMに適用されます。
Defect indications can be categorized into two types: forward and reverse, as described below. EVPN Service OAM MUST support at least one of these types of event-driven defect indications upon the detection of a connectivity defect.
以下に説明するように、欠陥表示は、前後に逆方向に2つのタイプに分類できます。EVPNサービスOAMは、接続性の欠陥の検出時に、これらのタイプのイベント駆動の欠陥表示の少なくとも1つをサポートしなければなりません。
FDI is used to signal a failure that is detected by a lower-layer OAM mechanism. A server MEP (i.e., an actual or virtual MEP) transmits a forward defect indication in a direction away from the direction of the failure (refer to Figure 4 below).
FDIは、より低層のOAMメカニズムによって検出された障害を知らせるために使用されます。サーバMEP（すなわち、実際のまたは仮想MEP）は、故障の方向から離れる方向に順方向欠陥表示を送信する（下記の図4参照）。
Failure
|
+-----+ +-----+ V +-----+ +-----+
| A |------| B |--XXX--| C |------| D |
+-----+ +-----+ +-----+ +-----+
<===========| |============>
Forward Forward
Defect Defect
Indication Indication
Figure 4: Forward Defect Indication
図4：前方欠陥表示
Forward defect indication may be used for alarm suppression and/or for the purpose of interworking with other layer OAM protocols. Alarm suppression is useful when a transport-level or network-level fault translates to multiple service- or flow-level faults. In such a scenario, it is enough to alert a network management station (NMS) of the single transport-level or network-level fault in lieu of flooding that NMS with a multitude of Service or Flow granularity alarms. EVPN PEs SHOULD support forward defect indication in the Service OAM mechanisms.
順方向欠陥指示は、警報抑制および/または他のレイヤOAMプロトコルとの相互作用を目的として使用することができる。アラーム抑制は、トランスポートレベルまたはネットワークレベルの障害が複数のサービスまたはフローレベルの障害に変換されたときに役立ちます。そのようなシナリオでは、多数のサービスまたはフローの粒度アラームを持つNMSのフラッディングの代わりに、単一のトランスポートレベルまたはネットワークレベルの障害のネットワーク管理ステーション（NMS）に警告するのに十分です。EVPN PESは、サービスOAMメカニズムにおける前方欠陥表示をサポートする必要があります。
RDI is used to signal that the advertising MEP has detected a LOC defect. RDI is transmitted in the direction of the failure (refer to Figure 5).
RDIは、広告MEPがLOC欠陥を検出したことを知らせるために使用されます。RDIは障害の方向に送信されます（図5参照）。
Failure
|
+-----+ +-----+ V +-----+ +-----+
| A |------| B |--XXX--| C |------| D |
+-----+ +-----+ +-----+ +-----+
|===========> <============|
Reverse Reverse
Defect Defect
Indication Indication
Figure 5: Reverse Defect Indication
図5：逆方向欠陥表示
RDI allows single-sided management, where the network operator can examine the state of a single MEP and deduce the overall health of a monitored service. EVPN PEs SHOULD support reverse defect indication in the Service OAM mechanisms. This includes both the ability to signal a LOC defect to a remote MEP as well as the ability to recognize RDI from a remote MEP. Note that, in a multipoint MA, RDI is not a useful indicator of unidirectional fault. This is because RDI carries no indication of the affected MEP(s) with which the sender had detected a LOC defect.
RDIは、ネットワークオペレータが単一のMEPの状態を調べ、監視対象サービスの全体的な状態を推測できる片面管理を可能にします。EVPN PESは、サービスOAMメカニズムにおける逆方向欠陥表示をサポートする必要があります。これには、リモートMEPにRDIを認識する機能と同様に、リモートMEPからRDIを認識する機能の両方が含まれます。なお、マルチポイントMAでは、RDIは一方向障害の有用なインジケータではありません。これは、RDIが送信者がLOCの欠陥を検出した影響を受けるMEPの表示を許可しないためです。
On-demand fault management functions are initiated manually by the network operator and continue for a bounded time period. These functions enable the operator to run diagnostics to investigate a defect condition.
オンデマンド障害管理機能は、ネットワークオペレータによって手動で開始され、有界期間を継続します。これらの関数は、オペレータが診断を実行して欠陥状態を調査できます。
EVPN Network OAM MUST support on-demand connectivity verification mechanisms for unicast and multicast destinations. The connectivity verification mechanisms SHOULD provide a means for specifying and carrying the following in the messages:
EVPNネットワークOAMは、ユニキャストとマルチキャスト宛先のオンデマンド接続検証メカニズムをサポートしている必要があります。接続性検証メカニズムは、メッセージに次のようなものを指定して伝えるための手段を提供する必要があります。
* variable-length payload/padding to test connectivity problems related to the Maximum Transmission Unit (MTU).
* 最大伝送ユニット（MTU）に関連する接続性問題をテストするための可変長ペイロード/パディング。
* test frame formats as defined in Appendix C of [RFC2544] to detect potential packet corruption.
* [RFC2544]の付録Cで定義されているテストフレームフォーマットは、潜在的なパケット破損を検出します。
EVPN Network OAM MUST support connectivity verification at per-flow granularity. This includes both user flows (to test a specific path between PEs) as well as test flows (to test a representative path between PEs).
EVPNネットワークOAMは、フローごとの粒度での接続検証をサポートしている必要があります。これには、（PE間の特定の経路をテストするための）ユーザーフロー（PES間の特定のパスをテストするため）の両方が含まれます（PES間の代表的な経路をテストする）。
EVPN Service OAM MUST support connectivity verification on test flows and MAY support connectivity verification on user flows.
EVPNサービスOAMは、テストフローに関する接続検証をサポートし、ユーザーフローの接続検証をサポートする可能性があります。
For multicast connectivity verification, EVPN Network OAM MUST support reporting on:
マルチキャスト接続の検証のために、EVPNネットワークOAMは以下の報告をサポートしている必要があります。
* the DF filtering status of a specific port(s) or all the ports in a given bridge domain.
* 特定のポートまたは特定のブリッジドメイン内のすべてのポートのDFフィルタステータス。
* the split-horizon filtering status of a specific port(s) or all the ports in a given bridge domain.
* 特定のポートまたは特定のブリッジドメイン内のすべてのポートのスプリットホライズンフィルタステータス。
EVPN OAM MUST support an on-demand fault localization function. This involves the capability to narrow down the locality of a fault to a particular port, link, or node. The characteristic of forward/ reverse path asymmetry in MPLS/IP makes fault isolation a direction-sensitive operation. That is, given two PEs A and B, localization of continuity failures between them requires running fault-isolation procedures from PE A to PE B as well as from PE B to PE A.
EVPN OAMはオンデマンド障害ローカリゼーション機能をサポートしている必要があります。これには、特定のポート、リンク、またはノードへの障害の局所性を絞り込む機能が含まれます。MPLS / IPにおける順方向/逆方向経路非対称性の特性は、故障分離を方向性に敏感にする。すなわち、2つのPES AおよびBが与えられると、それらの間の連続性故障の局在化は、PE AからPE Bまでの故障絶縁手順ならびにPE BからPE Aまでの故障絶縁手順を必要とする。
EVPN Service OAM mechanisms only have visibility to the PEs but not the MPLS or IP P nodes. As such, they can be used to deduce whether the fault is in the customer's own network, the local CE-PE segment, or a remote CE-PE segment(s). EVPN Network and Transport OAM mechanisms can be used for fault isolation between the PEs and P nodes.
EVPNサービスOAMメカニズムはPESの可視性のみがありますが、MPLSまたはIP Pノードはありません。そのように、それらは、障害が顧客自身のネットワーク、ローカルCE-PEセグメント、またはリモートCE PEセグメントにあるかどうかを推測するために使用されます。EVPNネットワークおよびトランスポートOAMメカニズムは、PESとPノード間の故障分離に使用できます。
Performance management functions can be performed both proactively and on demand. Proactive management involves a recurring function, where the performance management probes are run continuously without a trigger. We cover both proactive and on-demand functions in this section.
パフォーマンス管理機能は、積極的におよびオンデマンドの両方を実行できます。プロアクティブ管理は、パフォーマンス管理プローブがトリガーなしで継続的に実行される繰り返し機能を含みます。このセクションの予防的およびオンデマンド機能の両方をカバーします。
EVPN Network OAM SHOULD provide mechanisms for measuring packet loss for a given service -- for example, [RFC7680] and [RFC6673].
EVPNネットワークOAMは、特定のサービスのパケット損失を測定するためのメカニズムを提供する必要があります。たとえば、[RFC7680]と[RFC6673]。
Given that EVPN provides inherent support for multipoint-to-multipoint connectivity, packet loss cannot be accurately measured by means of counting user data packets. This is because user packets can be delivered to more PEs or more ports than are necessary (e.g., due to broadcast, unpruned multicast, or unknown unicast flooding). As such, a statistical means of approximating the packet loss rate is required. This can be achieved by sending "synthetic" OAM packets that are counted only by those ports (MEPs) that are required to receive them. This provides a statistical approximation of the number of data frames lost, even with multipoint-to-multipoint connectivity.
EVPNがマルチポイントツーマルチポイント接続に対する固有のサポートを提供することを考えると、ユーザーデータパケットをカウントすることによってパケット損失を正確に測定することはできません。これは、ユーザーパケットを必要な場合よりも多くのPES以上のポートに配信できるためです（例えば、ブロードキャスト、非増大のマルチキャスト、または不明なユニキャストフラッディングのために）。このように、パケット損失率を近似する統計的手段が必要とされる。これは、それらを受信するのに必要なポート（MEPS）によってのみカウントされる「合成」OAMパケットを送信することによって達成することができる。これは、多入力マルチポイント接続を伴っても、失われたデータフレーム数の統計的近似を提供します。
EVPN Service OAM SHOULD support measurement of one-way and two-way packet delay and delay variation (jitter) across the EVPN network. Measurement of one-way delay requires clock synchronization between the probe source and target devices. Mechanisms for clock synchronization are outside the scope of this document. Note that Service OAM performance management mechanisms defined in [Y.1731] can be used. See also [RFC7679], [RFC2681], and [RFC3393].
EVPNサービスOAMは、EVPNネットワーク全体で一方向および双方向パケット遅延と遅延変動（ジッタ）の測定をサポートする必要があります。一方向遅延の測定は、プローブソースとターゲットデバイス間のクロック同期を必要とする。クロック同期のメカニズムはこの文書の範囲外です。[Y.1731]で定義されているサービスOAM性能管理メカニズムを使用できます。[RFC7679]、[RFC2681]、[RFC3393]も参照してください。
EVPN Network OAM MAY support measurement of one-way and two-way packet delay and delay variation (jitter) across the EVPN network.
EVPNネットワークOAMは、EVPNネットワーク全体で一方向および双方向パケット遅延および遅延変動（ジッタ）の測定をサポートすることができる。
EVPN OAM MUST prevent OAM packets from leaking outside of the EVPN network or outside their corresponding Maintenance Domain. This can be done for CFM, for example, by having MEPs implement a filtering function based on the Maintenance Level associated with received OAM packets.
EVPN OAMは、OAMパケットがEVPNネットワークの外部または対応するメンテナンスドメインの外部の漏洩を防ぐ必要があります。これは、例えば、MEPSを受信したOAMパケットに関連付けられたメンテナンスレベルに基づいてフィルタリング機能を実装することによって、CFMについて行うことができる。
EVPN OAM SHOULD provide mechanisms for implementation and optional use to:
EVPN OAMは実装とオプションの使用のためのメカニズムを提供する必要があります。
* prevent denial-of-service attacks caused by exploitation of the OAM message channel (for example, by forging messages to exceed a Maintenance End Point's capacity to maintain state).
* OAMメッセージチャネルの利用によるサービス拒否攻撃を防ぐ（たとえば、メッセージを超えるメンテナンスエンドポイントの能力を維持するための容量を超えて）。
* authenticate communicating end points (for example, MEPs and MIPs).
* 通信エンドポイント（MEPSとMIPSなど）を認証します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] Postel、J.、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https：//www.rfc-editor.org/info/rfc792>。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[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>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[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>.
[RFC5880] Katz、D.およびD.ワード、「双方向転送検出（BFD）」、RFC 5880、DOI 10.17487 / RFC5880、2010年6月、<https://www.rfc-editor.org/info/rfc5880>。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <https://www.rfc-editor.org/info/rfc5881>.
[RFC5881] Katz、D.およびD. Ward、IPv4およびIPv6（シングルホップ）の双方向転送検出（BFD）、RFC 5881、DOI 10.17487 / RFC5881、2010年6月、<https：///www.rfc-編集者.org / info / rfc5881>。
[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>.
[RFC5883] Katz、D.およびD.ワード、「マルチホップパスのための双方向転送検出（BFD）」、RFC 5883、DOI 10.17487 / RFC5883、2010年6月、<https://www.rfc-editor.org/info/RFC5883>。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, <https://www.rfc-editor.org/info/rfc5884>.
[RFC5884] Aggarwal、R.、Kompella、K。、Nadeau、T.、およびG.ツバメ、「MPLSラベルスイッチパス（LSPS）」（LSP）の双方向転送検出（BFD） "、RFC 5884、DOI 10.17487 / RFC5884、2010年6月<https：//www.rfc-editor.org/info/rfc5884>。
[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>.
[RFC6291] Andersson、L.、Van Helvoort、H.、Bonica、R.、Romascanu、D.、およびS. Mansfield、「IETFのOAM「頭字語を使用するためのガイドライン」、BCP 161、RFC 6291、DOI 10.17487 / RFC6291、2011年6月、<https：//www.rfc-editor.org/info/rfc6291>。
[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A., Yasukawa, S., and T. Nadeau, "Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011, <https://www.rfc-editor.org/info/rfc6425>.
[RFC6425] Saxena、S、ED。、飲み込む、G.、Ali、Z.、Farrel、A。、Yasukawa、S.、T.Nadeau「ポイントツーマルチポイントMPLSのデータプレーン障害の検出」 - LSP PINGへの拡張「RFC 6425、DOI 10.17487 / RFC6425、2011年11月、<https：//www.rfc-editor.org/info/rfc6425>。
[RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, <https://www.rfc-editor.org/info/rfc6428>.
[RFC6428] Allan、D.、ED。、G.、ED。、およびJ. Drake、ED。、「PLSトランスポートプロファイルのためのプロアクティブ接続検証、継続確認、およびリモート不良箇所」、RFC 6428、DOI10.17487 / RFC6428、2011年11月、<https：//www.rfc-editor.org/info/rfc6428>。
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC7432] Sajassi、A.、Ed。、Aggarwal、R.、Bitar、N.、Isaac、A.、Uttaro、J.、Drake、J.、およびW.HenderickX、「BGP MPLSベースのイーサネットVPN」、RFC 7432、DOI 10.17487 / RFC7432、2015年2月、<https：//www.rfc-editor.org/info/rfc7432>。
[RFC7623] Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W. Henderickx, "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623, September 2015, <https://www.rfc-editor.org/info/rfc7623>.
[RFC7623] Sajassi、A.、Ed。、Salam、S、Bitar、N.、ISAAC、A.、およびW.HenderickX、「イーサネットVPNと組み合わせたプロバイダバックボーンブリッジング（PBB-EVPN）」、RFC 7623、DOI10.17487 / RFC7623、2015年9月、<https：//www.rfc-editor.org/info/rfc7623>。
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S.、およびM. Chen、「マルチプロトコルラベルスイッチ付き（MPLS）データプレーン障害の検出」、RFC 8029、DOI 10.17487 / RFC8029、2017年3月、<https：//www.rfc-editor.org/info/rfc8029>。
[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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[IEEE-802.1Q] IEEE, "IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December 2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
[IEEE-802.1Q] IEEE、「地元の地域と首都圏のネットワークのIEEE規格 - ブリッジ＆ブリッジネットワーク」、IEEE STD 802.1Q-2014、DOI 10.1109 / IEEESTD.2014.6991462、2014年12月、<https：//doi.org/ 10.1109/ieeestd.2014.6991462>。
[IEEE-802.3] IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018, DOI 10.1109/IEEESTD.2018.8457469, August 2018, <https://doi.org/10.1109/IEEESTD.2018.8457469>.
[IEEE-802.3] IEEE、「イーサネットのためのIEEE規格」、IEEE STD 802.3-2018、DOI 10.1109 / IEEESTD.2018.8457469、<https：//doi.org/10.1109/ieeeestd.2018.8457469>。
[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>.
[RFC2544] Bradner、S.およびJ.Cquaid、「ネットワークインターコネクトデバイスのベンチマーク方法」、RFC 2544、DOI 10.17487 / RFC2544、1999年3月、<https：//www.rfc-editor.org/info/rfc2544>。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681] Almes、G.、KalidIndi、S.、およびM.Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、DOI 10.17487 / RFC2681、1999年9月、<https：//www.rfc-編集者.ORG / INFO / RFC2681>。
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, DOI 10.17487/RFC3393, November 2002, <https://www.rfc-editor.org/info/rfc3393>.
[RFC3393] Demichelis、C.およびP. Chimento、IPパフォーマンスメトリック（IPPM）のIPパケット遅延バリエーションメトリック、RFC 3393、DOI 10.17487 / RFC3393、2002年11月、<https：//www.rfc-editor.org/ info / rfc3393>。
[RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, <https://www.rfc-editor.org/info/rfc5085>.
[RFC5085] Nadeau、T.、ED。「Pseudowire仮想サーキット接続検証（VCCV）：擬似電車の制御チャネル、RFC 5085、DOI 10.17487 / RFC5085、2007年12月、<https：//www.rfc-editor.org/info/ RFC5085>。
[RFC6136] Sajassi, A., Ed. and D. Mohan, Ed., "Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework", RFC 6136, DOI 10.17487/RFC6136, March 2011, <https://www.rfc-editor.org/info/rfc6136>.
[RFC6136] Sajassi、A.、ED。D. Mohan、Ed。、「レイヤ2仮想プライベートネットワーク（L2VPN）オペレーション、管理、メンテナンス（OAM）要件とメンテナンス（OAM）要件とフレームワーク「RFC 6136、DOI 10.17487 / RFC6136、2011年3月、<https：//www.rfc-editor.org/info/rfc6136>。
[RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, June 2012, <https://www.rfc-editor.org/info/rfc6632>.
[RFC6632] Eerce、M.、ED。B. Claise、「IETFネットワーク管理規格の概要」、RFC 6632、DOI 10.17487 / RFC6632、2012年6月、<https：//www.rfc-editor.org/info/rfc6632>。
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.
[RFC6673]モートン、A。、「往復パケットロスメトリクス」、RFC 6673、DOI 10.17487 / RFC6673、2012年8月、<https://www.rfc-editor.org/info/rfc6673>。
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January 2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7679] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向遅延メトリック（IPPM）」、STD 81、RFC 7679、DOI 10.17487/ RFC7679、2016年1月、<https://www.rfc-editor.org/info/rfc7679>。
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC7680] Almes、G.、Kiristindi、S.、Zekauskas、M.、およびA.モートン、「IP性能メトリックの一方向損失測定基準（IPPM）」、STD 82、RFC 7680、DOI 10.17487/ RFC7680、2016年1月、<https://www.rfc-editor.org/info/rfc7680>。
[Y.1731] ITU-T, "Operation, administration and maintenance (OAM) functions and mechanisms for Ethernet-based networks", ITU-T Recommendation G.8013/Y.1731, August 2015.
[Y.1731] ITU-T、「操作、管理およびメンテナンス（OAM）機能とイーサネットベースネットワークのメカニズム」、2015年8月、ITU-T勧告G.8013 / Y.1731。
Acknowledgements
謝辞
The authors would like to thank the following for their review of this work and their valuable comments: David Black, Martin Duke, Xiao Min, Gregory Mirsky, Zaheduzzaman Sarker, Dave Schinazi, John Scudder, Melinda Shore, Robert Wilton, Alexander Vainshtein, Stig Venaas, and Éric Vyncke.
著者らはこの作品とその価値あるコメントのレビューに感謝したいと思います.David Black、Martin Duke、Xiao Min、Gregory Mirsky、Zaheduzzaman Sarker、Dave Schinazi、John Scudder、Melinda Shore、Robert Wilton、Alexander Vainshtein、StigVenaas、そしてéricVyncke。
Authors' Addresses
著者の住所
Samer Salam Cisco The Atrium Building, Floor 3 Weygand St. Beirut Lebanon
サマーサラムシスコザアトリウムビル、フロア3 Weygand St. Beirut Lebanon
Email: ssalam@cisco.com
Ali Sajassi Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
アリ・サジャシCisco 170 West Tasman Drive San Jose、CA 95134アメリカ
Email: sajassi@cisco.com
Sam Aldrin Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Sam Aldrin Google、Inc。1600 Amphitheater Parkway Mountain View、CA 94043アメリカ合衆国
Email: aldrin.ietf@gmail.com
John E. Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America
John E. Drake Juniper Networks 1194 N. Mathilda Ave. Sunnyvale、CA 94089アメリカ合衆国
Email: jdrake@juniper.net
Donald E. Eastlake 3rd Futurewei Technologies 2386 Panoramic Circle Apopka, FL 32703 United States of America
Donald E.イーストレイク3RDフューチャーワイテクノロジーズ2386パノラマサークルアポッカ、FL 32703アメリカ合衆国
Phone: +1-508-333-2270
Email: d3e3e3@gmail.com