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
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サービスを横切って積層OAM、疑似回線（PWの）を提供することを意図し、パケットがネットワーク（PSN）トンネルを切り替えられます。この文書は、L2VPNサービス、すなわち、仮想プライベートLANサービス（VPLS）、仮想専用線サービス（VPWS）、およびIP専用LANサービス（IPLS）のためのOAM要件を特定することを意図しています。 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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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の適用範囲は、自然の中で非常に広いことができます。 a）の障害管理、b）の構成管理、c）の会計管理、d）のパフォーマンス管理、およびe）セキュリティ管理：OSIは、一般に「FCAPS」[NM-規格]と略記、以下の5つの一般的な機能領域を定義しています。
This document focuses on the Fault and Performance Management aspects. Other functional aspects of FCAPS are for further study.
この文書では、障害およびパフォーマンス管理の側面に焦点を当てています。 FCAPSの他の機能的側面は、今後の検討課題です。
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:
そのようなリンクや装置故障などのハード障害、およびそのようなソフトウェアの障害、メモリの破損、設定ミス等典型的にはソフト障害の両方を検出することができる機構（複数可）を有する検出プラン障害、軽量なプロトコルが障害を検出することが望ましいとしたがって、障害を単離することに追加の手順を取る前に、障害検証機構を介して障害を確認するのが賢明だろう。障害がデータ経路に沿って発生していることを確認した後、所与のデバイスまたはリンクのレベルに障害を分離できることが重要です。そのため、障害分離機構は、障害管理に必要とされています。障害通知機構は、故障検出点の上流と下流の装置に通知する障害検出機構と組み合わせて使用することができます。二層のネットワーク間のクライアント/サーバ関係が存在する場合、例えば、サーバレイヤでの障害検出は、以下の障害通知をもたらすことができます。
- 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.
検討中のネットワーク/サービスの性能を決定し、測定することができメカニズム（複数可）とパフォーマンス管理を扱っています。パフォーマンス管理は、サービス・レベルとネットワーク・レベルのメトリック目標/両方の仕様への準拠を検証するために使用することができます。管理対象エンティティが使用可能な状態にあるとき、パフォーマンス管理は、通常、管理対象エンティティ間などのパフォーマンスメトリック、例えば、フレーム損失、フレーム遅延、フレーム遅延変動（別名ジッタ）、の測定で構成されています。パフォーマンス管理は利用できない管理対象エンティティ間で中断されます。
[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).
仮想プライベートLANサービス（VPLS）、（仮想専用線サービス（VPWS）、およびIP専用LANサービス（IPLS）：[L2VPN-FRWK]は、レイヤ2 VPNサービスの3つの異なる種類を指定します。
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に関連し、それに関連する疑似回線（PWの）とパブリックネットワーク（PSN）トンネルをスイッチとしてこの文書では、OAMのための参照モデルを提供します。 L2VPNサービス（例えば、VPLSとVPWS）のためのOAM要件も特定されています。 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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））、障害検証（ループバック）、および障害分離（リンクトレース）するためのメカニズムおよび手順を定義します。
- 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)
同じサービスインスタンスに属しているのMEを表し、またメンテナンス協会（MA）と呼ばれているMEGメンテナンスエンティティグループ、
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
別の802.1Qタグ内のQinQ 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.
[L2VPN-REQ]で説明したように図1は、L2VPN参照モデルを示します。 L2VPN Bは、ブリッジサービスを表すL2VPN Aは、ポイントツーポイントサービスを表します。
+-----+ +-----+
+ 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]はVPWS、VPLS、およびIPLSを指定します。 VPWSは、カスタマエッジ（CES）は、ポイントツーポイント仮想回線が表示され、ポイントツーポイントサービスです。 VPLSは、VPNのメンバーであるCEの集合に提供ブリッジLANサービスです。それらはブリッジLANを介して接続されたかのように同じサービスインスタンスのメンバーであるCEは、互いに通信します。 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機能は、複数のCEが接続されているプロバイダエッジのネットワーク（PES）によってエミュレートされます。 PEのこのネットワークは、単一のネットワークオペレータに属することができ、または複数のネットワーク事業者にまたがることができます。さらに、それは、単一のサービスプロバイダに属することができ、または複数のサービスプロバイダにまたがることができます。ネットワークオペレータ（別名施設プロバイダー）がそのサービスをサポートするサービスプロバイダ（複数可）に必要な施設を提供し、一方、サービスプロバイダは、顧客に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の実現に関連した様々な層は、サービス層とネットワーク層を含みます。ネットワーク層は、反復することができます。 L2VPNの文脈では、サービス層がVPLS、VPWS（例えば、イーサネット、ATM、FR、HDLC、SONET、ポイントツーポイントエミュレーション、等）、及びIPLSから成ります。同様のL2VPNの文脈において、ネットワーク層は、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ドメインの一部であってもよいです。 PEは、OAMドメインの境界における界面で、発信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は、同じサービスインスタンスに関連付けられた保守エンティティ（MES）のセットで構成保守エンティティグループ（MEG）、関連付けられています。 MEは、のMEPのペア間のポイントツーポイントの関連付けであり、監視対象エンティティを表します。例えば、必要とするNのCE VPLSにおいて、顧客のOAMドメイン内VPLSに関連付けられているすべてのME（すなわち、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ドメインのMIPをで見られないし、それらを通過します透過的）。さらに、のME（またはメガバイト）は階層階層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.
、a）はネットワーク上でブリッジLANサービスとして、MPLS / IPしているそのうちのいくつかは、B）これらのブリッジLANサービスをサポートするMPLS / IPネットワークとして：仮想プライベートLANサービス（VPLS）は、次のような異なるコンテキストで使用されています及びc）（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ネットワーク上でブリッジLANサービスのためです。サービスカバレッジは、エンドツーエンドCEデバイス間（ACまたはAC）UNIにUNIからとみなされ、それはそのサービスインスタンスに属する取り付けCEに仮想LANサービスを提供します。それが呼び出された理由は、このエンドツーエンドの仮想LANサービスを提供VPLS対応PEは[L2VPN-FRWK]に記載されているようにブリッジング機能（全体またはサブセットのいずれか）を行っているため、LANサービスであるブリッジ。このVPLS定義は、[L2VPN-REQ]で指定されるように、ブリッジモジュールと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メカニズムは、ブリッジモジュール、VPLSフォワーダ、および関連など、ACからACにある、[L2VPN-REQ]で定義されるように、エンドツーエンドのVPLSをカバーするために必要このサービスのPWを。この文書では、このような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は、また、ブリッジLANサービスをサポートしている基本的なネットワークを参照するために使用されます。このネットワークは、MPLS / IPアクセスのH-VPLSのように、エンド・ツー・エンドのMPLS / IPネットワークであってもよく、またはそれはMPLS / IPコアおよびイーサネット（登録商標）アクセスネットワークからなる混合ネットワークとすることができる、とH-VPLSのようQinQアクセス。いずれの場合においても、ネットワークは、（完全またはサブセットのいずれか）ブリッジング機能を実行することができるVPLS対応PEデバイスの集合で構成されています。これらVPLS対応PEデバイスは、階層的なトポロジー、分散トポロジ、またはそのような多層又はスタートポロジのようないくつかの他のトポロジとして、特定のトポロジに配置することができます。かかわらず、ネットワークトポロジのネットワークの整合性をチェックするために、（例えば、MPLS / IPネットワークのOAMなど）、ネットワークレベルの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
時には、VPLSは、また、（V）LANエミュレーションを指します。この文脈において、VPLSは、所定のサービスインスタンスとその関連VPLSフォワーダのためのMPLS / IPネットワークを介してLANセグメントをエミュレートスプリットホライズンとのPWsの完全なメッシュを指します。エミュレートされたLANセグメントがVPLS可能なPEのブリッジモジュールへの仮想LAN（VLAN）として提示されているので、エミュレートされたセグメントはまた、エミュレートされたVLANとも呼ばれます。この文脈でのOAMメカニズムは、整合性のVPLSフォワーダのチェックとのそれらに関連するフルメッシュに主に参照してください。
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.
PWを、部分メッシュの障害を検出して通知する機能。また、このドキュメントでは、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メカニズムの透明性がなどMPLS、IP、など基本的なトランスポート技術の上に保証されなければならない、OAMメカニズムは、基礎となるトランスポート機構から独立しているともっぱらVPLSに依存していることを確認することが重要です
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.
この提案は、ITU-T Q.5 / 13、IEEE 802.1、およびアドレスイーサネットネットワークとサービスOAMメトロイーサネットフォーラム（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デバイスによってマークされたサービス・プロバイダ・ネットワークを介して（二CEが顧客Aに属すると）VPLSの一例を示しています。同じ顧客Aに属するほかのCEデバイスは異なる顧客サイトの両端に接続することができます。サービス・プロバイダ・ネットワークは、コアネットワークとアクセスネットワークの二種類に分割されます。図3において、（A）は、ブリッジ要素によって表される架橋アクセスネットワークはBとMPLS成分で表されるMPLSアクセス及びコアネットワーク（b）は、図3のPをマークマーク示すイーサネットMACのサービス/ネットワーク図を示しています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デバイス（例えば、両者PES）の経路に沿ったOAMは、トランスポート層によって覆われており、それは、この文書の範囲外です。
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.
前のセクションで説明したように、与えられた顧客のVPLSは、1つ以上のサービスプロバイダやネットワーク事業者にまたがることができます。所与の顧客のCEの間である（A）顧客ドメイン、所与のサービスプロバイダのエッジのPEの中で（B）、サービスプロバイダドメイン、および（C）ネットワークオペレータのドメイン：図4は、三個のOAMドメインを示します所与のオペレータのPEの間です。
--- ---
/ \ ------ ------- ---- / \
| 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デバイスのブリッジモジュール/ VPLSフォワーダに実装されることが期待されます。 （D）は、サービスプロバイダドメイン内で可視のMEP及びMIPを表します。これらのMEPとのMIPは、[L2VPN-FRWK]に従って、PEデバイスのブリッジモジュール/ VPLSフォワーダに実装されることが期待されます。 （E）（すなわち、MPLSアクセスネットワークは、オペレータレベルのMIPを有していない）のMIPのみイーサネットアクセスネットワーク内に存在する各オペレータドメイン内の可視のMEP及び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、およびMIPの
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層のために、議員とMIPは、そのイーサネットMACアドレスとメンテナンスエンティティグループ識別子（MEG ID）で識別されなければなりません。 [VPLS-LDP]に記載されているように、VPLSインスタンスは、MPLS / IPネットワークで、PW-IDが使用されている間VLANタグ（サービスタグ）を使用して、イーサネット・ドメイン（例えば、802.1adドメイン）で同定することができます。所与のVPLSインスタンスの両方PW-IDとVLANタグは、サービス識別子（例えば、VPN識別子）に関連付けられています。 MEP及びMIPの識別子、すなわち、MEP及びMIPのIds 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は、CEのは、ポイントツーポイントの仮想回線を提示されているポイントツーポイントサービスです。 VPWSは、接続回線の対（ACS）と2つのPE間の単一の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:
次のようにVPWSを分類できます。
- VPWS with homogeneous ACs (where both ACs are same type)
- （両方のACSが同じタイプである）均質ACSとVPWS
- VPWS with heterogeneous ACs (where the ACs are of different Layer-2 encapsulation)
- （ACSは異なるレイヤ2のカプセル化である）異種ACSとVPWS
Further, the VPWS can itself be classified as follows:
次のようにさらに、VPWS自体が分類することができます。
- Homogeneous VPWS (when two ACs and PW are of the same type)
- 均質VPWS（二ACSおよびPWは、同じタイプのものです）
- Heterogeneous VPWS (when at least one AC or PW is a different type than the others)
- （少なくとも1つのACまたはPWが他とは異なるタイプである）異種VPWS
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.
上記の分類に基づいて、異種VPWSは、同種または異種のいずれかのACSを有していてもよいです。一方、均質なVPWSは、均質なACSを持つことができます。
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.
VPWSのための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デバイスによってマークされたサービス・プロバイダ・ネットワークを介して（顧客Aに属する2つのCEデバイスと）VPWSの一例を示しています。サービス・プロバイダ・ネットワークは、コアネットワークとアクセスネットワークの二種類に分割されると考えることができます。
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.
それはクライアントのサービスPDUを処理およびPWおよびACSにクライアントサービスPDUをカプセル化および脱カプセル化の原因である場合に最も一般的なケースでは、PEは、クライアントサービスを知ることができます。これは、均質なVPWSのために特に関連があります。これらは、エンドツーエンドVPWS OAMに関与することが期待されている装置であるため、このような展開のためのサービス固有のデバイスビューは、図7の（A）で強調されています。
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.
それはネイティブサービスPDUを処理していないときに、他の事例では、PEは、クライアントサービス気づかないことができますが、代わりに、PWを介してアクセス技術PDUをカプセル化します。これは、ATM ACを横切って提供されているイーサネットVPWS、ATM PW、およびイーサネット（登録商標）ACとして異種ACS、とVPWSのために関連し得ます。この場合に、ATM AC及びATM PWに取り付けられているPEは、クライアント・イーサネットサービスのPDUに透明であってもよいです。一方、ATM PWおよびイーサネットACに取り付けられているPEが対応クライアントのイーサネットサービスであると予想されます。これらは、PE1が気づかないクライアントサービスであると予想されるエンド・ツー・エンドのVPWS OAM、に関与することが期待されている装置であるため、このような展開のためのサービス固有のデバイスビューは、図7の（B）で強調されています。
|<--------------- 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.
前のセクションで説明したように、所与の顧客のためのVPWSは、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.
所与の顧客のCEの間である（A）顧客のドメイン、管理モデルに依存して（B）、サービスプロバイダドメインとの間である（C）ネットワークオペレータのドメイン：図8Aおよび8Bは、三個のOAMドメインを示しますACSは、異なるネットワークオペレータによって提供される場合、所与のオペレータのPEとは、アクセスネットワーク内に存在するかもしれません。コアネットワークオペレータは、これらの例で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に示す第1の管理モデルについては、CEのは、顧客によって管理されると予想され、顧客が必要な場合は、エンドツーエンドのサービスOAMを実行する責任があります。サービスプロバイダは、PW MEを監視する責任がある、とACの監視は、顧客とサービスプロバイダの共同責任です。 ACは、PEにCEを接続する物理インターフェイスを介して実現される場合、最も単純なケースでは、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は、CEのは、CEとPEのは、アクセスネットワークを介して接続されているサービスプロバイダとによって管理されている別の管理モデルを、強調しています。 CEとPE間のアクセスネットワークは、または異なるネットワークオペレータによって提供されていてもいなくてもよいです。図8bに（B）に示すように、このモデルでは、VPWS MEは、サービスプロバイダOAMドメイン内のCEの間に及びます。図8bに（C）で示すように、サービスプロバイダOAMドメインは、さらに、個別に交流のME及びPWのMEを監視してもよいです。図8bに（D）に示すように、ネットワークオペレータは、アクセスサービスのME（例えば、アクセストンネル）とコアPSNトンネルのMEの管理を担当することができます。図8Bに（C）及び（D）との間の区別は、（C）において、のMEは、CESでとのPEでのMEPを有し、全くMIPを持たないことです。 （D）でながら、MESがCESでとのPEでの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.
注：複数のオペレータドメインがユーザーに面するPE（U-PE）デバイス間で発生する可能性が図4にVPLS OAMドメインとは異なり、図8Aおよび8BにVPWS OAMドメインは、PEデバイス間の単一のオペレータドメインを強調ことに留意されたいです。これは、VPLS対応U-PEとネットワーク側のPE（N-PEは）分散PEを実現するために使用することができる分散VPLS PEケース（D-VPLS）とは異なり、VPWSは、そのような分散型PEモデルを有していない、ためであります。 PSNは、マルチセグメントPW [MS-PW-ARCH]で得られた、複数のオペレータドメインを含む場合切り替えPEは、典型的にネイティブサービスを認識していないので、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監視は、セグメントのMEによってサービスプロバイダOAMドメインのすべてが提供されます。階層OAMドメインについては、セクション4.2で述べたように、エンド・ツー・エンドのMEおよびセグメントのMEは、階層的に編成されています。これは、図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.
また、図9に（B1）及び（B2）に示すように、CEインターフェイスは、エンドツーエンドのサービスとしてVPWSのエンドツーエンドサービスプロバイダOAMレベルでのMEPをサポートし、PEインタフェースは、MIPをサポートしてもよいですエンドツーエンドのサービスプロバイダーOAMレベルのPEは、1つのエンドツーエンドのイーサネット回線サービスは、MPLS上のATMトランスポート（ATMを使用して提供考える場合、一例として図9に（B2）に示すように、クライアントサービス認識し、ある場合PW）は、その後のPEは、任意のイーサネットMIPをサポートすることができないため、気づかないイーサネットサービスであると考えられています。図9の（B1）は、この特定の状況を表しています。もちろん、エンドツーエンドのサービスの別のビューがPE1とPE2は認識サービスであり、従って、ATM MIPをサポートするように考えることができる場合にはATM、とすることができます。図9の（B2）は、この特定の状況を表しています。
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.
また、CEとPEインタフェースはACとPWのMEのためのセグメント（低レベル）サービスプロバイダーOAMレベルでのMEPをサポートし、図9オペレータに（C）に示すように、何のMIPは、このセグメントサービスプロバイダOAMレベルで関与していませんまた、図9（D）に示すように、ネットワークオペレータ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監視が行われた場合、クライアント層のエンドツーエンドMEは、単にサーバー層のセグメントからの障害通知を使用する可能性があるので、積極的なエンド・ツー・エンドの監視が必要とされない場合があり、例えば、いくつかの最適化を行うことも可能ですME。
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.
多くの異なるOAM層が可能であるが、図9に示すように、全てではないが実現されてもよいです。例えば、図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のMEPとMIPの
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では、議員とMIPは、その本来のアドレス指定方式で識別されなければなりません。 MEP及びMIPの識別子、すなわち、MEP及びMIPのIds 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サービスとしてVPLSを提供VPLS 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 VPLS-aware device to learn about other devices that support the same VPLS instance within a given domain.
ディスカバリーは、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.
発見はまた、VPLS認識装置が充分な情報を学習することができ（例えば、IPアドレス、MACアドレス等）VPLS OAMフレームはサービス認識デバイス間で交換することができるように、他のVPLS対応デバイスから。
(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は、所与のOAMドメイン内で同一のVPLSインスタンスを共有する他のデバイス（単数または複数）を発見する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対応デバイスとの間の輸送中に失われた場合VPLSは劣化と見なすことができます。 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.
（のR 4a）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 OAMフレームは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）は、OAMフレームが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インスタンスのために使用することができ、ベストエフォートVPLSsのために使用されていない場合でも、サービスごとの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は、サービス認識デバイスは、デバイスによってサポートされている各VPLSのための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 OAMは、通常のVPLSデータ・フレーム/パケットに似てフレームを転送することができなければならないように定義されるべきです。
(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データ・フレーム/パケットと同様の方法でOAMフレームを転送することができるように定義されなければなりません。
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).
VPLS OAMは、発信とその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）VPLS OAMは、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.
このようなOAMフレームは、より高いレベルのOAMドメインに属している場合（R9C）VPLS 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.
VPLS自体は、アプリケーション・フレーム/パケットを運ぶために使用されてもよいです。アプリケーションは独自のOAMを使用することができます。サービスOAMは、アプリケーションOAMに依存してはなりません。一例として、VPLSは、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.
ディスカバリーはVPWS対応のデバイスは、特定のドメイン内の同じVPWSインスタンスをサポートする他のデバイスについて学習することができます。発見はまた、OAMフレームはVPWS対応デバイス間で交換することができるような他のVPWS対応デバイスから十分な情報（例えば、IPアドレス、MACアドレス等）を学習するVPWS対応デバイスを可能にします。
(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.
例えば、ローカルCE及びACを介して接続されているローカルPE、両方とも、ACが失敗した場合、接続障害を検出することができます。ローカルPE障害に関するリモートPEに通知する必要がありながら、ローカルCEは、障害に関するリモートCEに通知しなければなりません。
(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対応デバイスとの間の輸送中に失われた場合VPWSが低下考えることができます。 VPWSを伴うフレーム/パケット損失に分解されるかどうかを決定するために、フレーム/パケット損失の測定が必要です。
(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.
VPWSはVPWS対応デバイスとの間の輸送中VPWSフレーム/パケットが経験する遅延に敏感であってもよいです。 VPWSを伴うフレーム/パケット遅延に分解されるかどうかを決定するために、フレーム/パケット遅延の測定が必要です。
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.
VPWSはVPWS対応デバイスとの間の輸送中VPWSフレーム/パケットが経験する変化を遅延に敏感であってもよいです。 VPWS起因フレーム/パケット遅延変動に劣化しているかどうかを決定するために、計測フレーム/パケット遅延の変化が必要です。フレーム/パケット遅延変動の測定のために、一方向機構は十分であると考えられます。
(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 OAMは、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は、サービス認識デバイスは、デバイスによってサポートされている各VPWSための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 OAMが正規VPWSデータフレーム/パケットに似てフレームを転送することができなければならないようなものであるべきです。
(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は、発信とそのOAMドメイン内に終了OAMドメインに属するフレーム。セキュリティは、OAMドメインは、OAMフレームをフィルタリングすることが可能でなければならないことを意味しています。フィルタリングはVPWS OAMフレームは、そのドメインの外部に漏れることが防止されるようなものです。また、
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).
VPWS OAMは、（例えば、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は、OAMフレームが同じレベルまたは低レベルのOAMドメインに属している場合OAMドメインに入るのを防止しなければならないOAMドメインの外部からフレームVPWS。
(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.
このようなOAMフレームは、より高いレベルのOAMドメインに属している場合（R20c）VPWS 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.
VPWS自体は、アプリケーション・フレーム/パケットを運ぶために使用されてもよいです。アプリケーションは独自のOAMを使用することができます。 VPWS OAMは、アプリケーションのOAMに依存してはなりません。一例として、VPWSは、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.
VPWSは、各接続および/または性能の点で特定の要件を有する所与の使用/アプリケーションに関連する、いくつかのデータ・フローで構成することができます。専用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セグメントおよび障害に依存しています。部分的なメッシュの障害が（V）LANエミュレーションで発生し、いずれか一方のみ全体VPLSが許容可能であるかのPWの一部が残りのPWは、それらの間の完全な接続性を有するようにシャットダウンする必要があるとき全体PWメッシュをシャットダウンしなければならないため、場合部分的VPLSは、許容可能であるとき。
(R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow detection of a partial-mesh failure condition.
PW用（R13A）PW OAM（V）LANエミュレーションに関連する部分メッシュ障害状態の検出を可能にしなければなりません。
(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.
（V）LANエミュレーションに関連のPW用（R13b）PW OAMはのPWのメッシュ全体は、部分メッシュの障害状態の検出時にシャットダウンされることを可能にしなければなりません。
(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.
（V）LANエミュレーションに関連する（R13c）PWsのためのPW OAMは、のPWの部分集合がフルメッシュは、残りのサブセットを横切って存在するように部分的なメッシュの障害状態の検出時にシャットダウンされることを可能にしなければなりません。
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.
PWのための（R14A）PW OAM（V）に関連したLANエミュレーションは、より速く、顧客の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.
PWのための（R14b）PW OAM（V）に関連したLANエミュレーションは、より速く、顧客の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.
PW用（R15）PW OAM（V）に関連したLANエミュレーションは、障害通知をトリガと（V）LANエミュレーションにおける故障検出時にVPLSのアラーム抑制を許可するようにVPLS OAMとのインターワーキングをサポートしなければなりません。
This section highlights how the different OAM mechanisms can be applied as per the OAM framework for different L2VPN services.
このセクションでは、さまざまなOAMメカニズムが異なるL2VPNサービスのための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、およびMIPの
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で同定さMES、[IEEE802.1ag]および[Y.1731]イーサネットOAMメカニズムのうち機構が両端に印加することができ、セクション7で同定された様々な要件を満たすために適用することができます図10のMEにおける（C）。
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メカニズムは、セクション7で同定された機能要件を満たすために、図10の（D）のMEを横切って適用することができます。
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
これは、PEデバイス間で利用できない中間で、場合[IEEE802.1ag]及び[Y.1731]能力ことに留意されたい、セクション6.2.3に導入されたセグメントOAMを使用して障害管理オプションを制限して、適用することができます以下に引用。このオプションでは、サービスプロバイダは、図中（D1）のMEを横切るセグメントOAMを実行することができ
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.
ネットワーク技術は、MPLSとき10.図10の（D1）のMEを横切るOAMメカニズムは、非イーサネット（登録商標）、例えば、仮想回線接続性検証（VCCV）、または双方向フォワーディング検出（BFD）とすることができます。サービスプロバイダは、MEがネイティブ技術OAMを使用して、各サブネットワークセグメントを監視し、セグメントのMEを横切っインターワーキングを行うことにより、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メカニズムもまた、セクション7で同定された機能要件を満たすために、図10の（E）中のMEを横切って適用することができ、ネットワークオペレータ（F）を越え、例えば、VCCVまたはBFD、ネイティブのOAMメカニズムを使用するように、追加の監視のためまたは（E）のME間での監視の代替としてのMEを決めることができました。
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フレームを防止することによって対処されます。要件は、セクション7.10および8.10で指定されたより高いOAMドメインからOAMフレームに透明であることがOAMドメインOAMドメイン外に漏れるとするためのOAMメッセージを防止します。
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
サイモンDelord Uecomm 658教会セントリッチモンド、VIC、3121、オーストラリアメール：sdelord@uecomm.com.au
Philippe Niger France Telecom 2 av. Pierre Marzin 22300 LANNION, France EMail: philippe.niger@francetelecom.com
フィリップ・ニジェールフランステレコム2のAV。ピエールMarzin 22300ラニオン、フランスのEメール：philippe.niger@francetelecom.com
Samer Salam Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: ssalam@cisco.com
SAMERサラムシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 Eメール：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.
作者は彼らのレビューとコメントのためのデボラBrungard、バシレRadoaca、レイ朱、祐一池尻、雄一郎和田健治熊木に感謝したいと思います。
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、ノーム・フィン、デイブ・アラン、トーマスナドー、モニークモロー、ヨアフ・コーエン、マルク・Holness、マルコムベッツ、ポールBottorff、ハミド・ウルドBrahimの、LIOR Shabtay、およびダンコーシーに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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） - イーサネットベースのネットワークのためのOAM機能およびメカニズム" 2008年2月。
[L2VPN-FRWK] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[L2VPN-FRWK]アンダーソン、L.、エド。、およびE.ローゼン、エド。、RFC 4664 "レイヤ2個の仮想プライベートネットワーク（のL2VPN）のためのフレームワーク"、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]アウグスティン、W.、エド。、およびY. Serbest、エド。、 "レイヤ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]アンデションとL.とT.マドセン、 "プロバイダーのプロビジョニングされた仮想プライベートネットワーク（VPN）用語"、RFC 4026、2005月。
[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.、エド。、およびY. Rekhter、エド。、 "仮想プライベートLANサービス（VPLS）自動検出およびシグナリングのためにBGPを使用する"、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.、エド。、およびV. Kompella、エド。、 "仮想プライベートLANサービス（VPLS）ラベル配布プロトコル（LDP）シグナリングの使用"、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.編、Brockners、F.、モハン、D.、編、及びY. Serbest、 "CEブリッジとVPLSの相互運用性"、進歩、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]ローゼン、E.、デイビー、B.、Radoaca、V.、およびW.羅、 "プロビジョニング、自動検出、およびレイヤでシグナリング2個の仮想プライベートネットワーク（のL2VPN）"、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-アーチ]ボッチ、M.およびS.ブライアント、 "マルチセグメント疑似回線エミュレーションエッジ・ツー・エッジのためのアーキテクチャ"、RFC 5659、2009年10月。
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
、RFC 2544、1999年3月 "ネットワーク相互接続デバイスのためのベンチマーキング方法論" [RFC2544]ブラドナー、S.とJ. McQuaid、。
Appendix A. Alternate Management Models
付録A.代替管理モデル
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.
階層モデルは、本書で詳しく述べ以外にも展開できる管理モデルを考慮して、この付録では、以下の指摘するように、それらの制限のために推奨されていないいくつかの代替モデルを強調しています。ネットワーク機器は、フル機能をサポートし、本文書によって前方に設定要件を満たすためにアップグレードされている間、これらの選択肢は、潜在的な中間モデルとして脚光を浴びています。
A.1. Alternate Model 1 (Minimal OAM)
A.1。代替モデル1（最小OAM）
In this model, the end-to-end service monitoring is provided by applying CE to CE ME in the service provider OAM domain.
このモデルでは、エンドツーエンドのサービス監視は、サービスプロバイダのOAMドメイン内MEを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）に示すように、VPWSの一部である各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の監視がCEに制限されることです。このオプションの制限は、障害の局在が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のMEPとMIPS（最小OAM）
A.2. Alternate Model 2 (Segment OAM Interworking)
A.2。代替モデル2（セグメント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つの交流のMEとPW MEを含みます。これらのセグメントは、サービスプロバイダのOAMドメインに期待されています。インターワーキング機能は、OAM情報は、エンドツーエンドの監視のためにOAMセグメントを横切って流れる転送する必要があります。均質なVPWSが展開されているか、異種VPWSが配備されているかどうかに応じて、相互作用機能は、簡単またはより複雑である可能性があります。
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のMEのためのMEPをサポートし、図A.2に（C）に示すように、何のMIPは、サービスプロバイダOAMレベルで関与していません。図A.2に（D）に示すように、ネットワークオペレータは、ネットワークオペレータ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の決定のために、エンドツーエンドのサービスフレームパスは必ずしも行使されません。さらに、それは、エンドツーエンドのサービスを実現するために使用することができるアクセスおよびコア全体のすべての可能な技術のためのインターワーキング機能の実装が必要です。
|<--------------- 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のMEPとMIPS（セグメントOAMインターワーキング）
Authors' Addresses
著者のアドレス
Ali Sajassi (editor) Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: sajassi@cisco.com
アリSajassi（エディタ）は、シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134 USA電子メール：sajassi@cisco.com
Dinesh Mohan (editor) Nortel Ottawa, ON K2K3E5 EMail: dinmohan@hotmail.com
ディネッシュモハン（エディタ）ノーテルオタワ、K2K3E5メールに：dinmohan@hotmail.com