[要約] RFC 7023は、MPLSとEthernetのOAMの相互運用性に関する標準化された手順を提供します。このRFCの目的は、MPLSとEthernetのネットワーク間でOAM機能を効果的に統合し、ネットワークの運用、管理、および保守を向上させることです。
Internet Engineering Task Force (IETF) D. Mohan, Ed.
Request for Comments: 7023 Nortel Networks
Category: Standards Track N. Bitar, Ed.
ISSN: 2070-1721 Verizon
A. Sajassi, Ed.
Cisco
S. Delord
Alcatel-Lucent
P. Niger
France Telecom
R. Qiu
Juniper
October 2013
MPLS and Ethernet Operations, Administration, and Maintenance (OAM) Interworking
MPLSとイーサネットの運用、管理、保守（OAM）インターワーキング
Abstract
概要
This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet pseudowires (PWs) connected in accordance with the Pseudowire Emulation Edge-to-Edge (PWE3) architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects.
このドキュメントでは、エンドツーエンドのエミュレートされたイーサネットサービスを実現するために、疑似配線エミュレーションエッジツーエッジ（PWE3）アーキテクチャに従って接続されたイーサネット接続回路（AC）と関連するイーサネット疑似配線（PW）の間の欠陥状態のマッピングを指定します。イーサネットPWおよびAC障害に関するプロバイダーエッジ（PE）の動作を標準化します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7023.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7023で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Specification of Requirements ..............................4
2. Overview ........................................................4
2.1. Reference Model and Defect Locations .......................6
2.2. Abstract Defect States .....................................6
3. Abbreviations and Terminology ...................................7
3.1. Abbreviations ..............................................7
3.2. Terminology ................................................8
4. PW Status and Defects ...........................................9
4.1. Use of Native Service (NS) Notification ....................9
4.2. Use of PW Status Notification for MPLS PSNs ...............10
4.3. Use of BFD Diagnostic Codes ...............................10
4.4. PW Defect States Entry and Exit Criteria ..................11
4.4.1. PW Receive Defect State Entry and Exit .............11
4.4.2. PW Transmit Defect State Entry and Exit ............11
5. Ethernet AC Defect States Entry and Exit Criteria ..............12
5.1. AC Receive Defect State Entry and Exit ....................12
5.2. AC Transmit Defect State Entry and Exit ...................13
6. Ethernet AC and PW Defect States Interworking ..................14
6.1. PW Receive Defect State Entry Procedures ..................14
6.2. PW Receive Defect State Exit Procedures ...................15
6.3. PW Transmit Defect State Entry Procedures .................16
6.4. PW Transmit Defect State Exit Procedures ..................16
6.5. AC Receive Defect State Entry Procedures ..................16
6.6. AC Receive Defect State Exit Procedures ...................17
6.7. AC Transmit Defect State Entry Procedures .................17
6.8. AC Transmit Defect State Exit Procedures ..................18
7. Security Considerations ........................................18
8. Acknowledgments ................................................19
9. References .....................................................19
9.1. Normative References ......................................19
9.2. Informative References ....................................20
Appendix A. Ethernet Native Service Management ....................21
RFC 6310 [RFC6310] specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuit (AC) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects for a number of technologies (e.g., Asynchronous Transfer Mode (ATM) and Frame Relay (FR)) emulated over PWs in MPLS and MPLS/IP Packet Switched Networks (PSNs). However, [RFC6310] does not describe this function for the Ethernet PW service owing to its unique characteristics.
RFC 6310 [RFC6310]は、疑似配線（PW）とエンドツーエンドのエミュレートされたサービスの接続回線（AC）間の障害状態のマッピングと通知を指定しています。 MPLSおよびMPLS / IPパケット交換ネットワークのPWを介してエミュレートされる多数のテクノロジー（非同期転送モード（ATM）やフレームリレー（FR）など）のPWおよびAC障害に関するプロバイダーエッジ（PE）の動作を標準化します。 （PSN）。ただし、[RFC6310]は、イーサネットPWサービスの独自の特性のため、この機能については説明していません。
This document specifies the mapping of defect states between ACs and associated Ethernet PWs connected in accordance with the PWE3 architecture [RFC3985] to realize an end-to-end emulated Ethernet service. This document augments the mapping of defect states between a PW and associated AC of the end-to-end emulated service in [RFC6310]. Similar to [RFC6310], the intent of this document is to standardize the behavior of PEs with respect to failures on Ethernet ACs and PWs, so that there is no ambiguity about the alarms generated and consequent actions undertaken by PEs in response to specific failure conditions.
このドキュメントでは、エンドツーエンドのエミュレートされたイーサネットサービスを実現するために、PWE3アーキテクチャ[RFC3985]に従って接続されたACと関連するイーサネットPW間の障害状態のマッピングを指定します。このドキュメントは、[RFC6310]のエンドツーエンドのエミュレートされたサービスのPWと関連するACの間の欠陥状態のマッピングを強化します。 [RFC6310]と同様に、このドキュメントの目的は、イーサネットACおよびPWの障害に関するPEの動作を標準化することです。これにより、特定の障害状態に対応してPEが生成するアラームとその結果のアクションに曖昧さがなくなります。 。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
There are a number of Operations, Administration, and Maintenance (OAM) technologies defined for Ethernet, providing various functionalities. This document covers the following Ethernet OAM mechanisms and their interworking with PW OAM mechanisms:
イーサネット用に定義されたさまざまな運用、管理、保守（OAM）テクノロジがあり、さまざまな機能を提供します。このドキュメントでは、次のイーサネットOAMメカニズムと、PW OAMメカニズムとの相互作用について説明します。
- Ethernet Link OAM [802.3] - Ethernet Local Management Interface (E-LMI) [MEF16] - Ethernet Continuity Check (CC) [CFM] [Y.1731] - Ethernet Alarm Indication Signaling (AIS) and Remote Defect Indication (RDI) [Y.1731]
- イーサネットリンクOAM [802.3]-イーサネットローカル管理インターフェース（E-LMI）[MEF16]-イーサネット継続性チェック（CC）[CFM] [Y.1731]-イーサネットアラーム表示シグナリング（AIS）およびリモート障害表示（RDI）[ Y.1731]
Ethernet Link OAM [802.3] allows some link defect states to be detected and communicated across an Ethernet link. When an Ethernet AC is an Ethernet physical port, there may be some application of Ethernet Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some Ethernet Virtual Circuit (EVC) defect states to be communicated across an Ethernet User Network Interface (UNI) where Ethernet UNI constitutes a single-hop Ethernet link (i.e., without any bridges compliant with IEEE 802.1Q/.1ad in between). There may be some application of E-LMI [MEF16] for failure notification across single-hop Ethernet ACs in certain deployments that specifically do not support IEEE Connectivity Fault Management [CFM] and/or ITU-T Y.1731 [Y.1731], simply referred to as CFM and Y.1731, respectively, in this document. Mechanisms based on Y.1731 and CFM are applicable in all types of Ethernet ACs. Ethernet Link OAM and E-LMI are optional, and their applicability is called out, where applicable.
イーサネットリンクOAM [802.3]を使用すると、一部のリンク障害状態を検出してイーサネットリンク経由で通信できます。イーサネットACがイーサネット物理ポートである場合、イーサネットリンクOAM [802.3]のいくつかのアプリケーションがあるかもしれません。さらに、E-LMI [MEF16]では、イーサネット仮想回路（EVC）の一部の障害状態をイーサネットユーザーネットワークインターフェイス（UNI）経由で通信することもできます。イーサネットUNIはシングルホップイーサネットリンクを構成します（つまり、 IEEE 802.1Q / .1adの間）。 IEEE接続障害管理[CFM]やITU-T Y.1731 [Y.1731]をサポートしていない特定の展開では、シングルホップイーサネットAC全体の障害通知にE-LMI [MEF16]が適用される場合があります。 、このドキュメントではそれぞれ単にCFMおよびY.1731と呼びます。 Y.1731およびCFMに基づくメカニズムは、すべてのタイプのイーサネットACに適用できます。イーサネットリンクOAMおよびE-LMIはオプションであり、該当する場合、それらの適用可能性が示されます。
Native service (NS) OAM may be transported transparently over the corresponding PW as user data. This is referred to as the "single emulated OAM loop mode" per [RFC6310]. For Ethernet, as an example, CFM continuity check messages (CCMs) between two Maintenance Entity Group End Points (MEPs) can be transported transparently as user data over the corresponding PW. At MEP locations, service failure is detected when CCMs are not received over an interval that is 3.5 times the local CCM transmission interval. This is one of the failure conditions detected via continuity check. MEP peers can exist between customer edge (CE) endpoints (MEPs of a given Maintenance Entity Group (MEG) reside on the CEs), between PE pairs (the MEPs of a given MEG reside on the PEs), or between the CE and PE (the MEPs of a given MEG reside on the PE and CE), as long as the MEG level nesting rules are maintained. It should be noted that Ethernet allows the definition of up to 8 MEG levels, each comprised of MEPs (Down MEPs and Up MEPs) and Maintenance Entity Group Intermediate Points (MIPs). These levels can be nested or touching. MEPs and MIPs generate and process messages in the same MEG level. Thus, in this document, when we refer to messages sent by a MEP or a MIP to a peer MEP or MIP, these MEPs and MIPs are in the same MEG level.
ネイティブサービス（NS）OAMは、対応するPWを介してユーザーデータとして透過的に転送できます。これは、[RFC6310]に従って「シングルエミュレートOAMループモード」と呼ばれています。イーサネットの場合、例として、2つのメンテナンスエンティティグループエンドポイント（MEP）間のCFM連続性チェックメッセージ（CCM）は、対応するPWを介してユーザーデータとして透過的に転送できます。 MEPロケーションでは、ローカルCCM送信間隔の3.5倍の間隔でCCMが受信されない場合、サービス障害が検出されます。これは、導通チェックによって検出された障害状態の1つです。 MEPピアは、カスタマーエッジ（CE）エンドポイント（特定のメンテナンスエンティティグループ（MEG）のMEPはCEに常駐）、PEペア（特定のMEGのMEPはPEに常駐）、またはCEとPEの間に存在できます。 （指定されたMEGのMEPはPEおよびCEに存在します）、MEGレベルのネストルールが維持されている限り。イーサネットでは、最大8つのMEGレベルを定義できます。それぞれのレベルは、MEP（ダウンMEPおよびアップMEP）とメンテナンスエンティティグループ中間ポイント（MIP）で構成されます。これらのレベルは入れ子にしたり、触れたりすることができます。 MEPとMIPは、同じMEGレベルでメッセージを生成して処理します。したがって、このドキュメントでは、MEPまたはMIPからピアMEPまたはMIPに送信されるメッセージを指す場合、これらのMEPとMIPは同じMEGレベルにあります。
When interworking two networking domains, such as native Ethernet and PWs 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 NS OAM mechanisms and the PW OAM mechanisms. In addition, scalability constraints may not allow running proactive monitoring, such as CCMs with transmission enabled, at a PE to detect the failure of an EVC across the PW domain. Thus, network-driven alarms generated upon failure detection in the NS or PW domain and their mappings to the other domain are needed. There are also cases where a PE MAY not be able to process NS OAM messages received on the PW even when such messages are defined, as in the case of Ethernet, necessitating the need for fault notification message mapping between the PW domain and the NS domain.
ネイティブイーサネットとPWなどの2つのネットワークドメインを相互作用させて、エンドツーエンドのエミュレートサービスを提供する場合、PEがNS OAMメカニズムとPW OAMメカニズムの両方をサポートしている場合でも、障害ドメインと場所を特定する必要があります。さらに、スケーラビリティの制約により、PEで伝送が有効になっているCCMなどのプロアクティブな監視を実行して、PWドメイン全体のEVCの障害を検出できない場合があります。したがって、NSまたはPWドメインでの障害検出時に生成されるネットワーク主導のアラームと、他のドメインへのそれらのマッピングが必要です。イーサネットの場合のように、PWで受信されたNS OAMメッセージが定義されていても、PEが処理できない場合があるため、PWドメインとNSドメイン間の障害通知メッセージのマッピングが必要になる場合もあります。 。
For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs) are not aware of the NS. Thus, failure detection and notification at S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and NS OAM will be required at the Terminating PEs (T-PEs) to propagate the failure notification to the EVC end points.
マルチセグメントPW（MS-PW）[RFC5659]の場合、スイッチングPE（S-PE）はNSを認識しません。したがって、S-PEでの障害検出と通知は、PW OAMメカニズムに基づいています。 PW OAMとNS OAMの間のマッピングは、障害通知をEVCエンドポイントに伝達するために、終端PE（T-PE）で必要になります。
Figure 1 was used in [RFC6310]; it is reproduced in this document as a reference to highlight defect locations.
図1は[RFC6310]で使用されました。このドキュメントでは、欠陥箇所を強調するための参照としてそれを再現しています。
ACs PSN tunnel ACs
+----+ +----+
+----+ | PE1|==================| PE2| +----+
| |---(a)---(b)..(c)......PW1..(d)..(e)..(f)---(g)---| |
| CE1| (N1) | | | | (N2) |CE2 |
| |----------|............PW2.............|----------| |
+----+ | |==================| | +----+
^ +----+ +----+ ^
| Provider Edge 1 Provider Edge 2 |
| |
|<-------------- Emulated Service ---------------->|
Customer Customer Edge 1 Edge 2
カスタマーカスタマーエッジ1エッジ2
Figure 1: PWE3 Network Defect Locations
図1：PWE3ネットワーク障害の場所
Abstract defect states are also introduced in [RFC6310]. As shown in Figure 2, this document uses the same conventions as [RFC6310]. It may be noted, however, that CE devices, shown in Figure 2, do not necessarily have to be end customer devices. These are essentially devices in client network segments that are connecting to the Packet Switched Network (PSN) for the emulated services.
[RFC6310]では、抽象的な欠陥状態も導入されています。図2に示すように、このドキュメントでは[RFC6310]と同じ規則を使用しています。ただし、図2に示すCEデバイスは、必ずしもエンドカスタマーデバイスである必要はありません。これらは基本的に、エミュレートされたサービスのためにパケット交換ネットワーク（PSN）に接続しているクライアントネットワークセグメント内のデバイスです。
+-----+
----AC receive ----->| |-----PW transmit---->
CE1 | PE1 | PE2/CE2
<---AC transmit------| |<----PW receive-----
+-----+
(arrows indicate direction of user traffic impacted by a defect)
Figure 2: Transmit and Receive Defect States and Notifications
図2：欠陥の状態と通知の送受信
The procedures outlined in this document define the entry and exit criteria for each of the four defect states with respect to Ethernet ACs and corresponding PWs; this document also defines the consequent actions that PE1 MUST support to properly interwork these defect states and corresponding notification messages between the PW domain and the native service (NS) domain. Receive defect state SHOULD have precedence over transmit defect state in terms of handling, when both transmit and receive defect states are identified simultaneously.
このドキュメントで概説されている手順は、イーサネットACおよび対応するPWに関して、4つの欠陥状態のそれぞれの開始および終了基準を定義します。このドキュメントでは、PWドメインとネイティブサービス（NS）ドメイン間でこれらの障害状態と対応する通知メッセージを適切に相互作用させるためにPE1がサポートする必要のある結果的なアクションも定義しています。送信と受信の両方の欠陥状態が同時に識別される場合、受信の欠陥状態は、処理の点で送信の欠陥状態よりも優先されるべきです。
Following is a summary of the defect states from the viewpoint of PE1 in Figure 2:
以下は、図2のPE1の観点から見た欠陥状態の要約です。
- A PW receive defect at PE1 impacts PE1's ability to receive traffic on the PW. Entry and exit criteria for the PW receive defect state are described in Section 4.4.1.
- PE1でのPW受信障害は、PWでトラフィックを受信するPE1の機能に影響を与えます。 PW受信障害状態の開始および終了基準については、セクション4.4.1で説明します。
- A PW transmit defect at PE1 impacts PE1's ability to send user traffic toward CE2. PE1 MAY be notified of a PW transmit defect via a Reverse Defect Indication from PE2, which could point to problems associated with PE2's inability to receive traffic on the PW or PE2's inability to transmit traffic on its local AC. Entry and exit criteria for the PW transmit defect state are described in Section 4.4.2.
- PE1でのPW送信障害は、CE1にユーザートラフィックを送信するPE1の機能に影響を与えます。 PE1は、PE2からのリバース障害表示を介してPW送信障害を通知される場合があります。これは、PE2がPWでトラフィックを受信できない、またはPE2がローカルACでトラフィックを送信できないことに関連する問題を示している可能性があります。 PW送信障害状態のエントリと終了の基準については、セクション4.4.2で説明します。
- An AC receive defect at PE1 impacts PE1's ability to receive user traffic from the client domain attached to PE1 via that AC. Entry and exit criteria for the AC receive defect state are described in Section 5.1.
- PE1でのAC受信障害は、そのACを介してPE1に接続されたクライアントドメインからユーザートラフィックを受信するPE1の機能に影響を与えます。 AC受信障害状態の開始および終了基準については、セクション5.1で説明します。
- An AC transmit defect at PE1 impacts PE1's ability to send user traffic on the local AC. Entry and exit criteria for the AC transmit defect state are described in Section 5.2.
- PE1でのAC送信障害は、ローカルACでユーザートラフィックを送信するPE1の機能に影響を与えます。 AC送信障害状態の開始および終了基準については、セクション5.2で説明します。
AC Attachment Circuit AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC Continuity Check CCM Continuity Check Message CE Customer Edge CV Connectivity Verification E-LMI Ethernet Local Management Interface EVC Ethernet Virtual Circuit LDP Label Distribution Protocol LoS Loss of Signal MA Maintenance Association MD Maintenance Domain ME Maintenance Entity MEG Maintenance Entity Group MEP MEG End Point MIP MEG Intermediate Point MPLS Multiprotocol Label Switching MS-PW Multi-Segment Pseudowire NS Native Service OAM Operations, Administration, and Maintenance PE Provider Edge PSN Packet Switched Network PW Pseudowire RDI Remote Defect Indication when used in the context of CCM RDI Reverse Defect Indication when used to semantically refer to defect indication in the reverse direction S-PE Switching Provider Edge T-PE Terminating Provider Edge TLV Type-Length Value VCCV Virtual Circuit Connectivity Verification
AC接続回線AISアラーム表示信号BFD双方向転送検出CC導通チェックCCM導通チェックメッセージCEカスタマーエッジCV接続検証E-LMIイーサネットローカル管理インターフェースEVCイーサネット仮想回線LDPラベル配布プロトコルLoS信号消失MAメンテナンスアソシエーションMDメンテナンスドメインMEメンテナンスエンティティMEGメンテナンスエンティティグループMEP MEGエンドポイントMIP MEG中間ポイントMPLSマルチプロトコルラベルスイッチングMS-PWマルチセグメント疑似配線NSネイティブサービスOAM運用、管理、およびメンテナンスPEプロバイダーエッジPSNパケット交換ネットワークPW疑似配線RDIリモート障害表示CCM RDIのコンテキストで、逆方向の欠陥表示を意味的に使用する場合の逆欠陥表示S-PEスイッチングプロバイダーエッジT-PEターミネーションプロバイダーエッジTLVタイプ長さ値VCCV仮想回線接続検証
This document uses the following terms with corresponding definitions:
このドキュメントでは、次の用語と対応する定義を使用しています。
- MEG Level: identifies a value in the range of 0-7 associated with an Ethernet OAM frame. MEG level identifies the span of the Ethernet OAM frame.
- MEGレベル：イーサネットOAMフレームに関連付けられた0〜7の範囲の値を識別します。 MEGレベルは、イーサネットOAMフレームのスパンを識別します。
- MEG End Point (MEP): is responsible for origination and termination of OAM frames for a given MEG.
- MEGエンドポイント（MEP）：特定のMEGのOAMフレームの開始と終了を担当します。
- MEG Intermediate Point (MIP): is located between peer MEPs and can process OAM frames but does not initiate them.
- MEG中間ポイント（MIP）：ピアMEPの間にあり、OAMフレームを処理できますが、開始しません。
- MPLS PSN: a PSN that makes use of MPLS Label-Switched Paths [RFC3031] as the tunneling technology to forward PW packets.
- MPLS PSN：PWパケットを転送するトンネリング技術としてMPLSラベルスイッチドパス[RFC3031]を利用するPSN。
- MPLS/IP PSN: a PSN that makes use of MPLS-in-IP tunneling [RFC4023] to tunnel MPLS-labeled PW packets over IP tunnels.
- MPLS / IP PSN：MPLS-in-IPトンネリング[RFC4023]を利用して、IPトンネルを介してMPLSラベル付きPWパケットをトンネリングするPSN。
Further, this document also uses the terminology and conventions used in [RFC6310].
さらに、このドキュメントでは、[RFC6310]で使用されている用語と規則も使用しています。
[RFC6310] introduces a range of defects that impact PW status. All these defect conditions are applicable for Ethernet PWs.
[RFC6310]は、PWステータスに影響を与えるさまざまな欠陥を導入しています。これらすべての障害状態は、イーサネットPWに該当します。
Similarly, there are different mechanisms described in [RFC6310] to detect PW defects, depending on the PSN type (e.g., MPLS PSN or MPLS/IP PSN). Any of these mechanisms can be used when monitoring the state of Ethernet PWs. [RFC6310] also discusses the applicability of these failure detection mechanisms.
同様に、PSNタイプ（MPLS PSNまたはMPLS / IP PSNなど）に応じて、[RFC6310]で説明されているPW欠陥を検出するためのさまざまなメカニズムがあります。これらのメカニズムは、イーサネットPWの状態を監視するときに使用できます。 [RFC6310]では、これらの障害検出メカニズムの適用性についても説明しています。
When two PEs terminate an Ethernet PW with associated MEPs, each PE can use native service (NS) OAM capabilities for failure notifications by transmitting appropriate NS OAM messages over the corresponding PW to the remote PE. Options include:
2つのPEが関連するMEPでイーサネットPWを終端する場合、各PEは、対応するPW経由で適切なNS OAMメッセージをリモートPEに送信することにより、障害通知にネイティブサービス（NS）OAM機能を使用できます。オプションは次のとおりです。
- Sending of AIS frames from the local MEP to the MEP on the remote PE when the MEP needs to convey PE receive defects and when CCM transmission is disabled.
- MEPがPE受信障害を伝達する必要があり、CCM送信が無効になっている場合の、ローカルMEPからリモートPE上のMEPへのAISフレームの送信。
- Suspending transmission of CCM frames from the local MEP to the peer MEP on the remote PE to convey PE receive defects when CCM transmission is enabled.
- CCM送信が有効な場合に、ローカルMEPからリモートPE上のピアMEPへのCCMフレームの送信を一時停止して、PE受信障害を伝達します。
- Setting the RDI bit in transmitted CCM frames when loss of CCMs from the peer MEP is detected or when the PE needs to convey PW reverse defects.
- ピアMEPからのCCMの損失が検出されたとき、またはPEがPWリバース障害を伝達する必要があるときに、送信されたCCMフレームにRDIビットを設定します。
Similarly, when the defect conditions are cleared, a PE can take one of the following actions, depending on the mechanism that was used for failure notification, to clear the defect state on the peer PE:
同様に、障害状態がクリアされると、障害通知に使用されたメカニズムに応じて、PEは次のいずれかのアクションを実行して、ピアPEの障害状態をクリアできます。
- Stopping AIS frame transmission from the local MEP to the MEP on the remote PE to clear PW receive defects.
- ローカルMEPからリモートPEのMEPへのAISフレーム送信を停止して、PW受信障害をクリアします。
- Resuming transmission of CCM frames from the local MEP to the peer MEP on the remote PE to clear PW forward defect notification when CCM transmission is enabled.
- ローカルCMPからリモートPEのピアMEPへのCCMフレームの送信を再開して、CCM送信が有効な場合にPW転送障害通知をクリアします。
- Clearing the RDI bit in transmitted CCM frames to clear PW transmit defect notification when CCM transmission is enabled.
- CCM送信が有効な場合、送信されたCCMフレームのRDIビットをクリアしてPW送信障害通知をクリアします。
RFC 4447 [RFC4447] specifies that for PWs that have been set up using the Label Distribution Protocol (LDP), the default mechanism to signal status and defects for ACs and PWs is the LDP status notification message. For PWs established over an MPLS or MPLS/IP PSN using other mechanisms (e.g., static configuration), in-band signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC and PW status and defects. Alternatively, the mechanisms defined in [RFC6478] MAY be used.
RFC 4447 [RFC4447]は、Label Distribution Protocol（LDP）を使用してセットアップされたPWの場合、ACおよびPWのステータスと障害を通知するデフォルトのメカニズムがLDPステータス通知メッセージであることを指定しています。他のメカニズム（静的構成など）を使用してMPLSまたはMPLS / IP PSNで確立されたPWの場合、VCCV-BFDを使用したインバンドシグナリング[RFC5885]を使用して、ACおよびPWのステータスと欠陥を伝える必要があります。あるいは、[RFC6478]で定義されているメカニズムを使用してもよい（MAY）。
[RFC6310] identifies the following PW defect status code points:
[RFC6310]は、次のPW欠陥ステータスコードポイントを識別します。
- Forward defect: corresponds to a logical OR of Local Attachment Circuit (ingress) Receive Fault, Local PSN-facing PW (egress) Transmit Fault, and Pseudowire Not Forwarding fault.
- 転送障害：ローカル接続回路（入力）受信障害、ローカルPSNに面したPW（出力）送信障害、および疑似配線非転送障害の論理ORに対応します。
- Reverse defect: corresponds to a logical OR of Local Attachment Circuit (egress) Transmit Fault and Local PSN-facing PW (ingress) Receive Fault.
- 逆欠陥：ローカル接続回路（出力）送信障害とローカルPSNに面したPW（入力）受信障害の論理ORに対応します。
There are also scenarios where a PE carries out PW label withdrawal instead of PW status notification. These include administrative disablement of the PW or loss of the Target LDP session with the peer PE.
PEがPWステータス通知の代わりにPWラベルの撤回を実行するシナリオもあります。これには、PWの管理者による無効化またはピアPEとのターゲットLDPセッションの損失が含まれます。
When using VCCV, the control channel type and Connectivity Verification (CV) type are agreed on between the peer PEs using the VCCV parameter field signaled as a sub-TLV of the interface parameters TLV when using FEC 129 and the interface parameter sub-TLV when using FEC 128 [RFC5085].
VCCVを使用する場合、FEC 129を使用する場合はインターフェイスパラメーターTLVのサブTLVとして通知されるVCCVパラメーターフィールドを使用し、次の場合はインターフェイスパラメーターサブTLVを使用して、ピアPE間で制御チャネルタイプと接続検証（CV）タイプが合意されます。 FEC 128 [RFC5085]を使用します。
As defined in [RFC6310], when a CV type of 0x04 or 0x10 is used to indicate that BFD is used for PW fault detection only, PW defect is detected via the BFD session while other defects, such as AC defect or PE internal defects preventing it from forwarding traffic, are communicated via an LDP status notification message in MPLS and MPLS/IP PSNs or other mechanisms in L2TP/IP PSNs.
[RFC6310]で定義されているように、CVタイプ0x04または0x10を使用してBFDがPW障害検出のみに使用されていることを示す場合、PW障害はBFDセッションを介して検出され、AC障害やPE内部障害などの他の障害は防止します。トラフィックの転送から、MPLSおよびMPLS / IP PSNのLDPステータス通知メッセージまたはL2TP / IP PSNの他のメカニズムを介して通信されます。
Similarly, when a CV type of 0x08 or 0x20 is used to indicate that BFD is used for both PW fault detection and AC/PW fault notification, all defects are signaled via BFD.
同様に、CVタイプ0x08または0x20を使用して、BFDがPW障害検出とAC / PW障害通知の両方に使用されていることを示す場合、すべての障害はBFDを介して通知されます。
As described in Section 6.2.1 of [RFC6310], PE1 will enter the PW receive defect state if one or more of the following occur:
[RFC6310]のセクション6.2.1で説明されているように、次の1つ以上が発生すると、PE1はPW受信障害状態になります。
- It receives a Forward Defect Indication (FDI) from PE2 either indicating a receive defect on the remote AC or indicating that PE2 detected or was notified of a downstream PW fault.
- PE2からForward Defect Indication（FDI）を受信します。これは、リモートACでの受信障害を示すか、PE2がダウンストリームPW障害を検出または通知したことを示します。
- It detects loss of connectivity on the PSN tunnel upstream of PE1, which affects the traffic it receives from PE2.
- PE1の上流のPSNトンネルで接続の喪失を検出します。これは、PE2から受信するトラフィックに影響します。
- It detects a loss of PW connectivity through VCCV-BFD, VCCV-Ping, or NS OAM mechanisms (i.e., CC) when enabled, which affects the traffic it receives from PE2.
- 有効にすると、VCCV-BFD、VCCV-Ping、またはNS OAMメカニズム（CC）を介したPW接続の喪失を検出します。これは、PE2から受信するトラフィックに影響します。
Note that if the PW LDP control session between the PEs fails, the PW is torn down and needs to be re-established. However, the consequent actions towards the ACs are the same as if the PW entered the receive defect state.
PE間のPW LDP制御セッションが失敗した場合、PWは破棄され、再確立する必要があることに注意してください。ただし、ACに対するその後のアクションは、PWが受信障害状態になった場合と同じです。
PE1 will exit the PW receive defect state when the following conditions are met. Note that this may result in a transition to the PW operational state or the PW transmit defect state.
次の条件が満たされると、PE1はPW受信障害状態を終了します。これにより、PW動作状態またはPW送信障害状態に遷移する可能性があることに注意してください。
- All previously detected defects have disappeared. - PE2 cleared the FDI, if applicable.
- 以前に検出された欠陥はすべて消えました。 -該当する場合、PE2はFDIをクリアしました。
PE1 will enter the PW transmit defect state if the following conditions occur:
次の条件が発生すると、PE1はPW送信障害状態になります。
- It receives a Reverse Defect Indication (RDI) from PE2 either indicating a transmit fault on the remote AC or indicating that PE2 detected or was notified of an upstream PW fault.
- リモートACの送信障害を示すか、またはPE2がアップストリームPW障害を検出したか通知されたことを示す、PE2からの逆欠陥表示（RDI）を受け取ります。
- It is not already in the PW receive defect state.
- まだPW受信障害状態ではありません。
PE1 will exit the transmit defect state if it receives an OAM message from PE2 clearing the RDI or if it has entered the PW receive defect state.
PE1は、RDIをクリアするPE2からOAMメッセージを受信した場合、またはPW受信障害状態になった場合、送信障害状態を終了します。
PE1 enters the AC receive defect state if any of the following conditions is met:
次のいずれかの条件が満たされた場合、PE1はAC受信障害状態になります。
- It detects or is notified of a physical-layer fault on the Ethernet interface. Ethernet link failure can be detected based on loss of signal (LoS) or via Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Dying Gasp" or "Critical Event" indication or via a client Signal Fail message [Y.1731].
- イーサネットインターフェイス上の物理層の障害を検出または通知します。イーサネットリンクの障害は、信号消失（LoS）に基づいて、またはイーサネットリンクOAM [802.3]を介して検出できます。クリティカルリンクイベント通知は、「Dying Gasp」または「Critical Event」を示すアップストリームノードCE1で生成されるか、クライアントのシグナルエラーメッセージを介して[Y.1731]。
- A MEP associated with the local AC receives an Ethernet AIS frame from CE1.
- ローカルACに関連付けられたMEPは、CE1からイーサネットAISフレームを受信します。
- A MEP associated with the local AC does not receive CCM frames from the peer MEP in the client domain (e.g., CE1) within an interval equal to 3.5 times the CCM transmission period configured for the MEP. This is the case when CCM transmission is enabled.
- ローカルACに関連付けられたMEPは、MEPに構成されたCCM送信期間の3.5倍に等しい間隔内で、クライアントドメイン（CE1など）のピアMEPからCCMフレームを受信しません。これは、CCM送信が有効になっている場合です。
- A CCM has an Interface Status TLV indicating interface down. Other CCM Interface Status TLVs will not be used to indicate failure or recovery from failure.
- CCMには、インターフェイスのダウンを示すインターフェイスステータスTLVがあります。他のCCMインターフェイスステータスTLVは、障害または障害からの回復を示すために使用されません。
It should be noted that when a MEP at a PE or a CE receives a CCM with the wrong MEG ID, MEP ID, or MEP level, the receiving PE or CE SHOULD treat such an event as an AC receive defect. In any case, if such events persist for 3.5 times the MEP local CCM transmission time, loss of continuity will be declared at the receiving end.
PEまたはCEのMEPが間違ったMEG ID、MEP ID、またはMEPレベルのCCMを受信した場合、受信側のPEまたはCEはそのようなイベントをAC受信障害として扱う必要があることに注意してください。いずれの場合も、そのようなイベントがMEPローカルCCM送信時間の3.5倍続く場合、受信側で連続性の喪失が宣言されます。
PE1 exits the AC receive defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions:
PE1は、障害状態になる原因となったすべての条件がクリアされると、AC受信障害状態を終了します。これには、以下のすべての条件が含まれます。
- Any physical-layer fault on the Ethernet interface, if detected or where PE1 was notified previously, is removed (e.g., loss of signal (LoS) cleared or Ethernet Link OAM [802.3] critical link event notifications with "Dying Gasp" or "Critical Event" indications cleared at an upstream node CE1).
- イーサネットインターフェイス上の物理層の障害が検出された場合、またはPE1が以前に通知された場合は削除されます（たとえば、信号消失（LoS）がクリアされた、またはイーサネットリンクOAM [802.3]クリティカルリンクイベント通知が「Dying Gasp」または「Criticalイベント」の表示が上流ノードでクリアされたCE1）。
- A MEP associated with the local AC does not receive any Ethernet AIS frame within a period indicated by previously received AIS if AIS resulted in entering the defect state.
- ローカルACに関連付けられたMEPは、AISが障害状態になった場合、以前に受信したAISが示す期間内にイーサネットAISフレームを受信しません。
- A MEP associated with the local AC and configured with CCM enabled receives a configured number (e.g., 3 or more) of consecutive CCM frames from the peer MEP on CE1 within an interval equal to a multiple (3.5) of the CCM transmission period configured for the MEP.
- ローカルACに関連付けられ、CCMが有効に構成されたMEPは、CE1のピアMEPから構成された数（3以上など）の連続したCCMフレームを、設定されたCCM送信期間の倍数（3.5）に等しい間隔内で受信します。 MEP。
- CCM indicates interface status up.
- CCMは、インターフェイスのステータスがアップであることを示します。
PE1 enters the AC transmit defect state if any of the following conditions is met:
次のいずれかの条件が満たされた場合、PE1はAC送信障害状態になります。
- It detects or is notified of a physical-layer fault on the Ethernet interface where the AC is configured (e.g., via loss of signal (LoS) or Ethernet Link OAM [802.3] critical link event notifications generated at an upstream node CE1 with "Link Fault" indication).
- これは、ACが構成されているイーサネットインターフェイスの物理層の障害を検出または通知します（たとえば、信号消失（LoS）またはイーサネットリンクOAM [802.3]を介して上流のノードCE1で生成された「リンク障害」の表示）。
- A MEP configured with CCM transmission enabled and associated with the local AC receives a CCM frame, with its RDI (Remote Defect Indication) bit set, from the peer MEP in the client domain (e.g., CE1).
- CCM送信を有効にして構成され、ローカルACに関連付けられたMEPは、クライアントドメイン（CE1など）のピアMEPから、RDI（リモート障害表示）ビットが設定されたCCMフレームを受信します。
PE1 exits the AC transmit defect state if all of the conditions that resulted in entering the defect state are cleared. This includes all of the following conditions:
PE1は、障害状態になる原因となったすべての条件がクリアされると、AC送信障害状態を終了します。これには、以下のすべての条件が含まれます。
- Any physical-layer fault on the Ethernet interface, if detected or where PE1 was notified previously, is removed (e.g., LoS cleared or Ethernet Link OAM [802.3] critical link event notifications with "Link Fault" indication cleared at an upstream node CE1).
- イーサネットインターフェイス上の物理層の障害が検出された場合、またはPE1が以前に通知された場合は、削除されます（たとえば、LoSがクリアされた、またはイーサネットリンクOAM [802.3]クリティカルリンクイベント通知に「リンク障害」の表示がアップストリームノードCE1でクリアされた） 。
- A MEP configured with CCM transmission enabled and associated with the local AC does not receive a CCM frame with the RDI bit set, having received a previous CCM frame with the RDI bit set from the peer MEP in the client domain (e.g., CE1).
- CCM送信を有効にして構成され、ローカルACに関連付けられたMEPは、RDIビットが設定されたCCMフレームを受信せず、クライアントドメインのピアMEP（CE1など）からRDIビットが設定された以前のCCMフレームを受信しました。
When the PW status on PE1 transitions from working to PW receive defect state, PE1's ability to receive user traffic from CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem.
PE1のPWステータスが動作状態からPW受信障害状態に移行すると、CE2からユーザートラフィックを受信するPE1の機能が影響を受けます。その結果、PE1はこの問題についてCE1に通知する必要があります。
Upon entry to the PW receive defect state, the following MUST be done:
PW受信障害状態に入ると、次のことを実行する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is not enabled, the MEP associated with the AC MUST transmit AIS frames periodically to the peer MEP in the client domain (e.g., on CE1) based on the configured AIS transmission period.
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっていない場合、ACに関連付けられたMEPは、構成されたAISに基づいて、クライアントドメイン（CE1など）のピアMEPに定期的にAISフレームを送信する必要があります送信期間。
- If PE1 is configured with a Down MEP associated with the local AC, CCM transmission is enabled, and the MEP associated with the AC is configured to support the Interface Status TLV in CCMs, the MEP associated with the AC MUST transmit CCM frames with the Interface Status TLV as being Down to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効であり、ACに関連付けられたMEPがCCMのインターフェイスステータスTLVをサポートするように構成されている場合、ACに関連付けられたMEPはインターフェイスでCCMフレームを送信する必要がありますTLVがクライアントドメインのピアMEPにダウンしている（CE1など）。
- If PE1 is configured with a Down MEP associated with the local AC, CCM transmission is enabled, and the MEP associated with the AC is configured to not support the Interface Status TLV in CCMs, the MEP associated with the AC MUST stop transmitting CCM frames to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効であり、ACに関連付けられたMEPがCCMのインターフェイスステータスTLVをサポートしないように構成されている場合、ACに関連付けられたMEPはCCMフレームの送信を停止する必要がありますクライアントドメイン（CE1など）のピアMEP。
- If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI is used for failure notification, PE1 MUST transmit an E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that the PW is Not Active.
- PE1がCE1でE-LMI [MEF16]を実行するように構成されており、E-LMIが障害通知に使用されている場合、PE1は、PWがアクティブではないことを示すレポートタイプシングルEVC非同期ステータスでE-LMI非同期ステータスメッセージを送信する必要があります。
Further, when PE1 enters the receive defect state, it MUST assume that PE2 has no knowledge of the defect and MUST send a reverse defect failure notification to PE2. For MPLS PSN or MPLS/IP PSN, this is either done via a PW status notification message indicating a reverse defect or done via a VCCV-BFD diagnostic code of reverse defect if a VCCV CV type of 0x08 or 0x20 had been negotiated. When a native service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1.
さらに、PE1が欠陥の受信状態に入ると、PE2は欠陥を認識していないと想定し、逆欠陥エラー通知をPE2に送信する必要があります。 MPLS PSNまたはMPLS / IP PSNの場合、これは、逆方向不良を示すPWステータス通知メッセージを介して行われるか、またはVCCV CVタイプ0x08または0x20がネゴシエートされている場合は逆方向不良のVCCV-BFD診断コードを介して行われます。 PE1でネイティブサービスOAMメカニズムがサポートされている場合、セクション4.1で指定されているように、NS OAM通知も使用できます。
If PW receive defect state is entered as a result of a forward defect notification from PE2 or via loss of control adjacency, no additional action is needed since PE2 is expected to be aware of the defect.
PE2が障害を認識していることが期待されているため、PE2からのフォワード障害通知の結果として、または制御隣接関係の喪失によってPW受信障害状態になった場合、追加のアクションは必要ありません。
When the PW status transitions from PW receive defect state to working, PE1's ability to receive user traffic from CE2 is restored. As a result, PE1 needs to cease defect notification to CE1 by performing the following:
PWステータスがPW受信障害状態から動作状態に遷移すると、CE2からユーザートラフィックを受信するPE1の機能が復元されます。その結果、PE1は次を実行してCE1への障害通知を停止する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is not enabled, the MEP associated with the AC MUST stop transmitting AIS frames towards the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっていない場合、ACに関連付けられたMEPは、クライアントドメインのピアMEP（CE1など）へのAISフレームの送信を停止する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC, CCM transmission is enabled, and the MEP associated with the AC is configured to support the Interface Status TLV in CCMs, the MEP associated with the AC MUST transmit CCM frames with the Interface Status TLV as being Up to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効であり、ACに関連付けられたMEPがCCMのインターフェイスステータスTLVをサポートするように構成されている場合、ACに関連付けられたMEPはインターフェイスでCCMフレームを送信する必要がありますクライアントドメイン（CE1など）のピアMEPが稼働中であるというTLVのステータス。
- If PE1 is configured with a Down MEP associated with the local AC, CCM transmission is enabled, and the MEP associated with the AC is configured to not support the Interface Status TLV in CCMs, the MEP associated with the AC MUST resume transmitting CCM frames to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効であり、ACに関連付けられたMEPがCCMのインターフェイスステータスTLVをサポートしないように構成されている場合、ACに関連付けられたMEPはCCMフレームの送信を再開する必要がありますクライアントドメイン（CE1など）のピアMEP。
- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 MUST transmit an E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that the PW is Active.
- PE1がCE1でE-LMI [MEF16]を実行するように構成されており、E-LMIが障害通知に使用されている場合、PE1は、PWがアクティブであることを示すレポートタイプシングルEVC非同期ステータスでE-LMI非同期ステータスメッセージを送信する必要があります。
Further, if the PW receive defect was explicitly detected by PE1, it MUST now notify PE2 about clearing of receive defect state by clearing the reverse defect notification. For PW over MPLS PSN or MPLS/IP PSN, this is either done via a PW status message indicating a working state or done via a VCCV-BFD diagnostic code if a VCCV CV type of 0x08 or 0x20 had been negotiated. When a native service OAM mechanism is supported on PE, it can also clear the NS OAM notification as specified in Section 4.1.
さらに、PW受信障害がPE1によって明示的に検出された場合、リバース障害通知をクリアすることにより、PE2に受信障害状態のクリアについて通知する必要があります。 PW over MPLS PSNまたはMPLS / IP PSNの場合、これは、動作状態を示すPWステータスメッセージを介して行われるか、VCCV CVタイプ0x08または0x20がネゴシエートされている場合は、VCCV-BFD診断コードを介して行われます。 PEでネイティブサービスOAMメカニズムがサポートされている場合、セクション4.1で指定されているように、NS OAM通知をクリアすることもできます。
If PW receive defect was established via notification from PE2 or via loss of control adjacency, no additional action is needed since PE2 is expected to be aware of the defect clearing.
PW受信障害がPE2からの通知または制御の隣接関係の喪失によって確立された場合、PE2は障害のクリアを認識していることが期待されるため、追加のアクションは必要ありません。
When the PW status transitions from working to PW transmit defect state, PE1's ability to transmit user traffic to CE2 is impacted. As a result, PE1 needs to notify CE1 about this problem.
PWステータスが動作状態からPW送信障害状態に移行すると、ユーザートラフィックをCE2に送信するPE1の機能が影響を受けます。その結果、PE1はこの問題についてCE1に通知する必要があります。
Upon entry to the PW transmit defect state, the following MUST be done:
PW送信障害状態に入ると、次のことを実行する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC MUST set the RDI bit in transmitted CCM frames or send a status TLV with interface down to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっている場合、ACに関連付けられたMEPは、送信されたCCMフレームでRDIビットを設定するか、クライアントドメインのピアMEPにインターフェイスを備えたステータスTLVを送信する必要があります（例えば、CE1）。
- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is used for fault notification, PE1 MUST transmit an E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that the PW is Not Active.
- PE1がCE1でE-LMI [MEF16]を実行するように構成されており、障害通知にE-LMIが使用されている場合、PE1は、PWがアクティブではないことを示すレポートタイプシングルEVC非同期ステータスでE-LMI非同期ステータスメッセージを送信する必要があります。
- If the PW failure was detected by PE1 without receiving a reverse defect notification from PE2, PE1 MUST assume PE2 has no knowledge of the defect and MUST notify PE2 by sending an FDI.
- PE2からの逆欠陥通知を受信せずにPW障害がPE1によって検出された場合、PE1はPE2が欠陥を認識していないと想定し、FDIを送信してPE2に通知する必要があります。
When the PW status transitions from PW transmit defect state to working, PE1's ability to transmit user traffic to CE2 is restored. As a result, PE1 needs to cease defect notifications to CE1 and perform the following:
PWステータスがPW送信障害状態から動作状態に移行すると、ユーザートラフィックをCE2に送信するPE1の機能が復元されます。その結果、PE1はCE1への障害通知を停止し、次を実行する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC MUST clear the RDI bit in the transmitted CCM frames to the peer MEP or send a status TLV with interface up to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっている場合、ACに関連付けられたMEPは、送信されたCCMフレームのRDIビットをピアMEPにクリアするか、ピアまでのインターフェイスを持つステータスTLVを送信する必要がありますクライアントドメインのMEP（たとえば、CE1）。
- If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 MUST transmit an E-LMI asynchronous STATUS message with report type Single EVC Asynchronous Status indicating that the PW is Active.
- PE1がCE1でE-LMI [MEF16]を実行するように構成されている場合、PE1は、PWがアクティブであることを示すレポートタイプシングルEVC非同期ステータスでE-LMI非同期ステータスメッセージを送信する必要があります。
- PE1 MUST clear the FDI to PE2, if applicable.
- PE1は、該当する場合、PE2へのFDIをクリアする必要があります。
When AC status transitions from working to AC receive defect state, PE1's ability to receive user traffic from CE1 is impacted. As a result, PE1 needs to notify PE2 and CE1 about this problem.
ACステータスが動作状態からAC受信障害状態に移行すると、CE1からユーザートラフィックを受信するPE1の機能が影響を受けます。その結果、PE1はこの問題についてPE2とCE1に通知する必要があります。
If the AC receive defect is detected by PE1, it MUST notify PE2 in the form of a forward defect notification.
AC受信障害がPE1によって検出された場合、フォワード障害通知の形式でPE2に通知する必要があります。
When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS/IP PSN, a forward defect notification is either done via a PW status message indicating a forward defect or done via a VCCV-BFD diagnostic code of forward defect if a VCCV CV type of 0x08 or 0x20 had been negotiated.
NS OAMがPE1でサポートされていない場合、PW over MPLS PSNまたはMPLS / IP PSNでは、転送障害通知は、転送障害を示すPWステータスメッセージを介して行われるか、または次の場合に転送障害のVCCV-BFD診断コードを介して行われます。 0x08または0x20のVCCV CVタイプがネゴシエートされました。
When a native service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1.
PE1でネイティブサービスOAMメカニズムがサポートされている場合、セクション4.1で指定されているように、NS OAM通知も使用できます。
In addition to the above actions, PE1 MUST perform the following:
上記のアクションに加えて、PE1は以下を実行する必要があります。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC MUST set the RDI bit in transmitted CCM frames.
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっている場合、ACに関連付けられたMEPは送信されたCCMフレームでRDIビットを設定する必要があります。
When AC status transitions from AC receive defect state to working, PE1's ability to receive user traffic from CE1 is restored. As a result, PE1 needs to cease defect notifications to PE2 and CE1 and perform the following:
ACステータスがAC受信障害状態から動作状態に移行すると、CE1からユーザートラフィックを受信するPE1の機能が復元されます。その結果、PE1はPE2およびCE1への障害通知を停止し、以下を実行する必要があります。
- When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS/IP PSN, the forward defect notification is cleared via a PW status message indicating a working state or via a VCCV-BFD diagnostic code if a VCCV CV type of 0x08 or 0x20 had been negotiated.
- PE1でNS OAMがサポートされていない場合、PW over MPLS PSNまたはMPLS / IP PSNでは、動作中の状態を示すPWステータスメッセージを介して、またはVCCV CVタイプが0x08の場合はVCCV-BFD診断コードを介して転送障害通知がクリアされます。または0x20がネゴシエートされました。
- When a native service OAM mechanism is supported on PE1, PE1 clears the NS OAM notification as specified in Section 4.1.
- PE1でネイティブサービスOAMメカニズムがサポートされている場合、PE1はセクション4.1で指定されているようにNS OAM通知をクリアします。
- If PE1 is configured with a Down MEP associated with the local AC and CCM transmission is enabled, the MEP associated with the AC MUST clear the RDI bit in transmitted CCM frames to the peer MEP in the client domain (e.g., on CE1).
- PE1がローカルACに関連付けられたダウンMEPで構成され、CCM送信が有効になっている場合、ACに関連付けられたMEPは、クライアントドメインのピアMEP（CE1など）に送信されたCCMフレームのRDIビットをクリアする必要があります。
When AC status transitions from working to AC transmit defect state, PE1's ability to transmit user traffic to CE1 is impacted. As a result, PE1 needs to notify PE2 about this problem.
ACステータスが動作状態からAC送信障害状態に移行すると、ユーザートラフィックをCE1に送信するPE1の機能が影響を受けます。その結果、PE1はこの問題についてPE2に通知する必要があります。
If the AC transmit defect is detected by PE1, it MUST notify PE2 in the form of a reverse defect notification.
AC送信障害がPE1によって検出された場合、逆障害通知の形式でPE2に通知する必要があります。
When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS/IP PSN, a reverse defect notification is either done via a PW status message indicating a reverse defect or done via a VCCV-BFD diagnostic code of reverse defect if a VCCV CV type of 0x08 or 0x20 had been negotiated.
PE1でNS OAMがサポートされていない場合、PW over MPLS PSNまたはMPLS / IP PSNで、逆欠陥通知は、逆欠陥を示すPWステータスメッセージを介して行われるか、または0x08または0x20のVCCV CVタイプがネゴシエートされました。
When a native service OAM mechanism is supported on PE1, it can also use the NS OAM notification as specified in Section 4.1.
PE1でネイティブサービスOAMメカニズムがサポートされている場合、セクション4.1で指定されているように、NS OAM通知も使用できます。
When AC status transitions from AC transmit defect state to working, PE1's ability to transmit user traffic to CE1 is restored. As a result, PE1 MUST clear the reverse defect notification to PE2.
ACステータスがAC送信障害状態から動作状態に移行すると、ユーザートラフィックをCE1に送信するPE1の機能が復元されます。その結果、PE1はPE2への逆方向障害通知をクリアする必要があります。
When NS OAM is not supported on PE1, in PW over MPLS PSN or MPLS/IP PSN, the reverse defect notification is cleared via a PW status message indicating a working state or via a VCCV-BFD diagnostic code if a VCCV CV type of 0x08 or 0x20 had been negotiated.
PE1でNS OAMがサポートされていない場合、PW over MPLS PSNまたはMPLS / IP PSNで、動作状態を示すPWステータスメッセージを介して、またはVCCV CVタイプが0x08の場合はVCCV-BFD診断コードを介して、逆方向障害通知がクリアされます。または0x20がネゴシエートされました。
When a native service OAM mechanism is supported on PE1, PE1 can clear NS OAM notification as specified in Section 4.1.
PE1でネイティブサービスOAMメカニズムがサポートされている場合、PE1はセクション4.1で指定されているようにNS OAM通知をクリアできます。
The OAM interworking mechanisms described in this document do not change the security functions inherent in the actual messages. All generic security considerations applicable to PW traffic specified in Section 10 of [RFC3985] are applicable to NS OAM messages transferred inside the PW.
このドキュメントで説明されているOAMインターワーキングメカニズムは、実際のメッセージに固有のセキュリティ機能を変更しません。 [RFC3985]のセクション10で指定されたPWトラフィックに適用されるすべての一般的なセキュリティの考慮事項は、PW内で転送されるNS OAMメッセージに適用されます。
The security considerations in Section 10 of [RFC5085] for VCCV apply to the OAM messages thus transferred. Security considerations applicable to the PWE3 control protocol as described in Section 8.2 of [RFC4447] apply to OAM indications transferred using the LDP status message.
[RFC5085]のセクション10にあるVCCVのセキュリティに関する考慮事項は、転送されたOAMメッセージに適用されます。 [RFC4447]のセクション8.2で説明されているPWE3制御プロトコルに適用されるセキュリティの考慮事項は、LDPステータスメッセージを使用して転送されるOAMインジケーションに適用されます。
Since the mechanisms of this document enable propagation of OAM messages and fault conditions between native service networks and PSNs, continuity of the end-to-end service depends on a trust relationship between the operators of these networks. Security considerations for such scenarios are discussed in Section 7 of [RFC5254].
このドキュメントのメカニズムにより、ネイティブサービスネットワークとPSN間のOAMメッセージと障害状態の伝播が可能になるため、エンドツーエンドサービスの継続性は、これらのネットワークのオペレーター間の信頼関係に依存します。このようなシナリオのセキュリティに関する考慮事項は、[RFC5254]のセクション7で説明されています。
The authors are thankful to Samer Salam, Matthew Bocci, Yaakov Stein, David Black, Lizhong Jin, Greg Mirsky, Huub van Helvoort, and Adrian Farrel for their valuable input and comments.
著者は、貴重な意見やコメントを提供してくれたSamer Salam、Matthew Bocci、Yaakov Stein、David Black、Lizhong Jin、Greg Mirsky、Huub van Helvoort、Adrian Farrelに感謝しています。
[802.3] IEEE, "Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (Clause 57 for Operations, Administration, and Maintenance)", IEEE Std 802.3-2005, December 2005.
[802.3] IEEE、「Part 3：Carrier Sense Multiple Access with Collision Detection（CSMA / CD）Access Method and Physical Layer Specifications（Clause 57 for Operations、Administration、and Maintenance）」、IEEE Std 802.3-2005、2005年12月。
[CFM] IEEE, "Connectivity Fault Management clause of IEEE 802.1Q", IEEE 802.1Q, 2013.
[CFM] IEEE、「IEEE 802.1Qの接続障害管理条項」、IEEE 802.1Q、2013。
[MEF16] Metro Ethernet Forum, "Ethernet Local Management Interface (E-LMI)", Technical Specification MEF16, January 2006.
[MEF16] Metro Ethernet Forum、「Ethernet Local Management Interface（E-LMI）」、技術仕様MEF16、2006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T.、Ed。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、2007年12月。
[RFC5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[RFC5885]ナドー、T。、編、およびC.ピニャタロ、編、「疑似配線仮想回線接続検証（VCCV）のための双方向転送検出（BFD）」、RFC 5885、2010年6月。
[RFC6310] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., Nadeau, T., and Y(J). Stein, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping", RFC 6310, July 2011.
[RFC6310] Aissaoui、M.、Busschbach、P.、Martini、L.、Morrow、M.、Nadeau、T.、and Y（J）。 Stein、「Pseudowire（PW）Operations、Administration、and Maintenance（OAM）Message Mapping」、RFC 6310、2011年7月。
[RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", RFC 6478, May 2012.
[RFC6478]マティーニ、L。、スワロー、G。、ヘロン、G。、およびM.ボッチ、「静的な疑似配線の疑似配線ステータス」、RFC 6478、2012年5月。
[Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based networks", ITU-T Y.1731, July 2011.
[Y.1731] ITU-T、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU-T Y.1731、2011年7月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E。、ヴィスワナサン、A。、およびR.キャロン、「マルチプロトコルラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、Ed。およびP. Pate、Ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）Architecture」、RFC 3985、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、2005年3月。
[RFC5254] Bitar, N., Ed., Bocci, M., Ed., and L. Martini, Ed., "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge (PWE3)", RFC 5254, October 2008.
[RFC5254] Bitar、N.、Ed。、Bocci、M.、Ed。、and L. Martini、Ed。、 "Requirements for Multi-Segment Pseudowire Emulation Edge-to-Edge（PWE3）"、RFC 5254、October 2008 。
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[RFC5659] Bocci、M.およびS. Bryant、「An-Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge」、RFC 5659、2009年10月。
This appendix is informative.
この付録は参考情報です。
Ethernet OAM mechanisms are broadly classified into two categories: Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731 [Y.1731] provides coverage for both FM and PM while IEEE CFM [CFM] provides coverage for a subset of FM functions.
イーサネットOAMメカニズムは、Fault Management（FM）とPerformance Monitoring（PM）の2つのカテゴリに大別されます。 ITU-T Y.1731 [Y.1731]はFMとPMの両方に対応し、IEEE CFM [CFM]はFM機能のサブセットに対応します。
Ethernet OAM also introduces the concept of a Maintenance Entity (ME), which is used to identify the entity that needs to be managed. An ME is inherently a point-to-point association. However, in the case of a multipoint association, a Maintenance Entity Group (MEG) consisting of different MEs is used. IEEE 802.1 uses the concept of a Maintenance Association (MA), which is used to identify both point-to-point and multipoint associations. Each MEG/MA consists of MEG End Points (MEPs) that are responsible for originating OAM frames. In between the MEPs, there can also be MEG Intermediate Points (MIPs) that do not originate OAM frames but do respond to OAM frames from MEPs.
イーサネットOAMは、管理する必要があるエンティティを識別するために使用されるメンテナンスエンティティ（ME）の概念も導入します。 MEは本質的にポイントツーポイントアソシエーションです。ただし、マルチポイントアソシエーションの場合、異なるMEで構成されるメンテナンスエンティティグループ（MEG）が使用されます。 IEEE 802.1はメンテナンスアソシエーション（MA）の概念を使用します。MAは、ポイントツーポイントアソシエーションとマルチポイントアソシエーションの両方を識別するために使用されます。各MEG / MAは、OAMフレームの発信を担当するMEGエンドポイント（MEP）で構成されています。 MEPの間に、OAMフレームを生成しないがMEPからのOAMフレームに応答するMEG中間ポイント（MIP）が存在する場合もあります。
Ethernet OAM allows for hierarchical Maintenance Entities to allow for simultaneous end-to-end and segment monitoring. This is achieved by having a provision of up to 8 MEG levels (MD levels), where each MEP or MIP is associated with a specific MEG level.
イーサネットOAMでは、階層的なメンテナンスエンティティを使用して、エンドツーエンドとセグメントの同時監視を行うことができます。これは、各MEPまたはMIPが特定のMEGレベルに関連付けられている最大8つのMEGレベル（MDレベル）を提供することで実現されます。
It is important to note that the FM mechanisms common to both IEEE CFM [CFM] and ITU-T Y.1731 [Y.1731] are completely compatible.
IEEE CFM [CFM]とITU-T Y.1731 [Y.1731]の両方に共通のFMメカニズムは完全に互換性があることに注意することが重要です。
The common FM mechanisms include:
一般的なFMメカニズムは次のとおりです。
1) Continuity Check Message (CCM)
1）導通チェックメッセージ（CCM）
2) Loopback Message (LBM) and Loopback Reply (LBR)
2）ループバックメッセージ（LBM）およびループバック応答（LBR）
3) Link Trace Message (LTM) and Link Trace Reply (LTR)
3）リンクトレースメッセージ（LTM）およびリンクトレース応答（LTR）
CCMs are used for fault detection, including misconnections and misconfigurations. Typically, CCMs are sent as multicast frames or unicast frames and also allow RDI notifications. LBM and LBR are used to perform fault verification, while also allowing for MTU verification and CIR/EIR (Committed Information Rate / Excess Information Rate) measurements. LTM and LTR can be used for discovering the path traversed between a MEP and another target MIP/MEP in the same MEG. LTM and LTR also allow for fault localization.
CCMは、誤接続や誤設定などの障害検出に使用されます。通常、CCMはマルチキャストフレームまたはユニキャストフレームとして送信され、RDI通知も許可します。 LBMとLBRは、障害検証を実行するために使用されますが、MTU検証とCIR / EIR（認定情報レート/超過情報レート）測定も可能です。 LTMとLTRは、MEPと、同じMEG内の別のターゲットMIP / MEPの間を通過するパスを検出するために使用できます。 LTMとLTRでは、障害の特定も可能です。
In addition, ITU-T Y.1731 [Y.1731] also specifies the following FM functions:
さらに、ITU-T Y.1731 [Y.1731]では、次のFM機能も指定されています。
4) Alarm Indication Signal (AIS)
4）アラーム表示信号（AIS）
AIS allows for fault notification to downstream and upstream nodes.
AISでは、ダウンストリームノードとアップストリームノードへの障害通知が可能です。
Further, ITU-T Y.1731 [Y.1731] also specifies the following PM functions:
さらに、ITU-T Y.1731 [Y.1731]では、次のPM機能も指定されています。
5) Loss Measurement Message (LMM) and Loss Measurement Reply (LMR)
5）損失測定メッセージ（LMM）および損失測定応答（LMR）
6) Delay Measurement Message (DMM) and Delay Measurement Reply (DMR)
6）遅延測定メッセージ（DMM）および遅延測定応答（DMR）
7) 1-way Delay Measurement (1DM)
7）1ウェイ遅延測定（1DM）
While LMM and LMR are used to measure Frame Loss Ratio (FLR), DMM and DMR are used to measure single-ended (aka two-way) Frame Delay (FD) and Frame Delay Variation (FDV, also known as Jitter). 1DM can be used for dual-ended (aka one-way) FD and FDV measurements.
LMMとLMRはフレーム損失率（FLR）の測定に使用されますが、DMMとDMRはシングルエンド（別名双方向）フレーム遅延（FD）とフレーム遅延変動（FDV、別名ジッター）の測定に使用されます。 1DMは、デュアルエンド（別名片方向）FDおよびFDV測定に使用できます。
Authors' Addresses
著者のアドレス
Dinesh Mohan (editor) Nortel Networks EMail: dinmohan@hotmail.com
Dinesh Mohan（編集者）Nortel Networks Eメール：dinmohan@hotmail.com
Nabil Bitar (editor) Verizon 60 Sylvan Road Waltham, MA 02145 United States EMail: nabil.n.bitar@verizon.com
Nabil Bitar（編集者）Verizon 60 Sylvan Road Waltham、MA 02145アメリカ合衆国Eメール：nabil.n.bitar@verizon.com
Ali Sajassi (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 United States EMail: sajassi@cisco.com
Ali Sajassi（編集者）Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ合衆国Eメール：sajassi@cisco.com
Simon Delord Alcatel-Lucent 215 Spring Street Melbourne Australia EMail: simon.delord@gmail.com
サイモンデロードアルカテルルーセント215スプリングストリートメルボルンオーストラリアEメール：simon.delord@gmail.com
Philippe Niger France Telecom 2 av. Pierre Marzin 22300 Lannion France EMail: philippe.niger@orange.com
フィリップニジェールフランステレコム2 av。 Pierre Marzin 22300 Lannion Franceメール：philippe.niger@orange.com
Ray Qiu Juniper 1194 North Mathilda Avenue Sunnyvale, CA 94089 United States EMail: rqiu@juniper.net
Ray Qiu Juniper 1194 North Mathilda Avenue Sunnyvale、CA 94089アメリカ合衆国Eメール：rqiu@juniper.net