[要約] RFC 6136は、Layer 2 Virtual Private Network (L2VPN)の運用、管理、および保守 (OAM) の要件とフレームワークに関するものです。このRFCの目的は、L2VPNのOAM機能の要件を定義し、適切なフレームワークを提供することです。
Internet Engineering Task Force (IETF) A. Sajassi, Ed.
Request for Comments: 6136 Cisco
Category: Informational D. Mohan, Ed.
ISSN: 2070-1721 Nortel
March 2011
Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM) Requirements and Framework
レイヤー2仮想プライベートネットワーク（L2VPN）運用、管理、およびメンテナンス（OAM）要件とフレームワーク
Abstract
概要
This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operations, Administration, and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, pseudowires (PWs), and Packet Switched Network (PSN) tunnels. This document is intended to identify OAM requirements for L2VPN services, i.e., Virtual Private LAN Service (VPLS), Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS). Furthermore, if L2VPN service OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified.
このドキュメントは、レイヤー2仮想プライベートネットワーク（L2VPN）操作、管理、およびメンテナンス（OAM）のフレームワークと要件を提供します。OAMフレームワークは、L2VPNサービス、プソイドワイヤ（PWS）、およびパケットスイッチ付きネットワーク（PSN）トンネル全体にOAM層を提供することを目的としています。このドキュメントは、L2VPNサービスのOAM要件、つまり仮想プライベートLANサービス（VPLS）、仮想プライベートワイヤサービス（VPWS）、およびIPのみのLANサービス（IPLS）を特定することを目的としています。さらに、L2VPNサービスOAM要件がPW OAMおよび/またはPSN OAMに特定の要件を課している場合、これらの特定のPWおよび/または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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6136.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6136で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Specification of Requirements ..............................6
1.2. Relationship with Other OAM Work ...........................6
2. Terminology .....................................................7
3. L2VPN Services and Networks .....................................7
4. L2VPN OAM Framework .............................................8
4.1. OAM Layering ...............................................8
4.2. OAM Domains ................................................9
4.3. MEPs and MIPs .............................................10
4.4. MEP and MIP Identifiers ...................................11
5. OAM Framework for VPLS .........................................11
5.1. VPLS as Service/Network ...................................11
5.1.1. VPLS as Bridged LAN Service ........................11
5.1.2. VPLS as a Network ..................................12
5.1.3. VPLS as (V)LAN Emulation ...........................12
5.2. VPLS OAM ..................................................13
5.2.1. VPLS OAM Layering ..................................13
5.2.2. VPLS OAM Domains ...................................14
5.2.3. VPLS MEPs and MIPs .................................15
5.2.4. VPLS MEP and MIP Identifiers .......................16
6. OAM Framework for VPWS .........................................17
6.1. VPWS as Service ...........................................17
6.2. VPWS OAM ..................................................18
6.2.1. VPWS OAM Layering ..................................18
6.2.2. VPWS OAM Domains ...................................19
6.2.3. VPWS MEPs and MIPs .................................21
6.2.4. VPWS MEP and MIP Identifiers .......................23
7. VPLS OAM Requirements ..........................................23
7.1. Discovery .................................................24
7.2. Connectivity Fault Management .............................24
7.2.1. Connectivity Fault Detection .......................24
7.2.2. Connectivity Fault Verification ....................24
7.2.3. Connectivity Fault Localization ....................24
7.2.4. Connectivity Fault Notification and Alarm
Suppression ........................................25
7.3. Frame Loss ................................................25
7.4. Frame Delay ...............................................25
7.5. Frame Delay Variation .....................................26
7.6. Availability ..............................................26
7.7. Data Path Forwarding ......................................26
7.8. Scalability ...............................................27
7.9. Extensibility .............................................27
7.10. Security .................................................27
7.11. Transport Independence ...................................28
7.12. Application Independence .................................28
8. VPWS OAM Requirements ..........................................28
8.1. Discovery .................................................29
8.2. Connectivity Fault Management .............................29
8.2.1. Connectivity Fault Detection .......................29
8.2.2. Connectivity Fault Verification ....................29
8.2.3. Connectivity Fault Localization ....................29
8.2.4. Connectivity Fault Notification and Alarm
Suppression ........................................30
8.3. Frame Loss ................................................30
8.4. Frame Delay ...............................................30
8.5. Frame Delay Variation .....................................31
8.6. Availability ..............................................31
8.7. Data Path Forwarding ......................................32
8.8. Scalability ...............................................32
8.9. Extensibility .............................................32
8.10. Security .................................................32
8.11. Transport Independence ...................................33
8.12. Application Independence .................................33
8.13. Prioritization ...........................................34
9. VPLS (V)LAN Emulation OAM Requirements .........................34
9.1. Partial-Mesh of PWs .......................................34
9.2. PW Fault Recovery .........................................34
9.3. Connectivity Fault Notification and Alarm Suppression .....35
10. OAM Operational Scenarios .....................................35
10.1. VPLS OAM Operational Scenarios ...........................36
11. Security Considerations .......................................37
12. Contributors ..................................................38
13. Acknowledgements ..............................................38
14. References ....................................................38
14.1. Normative References .....................................38
14.2. Informative References ...................................39
Appendix A. Alternate Management Models ...........................41
A.1. Alternate Model 1 (Minimal OAM) ..............................41
A.2. Alternate Model 2 (Segment OAM Interworking) .................41
This document provides framework and requirements for Layer 2 Virtual Private Network (L2VPN) Operation, Administration, and Maintenance (OAM).
このドキュメントは、レイヤー2仮想プライベートネットワーク（L2VPN）操作、管理、およびメンテナンス（OAM）のフレームワークと要件を提供します。
The scope of OAM for any service and/or transport/network infrastructure technologies can be very broad in nature. OSI has defined the following five generic functional areas commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault Management, b) Configuration Management, c) Accounting Management, d) Performance Management, and e) Security Management.
あらゆるサービスおよび/またはトランスポート/ネットワークインフラストラクチャテクノロジーのOAMの範囲は、本質的に非常に広範です。OSIは、一般に「FCAP」[NMスタンダード]として省略されている次の5つの一般的な機能領域を定義しました。A）障害管理、b）構成管理、c）会計管理、d）パフォーマンス管理、およびセキュリティ管理。
This document focuses on the Fault and Performance Management aspects. Other functional aspects of FCAPS are for further study.
このドキュメントは、障害とパフォーマンス管理の側面に焦点を当てています。FCAPの他の機能的側面は、さらなる研究のためです。
Fault Management can typically be viewed in terms of the following categories:
障害管理は、通常、次のカテゴリの観点から見ることができます。
- Fault Detection
- 障害検出
- Fault Verification
- 障害検証
- Fault Isolation
- 誤った隔離
- Fault Notification and Alarm Suppression
- 障害通知とアラーム抑制
- Fault Recovery
- 障害回復
Fault detection deals with mechanism(s) that can detect both hard failures, such as link and device failures, and soft failures, such as software failure, memory corruption, misconfiguration, etc. Typically, a lightweight protocol is desirable to detect the fault and thus it would be prudent to verify the fault via a fault verification mechanism before taking additional steps in isolating the fault. After verifying that a fault has occurred along the data path, it is important to be able to isolate the fault to the level of a given device or link. Therefore, a fault isolation mechanism is needed in Fault Management. A fault notification mechanism can be used in conjunction with a fault detection mechanism to notify the devices upstream and downstream to the fault detection point. For example, when there is a client/server relationship between two layered networks, fault detection at the server layer may result in the following fault notifications:
障害検出は、リンクやデバイスの障害などの硬い障害と、ソフトウェア障害、メモリの破損、誤解などのソフト障害の両方を検出できるメカニズムを扱います。通常、軽量プロトコルは障害と障害を検出することが望ましいですしたがって、障害を分離するために追加の手順を実行する前に、障害検証メカニズムを介して障害を検証することは賢明です。データパスに沿って障害が発生したことを確認した後、特定のデバイスまたはリンクのレベルに障害を分離できることが重要です。したがって、障害管理には断層分離メカニズムが必要です。障害通知メカニズムは、障害検出メカニズムと組み合わせて使用して、上流および下流のデバイスに障害検出ポイントに通知することができます。たとえば、2つの層状ネットワーク間にクライアント/サーバーの関係がある場合、サーバーレイヤーでの障害検出により、次の障害通知が発生する場合があります。
- Sending a forward fault notification from the server layer to the client layer network(s) using the fault notification format appropriate to the client layer
- サーバーレイヤーからクライアントレイヤーネットワークにサーバーレイヤーからフォワードフォールト通知を送信します。クライアントレイヤーに適した障害通知形式
- Sending a backward fault notification at the server layer, if applicable, in the reverse direction
- 該当する場合は、逆方向にサーバーレイヤーで後方障害通知を送信します
- Sending a backward fault notification at the client layer, if applicable, in the reverse direction
- クライアントレイヤーで後方障害通知を送信すると、該当する場合は逆方向に
Finally, fault recovery deals with recovering from the detected failure by switching to an alternate available data path using alternate devices or links (e.g., device redundancy or link redundancy).
最後に、障害回復は、代替デバイスまたはリンク（デバイスの冗長性やリンク冗長性など）を使用して、利用可能な代替データパスに切り替えることにより、検出された障害からの回復を扱います。
Performance Management deals with mechanism(s) that allow determining and measuring the performance of the network/services under consideration. Performance Management can be used to verify the compliance to both the service-level and network-level metric objectives/specifications. Performance Management typically consists of measurement of performance metrics, e.g., Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter), etc., across managed entities when the managed entities are in available state. Performance Management is suspended across unavailable managed entities.
パフォーマンス管理は、検討中のネットワーク/サービスのパフォーマンスを決定および測定できるメカニズムを扱います。パフォーマンス管理を使用して、サービスレベルとネットワークレベルのメトリック目標/仕様の両方へのコンプライアンスを検証できます。パフォーマンス管理は通常、パフォーマンスメトリックの測定、たとえば、フレーム損失、フレーム遅延、フレーム遅延変動（Jitter）など、管理されたエンティティが利用可能な状態にある場合に管理されたエンティティ全体で構成されます。パフォーマンス管理は、利用できないマネージドエンティティ全体で停止されています。
[L2VPN-FRWK] specifies three different types of Layer 2 VPN services: Virtual Private LAN Service (VPLS), (Virtual Private Wire Service (VPWS), and IP-only LAN Service (IPLS).
[L2VPN-FRWK] 3つの異なるタイプのレイヤー2 VPNサービスを指定します：仮想プライベートLANサービス（VPLS）、仮想プライベートワイヤサービス（VPWS）、およびIPのみのLANサービス（IPLS）。
This document provides a reference model for OAM as it relates to L2VPN services and their associated pseudowires (PWs) and Public Switched Network (PSN) tunnels. OAM requirements for L2VPN services (e.g., VPLS and VPWS) are also identified. Furthermore, if L2VPN service OAM requirements impose requirements for PW and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified.
このドキュメントは、L2VPNサービスと関連する擬似動物（PWS）およびパブリックスイッチネットワーク（PSN）トンネルに関連するOAMの参照モデルを提供します。L2VPNサービスのOAM要件（VPLSやVPWなど）も特定されています。さらに、L2VPNサービスOAM要件がPWおよび/またはPSN OAMの要件を課している場合、これらの特定のPWおよび/またはPSN OAM要件も特定されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
This document leverages protocols, mechanisms, and concepts defined as part of other OAM work, specifically the following:
このドキュメントは、他のOAM作業の一部として定義されたプロトコル、メカニズム、および概念を活用しています。
- IEEE Std. 802.1ag-2007 [IEEE802.1ag] specifies the Ethernet Connectivity Fault Management protocol, which defines the concepts of Maintenance Domains, Maintenance End Points, and Maintenance Intermediate Points. This standard also defines mechanisms and procedures for proactive fault detection (Continuity Check), fault notification (Remote Defect Indication (RDI)), fault verification (Loopback), and fault isolation (LinkTrace) in Ethernet networks.
- IEEE std。802.1AG-2007 [IEEE802.1AG]メンテナンスドメイン、メンテナンスエンドポイント、メンテナンスの中間点の概念を定義するイーサネット接続障害管理プロトコルを指定します。この標準は、イーサネットネットワークの障害通知（リモート欠陥表示（RDI））、障害検証（ループバック）、および障害分離（LinkTrace）のメカニズムと手順も定義します。
- ITU-T Std. Y.1731 [Y.1731] builds upon and extends IEEE 802.1ag in the following areas: it defines fault notification and alarm suppression functions for Ethernet (via Alarm Indication Signal (AIS)). It also specifies messages and procedures for Ethernet performance management, including loss, delay, jitter, and throughput measurement.
- itu-t std。Y.1731 [Y.1731]は、次の領域でIEEE 802.1AGに基づいて拡張されます。イーサネットの障害通知とアラーム抑制関数を定義します（アラーム表示信号（AIS））。また、損失、遅延、ジッター、スループット測定など、イーサネットのパフォーマンス管理のメッセージと手順を指定します。
This document introduces and uses the following terms. This document also uses the terms defined in [L2VPN-FRWK] and [L2VPN-TERM].
このドキュメントでは、次の用語を紹介および使用します。このドキュメントでは、[L2VPN-FRWK]および[L2VPN-TERM]で定義された用語も使用します。
AIS Alarm Indication Signal
AISアラーム表示信号
IPLS IP-only LAN Service
IPLS IPのみのLANサービス
ME Maintenance Entity, which is defined in a given OAM domain and represents an entity requiring management
特定のOAMドメインで定義され、管理を必要とするエンティティを表すMEメンテナンスエンティティ
MEG Maintenance Entity Group, which represents MEs belonging to the same service instance and is also called Maintenance Association (MA)
MEGメンテナンスエンティティグループ。同じサービスインスタンスに属するMESを表し、メンテナンスアソシエーション（MA）とも呼ばれます
MEP Maintenance End Point is responsible for origination and termination of OAM frames for a given MEG.
MEPメンテナンスのエンドポイントは、特定のMEGのOAMフレームの起源と終了に責任があります。
MIP Maintenance Intermediate Point is located between peer MEPs and can process and respond to certain OAM frames but does not initiate or terminate them.
MIPメンテナンス中間点はピアMEPの間にあり、特定のOAMフレームを処理および応答できますが、それらを開始または終了しません。
OAM Domain OAM Domain represents a region over which OAM frames can operate unobstructed.
OAMドメインOAMドメインは、OAMフレームが遮るもののない動作を行うことができる領域を表します。
QinQ 802.1Q tag inside another 802.1Q tag
QINQ 802.1Qタグ別の802.1Qタグ内
RDI Remote Defect Indication
RDIリモート欠陥の表示
VPLS Virtual Private LAN Service
VPLS仮想プライベートLANサービス
VPWS Virtual Private Wire Service
VPWS仮想プライベートワイヤーサービス
Figure 1 shows an L2VPN reference model as described in [L2VPN-REQ]. L2VPN A represents a point-to-point service while L2VPN B represents a bridged service.
図1は、[L2VPN-REQ]で説明されているL2VPN参照モデルを示しています。L2VPN Aはポイントツーポイントサービスを表し、L2VPN Bはブリッジされたサービスを表します。
+-----+ +-----+
+ CE1 +--+ +--| CE2 |
+-----+ | ..................... | +-----+
L2VPN A | +----+ +----+ | L2VPN A
+--| PE |-- Service --| PE |--+
+----+ Provider +----+
/ . Backbone . \ --------_
+-----+ / . | . \ / \ +-----+
+ CE4 +--+ . | . +-\ Access \--| CE5 |
+-----+ . +----+ . | Network | +-----+
L2VPN B ........| PE |....... \ / L2VPN B
+----+ ^ -------
| | logical
| | switching
+-----+ | instance
| CE3 |
+-----+
L2VPN B
Figure 1: L2VPN Reference Model
図1：L2VPN参照モデル
[L2VPN-FRWK] specifies VPWS, VPLS, and IPLS. VPWS is a point-to-point service where Customer Edges (CEs) are presented with point-to-point virtual circuits. VPLS is a bridged LAN service provided to a set of CEs that are members of a VPN. CEs that are members of the same service instance communicate with each other as if they were connected via a bridged LAN. IPLS is a special VPLS that is used to carry only IP service packets.
[L2VPN-FRWK]は、VPW、VPLS、およびIPLSを指定します。VPWSは、顧客エッジ（CES）にポイントツーポイント仮想回路が表示されるポイントツーポイントサービスです。VPLSは、VPNのメンバーであるCESのセットに提供されるブリッジ付きLANサービスです。同じサービスインスタンスのメンバーであるCESは、橋渡しされたLANを介して接続されているかのように互いに通信します。IPLSは、IPサービスパケットのみを運ぶために使用される特別なVPLSです。
[L2VPN-REQ] assumes the availability of runtime monitoring protocols while defining requirements for management interfaces. This document specifies the requirements and framework for operations, administration, and maintenance (OAM) protocols between network devices.
[L2VPN-REQ]は、管理インターフェイスの要件を定義しながら、ランタイム監視プロトコルの可用性を想定しています。このドキュメントは、ネットワークデバイス間の運用、管理、およびメンテナンス（OAM）プロトコルの要件とフレームワークを指定します。
The point-to-point or bridged LAN functionality is emulated by a network of Provider Edges (PEs) to which the CEs are connected. This network of PEs can belong to a single network operator or can span across multiple network operators. Furthermore, it can belong to a single service provider or can span across multiple service providers. A service provider is responsible for providing L2VPN services to its customers, whereas a network operator (aka facility provider) provides the necessary facilities to the service provider(s) in support of their services. A network operator and a service provider can be part of the same administrative organization, or they can belong to different administrative organizations.
ポイントツーポイントまたはブリッジ付きLAN機能は、CESが接続されているプロバイダーエッジ（PES）のネットワークによってエミュレートされます。PESのこのネットワークは、単一のネットワークオペレーターに属するか、複数のネットワーク演算子にまたがることがあります。さらに、単一のサービスプロバイダーに属するか、複数のサービスプロバイダーにまたがることがあります。サービスプロバイダーは、顧客にL2VPNサービスを提供する責任がありますが、ネットワークオペレーター（別名施設プロバイダー）は、サービスをサポートするために必要な施設をサービスプロバイダーに提供します。ネットワークオペレーターとサービスプロバイダーは、同じ管理組織の一部であるか、異なる管理組織に属することができます。
The different layers involved in realizing L2VPNs include service layers and network layers. Network layers can be iterative. In the context of L2VPNs, the service layer consists of VPLS, VPWS (e.g., Ethernet, ATM, FR, HDLC, SONET, point-to-point emulation, etc.), and IPLS. Similarly, in the context of L2VPNs, network layers consist of MPLS/IP networks. The MPLS/IP networks can consist of networks links realized by different technologies, e.g., SONET, Ethernet, ATM, etc.
L2VPNの実現に関与するさまざまなレイヤーには、サービスレイヤーとネットワークレイヤーが含まれます。ネットワークレイヤーは反復的です。L2VPNSのコンテキストでは、サービスレイヤーはVPL、VPW（例：イーサネット、ATM、FR、HDLC、ソネット、ポイントツーポイントエミュレーションなど）、およびIPLSで構成されています。同様に、L2VPNSのコンテキストでは、ネットワークレイヤーはMPLS/IPネットワークで構成されています。MPLS/IPネットワークは、SONET、イーサネット、ATMなど、さまざまなテクノロジーによって実現されたネットワークリンクで構成できます。
Each layer is responsible for its own OAM. This document provides the OAM framework and requirements for L2VPN services and networks.
各レイヤーは、独自のOAMに責任があります。このドキュメントは、L2VPNサービスとネットワークのOAMフレームワークと要件を提供します。
When discussing OAM tools for L2VPNs, it is important to provide OAM capabilities and functionality over each domain for which a service provider or a network operator is responsible. It is also important that OAM frames not be allowed to enter/exit other domains. We define an OAM domain as a network region over which OAM frames operate unobstructed, as explained below.
L2VPNのOAMツールについて議論する場合、サービスプロバイダーまたはネットワークオペレーターが責任を負う各ドメインに対してOAM機能と機能を提供することが重要です。また、OAMフレームを他のドメインに入る/出ることを許可しないことも重要です。以下で説明するように、OAMドメインをOAMフレームが遮るもので動作しないネットワーク領域として定義します。
At the edge of an OAM domain, filtering constructs should prevent OAM frames from exiting and entering that domain. OAM domains can be nested but not overlapped. In other words, if there is a hierarchy of the OAM domains, the OAM frames of a higher-level domain pass transparently through the lower-level domains, but the OAM frames of a lower-level domain get blocked/filtered at the edge of that domain.
OAMドメインの端で、フィルタリングコンストラクトは、OAMフレームがそのドメインを出て入力するのを防ぐ必要があります。OAMドメインはネストできますが、重複することはできません。言い換えれば、OAMドメインの階層がある場合、高レベルのドメインのOAMフレームは低レベルのドメインを透過的に通過しますが、下位レベルドメインのOAMフレームはの端でブロック/フィルタリングされます。そのドメイン。
In order to facilitate the processing of OAM frames, each OAM domain can be associated with the level at which it operates. Higher-level OAM domains can contain lower-level OAM domains, but the converse is not true. It may be noted that the higher-level domain does not necessarily mean a higher numerical value of the level encoding in the OAM frame.
OAMフレームの処理を促進するために、各OAMドメインは、動作するレベルに関連付けられます。高レベルのOAMドメインには、低レベルのOAMドメインを含めることができますが、逆は真実ではありません。高レベルのドメインは、必ずしもOAMフレーム内のレベルエンコードの数値が高いことを意味するわけではないことに注意することができます。
A PE can be part of several OAM domains, with each interface belonging to the same or a different OAM domain. A PE, with an interface at the boundary of an OAM domain, shall block outgoing OAM frames, filter out incoming OAM frames whose domain level is lower or the same as the one configured on that interface, and pass through the OAM frames whose domain level is higher than the one configured on that interface.
PEはいくつかのOAMドメインの一部であり、各インターフェイスは同じまたは異なるOAMドメインに属します。OAMドメインの境界にインターフェイスを備えたPEは、発信OAMフレームをブロックし、ドメインレベルが低いまたはそのインターフェイスで構成されているものと同じ入っているOAMフレームを除外し、ドメインレベルのOAMフレームを通過するものとします。そのインターフェイスで構成されているものよりも高くなっています。
Generically, L2VPNs can be viewed as consisting of a customer OAM domain, a service provider OAM domain, and network operator OAM domains as depicted in Figure 2.
一般的に、L2VPNは、図2に示すように、顧客OAMドメイン、サービスプロバイダーOAMドメイン、およびネットワーク演算子OAMドメインで構成されると見ることができます。
--- ---
/ \ ------ ------- ----- / \
| CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ /
--- --PE P P PE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- -----
Customer OAM Domain
|<-------------------------------------------->|
Service Provider OAM Domain
|<------------------------------>|
Operator Operator Operator
|<-------->|<--------->|<------->|
OAM Domain OAM Domain OAM Domain
Figure 2: OAM Domains
図2：OAMドメイン
The OAM Domains can be categorized as follows:
OAMドメインは次のように分類できます。
- Hierarchical OAM Domains: Hierarchical OAM Domains result from OAM Layering and imply a contractual agreement among the OAM Domain owning entities. In Figure 2, the customer OAM domain, the service provider OAM domain, and the operator OAM domains are hierarchical.
- 階層的なOAMドメイン：階層的なOAMドメインは、OAMの階層化に起因し、OAMドメイン所有エンティティ間の契約上の合意を意味します。図2では、顧客OAMドメイン、サービスプロバイダーOAMドメイン、およびオペレーターOAMドメインが階層的です。
- Adjacent OAM Domains: Adjacent OAM Domains are typically independent of each other and do not have any relationship among them. In Figure 2, the different operator OAM domains are independent of each other.
- 隣接するOAMドメイン：隣接するOAMドメインは通常、互いに独立しており、それらの間に何の関係もありません。図2では、異なる演算子OAMドメインは互いに独立しています。
Maintenance End Points (MEPs) are responsible for origination and termination of OAM frames. MEPs are located at the edge of their corresponding OAM domains. Maintenance Intermediate Points (MIPs) are located within their corresponding OAM domains, and they normally pass OAM frames but never initiate them. Since MEPs are located at the edge of their OAM domains, they are responsible for filtering outbound OAM frames from leaving the OAM domain or inbound OAM frames from entering the OAM domain.
メンテナンスエンドポイント（MEP）は、OAMフレームの発信と終了を担当します。MEPは、対応するOAMドメインの端にあります。メンテナンス中間点（MIP）は、対応するOAMドメイン内にあり、通常はOAMフレームを通過しますが、開始することはありません。MEPはOAMドメインの端にあるため、OAMドメインまたはインバウンドOAMフレームがOAMドメインに入るのを防ぐことから、アウトバウンドOAMフレームをフィルタリングする責任があります。
An OAM frame is generally associated with a Maintenance Entity Group (MEG), where a MEG consists of a set of Maintenance Entities (MEs) associated with the same service instance. An ME is a point-to-point association between a pair of MEPs and represents a monitored entity. For example, in a VPLS that involves n CEs, all the MEs associated with the VPLS in the customer OAM domain (i.e., from CE to CE) can be considered to be part of a VPLS MEG, where the n-point MEG consists of a maximum of n(n-1)/2 MEs. MEPs and MIPs correspond to a PE, or, more specifically, to an interface of a PE. For example, an OAM frame can be said to originate from an ingress PE or more specifically an ingress interface of that PE. A MEP on a PE receives messages from n-1 other MEPs (some of them may reside on the same PE) for a given MEG.
OAMフレームは通常、メンテナンスエンティティグループ（MEG）に関連付けられており、MEGは同じサービスインスタンスに関連付けられたメンテナンスエンティティのセット（ME）で構成されています。MEは、MEPのペア間のポイントツーポイントの関連性であり、監視対象のエンティティを表しています。たとえば、N CEを含むVPLSでは、顧客OAMドメインのVPLSに関連付けられているすべてのMES（すなわち、CEからCEまで）は、NポイントMEGが構成されているVPLS MEGの一部と見なすことができます。N（n-1）/2 mesの最大値。MEPとMIPは、PE、またはより具体的にはPEのインターフェイスに対応しています。たとえば、OAMフレームは、侵入PEまたはより具体的にはそのPEの侵入インターフェイスに由来すると言えます。PEのMEPは、特定のMEGに対してN-1 MEP（それらのいくつかは同じPEに存在する可能性がある）からメッセージを受信します。
In Hierarchical OAM Domains, a MEP of lower-level OAM domain can correspond to a MIP or a MEP of a higher-level OAM domain. Furthermore, the MIPs of a lower-level OAM domain are always transparent to the higher-level OAM domain (e.g., OAM frames of a higher-level OAM domain are not seen by MIPs of a lower-level OAM domain and get passed through them transparently). Further, the MEs (or MEGs) are hierarchically organized in hierarchical OAM domains. For example, in a VPWS, the VPWS ME in the customer OAM domain can overlap with the Attachment Circuit (AC) ME, PW ME, and another AC ME in service provider OAM domain. Similarly, the PW ME can overlap with different ME in operator OAM domains.
階層的なOAMドメインでは、低レベルのOAMドメインのMEPがMIPまたは高レベルのOAMドメインのMEPに対応できます。さらに、低レベルのOAMドメインのMIPは常に高レベルのOAMドメインに対して透明です（たとえば、高レベルのOAMドメインのOAMフレームは、低レベルのOAMドメインのMIPSによっては見られず、それらを通過します透過的に）。さらに、MES（またはMEG）は、階層的なOAMドメインで階層的に組織されています。たとえば、VPWSでは、顧客OAMドメインのVPWS MEは、アタッチメント回路（AC）ME、PW ME、およびサービスプロバイダーOAMドメインの別のAC MEと重複することができます。同様に、PW MEは、オペレーターOAMドメインで異なるMEとオーバーラップできます。
As mentioned previously, OAM at each layer should be independent of other layers, e.g., a service layer OAM should be independent of an underlying transport layer. MEPs and MIPs at each layer should be identified with layer-specific identifiers.
前述のように、各レイヤーのOAMは他のレイヤーとは独立している必要があります。たとえば、サービスレイヤーOAMは、基礎となる輸送層から独立している必要があります。各レイヤーのMEPとMIPは、レイヤー固有の識別子で識別する必要があります。
Virtual Private LAN Service (VPLS) is used in different contexts, such as the following: a) as a bridged LAN service over networks, some of which are MPLS/IP, b) as an MPLS/IP network supporting these bridged LAN services, and c) as (V)LAN emulation.
仮想プライベートLANサービス（VPLS）は、次のようなさまざまなコンテキストで使用されます。a）ネットワーク上のブリッジ付きLANサービスとして、その一部はMPLS/IP、b）これらのブリッジ付きLANサービスをサポートするMPLS/IPネットワークとして、c）as（v）lanエミュレーション。
The most common definition for VPLS is for bridged LAN service over an MPLS/IP network. The service coverage is considered end-to-end from UNI to UNI (or AC to AC) among the CE devices, and it provides a virtual LAN service to the attached CEs belonging to that service instance. The reason it is called bridged LAN service is because the VPLS-capable PE providing this end-to-end virtual LAN service is performing bridging functions (either full or a subset) as described in [L2VPN-FRWK]. This VPLS definition, as specified in [L2VPN-REQ], includes both bridge module and LAN emulation module (as specified in [L2VPN-FRWK]).
VPLSの最も一般的な定義は、MPLS/IPネットワーク上のBridged LANサービスです。サービスカバレッジは、CEデバイス間でUNIからUNI（またはACからACからAC）までのエンドツーエンドと見なされ、そのサービスインスタンスに属する添付のCESに仮想LANサービスを提供します。Bridged LANサービスと呼ばれる理由は、[L2VPN-FRWK]で説明されているように、このエンドツーエンドの仮想LANサービスを提供するVPLS対応PEがブリッジ機能（フルまたはサブセット）を実行しているためです。[L2VPN-REQ]で指定されているこのVPLS定義には、ブリッジモジュールとLANエミュレーションモジュール（[L2VPN-FRWK]で指定）の両方が含まれます。
Throughout this document, whenever the term "VPLS" is used by itself, it refers to the service as opposed to network or LAN emulation.
このドキュメント全体を通して、「VPLS」という用語が単独で使用されるたびに、ネットワークまたはLANエミュレーションとは対照的にサービスを指します。
A VPLS instance is also analogous to a VLAN provided by IEEE 802.1Q networks since each VLAN provides a Virtual LAN service to its Media Access Control (MAC) users. Therefore, when a part of the service provider network is Ethernet based (such as H-VPLS with QinQ access network), there is a one-to-one correspondence between a VPLS instance and its corresponding provider VLAN in the service provider Ethernet network. To check the end-to-end service integrity, the OAM mechanism needs to cover the end-to-end VPLS as defined in [L2VPN-REQ], which is from AC to AC, including bridge module, VPLS forwarder, and the associated PWs for this service. This document specifies the framework and requirements for such OAM mechanisms.
VPLSインスタンスは、各VLANがメディアアクセス制御（MAC）ユーザーに仮想LANサービスを提供するため、IEEE 802.1Qネットワークによって提供されるVLANにも類似しています。したがって、サービスプロバイダーネットワークの一部がイーサネットベース（QINQアクセスネットワークを持つH-VPLSなど）である場合、VPLSインスタンスとサービスプロバイダーイーサネットネットワークに対応するプロバイダーVLANの間に1対1の対応があります。エンドツーエンドのサービスの完全性を確認するには、OAMメカニズムは、[L2VPN-REQ]で定義されているエンドツーエンドのVPLをカバーする必要があります。このサービスのPWS。このドキュメントは、このようなOAMメカニズムのフレームワークと要件を指定します。
Sometimes VPLS is also used to refer to the underlying network that supports bridged LAN services. This network can be an end-to-end MPLS/IP network, as in H-VPLS with MPLS/IP access, or it can be a hybrid network consisting of MPLS/IP core and Ethernet access network, as in H-VPLS with QinQ access. In either case, the network consists of a set of VPLS-capable PE devices capable of performing bridging functions (either full or a subset). These VPLS-capable PE devices can be arranged in a certain topology, such as hierarchical topology, distributed topology, or some other topologies such as multi-tier or star topologies. To check the network integrity regardless of the network topology, network-level OAM mechanisms (such as OAM for MPLS/IP networks) are needed. The discussion of network-level OAM is outside of the scope of this document.
VPLSは、Bridged LANサービスをサポートする基礎となるネットワークを参照するためにも使用される場合があります。このネットワークは、MPLS/IPアクセスを備えたH-VPLSのように、エンドツーエンドのMPLS/IPネットワークにすることができます。QINQアクセス。どちらの場合でも、ネットワークは、ブリッジング関数（フルまたはサブセット）を実行できるVPLS対応PEデバイスのセットで構成されています。これらのVPLS対応PEデバイスは、階層トポロジ、分散トポロジ、またはマルチティアやスタートポロジなどの他のトポロジなどの特定のトポロジに配置できます。ネットワークトポロジに関係なくネットワークの整合性を確認するには、ネットワークレベルのOAMメカニズム（MPLS/IPネットワークのOAMなど）が必要です。ネットワークレベルのOAMの議論は、このドキュメントの範囲外です。
Sometimes VPLS also refers to (V)LAN emulation. In this context, VPLS only refers to the full mesh of PWs with split horizon that emulates a LAN segment over a MPLS/IP network for a given service instance and its associated VPLS forwarder. Since the emulated LAN segment is presented as a Virtual LAN (VLAN) to the bridge module of a VPLS-capable PE, the emulated segment is also referred to as an emulated VLAN. The OAM mechanisms in this context refer primarily to integrity check of VPLS forwarders and their associated full mesh of PWs and the ability to detect and notify a partial mesh failure. This document also covers the OAM framework and requirements for such OAM mechanisms.
VPLSは、（v）LANエミュレーションを指す場合があります。これに関連して、VPLSは、特定のサービスインスタンスとそれに関連するVPLSフォワーダーのMPLS/IPネットワーク上でLANセグメントをエミュレートするスプリットホライズンを持つPWSの完全なメッシュのみを指します。エミュレートされたLANセグメントは、VPLS対応PEのブリッジモジュールに仮想LAN（VLAN）として提示されているため、エミュレートされたセグメントはエミュレートVLANとも呼ばれます。このコンテキストのOAMメカニズムは、主にVPLSフォワーダーの整合性チェックと、それに関連するPWSの完全なメッシュと、部分メッシュの障害を検出および通知する能力を指します。このドキュメントは、このようなOAMメカニズムのOAMフレームワークと要件もカバーしています。
When discussing the OAM mechanisms for VPLS, it is important to consider that the end-to-end service can span across different types of L2VPN networks. For example, the access network on one side can be a bridged network, e.g., [IEEE802.1ad], as described in Section 11 of [VPLS-LDP]. The access network can also be a [IEEE802.1ah]-based bridged network. The access network on the other side can be MPLS-based, as described in Section 10 of [VPLS-LDP], and the core network connecting them can be IP, MPLS, ATM, or SONET. Similarly, the VPLS instance can span across [VPLS-BGP] and distributed VPLS as described in [L2VPN-SIG].
VPLSのOAMメカニズムについて議論する場合、エンドツーエンドサービスが異なるタイプのL2VPNネットワークにまたがることができることを考慮することが重要です。たとえば、片側のアクセスネットワークは、[VPLS-LDP]のセクション11で説明されているように、[IEEE802.1AD]などのブリッジ型ネットワークにすることができます。アクセスネットワークは、[IEEE802.1AH]ベースのブリッジネットワークでもあります。反対側のアクセスネットワークは、[VPLS-LDP]のセクション10で説明されているようにMPLSベースにすることができ、それらを接続するコアネットワークはIP、MPLS、ATM、またはSONETです。同様に、VPLSインスタンスは[VPLS-BGP]と[L2VPN-SIG]で説明されているようにVPLSを分布させることができます。
Therefore, it is important that the OAM mechanisms can be applied to all these network types. Each such network may be associated with a separate administrative domain, and multiple such networks may be associated with a single administrative domain. It is important to ensure that the OAM mechanisms are independent of the underlying transport mechanisms and solely rely on VPLS, i.e., the transparency of OAM mechanisms must be ensured over underlying transport technologies such as MPLS, IP, etc.
したがって、OAMメカニズムをこれらすべてのネットワークタイプに適用できることが重要です。このような各ネットワークは、別の管理ドメインに関連付けられている可能性があり、複数のそのようなネットワークが単一の管理ドメインに関連付けられている場合があります。OAMメカニズムが基礎となる輸送メカニズムとは独立しており、VPLSのみに依存していることを確認することが重要です。つまり、MPLS、IPなどの基礎となる輸送技術よりもOAMメカニズムの透明度を確保する必要があります。
This proposal is aligned with the discussions in other standard bodies and groups such as ITU-T Q.5/13, IEEE 802.1, and Metro Ethernet Forum (MEF), which address Ethernet network and service OAM.
この提案は、イーサネットネットワークおよびサービスOAMに対処するITU-T Q.5/13、IEEE 802.1、Metro Ethernet Forum（MEF）などの他の標準機関やグループでの議論と一致しています。
Figure 3 shows an example of a VPLS (with two CEs belonging to customer A) across a service provider network marked by UPE and NPE devices. More CE devices belonging to the same customer A can be connected across different customer sites. The service provider network is segmented into a core network and two types of access networks. In Figure 3, (A) shows the bridged access network represented by its bridge components marked B and the MPLS access and core network represented by MPLS components marked P. In Figure 3, (B) shows the service/network view at the Ethernet MAC layer marked by E.
図3は、UPEおよびNPEデバイスでマークされたサービスプロバイダーネットワーク全体のVPL（2つのCEが顧客Aに属する）の例を示しています。同じ顧客Aに属するより多くのCEデバイスは、異なる顧客サイトに接続できます。サービスプロバイダーネットワークは、コアネットワークと2種類のアクセスネットワークにセグメント化されています。図3に、（a）は、Bとマークされたブリッジコンポーネントで表されるブリッジ型アクセスネットワークと、図3のMPLSアクセスおよびMPLSコンポーネントで表されるコアネットワークを示しています。Eでマークされたレイヤー
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B--B--NPE---P--P---NPE---P----UPE----CE
(B) E------E---E--E---E------------E----------E-----E
Figure 3: VPLS-Specific Device View
図3：VPLS固有のデバイスビュー
As shown in (B) of Figure 3, only the devices with Ethernet functionality are visible to OAM mechanisms operating at the Ethernet MAC layer, and the P devices are invisible. Therefore, the OAM along the path of P devices (e.g., between two PEs) is covered by the transport layer, and it is outside the scope of this document.
図3の（b）に示すように、イーサネット機能を備えたデバイスのみが、イーサネットMACレイヤーで動作するOAMメカニズムに表示され、Pデバイスは見えません。したがって、Pデバイスの経路に沿ったOAM（2つのPEの間）は輸送層で覆われており、このドキュメントの範囲外です。
However, VPLSs may impose some specific requirements on PSN OAM. This document aims to identify such requirements.
ただし、VPLSSはPSN OAMに特定の要件を課す可能性があります。このドキュメントは、そのような要件を特定することを目的としています。
As described in the previous section, a VPLS for a given customer can span across one or more service providers and network operators. Figure 4 depicts three OAM domains: (A) customer domain, which is among the CEs of a given customer, (B) service provider domain, which is among the edge PEs of the given service provider, and (C) network operator domain, which is among the PEs of a given operator.
前のセクションで説明したように、特定の顧客のVPLは、1つ以上のサービスプロバイダーとネットワークオペレーターにまたがることができます。図4は、3つのOAMドメインを示しています。（a）特定の顧客のCESの1つである顧客ドメイン、（b）特定のサービスプロバイダーのエッジPESの1つであるサービスプロバイダードメイン、および（c）ネットワークオペレータードメイン、これは、特定のオペレーターのPESの1つです。
--- ---
/ \ ------ ------- ---- / \
| CE-- / \ / \ / \ --CE |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
Customer OAM Domain
(A) |<----------------------------------------------->|
Provider OAM Domain
(B) |<---------------------------------->|
Operator Operator Operator
(C) |<--------->|<---------->|<-------->|
OAM Domain OAM Domain OAM Domain
Figure 4: VPLS OAM Domains
図4：VPLS OAMドメイン
As shown in Figure 5, (C) represents those MEPs and MIPs that are visible within the customer domain. The MIPs associated with (C) are expected to be implemented in the bridge module/VPLS forwarder of a PE device, as per [L2VPN-FRWK]. (D) represents the MEPs and MIPs visible within the service provider domain. These MEPs and MIPs are expected to be implemented in the bridge module/VPLS forwarder of a PE device, as per [L2VPN-FRWK]. (E) represents the MEPs and MIPs visible within each operator domain, where MIPs only exist in an Ethernet access network (i.e., an MPLS access network does not have MIPs at the operator level). Further, (F) represents the MEPs and MIPs corresponding to the MPLS layer and may apply MPLS-based mechanisms. The MPLS layer shown in Figure 5 is just an example; specific OAM mechanisms are outside the scope of this document.
図5に示すように、（c）は、顧客ドメイン内に見えるMEPとMIPを表しています。（c）に関連付けられたMIPは、[L2VPN-FRWK]に従って、PEデバイスのBridgeモジュール/VPLS転送業者に実装されると予想されます。（d）サービスプロバイダードメイン内に見えるMEPとMIPを表します。これらのMEPとMIPは、[L2VPN-FRWK]に従って、PEデバイスのBridgeモジュール/VPLSフォワーダーに実装されることが期待されています。（e）は、各オペレータドメイン内に表示されるMEPとMIPを表します。ここでは、MIPはイーサネットアクセスネットワークにのみ存在します（つまり、MPLSアクセスネットワークにはオペレーターレベルにMIPがありません）。さらに、（f）は、MPLS層に対応するMEPとMIPを表し、MPLSベースのメカニズムを適用する場合があります。図5に示すMPLS層は単なる例です。特定のOAMメカニズムは、このドキュメントの範囲外です。
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
(A) CE----UPE--B-----NPE---P------NPE---P----UPE----CE
(B) E------E---E------E------------E----------E-----E
Customer OAM Domain
(C) MEP---MIP--------------------------------MIP---MEP
Provider OAM Domain
(D) MEP--------MIP-----------MIP-------MEP
Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM (F) MEP--MIP--MEP|MEP-MIP-MEP domain domain
MPLS OAM MPLS OAM（F）MEP - MIP - MEP | MEP-MIP-MEPドメインドメイン
Figure 5: VPLS OAM Domains, MEPs, and MIPs
図5：VPLS OAMドメイン、MEP、およびMIPS
In VPLS, for the Ethernet MAC layer, the MEPs and MIPs should be identified with their Ethernet MAC addresses and Maintenance Entity Group Identifier (MEG ID). As described in [VPLS-LDP], a VPLS instance can be identified in an Ethernet domain (e.g., 802.1ad domain) using a VLAN tag (service tag) while in an MPLS/IP network, PW-ids are used. Both PW-ids and VLAN tags for a given VPLS instance are associated with a Service Identifier (e.g., VPN identifier). MEPs and MIPs Identifiers, i.e., MEP Ids and MIP Ids, must be unique within their corresponding Service Identifiers within the OAM domains.
VPLSでは、イーサネットMACレイヤーの場合、MEPSとMIPはイーサネットMACアドレスとメンテナンスエンティティグループ識別子（MEG ID）で識別する必要があります。[VPLS-LDP]で説明されているように、MPLS/IPネットワークでは、VLANタグ（サービスタグ）を使用して、イーサネットドメイン（802.1ADドメイン）でVPLSインスタンスを識別できます。PW-IDが使用されます。特定のVPLSインスタンスのPW-IDとVLANタグの両方は、サービス識別子（VPN識別子など）に関連付けられています。MEPおよびMIPS識別子、つまりMEP IDとMIP IDSは、OAMドメイン内の対応するサービス識別子内で一意でなければなりません。
For Ethernet services, e.g., VPLS, Ethernet frames are used for OAM frames, and the source MAC address of the OAM frames represent the source MEP in that domain for a specific MEG. For unicast Ethernet OAM frames, the destination MAC address represents the destination MEP in that domain for a specific MEG. For multicast Ethernet OAM frames, the destination MAC addresses correspond to all MEPs in that domain for a specific MEG.
イーサネットサービス、例えばVPLSの場合、イーサネットフレームはOAMフレームに使用され、OAMフレームのソースMACアドレスは、特定のMEGのドメインのソースMEPを表します。ユニキャストイーサネットOAMフレームの場合、宛先MACアドレスは、特定のMEGのドメインの宛先MEPを表します。マルチキャストイーサネットOAMフレームの場合、宛先MACアドレスは、特定のMEGのドメイン内のすべてのMEPに対応しています。
Figure 6 shows the VPWS reference model. VPWS is a point-to-point service where CEs are presented with point-to-point virtual circuits. VPWS is realized by combining a pair of Attachment Circuits (ACs) and a single PW between two PEs.
図6は、VPWS参照モデルを示しています。VPWSは、CESにポイントツーポイント仮想回路が提示されるポイントツーポイントサービスです。VPWSは、2つのPEの間のアタッチメント回路（ACS）と単一のPWを組み合わせることで実現されます。
|<------------- VPWS1 <AC11,PW1,AC12> ------------>|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC11---| |.......PW1........| |--AC12----| |
| CE1| |PE1 | | PE2| |CE2 |
| |---AC21---| |.......PW2........| |--AC22----| |
+----+ | |==================| | +----+
| +----+ PSN Tunnel +----+ |
| |
|<------------- VPWS2 <AC21,PW2,AC22> ------------>|
Figure 6: VPWS Reference Model
図6：VPWSリファレンスモデル
VPWS can be categorized as follows:
VPWは次のように分類できます。
- VPWS with homogeneous ACs (where both ACs are same type)
- 均一なACSを持つVPW（両方のACSが同じタイプ）
- VPWS with heterogeneous ACs (where the ACs are of different Layer-2 encapsulation)
- 不均一なACSを持つVPW（ACSは異なるレイヤー2カプセル化の場合）
Further, the VPWS can itself be classified as follows:
さらに、VPW自体は次のように分類できます。
- Homogeneous VPWS (when two ACs and PW are of the same type)
- 均一なVPW（2つのACSとPWが同じタイプの場合）
- Heterogeneous VPWS (when at least one AC or PW is a different type than the others)
- 不均一なVPW（少なくとも1つのACまたはPWが他のACまたはPWが異なる場合）
Based on the above classifications, the heterogeneous VPWS may have either homogeneous or heterogeneous ACs. On the other hand, homogeneous VPWS can have only homogeneous ACs.
上記の分類に基づいて、不均一なVPWは均一または不均一なACを持っている可能性があります。一方、均一なVPWには均一なACのみが含まれます。
Throughout this document, whenever the term "VPWS" is used by itself, it refers to the service.
このドキュメント全体を通して、「VPWS」という用語が単独で使用されるたびに、それはサービスを指します。
When discussing the OAM mechanisms for VPWS, it is important to consider that the end-to-end service can span across different types of networks. As an example, the access network between the CE and PE on one side can be an Ethernet-bridged network, an ATM network, etc. In common scenarios, it could simply be a point-to-point interface such as Ethernet Physical Layer (PHY). The core network connecting PEs can be IP, MPLS, etc.
VPWのOAMメカニズムについて議論する場合、エンドツーエンドサービスが異なるタイプのネットワークにまたがることができることを考慮することが重要です。例として、片側のCEとPEの間のアクセスネットワークは、一般的なシナリオでは、イーサネットブリッジネットワーク、ATMネットワークなどです。単にイーサネットの物理レイヤーなどのポイントツーポイントインターフェイスである可能性があります。phy）。PEを接続するコアネットワークは、IP、MPLSなどです。
Therefore, it is important that the OAM mechanisms can be applied to different network types, some of which are mentioned above. Each such network may be associated with a separate administrative domain, and multiple such networks may be associated with a single administrative domain.
したがって、OAMメカニズムをさまざまなネットワークタイプに適用できることが重要です。その一部は上記のものです。このような各ネットワークは、別の管理ドメインに関連付けられている可能性があり、複数のそのようなネットワークが単一の管理ドメインに関連付けられている場合があります。
Figure 7 shows an example of a VPWS (with two CE devices belonging to customer A) across a service provider network marked by PE devices. The service provider network can be considered to be segmented into a core network and two types of access networks.
図7は、PEデバイスでマークされたサービスプロバイダーネットワーク全体のVPW（2つのCEデバイスが顧客に属する）の例を示しています。サービスプロバイダーネットワークは、コアネットワークと2種類のアクセスネットワークにセグメント化されていると見なすことができます。
In the most general case, a PE can be client service aware when it processes client service PDUs and is responsible for encapsulating and de-encapsulating client service PDUs onto PWs and ACs. This is particularly relevant for homogeneous VPWS. The service-specific device view for such a deployment is highlighted by (A) in Figure 7, for these are the devices that are expected to be involved in end-to-end VPWS OAM.
最も一般的なケースでは、PEはクライアントサービスPDUを処理し、クライアントサービスPDUをPWSおよびACSにカプセル化および脱カプセル化することを担当するときにクライアントサービスを認識できます。これは、均一なVPWに特に関連しています。このような展開のサービス固有のデバイスビューは、図7の（a）で強調されています。これらは、エンドツーエンドのVPWS OAMに関与すると予想されるデバイスです。
In other instances, a PE can be client service unaware when it does not process native service PDUs but instead encapsulates access technology PDUs over PWs. This may be relevant for VPWS with heterogeneous ACs, such as Ethernet VPWS, which is offered across an ATM AC, ATM PW, and Ethernet AC. In this case, the PE that is attached to ATM AC and ATM PW may be transparent to the client Ethernet service PDUs. On the other hand, the PE that is attached to ATM PW and Ethernet AC is expected to be client Ethernet service aware. The service-specific device view for such a deployment is highlighted by (B) in Figure 7, for these are the devices that are expected to be involved in end-to-end VPWS OAM, where PE1 is expected to be client service unaware.
他の例では、PEは、ネイティブサービスPDUを処理せず、代わりにPWを介したアクセステクノロジーPDUをカプセル化する場合、クライアントサービスに気付くことができません。これは、ATM AC、ATM PW、およびイーサネットACで提供されるイーサネットVPWSなど、不均一なACSを持つVPWに関連する場合があります。この場合、ATM ACおよびATM PWに接続されているPEは、クライアントイーサネットサービスPDUに対して透過的である可能性があります。一方、ATM PWおよびイーサネットACに接続されているPEは、クライアントイーサネットサービスが認識されると予想されます。このような展開のサービス固有のデバイスビューは、図7の（b）で強調されています。これらは、エンドツーエンドのVPWS OAMに関与すると予想されるデバイスであり、PE1はクライアントサービスであると予想されます。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
access core access
|<---------->|<---------------------->|<------------>|
(A) CE----------PE-----------------------PE-------------CE
(B) CE-----------------------------------PE-------------CE
Figure 7: VPWS-Specific Device View
図7：VPWS固有のデバイスビュー
As described in the previous section, a VPWS for a given customer can span across one or more network operators.
前のセクションで説明したように、特定の顧客のVPWは、1つ以上のネットワーク演算子にまたがることができます。
Figures 8a and 8b depict three OAM domains: (A) customer domain, which is among the CEs of a given customer, (B) service provider domain, which depends on the management model, and (C) network operator domain, which is among the PEs of a given operator and could also be present in the access network if the ACs are provided by a different network operator. The core network operator may be responsible for managing the PSN Tunnel in these examples.
図8aおよび8bは、3つのOAMドメインを示しています。（a）特定の顧客のCESの1つである顧客ドメイン、（b）管理モデルに依存するサービスプロバイダードメイン、および（c）ネットワーク演算子ドメイン（特定のオペレーターのPESは、ACSが別のネットワークオペレーターによって提供される場合、アクセスネットワークに存在する可能性もあります。コアネットワークオペレーターは、これらの例でPSNトンネルの管理を担当する場合があります。
For the first management model, shown in Figure 8a, the CEs are expected to be managed by the customer, and the customer is responsible for running end-to-end service OAM if needed. The service provider is responsible for monitoring the PW ME, and the monitoring of the AC is the shared responsibility of the customer and the service provider. In most simple cases, when the AC is realized across a physical interface that connects the CE to PE, the monitoring requirements across the AC ME are minimal.
図8Aに示す最初の管理モデルでは、CESは顧客によって管理されることが期待され、顧客は必要に応じてエンドツーエンドサービスOAMを実行する責任があります。サービスプロバイダーはPW MEの監視を担当し、ACの監視は顧客とサービスプロバイダーの共有責任です。ほとんどの単純な場合、CEをPEに接続する物理インターフェイス全体でACが実現されると、AC ME全体の監視要件は最小限です。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
Customer OAM Domain
(A) |<------------------------------------------------->|
Service Provider OAM Domain
(B) |<--------------------------->|
Operator OAM Domain
(C) |<---------------->|
Figure 8a: VPWS OAM Domains - Management Model 1
図8a：VPWS OAMドメイン - 管理モデル1
Figure 8b highlights another management model, where the CEs are managed by the service provider and where CEs and PEs are connected via an access network. The access network between the CEs and PEs may or may not be provided by a distinct network operator. In this model, the VPWS ME spans between the CEs in the service provider OAM domain, as shown by (B) in Figure 8b. The service provider OAM domain may additionally monitor the AC MEs and PW MEs individually, as shown by (C) in Figure 8b. The network operators may be responsible for managing the access service MEs (e.g., access tunnels) and core PSN Tunnel MEs, as shown by (D) in Figure 8b. The distinction between (C) and (D) in Figure 8b is that in (C), MEs have MEPs at CEs and at PEs and have no MIPs. While in (D), MEs have MEPs at CEs and at PEs; furthermore, MIPs may be present in between the MEPs, thereby providing visibility of the network to the operator.
図8bは、CESがサービスプロバイダーによって管理され、CESとPESがアクセスネットワークを介して接続されている別の管理モデルを強調しています。CESとPESの間のアクセスネットワークは、異なるネットワークオペレーターによって提供される場合と提供されない場合があります。このモデルでは、図8bの（b）に示すように、VPWS MEはサービスプロバイダーOAMドメインのCESの間に広がっています。図8bに示すように、サービスプロバイダーOAMドメインは、AC MESとPW MEを個別に監視することができます。ネットワークオペレーターは、図8bの（d）に示すように、アクセスサービスMES（例：アクセストンネル）とコアPSNトンネルMESの管理を担当している場合があります。図8Bの（c）と（d）の区別は、（c）では、MESがCESおよびPESでMEPを持ち、MIPSがないことです。（d）にいる間、MESはCESおよびPESでMEPを持っています。さらに、MIPがMEPの間に存在する可能性があり、それによりオペレーターにネットワークの可視性を提供します。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
Customer OAM Domain
(A) |<-------------------------------------------------->|
Service Provider (SP) OAM Domain
(B) |<------------------------------------------------>|
SP OAM SP OAM SP OAM
(C) |<--------->|<----------------------->|<---------->|
Domain Domain Domain
Operator Operator Operator
(D) |<--------->|<----------------------->|<---------->|
OAM Domain OAM Domain OAM Domain
Figure 8b: VPWS OAM Domains - Management Model 2
図8B：VPWS OAMドメイン - 管理モデル2
Note: It may be noted that unlike VPLS OAM Domain in Figure 4, where multiple operator domains may occur between the User-facing PE (U-PE) devices, VPWS OAM domain in Figures 8a and 8b highlights a single operator domain between PE devices. This is since, unlike the distributed VPLS PE case (D-VPLS), where VPLS-aware U-PEs and Network-facing PEs (N-PEs) may be used to realize a distributed PE, the VPWS has no such distributed PE model. If the PSN involves multiple operator domains, resulting in a Multi-segment PW [MS-PW-Arch], VPWS OAM Domains remain unchanged since switched PEs are typically not aware of native service.
注：図4のVPLS OAMドメインとは異なり、ユーザー向けのPE（U-PE）デバイス、図8Aおよび8BのVPWS OAMドメイン間で複数の演算子ドメインが発生する可能性があることに注意してください。。これは、分散型VPLS PEケース（D-VPLS）とは異なり、VPLS認識U-PEとネットワーク向けPES（N-PE）を使用して分散PEを実現できるため、VPWSにはそのような分散PEモデルがありません。。PSNに複数の演算子ドメインが関与し、マルチセグメントPW [MS-PW-ARCH]をもたらす場合、Switched PESは通常ネイティブサービスを認識していないため、VPWS OAMドメインは変化しません。
The location of MEPs and MIPs can be based upon the management model used in the VPWS scenarios. The interest remains in being able to monitor end-to-end service and also support segment monitoring in the network to allow isolation of faults to specific areas within the network.
MEPとMIPの位置は、VPWSシナリオで使用される管理モデルに基づいています。エンドツーエンドのサービスを監視し、ネットワーク内のセグメント監視をサポートして、ネットワーク内の特定の領域に障害を分離できるようにすることに関心があります。
The end-to-end service monitoring is provided by an end-to-end ME, and additional segment OAM monitoring is provided by segment MEs, all in the service provider OAM domain. The end-to-end MEs and segment MEs are hierarchically organized as mentioned in Section 4.2 for hierarchical OAM domains. This is shown in (B) and (C) in Figure 8b.
エンドツーエンドのサービス監視は、エンドツーエンドのMEによって提供され、追加のセグメントOAMモニタリングは、すべてサービスプロバイダーOAMドメインのセグメントMESによって提供されます。エンドツーエンドのMESおよびセグメントMESは、階層的なOAMドメインのセクション4.2で述べたように、階層的に編成されています。これは、図8bに（b）および（c）に示されています。
The CE interfaces support MEPs at the end-to-end service provider OAM level for VPWS as an end-to-end service as shown in (B1) and (B2) in Figure 9. In addition, PE interfaces may support MIPs at the end-to-end service provider OAM level when PEs are client service aware, as shown in (B2) in Figure 9. As an example, if one considers an end-to-end Ethernet line service offered using ATM transport (ATM over MPLS PW), then the PEs are considered to be Ethernet service unaware and therefore cannot support any Ethernet MIPs. (B1) in Figure 9 represents this particular situation. Of course, another view of the end-to-end service can be ATM, in which case PE1 and PE2 can be considered to be service aware and therefore support ATM MIPs. (B2) in Figure 9 represents this particular situation.
CEインターフェイスは、図9の（B1）および（B2）に示すように、エンドツーエンドサービスとしてVPWのエンドツーエンドサービスプロバイダーOAMレベルでMEPをサポートします。さらに、PEインターフェイスは、PEインターフェイスをサポートする場合があります。エンドツーエンドのサービスプロバイダーOAMレベル図9の（B2）に示すように、PESがクライアントサービスを認識している場合。例として、ATM輸送を使用して提供されるエンドツーエンドのイーサネットラインサービスを考慮した場合（MPLSオーバーATMPW）、PESはイーサネットサービスとは認識されていないと見なされ、したがって、イーサネットMIPSをサポートできません。（b1）図9は、この特定の状況を表しています。もちろん、エンドツーエンドサービスの別のビューはATMである可能性があります。この場合、PE1とPE2はサービスを認識していると見なされるため、ATM MIPをサポートできます。（B2）図9は、この特定の状況を表しています。
In addition, CEs and PE interfaces support MEPs at a segment (lower level) service provider OAM level for AC and PW MEs, and no MIPs are involved at this segment service provider OAM level, as shown in (C) in Figure 9. Operators may also run segment OAM by having MEPs at network operator OAM level, as shown in (D) in Figure 9.
さらに、CESおよびPEインターフェイスは、ACおよびPW MESのセグメント（下位レベル）サービスプロバイダーOAMレベルでMEPをサポートし、図9の（c）に示すように、このセグメントサービスプロバイダーOAMレベルにはMIPが関与していません。図9に示すように、ネットワークオペレーターOAMレベルでMEPを使用することにより、セグメントOAMを実行することもできます。
The advantage of having layered OAM is that end-to-end and segment OAM can be carried out in an independent manner. It is also possible to carry out some optimizations, e.g., when proactive segment OAM monitoring is performed, proactive end-to-end monitoring may not be needed since client layer end-to-end ME could simply use fault notifications from the server layer segment MEs.
OAMを重ねたことの利点は、エンドツーエンドとセグメントOAMを独立した方法で実行できることです。また、いくつかの最適化を実行することも可能です。たとえば、プロアクティブセグメントOAMモニタリングが実行される場合、クライアントレイヤーエンドツーエンドでは、サーバーレイヤーセグメントからの障害通知を単純に使用できるため、プロアクティブなエンドツーエンドモニタリングは必要ない場合があります。mes。
Although many different OAM layers are possible, as shown in Figure 9, not all may be realized. For example, (B2) and (D) in Figure 9 may be adequate in some cases.
図9に示すように、多くの異なるOAM層が可能ですが、すべてが実現されるわけではありません。たとえば、図9の（b2）と（d）は場合によっては適切な場合があります。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(B1) MEP-----------------------------------------------MEP
(B2) MEP----------MIP---------------------MIP----------MEP
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure 9: VPWS MEPs and MIPs
図9：VPWS MEPSおよびMIPS
In VPWS, the MEPs and MIPs should be identified with their native addressing schemes. MEPs and MIPs Identifiers, i.e., MEP Ids and MIP Ids, must be unique to the VPWS instance and in the context of their corresponding OAM domains.
VPWSでは、MEPとMIPはネイティブアドレス指定スキームで識別される必要があります。MEPとMIPSの識別子、つまりMEP IDとMIP IDSは、VPWSインスタンスと、対応するOAMドメインのコンテキストにおいて一意でなければなりません。
These requirements are applicable to VPLS PE offering VPLS as an Ethernet Bridged LAN service, as described in Section 5.1.1. Further, the performance metrics used in requirements are based on [MEF10.1] and [RFC2544].
これらの要件は、セクション5.1.1で説明されているように、イーサネットブリッジ付きLANサービスとしてVPLを提供するVPLに適用されます。さらに、要件で使用されるパフォーマンスメトリックは[MEF10.1]および[RFC2544]に基づいています。
It is noted that OAM solutions that meet the following requirements may make use of existing OAM mechanisms, e.g., Ethernet OAM, VCCV, etc.; however, they must not break these existing OAM mechanisms. If extensions are required to existing OAM mechanisms, these should be coordinated with relevant groups responsible for these OAM mechanisms.
以下の要件を満たすOAMソリューションは、既存のOAMメカニズム、例えばイーサネットOAM、VCCVなどを利用する可能性があることに注意してください。ただし、これらの既存のOAMメカニズムを破ってはなりません。既存のOAMメカニズムに拡張が必要な場合、これらはこれらのOAMメカニズムの原因となる関連グループと調整する必要があります。
Discovery allows a VPLS-aware device to learn about other devices that support the same VPLS instance within a given domain.
Discoveryを使用すると、VPLS認識デバイスは、特定のドメイン内の同じVPLSインスタンスをサポートする他のデバイスについて学習できます。
Discovery also allows a VPLS-aware device to learn sufficient information (e.g., IP addresses, MAC addresses, etc.) from other VPLS-aware devices such that VPLS OAM frames can be exchanged among the service-aware devices.
また、Discoveryを使用すると、VPLS AWAREデバイスは、VPLS OAMフレームをサービスアウェアデバイス間で交換できるように、他のVPLS認識デバイスから十分な情報（IPアドレス、Macアドレスなど）を学習できます。
(R1) VPLS OAM MUST allow a VPLS-aware device to discover other devices that share the same VPLS instance(s) within a given OAM domain.
（R1）VPLS OAMでは、VPLS認識デバイスが特定のOAMドメイン内で同じVPLSインスタンスを共有する他のデバイスを発見する必要があります。
VPLS is realized by exchanging service frames/packets between devices that support the same VPLS instance. To allow the exchange of service frames, connectivity between these service-aware devices is required.
VPLSは、同じVPLSインスタンスをサポートするデバイス間でサービスフレーム/パケットを交換することで実現されます。サービスフレームの交換を許可するには、これらのサービスアウェアデバイス間の接続が必要です。
To ensure service, proactive connectivity monitoring is required. Connectivity monitoring facilitates connectivity fault detection.
サービスを確保するには、プロアクティブな接続監視が必要です。接続監視により、接続障害検出が容易になります。
(R2a) VPLS OAM MUST allow proactive connectivity monitoring between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R2A）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間のプロアクティブ接続監視を許可する必要があります。
Once a connectivity fault is detected, connectivity fault verification may be performed.
接続障害が検出されると、接続障害の検証が実行される場合があります。
(R2b) VPLS OAM MUST allow connectivity fault verification between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R2B）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間の接続障害検証を許可する必要があります。
Further, localization of connectivity fault may be carried out.
さらに、接続障害のローカライズを実行することができます。
(R2c) VPLS OAM MUST allow connectivity fault localization between two VPLS-aware devices that support the same instance within a given OAM domain.
（R2C）VPLS OAMは、特定のOAMドメイン内の同じインスタンスをサポートする2つのVPLS認識デバイス間の接続障害のローカリゼーションを許可する必要があります。
Typically, when a connectivity fault is detected and optionally verified, the VPLS device may notify the NMS (Network Management System) via alarms.
通常、接続障害が検出され、オプションで検証された場合、VPLSデバイスはアラームを介してNMS（ネットワーク管理システム）に通知する場合があります。
However, a single transport/network fault may cause multiple services to fail simultaneously, thereby causing multiple service alarms. Therefore, VPLS OAM must allow service-level fault notification to be triggered at the client layer as a result of transport/network faults in the service layer. This fault notification should be used for the suppression of service-level alarms at the client layer.
ただし、単一の輸送/ネットワーク障害により、複数のサービスが同時に失敗する可能性があり、それにより複数のサービスアラームが発生する場合があります。したがって、VPLS OAMは、サービスレイヤーの輸送/ネットワーク障害の結果として、クライアントレイヤーでサービスレベルの障害通知をトリガーする必要があります。この障害通知は、クライアントレイヤーでのサービスレベルのアラームの抑制に使用する必要があります。
(R2d) VPLS OAM MUST support fault notification to be triggered as a result of transport/network faults. This fault notification SHOULD be used for the suppression of redundant service-level alarms.
（R2D）VPLS OAMは、輸送/ネットワーク障害の結果としてトリガーされるための障害通知をサポートする必要があります。この障害通知は、冗長サービスレベルのアラームの抑制に使用する必要があります。
A VPLS may be considered degraded if service-layer frames/packets are lost during transit between the VPLS-aware devices. To determine if a VPLS is degraded due to frame/packet loss, measurement of frame/packet loss is required.
VPLS認識デバイス間の輸送中にサービス層フレーム/パケットが失われる場合、VPLは劣化したと見なされる場合があります。フレーム/パケット損失のためにVPLSが分解されるかどうかを判断するには、フレーム/パケット損失の測定が必要です。
(R3) VPLS OAM MUST support measurement of per-service frame/packet loss between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R3）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間のサービスごとのフレーム/パケット損失の測定をサポートする必要があります。
A VPLS may be sensitive to delay experienced by the VPLS frames/packets during transit between the VPLS-aware devices. To determine if a VPLS is degraded due to frame/packet delay, measurement of frame/packet delay is required.
VPLSは、VPLS認識デバイス間のトランジット中にVPLSフレーム/パケットが経験する遅延に敏感になる場合があります。フレーム/パケットの遅延によりVPLSが分解されるかどうかを判断するには、フレーム/パケットの遅延の測定が必要です。
VPLS frame/packet delay measurement can be of two types:
VPLSフレーム/パケット遅延測定には、次の2つのタイプがあります。
1) One-way delay is used to characterize certain applications like multicast and broadcast applications. The measurement for one-way delay usually requires clock synchronization between the two devices in question.
1) 一元配置遅延は、マルチキャストやブロードキャストアプリケーションなどの特定のアプリケーションを特徴付けるために使用されます。一元配置遅延の測定には、通常、問題の2つのデバイス間の時計同期が必要です。
2) Two-way delay or round-trip delay does not require clock synchronization between the two devices involved in measurement and is usually sufficient to determine the frame/packet delay being experienced.
2) 双方向の遅延または往復遅延は、測定に関与する2つのデバイス間の時計の同期を必要とせず、通常、経験されているフレーム/パケット遅延を決定するのに十分です。
(R4a) VPLS OAM MUST support measurement of per-service two-way frame/packet delay between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R4A）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間のサービスごとの双方向フレーム/パケット遅延の測定をサポートする必要があります。
(R4b) VPLS OAM SHOULD support measurement of per-service one-way frame/packet delay between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R4B）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間のサービスごとの一元配置/パケット遅延の測定をサポートする必要があります。
A VPLS may be sensitive to delay variation experienced by the VPLS frames/packets during transit between the VPLS-aware devices. To determine if a VPLS is degraded due to frame/packet delay variation, measurement of frame/packet delay variation is required. For frame/packet delay variation measurements, one-way mechanisms are considered to be sufficient.
VPLSは、VPLS認識デバイス間のトランジット中にVPLSフレーム/パケットが経験する遅延変動に敏感である場合があります。フレーム/パケット遅延の変動によりVPLSが分解されるかどうかを判断するには、フレーム/パケット遅延の変動の測定が必要です。フレーム/パケット遅延変動測定の場合、一方向のメカニズムで十分であると考えられています。
(R5) VPLS OAM MUST support measurement of per-service frame/packet delay variation between two VPLS-aware devices that support the same VPLS instance within a given OAM domain.
（R5）VPLS OAMは、特定のOAMドメイン内の同じVPLSインスタンスをサポートする2つのVPLS認識デバイス間のサービスごとのフレーム/パケット遅延変動の測定をサポートする必要があります。
A service may be considered unavailable if the service frames/packets do not reach their intended destination (e.g., connectivity is down or frame/packet loss is occurring) or the service is degraded (e.g., frame/packet delay and/or delay variation threshold is exceeded).
サービスフレーム/パケットが意図した宛先に到達しない場合（たとえば、接続性が低下したり、フレーム/パケットの損失が発生している）、またはサービスが劣化している場合（例：フレーム/パケットの遅延および/または遅延変動しきい値のしきい値が低下した場合、サービスは利用できないと見なされる場合があります。超えています）。
Entry and exit conditions may be defined for unavailable state. Availability itself may be defined in context of service type.
入場および出口条件は、利用できない状態で定義される場合があります。可用性自体は、サービスタイプのコンテキストで定義できます。
Since availability measurement may be associated with connectivity, frame/packet loss, frame/packet delay, and frame/packet delay variation measurements, no additional requirements are specified currently.
可用性測定は、接続性、フレーム/パケット損失、フレーム/パケット遅延、フレーム/パケット遅延変動測定に関連付けられている可能性があるため、現在、追加要件は指定されていません。
If the VPLS OAM frames flow across a different path than the one used by VPLS frames/packets, accurate measurement and/or determination of service state may not be made. Therefore, data path, i.e., the one being taken by VPLS frames/packets, must be used for the VPLS OAM.
VPLSフレームがVPLSフレーム/パケットで使用されているパスとは異なるパスを越えて流れる場合、正確な測定および/またはサービス状態の決定は行われない場合があります。したがって、データパス、つまりVPLSフレーム/パケットによって採取されているものは、VPLS OAMに使用する必要があります。
(R6) VPLS OAM frames MUST be forwarded along the same path (i.e., links and nodes) as the VPLS frames.
（R6）VPLSフレームは、VPLSフレームと同じパス（つまり、リンクとノード）に沿って転送する必要があります。
Mechanisms developed for VPLS OAM need to be such that per-service OAM can be supported even though the OAM may only be used for limited VPLS instances, e.g., premium VPLS instances, and may not be used for best-effort VPLSs.
VPLS OAM用に開発されたメカニズムは、OAMが限られたVPLSインスタンス、たとえばプレミアムVPLSインスタンスにのみ使用され、ベストエフォートVPLSに使用されない場合でも、サービスごとのOAMをサポートできるようにする必要があります。
(R7) VPLS OAM MUST be scalable such that a service-aware device can support OAM for each VPLS that is supported by the device.
（R7）VPLS OAMは、デバイスでサポートされている各VPLのOAMをサポートできるように、スケーラブルでなければなりません。
Extensibility is intended to allow introduction of additional OAM functionality in the future such that backward compatibility can be maintained when interoperating with older version devices. In such a case, VPLS OAM with reduced functionality should still be possible. Further, VPLS OAM should be defined such that OAM incapable devices in the middle of the OAM domain should be able to forward the VPLS OAM frames similar to the regular VPLS data frames/packets.
拡張性は、古いバージョンのデバイスと相互に拡張するときに後方互換性を維持できるように、将来の追加のOAM機能の導入を可能にすることを目的としています。そのような場合、機能を低下させたVPLS OAMはまだ可能です。さらに、VPLS OAMは、OAMドメインの中央にあるOAMが不能なデバイスが、通常のVPLSデータフレーム/パケットと同様のVPLS OAMフレームを転送できるように定義する必要があります。
(R8a) VPLS OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in the future.
（R8A）VPLS OAMは、この機能に関連する新しい機能と情報要素を将来導入できるように拡張可能でなければなりません。
(R8b) VPLS OAM MUST be defined such that devices not supporting the OAM are able to forward the OAM frames in a similar fashion as the regular VPLS data frames/packets.
（R8B）VPLS OAMは、OAMをサポートしていないデバイスが通常のVPLSデータフレーム/パケットと同様の方法で転送できるように定義する必要があります。
VPLS OAM frames belonging to an OAM domain originate and terminate within that OAM domain. Security implies that an OAM domain must be capable of filtering OAM frames. The filtering is such that the OAM frames are prevented from leaking outside their domain. Also, OAM frames from outside the OAM domains should be either discarded (when such OAM frames belong to the same level or to a lower-level OAM domain) or transparently passed (when such OAM frames belong to a higher-level OAM domain).
OAMドメインに属するVPLS OAMフレームは、そのOAMドメイン内で発生し、終了します。セキュリティは、OAMドメインがOAMフレームをフィルタリングできることを意味します。フィルタリングは、OAMフレームがドメインの外に漏れることを防ぐようなものです。また、OAMドメインの外側からのOAMフレームは、そのようなOAMフレームが同じレベルに属する場合、または低レベルのOAMドメインに属する場合）または透過的に通過する必要があります（そのようなOAMフレームが高レベルのOAMドメインに属する場合）。
(R9a) VPLS OAM frames MUST be prevented from leaking outside their OAM domain.
（R9A）VPLS OAMフレームは、OAMドメインの外に漏れることを防ぐ必要があります。
(R9b) VPLS OAM frames from outside an OAM domain MUST be prevented from entering the OAM domain when such OAM frames belong to the same level or to a lower-level OAM domain.
（R9B）OAMドメインの外側からのVPLS OAMフレームは、そのようなOAMフレームが同じレベルまたは低レベルのOAMドメインに属している場合、OAMドメインに入ることを防ぐ必要があります。
(R9c) VPLS OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to a higher-level OAM domain.
（R9C）OAMドメインの外側からのVPLS OAMフレームは、そのようなOAMフレームが高レベルのOAMドメインに属している場合、OAMドメイン内で透過的に輸送する必要があります。
VPLS frame/packets delivery is carried out across transport infrastructure, also called network infrastructure. Though specific transport/network technologies may provide their own OAM capabilities, VPLS OAM must be independently supported as many different transport/network technologies can be used to carry service frame/packets.
VPLSフレーム/パケット配信は、ネットワークインフラストラクチャとも呼ばれるトランスポートインフラストラクチャ間で実行されます。特定のトランスポート/ネットワークテクノロジーは独自のOAM機能を提供する場合がありますが、VPLS OAMは、サービスフレーム/パケットを運ぶために多くの異なるトランスポート/ネットワークテクノロジーを使用できるため、独立してサポートする必要があります。
(R10a) VPLS OAM MUST be independent of the underlying transport/network technologies and specific transport/network OAM capabilities.
（R10A）VPLS OAMは、基礎となる輸送/ネットワークテクノロジーと特定の輸送/ネットワークOAM機能とは無関係でなければなりません。
(R10b) VPLS OAM MAY allow adaptation/interworking with specific transport/network OAM functions. For example, this would be useful to allow fault notifications from transport/network layer(s) to be sent to the VPLS layer.
（R10B）VPLS OAMは、特定のトランスポート/ネットワークOAM関数との適応/相互作用を可能にする場合があります。たとえば、これは、トランスポート/ネットワークレイヤーからの障害通知をVPLSレイヤーに送信できるようにするのに役立ちます。
VPLS itself may be used to carry application frame/packets. The application may use its own OAM; service OAM must not be dependent on application OAM. As an example, a VPLS may be used to carry IP traffic; however, VPLS OAM should not assume IP or rely on the use of IP-level OAM functions.
VPL自体は、アプリケーションフレーム/パケットを運ぶために使用できます。アプリケーションは独自のOAMを使用する場合があります。サービスOAMは、アプリケーションOAMに依存してはなりません。例として、VPLはIPトラフィックを運ぶために使用できます。ただし、VPLS OAMはIPを想定したり、IPレベルのOAM関数の使用に依存したりしてはなりません。
(R11a) VPLS OAM MUST be independent of the application technologies and specific application OAM capabilities.
（R11a）VPLS OAMは、アプリケーションテクノロジーと特定のアプリケーションOAM機能に依存しない必要があります。
These requirements are applicable to VPWS PE. The performance metrics used in requirements are based on [MEF10.1] and [RFC2544], which are applicable to Ethernet services.
これらの要件は、VPWS PEに適用されます。要件で使用されるパフォーマンスメトリックは、[MEF10.1]および[RFC2544]に基づいており、イーサネットサービスに適用できます。
It is noted that OAM solutions that meet the following requirements may make use of existing OAM mechanisms, e.g., Ethernet OAM, VCCV, etc.; however, they must not break these existing OAM mechanisms. If extensions are required to existing OAM mechanisms, these should be coordinated with relevant groups responsible for these OAM mechanisms.
以下の要件を満たすOAMソリューションは、既存のOAMメカニズム、例えばイーサネットOAM、VCCVなどを利用する可能性があることに注意してください。ただし、これらの既存のOAMメカニズムを破ってはなりません。既存のOAMメカニズムに拡張が必要な場合、これらはこれらのOAMメカニズムの原因となる関連グループと調整する必要があります。
Discovery allows a VPWS-aware device to learn about other devices that support the same VPWS instance within a given domain. Discovery also allows a VPWS-aware device to learn sufficient information (e.g., IP addresses, MAC addresses, etc.) from other VPWS-aware devices such that OAM frames can be exchanged among the VPWS-aware devices.
Discoveryを使用すると、VPWS対応デバイスは、特定のドメイン内の同じVPWSインスタンスをサポートする他のデバイスについて学習できます。また、Discoveryを使用すると、VPWS対応デバイスは、OAMフレームをVPWS対応デバイス間で交換できるように、他のVPWS対応デバイスから十分な情報（IPアドレス、Macアドレスなど）を学習できます。
(R12) VPWS OAM MUST allow a VPWS-aware device to discover other devices that share the same VPWS instance(s) within a given OAM domain.
（R12）VPWS OAMでは、VPWS認識デバイスが特定のOAMドメイン内で同じVPWSインスタンスを共有する他のデバイスを発見することを許可する必要があります。
VPWS is realized by exchanging service frames/packets between devices that support the same VPWS instance. To allow the exchange of service frames, connectivity between these service-aware devices is required.
VPWSは、同じVPWSインスタンスをサポートするデバイス間でサービスフレーム/パケットを交換することで実現されます。サービスフレームの交換を許可するには、これらのサービスアウェアデバイス間の接続が必要です。
To ensure service, proactive connectivity monitoring is required. Connectivity monitoring facilitates connectivity fault detection.
サービスを確保するには、プロアクティブな接続監視が必要です。接続監視により、接続障害検出が容易になります。
(R13a) VPWS OAM MUST allow proactive connectivity monitoring between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R13A）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWS対応デバイス間のプロアクティブ接続監視を許可する必要があります。
(R13b) VPWS OAM mechanism SHOULD allow detection of mis-branching or mis-connections.
（R13B）VPWS OAMメカニズムは、誤った分岐または誤接続の検出を可能にする必要があります。
Once a connectivity fault is detected, connectivity fault verification may be performed.
接続障害が検出されると、接続障害の検証が実行される場合があります。
(R13c) VPWS OAM MUST allow connectivity fault verification between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R13C）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWS対応デバイス間の接続障害検証を許可する必要があります。
Further, localization of connectivity fault may be carried out. This may amount to identifying the specific AC and/or PW that is resulting in the VPWS connectivity fault.
さらに、接続障害のローカライズを実行することができます。これは、VPWS接続障害をもたらす特定のACおよび/またはPWを識別することに相当する場合があります。
(R13d) VPWS OAM MUST allow connectivity fault localization between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R13D）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWS対応デバイス間の接続障害のローカリゼーションを許可する必要があります。
Typically, when a connectivity fault is detected and optionally verified, the service device may notify the NMS (Network Management System) via alarms.
通常、接続障害が検出され、オプションで検証された場合、サービスデバイスはアラームを介してNMS（ネットワーク管理システム）に通知する場合があります。
However, a single transport/network fault may cause multiple services to fail simultaneously causing multiple service alarms. Therefore, OAM must allow service-level fault notification to be triggered at the client layer as a result of transport/network faults in the service layer. This fault notification should be used for the suppression of service-level alarms at the client layer.
ただし、単一の輸送/ネットワーク障害により、複数のサービスが同時に故障して複数のサービスアラームが発生する可能性があります。したがって、OAMは、サービスレイヤーの輸送/ネットワーク障害の結果として、クライアントレイヤーでサービスレベルの障害通知をトリガーする必要があります。この障害通知は、クライアントレイヤーでのサービスレベルのアラームの抑制に使用する必要があります。
For example, if an AC fails, both the local CE and the local PE, which are connected via the AC, may detect the connectivity failure. The local CE must notify the remote CE about the failure while the local PE must notify the remote PE about the failure.
たとえば、ACが失敗した場合、ACを介して接続されているローカルCEとローカルPEの両方が、接続障害を検出する場合があります。ローカルCEは、障害についてリモートCEに通知する必要がありますが、ローカルPEは障害についてリモートPEに通知する必要があります。
(R13e) VPWS OAM MUST support fault notification to be triggered as a result of transport/network faults. This fault notification SHOULD be used for the suppression of redundant service-level alarms.
（R13E）VPWS OAMは、輸送/ネットワーク障害の結果としてトリガーされるための障害通知をサポートする必要があります。この障害通知は、冗長サービスレベルのアラームの抑制に使用する必要があります。
(R13f) VPWS OAM SHOULD support fault notification in backward direction, to be triggered as a result of transport/network faults. This fault notification SHOULD be used for the suppression of redundant service-level alarms.
（R13F）VPWS OAMは、輸送/ネットワーク障害の結果としてトリガーされるために、後方方向の障害通知をサポートする必要があります。この障害通知は、冗長サービスレベルのアラームの抑制に使用する必要があります。
A VPWS may be considered degraded if service-layer frames/packets are lost during transit between the VPWS-aware devices. To determine if a VPWS is degraded due to frame/packet loss, measurement of frame/packet loss is required.
VPWS対応デバイス間の輸送中にサービス層フレーム/パケットが失われる場合、VPWは劣化したと見なされる場合があります。フレーム/パケットの損失のためにVPWが分解されるかどうかを判断するには、フレーム/パケット損失の測定が必要です。
(R14) VPWS OAM MUST support measurement of per-service frame/packet loss between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R14）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWS対応デバイス間のサービスごとのフレーム/パケット損失の測定をサポートする必要があります。
A VPWS may be sensitive to delay experienced by the VPWS frames/packets during transit between the VPWS-aware devices. To determine if a VPWS is degraded due to frame/packet delay, measurement of frame/packet delay is required.
VPWは、VPWS対応デバイス間の輸送中にVPWSフレーム/パケットが経験する遅延に敏感になる可能性があります。フレーム/パケットの遅延によりVPWが分解されるかどうかを判断するには、フレーム/パケットの遅延の測定が必要です。
VPWS frame/packet delay measurement can be of two types:
VPWSフレーム/パケット遅延測定には、次の2つのタイプがあります。
1) One-way delay is used to characterize certain applications like multicast and broadcast applications. The measurement for one-way delay usually requires clock synchronization between the two devices in question.
1) 一元配置遅延は、マルチキャストやブロードキャストアプリケーションなどの特定のアプリケーションを特徴付けるために使用されます。一元配置遅延の測定には、通常、問題の2つのデバイス間の時計同期が必要です。
2) Two-way delay or round-trip delay does not require clock synchronization between the two devices involved in measurement and is usually sufficient to determine the frame/packet delay being experienced.
2) 双方向の遅延または往復遅延は、測定に関与する2つのデバイス間の時計の同期を必要とせず、通常、経験されているフレーム/パケット遅延を決定するのに十分です。
(R15a) VPWS OAM MUST support measurement of per-service two-way frame/packet delay between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R15A）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWSアウェアデバイス間のサービスごとの双方向フレーム/パケット遅延の測定をサポートする必要があります。
(R15b) VPWS OAM SHOULD support measurement of per-service one-way frame/packet delay between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R15B）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWSアウェアデバイス間のサービスごとの一方向フレーム/パケット遅延の測定をサポートする必要があります。
A VPWS may be sensitive to delay variation experienced by the VPWS frames/packets during transit between the VPWS-aware devices. To determine if a VPWS is degraded due to frame/packet delay variation, measurement of frame/packet delay variation is required. For frame/packet delay variation measurements, one-way mechanisms are considered to be sufficient.
VPWは、VPWS対応デバイス間のトランジット中にVPWSフレーム/パケットが経験する遅延変動に敏感である可能性があります。フレーム/パケット遅延の変動によりVPWが分解されるかどうかを判断するには、フレーム/パケット遅延の変動の測定が必要です。フレーム/パケット遅延変動測定の場合、一方向のメカニズムで十分であると考えられています。
(R16) VPWS OAM MUST support measurement of per-service frame/packet delay variation between two VPWS-aware devices that support the same VPWS instance within a given OAM domain.
（R16）VPWS OAMは、特定のOAMドメイン内の同じVPWSインスタンスをサポートする2つのVPWS対応デバイス間のサービスごとのフレーム/パケット遅延変動の測定をサポートする必要があります。
A service may be considered unavailable if the service frames/packets do not reach their intended destination (e.g., connectivity is down or frame/packet loss is occurring) or the service is degraded (e.g., frame/packet delay and/or delay variation threshold is exceeded).
サービスフレーム/パケットが意図した宛先に到達しない場合（たとえば、接続性が低下したり、フレーム/パケットの損失が発生している）、またはサービスが劣化している場合（例：フレーム/パケットの遅延および/または遅延変動しきい値のしきい値が低下した場合、サービスは利用できないと見なされる場合があります。超えています）。
Entry and exit conditions may be defined for unavailable state. Availability itself may be defined in context of service type.
入場および出口条件は、利用できない状態で定義される場合があります。可用性自体は、サービスタイプのコンテキストで定義できます。
Since availability measurement may be associated with connectivity, frame/packet loss, frame/packet delay, and frame/packet delay variation measurements, no additional requirements are specified currently.
可用性測定は、接続性、フレーム/パケット損失、フレーム/パケット遅延、フレーム/パケット遅延変動測定に関連付けられている可能性があるため、現在、追加要件は指定されていません。
If the VPWS OAM frames flow across a different path than the one used by VPWS frames/packets, accurate measurement and/or determination of service state may not be made. Therefore data path, i.e., the one being taken by VPWS frames/packets, must be used for the VPWS OAM.
VPWSフレームがVPWSフレーム/パケットで使用されているパスとは異なるパスを越えて流れる場合、正確な測定および/またはサービス状態の決定は行われない場合があります。したがって、データパス、つまりVPWSフレーム/パケットによって採取されているものは、VPWS OAMに使用する必要があります。
(R17a) VPWS OAM frames MUST be forwarded along the same path as the VPWS data frames.
（R17A）VPWS OAMフレームは、VPWSデータフレームと同じパスに沿って転送する必要があります。
(R17b) VPWS OAM MUST be forwarded using the transfer plane (data plane) as regular VPWS data frames/packets and must not rely on control plane messages.
（R17B）VPWS OAMは、通常のVPWSデータフレーム/パケットとして転送面（データプレーン）を使用して転送する必要があり、コントロールプレーンメッセージに依存してはなりません。
Mechanisms developed for VPWS OAM need to be such that per-service OAM can be supported even though the OAM may only be used for limited VPWS instances, e.g., premium VPWS instance, and may not be used for best-effort services.
VPWS OAM用に開発されたメカニズムは、OAMが限られたVPWSインスタンス、たとえばプレミアムVPWSインスタンスにのみ使用され、ベストエフェクトサービスには使用されない場合でも、サービスごとのOAMをサポートできるようにする必要があります。
(R18) VPWS OAM MUST be scalable such that a service-aware device can support OAM for each VPWS that is supported by the device.
（R18）VPWS OAMは、デバイスでサポートされている各VPWのOAMをサポートできるように、スケーラブルでなければなりません。
Extensibility is intended to allow introduction of additional OAM functionality in the future such that backward compatibility can be maintained when interoperating with older version devices. In such a case, VPWS OAM with reduced functionality should still be possible. Further, VPWS OAM should be such that OAM incapable devices in the middle of the OAM domain should be able to forward the VPWS OAM frames similar to the regular VPWS data frames/packets.
拡張性は、古いバージョンのデバイスと相互に拡張するときに後方互換性を維持できるように、将来の追加のOAM機能の導入を可能にすることを目的としています。そのような場合、機能が低下したVPWS OAMはまだ可能です。さらに、VPWS OAMは、OAMドメインの中央にあるOAMの無能力デバイスが、通常のVPWSデータフレーム/パケットと同様のVPWS OAMフレームを転送できるようにする必要があります。
(R19a) VPWS OAM MUST be extensible such that new functionality and information elements related to this functionality can be introduced in the future.
（R19A）VPWS OAMは、この機能に関連する新しい機能と情報要素を将来導入できるように拡張可能でなければなりません。
(R19b) VPWS OAM MUST be defined such that devices not supporting the OAM are able to forward the VPWS OAM frames in a similar fashion as the regular VPWS data frames/packets.
（R19B）VPWS OAMは、OAMをサポートしていないデバイスが、通常のVPWSデータフレーム/パケットと同様の方法でVPWS OAMフレームを転送できるように定義する必要があります。
VPWS OAM frames belonging to an OAM domain originate and terminate within that OAM domain. Security implies that an OAM domain must be capable of filtering OAM frames. The filtering is such that the VPWS OAM frames are prevented from leaking outside their domain. Also, VPWS OAM frames from outside the OAM domains should be either discarded (when such OAM frames belong to the same level or to a lower-level OAM domain) or transparently passed (when such OAM frames belong to a higher-level OAM domain).
OAMドメインに属するVPWS OAMフレームは、そのOAMドメイン内で発生し、終了します。セキュリティは、OAMドメインがOAMフレームをフィルタリングできることを意味します。フィルタリングは、VPWS OAMフレームがドメインの外に漏れることを防ぐようなものです。また、OAMドメインの外側からのVPWS OAMフレームは、そのようなOAMフレームが同じレベルに属している場合、または低レベルのOAMドメインに属する場合）または透過的に通過する必要があります（そのようなOAMフレームが高レベルのOAMドメインに属する場合）。
(R20a) VPWS OAM frames MUST be prevented from leaking outside their OAM domain.
（R20A）VPWS OAMフレームは、OAMドメインの外に漏れることを防ぐ必要があります。
(R20b) VPWS OAM frames from outside an OAM domain MUST be prevented from entering the OAM domain when such OAM frames belong to the same level or to a lower-level OAM domain.
（R20B）OAMドメインの外側からのVPWS OAMフレームは、そのようなOAMフレームが同じレベルまたは低レベルのOAMドメインに属している場合、OAMドメインに入ることを防ぐ必要があります。
(R20c) VPWS OAM frames from outside an OAM domain MUST be transported transparently inside the OAM domain when such OAM frames belong to a higher-level OAM domain.
（R20C）OAMドメインの外側からのVPWS OAMフレームは、そのようなOAMフレームが高レベルのOAMドメインに属している場合、OAMドメイン内で透過的に輸送する必要があります。
VPWS frame/packets delivery is carried out across transport infrastructure, also called network infrastructure. Though specific transport/network technologies may provide their own OAM capabilities, VPWS OAM must be independently supported as many different transport/network technologies can be used to carry service frame/packets.
VPWSフレーム/パケット配信は、ネットワークインフラストラクチャとも呼ばれるトランスポートインフラストラクチャ間で実行されます。特定のトランスポート/ネットワークテクノロジーは独自のOAM機能を提供する場合がありますが、VPWS OAMは、サービスフレーム/パケットを運ぶために多くの異なるトランスポート/ネットワークテクノロジーを使用できるため、独立してサポートする必要があります。
(R21a) VPWS OAM MUST be independent of the underlying transport/network technologies and specific transport/network OAM capabilities.
（R21A）VPWS OAMは、基礎となる輸送/ネットワークテクノロジーと特定の輸送/ネットワークOAM機能とは無関係でなければなりません。
(R21b) VPWS OAM MAY allow adaptation/interworking with specific transport/network OAM functions. For example, this would be useful to allow fault notifications from transport/network layer(s) to be sent to the VPWS layer.
（R21B）VPWS OAMは、特定のトランスポート/ネットワークOAM関数との適応/相互作用を可能にする場合があります。たとえば、これは、トランスポート/ネットワーク層からの障害通知をVPWSレイヤーに送信できるようにするのに役立ちます。
VPWS itself may be used to carry application frame/packets. The application may use its own OAM; VPWS OAM must not be dependent on application OAM. As an example, a VPWS may be used to carry IP traffic; however, VPWS OAM should not assume IP or rely on the use of IP-level OAM functions.
VPW自体は、アプリケーションフレーム/パケットを運ぶために使用できます。アプリケーションは独自のOAMを使用する場合があります。VPWS OAMは、アプリケーションOAMに依存してはなりません。例として、VPWはIPトラフィックを運ぶために使用できます。ただし、VPWS OAMはIPを想定したり、IPレベルのOAM関数の使用に依存したりしてはなりません。
(R22a) OAM MUST be independent of the application technologies and specific application OAM capabilities.
（R22A）OAMは、アプリケーションテクノロジーと特定のアプリケーションOAM機能とは無関係でなければなりません。
VPWS could be composed of several data flows, each related to a given usage/application with specific requirements in terms of connectivity and/or performance. Dedicated VPWS OAM should be applicable to these flows.
VPWは、接続および/またはパフォーマンスの観点から特定の要件を持つ特定の使用/アプリケーションに関連するいくつかのデータフローで構成されている可能性があります。専用のVPWS OAMは、これらのフローに適用する必要があります。
(R23) VPWS OAM SHOULD support configurable prioritization for OAM packet/frames to be compatible with associated VPWS packets/frames.
（R23）VPWS OAMは、関連するVPWSパケット/フレームと互換性があるOAMパケット/フレームの構成可能な優先順位付けをサポートする必要があります。
As indicated in [BRIDGE-INTEROP], VPLS OAM relies upon bidirectional Ethernet links or (V)LAN segments and failure in one direction or link results in failure of the whole link or (V)LAN segment. Therefore, when partial-mesh failure occurs in (V)LAN emulation, either the entire PW mesh should be shut down when only an entire VPLS is acceptable or a subset of PWs should be shut down such that the remaining PWs have full connectivity among them when partial VPLS is acceptable.
[Bridge-interop]に示されているように、VPLS OAMは双方向イーサネットリンクまたは（v）LANセグメントと一方向またはリンクの故障に依存しています。したがって、（V）LANエミュレーションで部分メッシュの障害が発生する場合、VPL全体が許容される場合、またはPWSのサブセットをシャットダウンする必要がある場合、PWメッシュ全体をシャットダウンする必要があります。部分的なVPLが許容される場合。
(R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow detection of a partial-mesh failure condition.
（R13A）A（V）LANエミュレーションに関連するPWのPW OAMは、部分メッシュ障害条件を検出する必要があります。
(R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the entire mesh of PWs to be shut down upon detection of a partial-mesh failure condition.
（R13B）A（V）LANエミュレーションに関連するPWのPW OAMは、部分メッシュの故障条件を検出すると、PWSのメッシュ全体をシャットダウンする必要があります。
(R13c) PW OAM for PWs related to a (V)LAN emulation MUST allow the subset of PWs to be shut down upon detection of a partial-mesh failure condition in a manner such that full mesh is present across the remaining subset.
（R13C）A（V）LANエミュレーションに関連するPWのPW OAMは、部分メッシュが残りのサブセット全体に存在するように、部分メッシュの故障条件を検出すると、PWSのサブセットをシャットダウンする必要があります。
Note: Shutdown action in R13b and R13c may not necessarily involve withdrawal of labels, etc.
注：R13BおよびR13Cでのシャットダウンアクションは、必ずしもラベルの撤回を含むとは限りません。
As indicated in [BRIDGE-INTEROP], VPLS OAM fault detection and recovery relies upon (V)LAN emulation recovery such that fault detection and recovery time in (V)LAN emulation should be less than the VPLS fault detection and recovery time to prevent unnecessary switch-over and temporary flooding/loop within the customer OAM domain that is dual-homed to the provider OAM domain.
[Bridge-interop]に示されているように、VPLS OAM障害検出と回復は、（V）LANエミュレーションの回復に依存しているため、（V）LANエミュレーションの障害検出と回復時間は、不必要な防止のためにVPLS障害検出と回復時間よりも短くする必要があります。プロバイダーOAMドメインにデュアルホームされた顧客OAMドメイン内のスイッチオーバーおよび一時的な洪水/ループ。
(R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a fault detection time in the provider OAM domain faster than the VPLS fault detection time in the customer OAM domain.
（R14A）A（V）LANエミュレーションに関連するPWのPW OAMは、顧客OAMドメインのVPLS障害検出時間よりも速いプロバイダーOAMドメインの障害検出時間をサポートする必要があります。
(R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a fault recovery time in the provider OAM domain faster than the VPLS fault recovery time in the customer OAM domain.
（R14B）A（V）LANエミュレーションに関連するPWのPW OAMは、顧客OAMドメインのVPLS障害回復時間よりも速いプロバイダーOAMドメインの障害回復時間をサポートする必要があります。
When a connectivity fault is detected in (V)LAN emulation, PE devices may notify the NMS (Network Management System) via alarms. However, a single (V)LAN emulation fault may result in CE devices or U-PE devices detecting a connectivity fault in VPLS and therefore also notifying the NMS. To prevent multiple alarms for the same fault, (V)LAN emulation OAM must provide alarm suppression capability in the VPLS OAM.
（V）LANエミュレーションで接続障害が検出されると、PEデバイスはアラームを介してNMS（ネットワーク管理システム）に通知する場合があります。ただし、単一の（V）LANエミュレーション障害により、CEデバイスまたはU-PEデバイスがVPLSの接続障害を検出するため、NMSも通知する場合があります。同じ障害の複数のアラームを防ぐには、（v）LANエミュレーションOAMがVPLS OAMでアラーム抑制機能を提供する必要があります。
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support interworking with VPLS OAM to trigger fault notification and allow alarm suppression in the VPLS upon fault detection in (V)LAN emulation.
（R15）A（V）LANエミュレーションに関連するPWのPW OAMは、VPLS OAMとのインターワーキングをサポートして障害通知をトリガーし、（V）LANエミュレーションで障害検出時にVPLSのアラーム抑制を許可する必要があります。
This section highlights how the different OAM mechanisms can be applied as per the OAM framework for different L2VPN services.
このセクションでは、さまざまなL2VPNサービスのOAMフレームワークに従って、さまざまなOAMメカニズムをどのように適用できるかを強調しています。
--- ---
/ \ ------ ------- ---- / \
| A CE-- / \ / \ / \ --CE A |
\ / \ / \ / \ / \ / \ /
--- --UPE NPE NPE UPE-- ---
\ / \ / \ /
\ / \ / \ /
------ ------- ----
Customer OAM Domain
(C) MEP---MIP--------------------------------MIP---MEP
Service Provider (SP) OAM Domain
(D) MEP--------MIP-----------MIP-------MEP
SP OAM SP OAM SP OAM
(D1) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
domain domain domain
Operator Operator Operator
(E) MEP-MIP--MEP|MEP-------MEP|MEP-----MEP
OAM domain OAM domain OAM domain
MPLS OAM MPLS OAM
(F) MEP--MIP-----MEP--MIP--MEP
domain domain
Figure 10: VPLS OAM Domains, MEPs, and MIPs
図10：VPLS OAMドメイン、MEP、およびMIPS
Among the different MEs identified in Figure 5 for VPLS OAM in the customer OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied to meet the various requirements identified in Section 7. The mechanisms can be applied across (C) in Figure 10 MEs.
顧客OAMドメインのVPLS OAMの図5で特定されたさまざまなMEの中で、[IEEE802.1AG]および[Y.1731]イーサネットOAMメカニズムを適用して、セクション7で特定されたさまざまな要件を満たすことができます。（c）図10 MES。
Similarly, inside the service provider OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can be applied across (D) MEs in Figure 10 to meet the functional requirements identified in Section 7.
同様に、サービスプロバイダーOAMドメイン内では、[IEEE802.1AG]および[Y.1731]イーサネットOAMメカニズムを図10のMESに適用して、セクション7で特定された機能要件を満たすことができます。
It may be noted that in the interim, when [IEEE802.1ag] and [Y.1731] capabilities are not available across the PE devices, the Fault Management option using segment OAM introduced in Section 6.2.3 can be applied, with the limitations cited below. In this option, the service provider can run segment OAM across the (D1) MEs in Figure 10. The OAM mechanisms across the (D1) MEs in Figure 10 can be non-Ethernet, e.g., Virtual Circuit Connectivity Verification (VCCV), or Bidirectional Forwarding Detection (BFD) when network technology is MPLS. The service provider can monitor each sub-network segment ME using the native technology OAM and, by performing interworking across the segment MEs, attempt to realize end-to-end monitoring between a pair of VPLS endpoints. However, such mechanisms do not fully exercise the data plane forwarding constructs as experienced by native (i.e., Ethernet) service PDUs. As a result, service monitoring ((D1) in Figure 10) is severely limited in the sense that it may lead to an indication that the ME between VPLS endpoints is functional while the customer may be experiencing end-to-end connectivity issues in the data plane.
暫定的には、[IEEE802.1AG]および[Y.1731]機能がPEデバイス全体で利用できない場合、セクション6.2.3で導入されたセグメントOAMを使用した障害管理オプションは、制限付きで適用できることに注意してください。以下で引用。このオプションでは、サービスプロバイダーは、図10の（D1）MESを越えてセグメントOAMを実行できます。図10の（D1）MEを横切るOAMメカニズムは、例えば、仮想回路接続検証（VCCV）、または仮想回路接続検証（VCCV）、またはネットワークテクノロジーがMPLSである場合、双方向転送検出（BFD）。サービスプロバイダーは、ネイティブテクノロジーOAMを使用して各サブネットワークセグメントを監視でき、セグメントMESを介してインターワーキングを実行することにより、VPLSエンドポイントのペア間のエンドツーエンドモニタリングを実現しようとします。ただし、このようなメカニズムは、ネイティブ（つまり、イーサネット）サービスPDUが経験するように、データプレーン転送構造を完全に行使しません。その結果、サービス監視（図10の（D1））は、VPLSエンドポイント間のMEが機能的である一方で、顧客がエンドツーエンドの接続性の問題を経験している可能性があるという意味で、非常に制限されています。データプレーン。
Inside the network operator OAM domain, [IEEE802.1ag] and [Y.1731] Ethernet OAM mechanisms can also be applied across MEs in (E) in Figure 10 to meet the functional requirements identified in Section 7. In addition, the network operator could decide to use native OAM mechanisms, e.g., VCCV or BFD, across (F) MEs for additional monitoring or as an alternative to monitoring across (E) MEs.
ネットワークオペレーターOAMドメイン内で、[IEEE802.1AG]および[Y.1731]イーサネットOAMメカニズムを図10のMESに適用して、セクション7で特定された機能要件を満たすこともできます。追加の監視のために、または（e）MES全体の監視に代わるものとして、（f）MESを超えて、ネイティブOAMメカニズム、例えばVCCVまたはBFDを使用することを決定できます。
This specification assumes that L2VPN components within the OAM domain are mutually trusted. Based on that assumption, confidentiality issues are fully addressed by filtering to prevent OAM frames from leaking outside their designated OAM domain. Similarly, authentication issues are addressed by preventing OAM frames generated outside a given OAM domain from entering the domain in question. Requirements to prevent OAM messages from leaking outside an OAM domain and for OAM domains to be transparent to OAM frames from higher OAM domains are specified in Sections 7.10 and 8.10.
この仕様は、OAMドメイン内のL2VPNコンポーネントが相互に信頼されていることを前提としています。その仮定に基づいて、機密性の問題は、OAMフレームが指定されたOAMドメインの外に漏れないようにフィルタリングすることにより完全に対処されます。同様に、認証の問題は、特定のOAMドメインの外で生成されたOAMフレームが問題のドメインに入るのを防ぐことにより対処されます。OAMメッセージがOAMドメインの外側に漏れないようにするための要件、およびOAMドメインがより高いOAMドメインからOAMフレームに透明になるためには、セクション7.10および8.10で指定されています。
For additional levels of security, solutions may be required to encrypt and/or authenticate OAM frames inside an OAM domain. However, these solutions are out of the scope of this document.
セキュリティの追加レベルのために、OAMドメイン内のOAMフレームを暗号化および/または認証するためにソリューションが必要になる場合があります。ただし、これらのソリューションはこのドキュメントの範囲外です。
In addition to the authors listed above, the following individuals also contributed to this document.
上記の著者に加えて、次の個人もこの文書に貢献しました。
Simon Delord Uecomm 658 Church St Richmond, VIC, 3121, Australia EMail: sdelord@uecomm.com.au
Simon Delord Uecomm 658 Church St Richmond、Vic、3121、Australiaメール：sdelord@uecomm.com.au
Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France EMail: philippe.niger@francetelecom.com
Philippe Niger France Telecom 2 Av。Pierre Marzin 22300 Lannion、France Email：Philippe.niger@francetelecom.com
Samer Salam Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: ssalam@cisco.com
Samer Salam Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134メール：ssalam@cisco.com
The authors would like to thank Deborah Brungard, Vasile Radoaca, Lei Zhu, Yuichi Ikejiri, Yuichiro Wada, and Kenji Kumaki for their reviews and comments.
著者は、レビューとコメントについて、デボラ・ブランガード、ヴァシール・ラドーカ、レイ・チュウ、ヨイチリ、王子島kenji kenjiに感謝したいと思います。
The authors would also like to thank Shahram Davari, Norm Finn, Dave Allan, Thomas Nadeau, Monique Morrow, Yoav Cohen, Marc Holness, Malcolm Betts, Paul Bottorff, Hamid-Ould Brahim, Lior Shabtay, and Dan Cauchy for their feedback.
著者はまた、Shahram Davari、Norm Finn、Dave Allan、Thomas Nadeau、Monique Morrow、Yoav Cohen、Marc Holness、Malcolm Betts、Paul Bottorff、Hamid-Brahim、Lior Shabtay、およびDan Cauchyのフィードバックに感謝します。
[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月。
[IEEE802.1ad] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 4: Provider Bridges", 2005.
[IEEE802.1AD]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ付きローカルエリアネットワーク、修正4：プロバイダーブリッジ」、2005年。
[IEEE802.1ag] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 5: Connectivity Fault Management", 2007.
[IEEE802.1AG]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク、修正5：接続障害管理」、2007年。
[IEEE802.1ah] "IEEE Standard for Local and metropolitan area networks - Virtual Bridged Local Area Networks, Amendment 6: Provider Backbone Bridges", 2008.
[IEEE802.1AH]「ローカルおよびメトロポリタンエリアネットワークのIEEE標準 - 仮想ブリッジ型ローカルエリアネットワーク、修正6：プロバイダーバックボーンブリッジ」、2008年。
[Y.1731] "ITU-T Recommendation Y.1731 (02/08) - OAM functions and mechanisms for Ethernet based networks", February 2008.
[Y.1731]「ITU -T推奨Y.1731（02/08） - 2008年2月にイーサネットベースのネットワークのOAM関数とメカニズム」。
[L2VPN-FRWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPN-FRWK] Andersson、L.、ed。、およびE. Rosen、ed。、「レイヤー2仮想プライベートネットワーク（L2VPNS）のフレームワーク」、RFC 4664、2006年9月。
[L2VPN-REQ] Augustyn, W., Ed., and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006.
[L2VPN-REQ] Augustyn、W.、ed。、およびY. Serbest、ed。、「レイヤー2プロバイダープロビジョニングされた仮想プライベートネットワークのサービス要件」、RFC 4665、2006年9月。
[L2VPN-TERM] Andersson, L. and T. Madsen, "Provider Provisioned Virtual Private Network (VPN) Terminology", RFC 4026, March 2005.
[L2VPN-Term] Andersson、L。およびT. Madsen、「プロバイダープロビジョニング仮想プライベートネットワーク（VPN）用語」、RFC 4026、2005年3月。
[MEF10.1] "Ethernet Services Attributes: Phase 2", MEF 10.1, 2006.
[MEF10.1]「イーサネットサービス属性：フェーズ2」、MEF 10.1、2006。
[NM-Standards] "TMN Management Functions", M.3400, February 2000.
[NMスタンダード]「TMN管理関数」、M.3400、2000年2月。
[VPLS-BGP] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, January 2007.
[VPLS-BGP] Kompella、K.、ed。、およびY. Rekhter、ed。、「自動配置とシグナル伝達のためにBGPを使用した仮想プライベートLANサービス（VPLS）」、RFC 4761、2007年1月。
[VPLS-LDP] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007.
[VPLS-LDP] Lasserre、M.、ed。、およびV. Kompella、ed。、「ラベル分布プロトコル（LDP）シグナル伝達を使用した仮想プライベートLANサービス（VPL）、RFC 4762、2007年1月。
[BRIDGE-INTEROP] Sajassi, A. Ed., Brockners, F., Mohan, D., Ed., and Y. Serbest, "VPLS Interoperability with CE Bridges", Work in Progress, October 2010.
[Bridge-Interop] Sajassi、A。Ed。、Brockners、F.、Mohan、D.、ed。、およびY. Serbest、「VPLSのCE Bridgesとの相互運用性」、2010年10月の進行中。
[L2VPN-SIG] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011.
[L2VPN-SIG] Rosen、E.、Davie、B.、Radoaca、V。、およびW. Luo、「プロビジョニング、自動ディスコービリ、およびレイヤー2仮想プライベートネットワーク（L2VPNS）のシグナリング」、RFC 6074、2011年1月。
[MS-PW-Arch] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[MS-PW-ARCH] Bocci、M。およびS. Bryant、「マルチセグメントの擬似ワイヤエミュレーションエッジツーエッジのアーキテクチャ」、RFC 5659、2009年10月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[RFC2544] Bradner、S。およびJ. McQuaid、「ネットワーク相互接続デバイスのベンチマーク方法論」、RFC 2544、1999年3月。
In consideration of the management models that can be deployed besides the hierarchical models elaborated in this document, this appendix highlights some alternate models that are not recommended due to their limitations, as pointed out below. These alternatives have been highlighted as potential interim models while the network equipment is upgraded to support full functionality and meet the requirements set forward by this document.
このドキュメントで詳しく説明されている階層モデルに加えて展開できる管理モデルを考慮して、この付録は、以下で指摘するように、制限のために推奨されないいくつかの代替モデルを強調しています。これらの代替案は潜在的な暫定モデルとして強調されていますが、ネットワーク機器は完全な機能をサポートし、このドキュメントによって定められた要件を満たすようにアップグレードされます。
In this model, the end-to-end service monitoring is provided by applying CE to CE ME in the service provider OAM domain.
このモデルでは、サービスプロバイダーOAMドメインにCEにCEを適用することにより、エンドツーエンドのサービス監視が提供されます。
A MEP is located at each CE interface that is part of the VPWS, as shown in (B) in Figure A.1. The network operators can carry out segment (e.g., PSN Tunnel ME, etc.) monitoring independent of the VPWS end-to-end service monitoring, as shown in (D) in Figure A.1.
MEPは、図A.1に（b）に示すように、VPWの一部である各CEインターフェイスにあります。ネットワークオペレーターは、図A.1の（d）に示すように、VPWSエンドツーエンドサービスモニタリングとは無関係に、セグメント（例：PSNトンネルMEなど）を実行できます。
The advantage of this option is that VPWS monitoring is limited to CEs. The limitation of this option is that the localization of faults is at the VPWS level.
このオプションの利点は、VPWSモニタリングがCESに限定されていることです。このオプションの制限は、障害のローカリゼーションがVPWSレベルにあることです。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(B) MEP-----------------------------------------------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A.1: VPWS MEPs and MIPs (Minimal OAM)
図A.1：VPWS MEPSおよびMIPS（最小OAM）
In this model, end-to-end service monitoring is provided by interworking OAM across each segment. Typical segments involved in this case include two AC MEs and a PW ME, as shown in (C) in Figure A.2. These segments are expected in the service provider OAM domain. An interworking function is required to transfer the OAM information flows across the OAM segments for the purposes of end-to-end monitoring. Depending on whether homogenous VPWS is deployed or heterogeneous VPWS is deployed, the interworking function could be straightforward or more involved.
このモデルでは、エンドツーエンドのサービス監視が、各セグメント全体でOAMインターワーキングによって提供されます。この場合に関与する典型的なセグメントには、図A.2に（c）に示すように、2つのAC MEとPW MEが含まれます。これらのセグメントは、サービスプロバイダーOAMドメインで予想されます。エンドツーエンドの監視を目的として、OAM情報フローをOAMセグメント全体に転送するには、インターワーキング関数が必要です。同種のVPWが展開されるか、異種のVPWが展開されているかどうかに応じて、インターワーキング関数は簡単またはより複雑になる可能性があります。
In this option, the CE and PE interfaces support MEPs for AC and PW MEs, and no MIPs are involved at the service provider OAM level, as shown in (C) in Figure A.2. Network operators may run segment OAM by having MEPs at the network operator OAM level, as shown in (D) in Figure A.2.
このオプションでは、CEおよびPEインターフェイスはACおよびPW MESのMEPをサポートしており、図A.2の（c）に示すように、サービスプロバイダーOAMレベルにはMIPが関与していません。ネットワークオペレーターは、図A.2に示すように、ネットワーク演算子OAMレベルにMEPを持つことにより、セグメントOAMを実行できます。
The limitations of this model are that it requires interworking across the OAM segments and does not conform to the OAM layering principles, where each OAM layer ought to be independent of the others. For end-to-end OAM determinations, the end-to-end service frame path is not necessarily exercised. Further, it requires interworking function implementation for all possible technologies across access and core that may be used to realize end-to-end services.
このモデルの限界は、OAMセグメント全体でインターワーキングを必要とし、各OAM層が他のOAM層から独立しているはずであるOAM層の原則に準拠していないことです。エンドツーエンドのOAM決定の場合、エンドツーエンドのサービスフレームパスが必ずしも行使されるわけではありません。さらに、エンドツーエンドサービスを実現するために使用できるアクセスとコアを介したすべての可能なテクノロジーのインターワーキング関数実装が必要です。
|<--------------- VPWS <AC1,PW,AC2> -------------->|
| |
| +----+ +----+ |
+----+ | |==================| | +----+
| |---AC1----|............PW..............|--AC2-----| |
| CE1| |PE1 | | PE2| |CE2 |
+----+ | |==================| | +----+
+----+ PSN Tunnel +----+
(C) MEP-------MEP|MEP------------------MEP|MEP--------MEP
(D) MEP-------MEP|MEP------------------MEP|MEP--------MEP
Figure A.2: VPWS MEPs and MIPs (Segment OAM Interworking)
図A.2：VPWS MEPSおよびMIPS（セグメントOAMインターワーキング）
Authors' Addresses
著者のアドレス
Ali Sajassi (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: sajassi@cisco.com
Ali Sajassi（編集者）Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134 USAメール：sajassi@cisco.com
Dinesh Mohan (editor) Nortel Ottawa, ON K2K3E5 EMail: dinmohan@hotmail.com
Dinesh Mohan（編集者）Nortel Ottawa、on K2K3E5メール：dinmohan@hotmail.com