Internet Engineering Task Force (IETF) I. Busi, Ed.
Request for Comments: 6371 Alcatel-Lucent
Category: Informational D. Allan, Ed.
ISSN: 2070-1721 Ericsson
September 2011
Operations, Administration, and Maintenance Framework for
MPLS-Based Transport Networks
Abstract
抽象
The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures.
マルチプロトコルラベルスイッチング（MPLS-TP）のトランスポートプロファイルは、MPLSトラフィックエンジニアリング（MPLS-TE）との擬似回線（PW）のデータ・プレーン・アーキテクチャに基づいてパケットベースの伝送技術です。
This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane.
この文書では、コントロールの存在に依存しない障害、パフォーマンス、および保護切り替えの管理とそのためのMPLS-TPのOAM要件を満たす運用、管理、および保守（OAM）手続きの包括的なセットをサポートするためのフレームワークについて説明します飛行機。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
この文書は、IETF MPLSおよび擬似回線エミュレーションエッジツーエッジ（PWE3）アーキテクチャ内MPLSトランスポートプロファイルを含めるための共同のインターネットエンジニアリングタスクフォース（IETF）/国際電気通信連合電気通信標準化部門（ITU-T）の努力の産物でありますITU-Tによって定義されるようなパケットトランスポートネットワークの能力と機能性をサポートします。
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/rfc6371.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6371で取得することができます。
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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Definitions ................................................7
3. Functional Components ..........................................10
3.1. Maintenance Entity and Maintenance Entity Group ...........10
3.2. MEG Nesting: SPMEs and Tandem Connection Monitoring .......13
3.3. MEG End Points (MEPs) .....................................14
3.4. MEG Intermediate Points (MIPs) ............................18
3.5. Server MEPs ...............................................20
3.6. Configuration Considerations ..............................21
3.7. P2MP Considerations .......................................21
3.8. Further Considerations of Enhanced Segment Monitoring .....22
4. Reference Model ................................................23
4.1. MPLS-TP Section Monitoring (SMEG) .........................26
4.2. MPLS-TP LSP End-to-End Monitoring Group (LMEG) ............27
4.3. MPLS-TP PW Monitoring (PMEG) ..............................27
4.4. MPLS-TP LSP SPME Monitoring (LSMEG) .......................28
4.5. MPLS-TP MS-PW SPME Monitoring (PSMEG) .....................30
4.6. Fate-Sharing Considerations for Multilink .................31
5. OAM Functions for Proactive Monitoring .........................32
5.1. Continuity Check and Connectivity Verification ............33
5.1.1. Defects Identified by CC-V .........................35
5.1.2. Consequent Action ..................................37
5.1.3. Configuration Considerations .......................38
5.2. Remote Defect Indication ..................................40
5.2.1. Configuration Considerations .......................40
5.3. Alarm Reporting ...........................................41
5.4. Lock Reporting ............................................42
5.5. Packet Loss Measurement ...................................44
5.5.1. Configuration Considerations .......................45
5.5.2. Sampling Skew ......................................45
5.5.3. Multilink Issues ...................................45
5.6. Packet Delay Measurement ..................................46
5.6.1. Configuration Considerations .......................46
5.7. Client Failure Indication .................................47
5.7.1. Configuration Considerations .......................47
6. OAM Functions for On-Demand Monitoring .........................48
6.1. Connectivity Verification .................................48
6.1.1. Configuration Considerations .......................49
6.2. Packet Loss Measurement ...................................50
6.2.1. Configuration Considerations .......................50
6.2.2. Sampling Skew ......................................50
6.2.3. Multilink Issues ...................................50
6.3. Diagnostic Tests ..........................................50
6.3.1. Throughput Estimation ..............................51
6.3.2. Data-Plane Loopback ................................52
6.4. Route Tracing .............................................54
6.4.1. Configuration Considerations .......................54
6.5. Packet Delay Measurement ..................................54
6.5.1. Configuration Considerations .......................55
7. OAM Functions for Administration Control .......................55
7.1. Lock Instruct .............................................55
7.1.1. Locking a Transport Path ...........................56
7.1.2. Unlocking a Transport Path .........................56
8. Security Considerations ........................................57
9. Acknowledgments ................................................58
10. References ....................................................58
10.1. Normative References .....................................58
10.2. Informative References ...................................59
11. Contributing Authors ..........................................60
As noted in the MPLS Transport Profile (MPLS-TP) framework RFCs (RFC 5921 [8] and RFC 6215 [9]), MPLS-TP is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures defined in RFC 3031 [1], RFC 3985 [2], and RFC 5659 [4].
MPLSトランスポートプロファイルで述べたように（MPLS-TP）フレームワークのRFC（RFC 5921 [8]およびRFC 6215 [9]）、MPLS-TPであるMPLSトラフィックエンジニアリング（MPLS-TE）に基づいて、パケットベースの伝送技術とRFC 3031で定義された疑似回線（PW）データプレーンアーキテクチャ[1]、RFC 3985 [2]、及びRFC 5659 [4]。
MPLS-TP utilizes a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures for fault, performance, and protection-switching management that do not rely on the presence of a control plane.
MPLS-TPは、運用、管理の包括的なセットを利用し、障害、パフォーマンス、およびコントロールプレーンの存在に依存しない保護切り替え管理のための保守（OAM）手続き。
In line with [15], existing MPLS OAM mechanisms will be used wherever possible, and extensions or new OAM mechanisms will be defined only where existing mechanisms are not sufficient to meet the requirements. Some extensions discussed in this framework may end up as aspirational capabilities and may be determined to be not tractably realizable in some implementations. Extensions do not deprecate support for existing MPLS OAM capabilities.
[15]と一致して、可能な限り既存のMPLS OAMメカニズムが使用され、拡張や新しいOAMメカニズムは既存のメカニズムが要件を満たすのに十分でない場合にのみ定義されます。この枠組みの中で議論のいくつかの拡張機能は、として向上心の機能を終わる可能性があり、いくつかの実装でtractably実現不可能であると判定することができます。拡張機能は、既存のMPLS OAM機能のサポートを廃止しないでください。
The MPLS-TP OAM framework defined in this document provides a protocol-neutral description of the required OAM functions and of the data-plane OAM architecture to support a comprehensive set of OAM procedures that satisfy the MPLS-TP OAM requirements of RFC 5860 [11]. In this regard, it defines similar OAM functionality as for existing Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN) OAM mechanisms (e.g., [19]).
この文書で定義されたMPLS-TP OAMフレームワークは、RFC 5860のMPLS-TPのOAM要件を満たすOAM手順の包括的なセットをサポートするために必要なOAM機能とデータプレーンOAMアーキテクチャのプロトコル中立記述を提供する[11 ]。これに関して、既存の同期光ネットワーク/同期デジタル階層（SONET / SDH）および光トランスポートネットワーク（OTN）OAMメカニズム（例えば、[19]）のための同様のOAM機能を定義します。
The MPLS-TP OAM framework is applicable to Sections, Label Switched Paths (LSPs), Multi-Segment Pseudowires (MS-PWs), and Sub-Path Maintenance Elements (SPMEs). It supports co-routed and associated bidirectional P2P transport paths as well as unidirectional P2P and P2MP transport paths.
MPLS-TPのOAMフレームワークは、セクションに適用され、ラベル・パス（LSPを）スイッチ、マルチセグメント疑似回線（MS-のPW）、サブパスメンテナンス要素（SPMEs）。なお、共ルーティングおよび関連する双方向P2P搬送路だけでなく、一方向のP2PとP2MPの輸送経路をサポートしています。
OAM packets that instrument a particular direction of a transport path are subject to the same forwarding treatment (i.e., fate-share) as the user data packets and in some cases, where Explicitly TC-encoded-PSC LSPs (E-LSPs) are employed, may be required to have common per-hop behavior (PHB) Scheduling Class (PSC) End-to-End (E2E) with the class of traffic monitored. In case of Label-Only-Inferred-PSC LSP (L-LSP), only one class of traffic needs to be monitored, and therefore the OAM packets have common PSC with the monitored traffic class.
OAMは、使用される搬送路の特定の方向を明示的TCは、符号化され、PSC（E-のLSP）LSPをユーザ・データ・パケットとして、場合によっては、同じ転送処理（すなわち、運命シェア）、対象となるその器具をパケット、監視対象トラフィックのクラスに共通ホップ単位動作（PHB）スケジューリングクラス（PSC）エンドツーエンド（E2E）を持つことが必要になることがあります。ラベル専用推定さ-PSC LSP（L-LSP）の場合には、トラフィックの唯一の一つのクラスは、監視する必要があり、従って、OAMパケットは、監視トラフィッククラスと共通のPSCを有します。
OAM packets can be distinguished from the used data packets using the Generic Associated Channel Label (GAL) and Associated Channel Header (ACH) constructs of RFC 5586 [7] for LSP, SPME, and Section, or the ACH construct of RFC 5085 [3] and RFC 5586 [7] for (MS-)PW. OAM packets are never fragmented and are not combined with user data in the same packet payload.
OAMパケットは、一般的な関連するチャネルラベル（GAL）と関連するチャネルヘッダ（ACH）RFC 5586の構築物を用いて使用されるデータ・パケットと区別することができる[7] LSP、SPME、およびセクション、またはRFC 5085のACHコンストラクト[3 ]および（MS-）PWのためのRFC 5586 [7]。 OAMパケットが断片化されることはありませんと同じパケットペイロード内のユーザデータと結合されていません。
This framework makes certain assumptions as to the utility and frequency of different classes of measurement that naturally suggest different functions are implemented as distinct OAM flows or packets. This is dictated by the combination of the class of problem being detected and the need for timeliness of network response to the problem. For example, fault detection is expected to operate on an entirely different time base than performance monitoring, which is also expected to operate on an entirely different time base than in-band management transactions.
このフレームワークは当然異なる機能を示唆しているが、別個のOAMフローまたはパケットとして実装されている測定の異なるクラスの有用性及び周波数に関して一定の仮定を行います。これは、検出された問題のクラスの組み合わせと問題へのネットワーク応答の適時の必要性によって決定されます。例えば、障害検出はまた、帯域内管理トランザクションとは全く異なる時間ベースで動作することが期待される性能監視、より完全に異なる時間ベースで動作することが期待されます。
The remainder of this memo is structured as follows:
次のように、このメモの残りの部分は構成されています。
Section 2 covers the definitions and terminology used in this memo.
第2節では、このメモで使用される定義と用語をカバーしています。
Section 3 describes the functional component that generates and processes OAM packets.
セクション3は、OAMパケットを生成し、処理する機能コンポーネントを記述する。
Section 4 describes the reference models for applying OAM functions to Sections, LSP, MS-PW, and their SPMEs.
セクション4はセクション、LSP、MS-PW、およびそれらSPMEsにOAM機能を適用するための参照モデルを記載しています。
Sections 5, 6, and 7 provide a protocol-neutral description of the OAM functions, defined in RFC 5860 [11], aimed at clarifying how the OAM protocol solutions will behave to achieve their functional objectives.
セクション5、6、及び7は、RFC 5860で定義されたOAM機能のプロトコル中立記述を提供[11]、OAMプロトコルソリューションは、それらの機能の目的を達成するためにどのように動作するかを明確化を目的としました。
Section 8 discusses the security implications of OAM protocol design in the MPLS-TP context.
第8節は、MPLS-TPの文脈におけるOAMプロトコルの設計のセキュリティへの影響について説明します。
The OAM protocol solutions designed as a consequence of this document are expected to comply with the functional behavior described in Sections 5, 6, and 7. Alternative solutions to required functional behaviors may also be defined.
この文書の結果として設計OAMプロトコルソリューションはセクション5、6に記載の機能的挙動に準拠することが期待され、そして必要な機能行動7.代替ソリューションも定義することができます。
OAM specifications following this OAM framework may be provided in different documents to cover distinct OAM functions.
このOAMフレームワーク次のOAM仕様が異なるOAM機能をカバーするために、異なる文書で提供されてもよいです。
This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T.
この文書は、共同IETF（Internet Engineering Task Force）のパケットの能力と機能をサポートするために、IETF MPLSとPWE3アーキテクチャ内のMPLSトランスポートプロファイルを含むように/国際電気通信連合電気通信標準化部門（ITU-T）の努力の産物でありますITU-Tによって定義されるようなトランスポートネットワーク。
AC Attachment Circuit
ACアタッチメント回路
AIS Alarm Indication Signal
AISアラーム表示信号
CC Continuity Check
CCの導通チェック
CC-V Continuity Check and Connectivity Verification
CC-Vの導通チェックや接続性検証
CV Connectivity Verification
CV接続検証
DBN Domain Border Node
DBNドメイン境界のノード
E-LSP Explicitly TC-encoded-PSC LSP
E-LSPは、明示的にTCエンコード-PSC LSP
ICC ITU Carrier Code
ICC ITUキャリア符号
LER Label Edge Router
LERラベルエッジルータ
LKR Lock Report
LKRロックレポート
L-LSP Label-Only-Inferred-PSC LSP
L-LSPラベルのみ-推定される-PSC LSP
LM Loss Measurement
LM損失測定
LME LSP Maintenance Entity
LME LSPメンテナンスエンティティ
LMEG LSP ME Group
LMEG LSP MEグループ
LSP Label Switched Path
LSPラベルスイッチパス
LSR Label Switching Router
LSRラベルスイッチングルータ
LSME LSP SPME ME
LSME LSP SPME ME
LSMEG LSP SPME ME Group
LSMEG LSP SPME MEグループ
ME Maintenance Entity
MEメンテナンスエンティティ
MEG Maintenance Entity Group
MEGメンテナンスエンティティグループ
MEP Maintenance Entity Group End Point
MEPメンテナンスエンティティグループエンドポイント
MIP Maintenance Entity Group Intermediate Point
MIPメンテナンスエンティティグループの中間点
NMS Network Management System
NMSネットワーク管理システム
PE Provider Edge
PEのプロバイダーエッジ
PHB Per-Hop Behavior
PHBホップ単位動作
PM Performance Monitoring
PMのパフォーマンス監視
PME PW Maintenance Entity
PME PWメンテナンスエンティティ
PMEG PW ME Group
PMEGは私にグループを教えて
PSC PHB Scheduling Class
PSC PHBスケジューリングクラス
PSME PW SPME ME
DTM SPMEは、MEを伝えます
PSMEG PW SPME ME Group
PSMEG PO SPME MEグループ
PW Pseudowire
PO Psefdoviri
SLA Service Level Agreement
SLAサービス・レベル・アグリーメント
SME Section Maintenance Entity
SME節メンテナンスエンティティ
SMEG Section ME Group
SMEG節MEグループ
SPME Sub-Path Maintenance Element
SPMEサブパスメンテナンス要素
S-PE Switching Provider Edge
S-PEスイッチングプロバイダーエッジ
TC Traffic Class
TCトラフィッククラス
T-PE Terminating Provider Edge
T-PE終端プロバイダエッジ
This document uses the terms defined in RFC 5654 [5].
この文書では、[5] RFC 5654で定義された用語を使用しています。
This document uses the term 'per-hop behavior' as defined in RFC 2474 [16].
RFC 2474 [16]で定義されるように、この文書では、「ホップ単位動作」という用語を使用します。
This document uses the term 'LSP' to indicate either a service LSP or a transport LSP (as defined in RFC 5921 [8]).
この文書は、（RFC 5921で定義されている[8]）サービスLSPまたは輸送LSPのいずれかを示すために「LSP」という用語を使用します。
This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960 [10].
この文書では、[10] RFC 5960で定義された用語「節」のn = 0の場合を参照するために排他的に用語「セクション」を使用します。
This document uses the term 'Sub-Path Maintenance Element (SPME)' as defined in RFC 5921 [8].
この文書は、RFC 5921で定義されるように、用語「サブパスメンテナンス要素（SPME）」を使用する[8]。
This document uses the term 'traffic profile' as defined in RFC 2475 [13].
RFC 2475で定義されるように、このドキュメントは、[13]用語「トラフィックプロファイル」を使用します。
Where appropriate, the following definitions are aligned with ITU-T recommendation Y.1731 [21] in order to have a common, unambiguous terminology. They do not however intend to imply a certain implementation but rather serve as a framework to describe the necessary OAM functions for MPLS-TP.
適切な場合、以下の定義が共通の、明確な用語を持っているために、ITU-T勧告Y.1731 [21]と整列されます。しかし彼らは、特定の実装を意味するものではなく、むしろMPLS-TPのために必要なOAM機能を記述するためのフレームワークとして機能するつもりはありません。
Adaptation function: The adaptation function is the interface between the client (sub-)layer and the server (sub-)layer.
適応機能：適応機能は、クライアント（サブ）レイヤとサーバ（サブ）層との界面です。
Branch Node: A node along a point-to-multipoint transport path that is connected to more than one downstream node.
ブランチノード：複数の下流ノードに接続されるポイント・ツー・マルチポイント搬送経路に沿ってノード。
Bud Node: A node along a point-to-multipoint transport path that is at the same time a branch node and a leaf node for this transport path.
芽ノード：同時に、この搬送路のためのブランチノードとリーフノードであり、ポイント・ツー・マルチポイント搬送経路に沿ってノード。
Data-plane loopback: An out-of-service test where a transport path at either an intermediate or terminating node is placed into a data-plane loopback state, such that all traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path.
データプレーンのループバック：中間または終端ノードは、データプレーンループバック状態に置かれるかで搬送路アウトオブサービス試験、（ペイロードとOAMの両方を含む）すべてのトラフィックがループバックインタフェース上で受信するように搬送経路の逆方向に送信されます。
Note: The only way to send an OAM packet to a node that has been put into data-plane loopback mode is via Time to Live (TTL) expiry, irrespective of whether the node is hosting MIPs or MEPs.
注：データプレーンループバック・モードに置かれているノードにOAMパケットを送信するための唯一の方法にかかわらず、ノードがMIPのまたはのMEPをホストしているかどうか、（TTL）の有効期限を生存時間を介してです。
Domain Border Node (DBN): An intermediate node in an MPLS-TP LSP that is at the boundary between two MPLS-TP OAM domains. Such a node may be present on the edge of two domains or may be connected by a link to the DBN at the edge of another OAM domain.
ドメイン境界ノード（DBN）2つのMPLS-TPのOAMドメインの間の境界にあるMPLS-TP LSPにおける中間ノード。そのようなノードは、二つのドメインのエッジ上に存在してもよく、または別のOAMドメインのエッジでDBNへのリンクによって接続されてもよいです。
Down MEP: A MEP that receives OAM packets from, and transmits them towards, the direction of a server layer.
ダウンMEP：からOAMパケットを受信し、サーバ層の方向に向かって送信するMEP。
Forwarding Engine: An abstract functional component, residing in an LSR, that forwards the packets from an ingress interface toward the egress interface(s).
フォワーディングエンジン：抽象機能部品、出力インターフェイス（複数可）に向かって入力インターフェイスからパケットを転送LSR、に存在します。
In-Service: The administrative status of a transport path when it is unlocked.
インサービス：それはロックが解除され、搬送路の管理ステータス。
Interface: An interface is the attachment point to a server (sub-)layer, e.g., a MPLS-TP Section or MPLS-TP tunnel.
インターフェース：インターフェースは、サーバ（サブ）レイヤ、例えば、MPLS-TPセクションまたはMPLS-TPトンネルへの結合点です。
Intermediate Node: An intermediate node transits traffic for an LSP or a PW. An intermediate node may originate OAM flows directed to downstream intermediate nodes or MEPs.
中間ノード：LSPまたはPWのための中間ノード遷移トラフィック。 OAMを生じ得る中間ノードは、下流の中間ノードまたはのMEPに向けて流れます。
Loopback: See data-plane loopback and OAM loopback definitions.
ループバック：データプレーンのループバックおよびOAMループバックの定義を参照してください。
Maintenance Entity (ME): Some portion of a transport path that requires management bounded by two points (called MEPs), and the relationship between those points to which maintenance and monitoring operations apply (details in Section 3.1).
保守エンティティ（ME）：二つの点（のMEPと呼ばれる）によって囲まれた管理を必要とする搬送路の一部、およびそれらの点の間の関係の保守および監視操作（3.1節に詳細）を適用します。
Maintenance Entity Group (MEG): The set of one or more maintenance entities that maintain and monitor a section or a transport path in an OAM domain.
メンテナンスエンティティグループ（MEG）：維持し、OAMドメイン内のセクションや搬送経路を監視する一個の以上の保守エンティティのセット。
MEP: A MEG End Point (MEP) is capable of initiating (source MEP) and terminating (sink MEP) OAM packets for fault management and performance monitoring. MEPs define the boundaries of an ME (details in Section 3.3).
MEP：MEGエンドポイント（MEP）は、（ソースMEP）を開始し、障害管理及び性能監視のためのOAMパケット（MEPシンク）終端することが可能です。 MEPは、ME（セクション3.3で詳細）の境界を画定します。
MIP: A MEG intermediate point (MIP) terminates and processes OAM packets that are sent to this particular MIP and may generate OAM packets in reaction to received OAM packets. It never generates unsolicited OAM packets itself. A MIP resides within a MEG between MEPs (details in Section 3.3).
MIP：MEGの中間点（MIP）が終了すると、この特定のMIPに送られ、受信したOAMパケットに反応におけるOAMパケットを生成することができるOAMパケットを処理します。それは決して迷惑OAMパケット自体を生成しません。 MIPは、のMEP（セクション3.3で詳細）との間のMEG内に存在します。
OAM domain: A domain, as defined in [5], whose entities are grouped for the purpose of keeping the OAM confined within that domain. An OAM domain contains zero or more MEGs.
OAMドメイン：ドメインで定義され[5]、そのエンティティそのドメイン内に閉じ込められたOAMを維持する目的のためにグループ化されます。 OAMドメインは、ゼロ個以上のメガが含まれています。
Note: Within the rest of this document, the term "domain" is used to indicate an "OAM domain".
注意：この文書の残りの部分の中で、「ドメイン」という用語は、「OAMドメイン」を示すために使用されます。
OAM flow: The set of all OAM packets originating with a specific source MEP that instrument one direction of a MEG (or possibly both in the special case of data-plane loopback).
OAMフロー：特定のソースMEPとMEG（あるいは両方のデータプレーンループバックの特別な場合）の器具一方向発信すべてのOAMパケットのセット。
OAM loopback: The capability of a node to be directed by a received OAM packet to generate a reply back to the sender. OAM loopback can work in-service and can support different OAM functions (e.g., bidirectional on-demand connectivity verification).
OAMループバック：送信者への応答を生成するために、受信したOAMパケットによって指示されるノードの能力。 OAMループバックは、インサービス動作することができ、別のOAM機能（例えば、双方向のオンデマンド接続性検証）をサポートすることができます。
OAM Packet: A packet that carries OAM information between MEPs and/or MIPs in a MEG to perform some OAM functionality (e.g., connectivity verification).
OAMパケット：MEG内のMEPおよび/またはMIPの間のOAM情報を運ぶパケットは、いくつかのOAM機能（例えば、接続性検証）を行います。
Originating MEP: A MEP that originates an OAM transaction packet (toward a target MIP/MEP) and expects a reply, either in-band or out-of-band, from that target MIP/MEP. The originating MEP always generates the OAM request packets in-band and expects and processes only OAM reply packets returned by the target MIP/MEP.
そのターゲットMIP / MEPから、帯域内または帯域外のいずれかで、（ターゲットMIP / MEPに向かって）OAMトランザクションパケットを発信し、応答を期待MEP：MEPを発信。発信MEPは常にターゲットMIP / MEPによって返さのみOAMリプライパケットを帯域内OAM要求パケットを生成し、期待とプロセス。
Out-of-Service: The administrative status of a transport path when it is locked. When a path is in a locked condition, it is blocked from carrying client traffic.
アウトオブサービス：それはロックされている搬送路の管理ステータス。パスがロックされた状態にあるとき、それは、クライアントのトラフィックを運ぶから遮断されています。
Path Segment: It is either a segment or a concatenated segment, as defined in RFC 5654 [5].
パスセグメント：これは、セグメントまたはRFC 5654で定義されるように連結されたセグメント、[5]のいずれかです。
Signal Degrade: A condition declared by a MEP when the data forwarding capability associated with a transport path has deteriorated, as determined by performance monitoring (PM). See also ITU-T recommendation G.806 [14].
信号劣化：性能監視（PM）により決定される搬送路に関連付けられたデータ転送能力は、劣化したMEPによって宣言条件。また、ITU-T勧告G.806 [14]を参照。
Signal Fail: A condition declared by a MEP when the data forwarding capability associated with a transport path has failed, e.g., loss of continuity. See also ITU-T recommendation G.806 [14].
信号失敗：搬送経路に関連するデータ転送能力は、例えば、連続性の喪失を失敗したMEPによって宣言条件。また、ITU-T勧告G.806 [14]を参照。
Sink MEP: A MEP acts as a sink MEP for an OAM packet when it terminates and processes the packets received from its associated MEG.
シンクMEP：それはその関連MEGから受信したパケットを終了し、処理するときMEPは、OAMパケットのシンクMEPとして機能します。
Source MEP: A MEP acts as source MEP for an OAM packet when it originates and inserts the packet into the transport path for its associated MEG.
ソースMEP：それはその関連MEGの搬送経路にパケットを発信し、挿入したときにMEPがOAMパケットのソースMEPとして作用します。
Tandem Connection: A tandem connection is an arbitrary part of a transport path that can be monitored (via OAM) independent of the end-to-end monitoring (OAM). The tandem connection may also include the forwarding engine(s) of the node(s) at the boundaries of the tandem connection. Tandem connections may be nested but cannot overlap. See also ITU-T recommendation G.805 [20].
タンデム接続：タンデム接続エンド・ツー・エンドの監視（OAM）の独立（OAMを介して）監視することができる搬送経路の任意の部分です。タンデム接続はまた、タンデム接続の境界でノード（単数または複数）のフォワーディングエンジン（単数または複数）を含むことができます。タンデム接続は入れ子にすることができるが、オーバーラップすることはできません。また、ITU-T勧告G.805 [20]を参照。
Target MEP/MIP: A MEP or a MIP that is targeted by OAM transaction packets and that replies to the originating MEP that initiated the OAM transactions. The target MEP or MIP can reply either in-band or out-of-band. The target sink MEP function always receives the OAM request packets in-band, while the target source MEP function only generates the OAM reply packets that are sent in-band.
ターゲットMEP / MIP：MEPまたはOAMトランザクションパケットが対象とし、それがOAM取引を開始した元のMEPに返信されるMIP。ターゲットMEPまたはMIPは、帯域内または帯域外のいずれかで応答することができます。ターゲットソースMEP機能のみ帯域内送信されるOAM応答パケットを生成しながら、目標シンクMEP関数は常に、帯域内OAM要求パケットを受信します。
Up MEP: A MEP that transmits OAM packets towards, and receives them from, the direction of the forwarding engine.
アップMEP：向けてOAMパケットを送信し、転送エンジンの方向からそれらを受信するMEP。
MPLS-TP is a packet-based transport technology based on the MPLS and PW data plane architectures ([1], [2], and [4]) and is capable of transporting service traffic where the characteristics of information transfer between the transport path end points can be demonstrated to comply with certain performance and quality guarantees.
MPLS-TPは、MPLSとPWデータプレーンアーキテクチャに基づくパケットベースの伝送技術である（[1]、[2]、及び[4]）と搬送路との間の情報伝達の特性サービストラフィックを輸送することができますエンドポイントは、特定の性能と品質保証に準拠することが証明することができます。
In order to describe the required OAM functionality, this document introduces a set of functional components.
必要なOAM機能を説明するために、この文書は、機能コンポーネントのセットを導入します。
MPLS-TP OAM operates in the context of Maintenance Entities (MEs) that define a relationship between two points of a transport path to which maintenance and monitoring operations apply. The two points that define a maintenance entity are called Maintenance Entity Group End Points (MEPs). The collection of one or more MEs that belongs to the same transport path and that are maintained and monitored as a group are known as a Maintenance Entity Group (MEG). In between MEPs, there are zero or more intermediate points, called Maintenance Entity Group Intermediate Points (MIPs). MEPs and MIPs are associated with the MEG and can be shared by more than one ME in a MEG.
MPLS-TP OAM保守および監視操作適用する搬送路の二点間の関係を定義保守エンティティ（MES）のコンテキスト内で動作します。メンテナンスエンティティを定義する2つのポイントは、メンテナンスエンティティグループのエンドポイント（MEPの）と呼ばれています。同一の搬送経路に属し、それが維持され、グループが保守エンティティグループ（MEG）として知られているように監視される1つの以上のMEのコレクション。 MEPとの間に、ゼロ以上の中間点と呼ばれる保守エンティティグループ中間ポイント（MIPは）があります。 MEPおよびMIPはMEGに関連付けられており、複数のME MEG中で共有することができます。
An abstract reference model for an ME is illustrated in Figure 1 below.
MEの抽象参照モデルは以下の図1に示されています。
+-+ +-+ +-+ +-+
|A|----|B|----|C|----|D|
+-+ +-+ +-+ +-+
Figure 1: ME Abstract Reference Model
図1：ME要約参照モデル
The instantiation of this abstract model to different MPLS-TP entities is described in Section 4. In Figure 1, nodes A and D can be Label Edge Routers (LERs) for an LSP or the Terminating Provider Edges (T-PEs) for an MS-PW, nodes B and C are LSRs for an LSP or Switching PEs (S-PEs) for an MS-PW. MEPs reside in nodes A and D, while MIPs reside in nodes B and C and may reside in A and D. The links connecting adjacent nodes can be physical links, (sub-)layer LSPs/SPMEs, or server-layer paths.
異なるMPLS-TPエンティティにこの抽象モデルのインスタンスは、ノードA及びDは、LSPまたはMSのための着信プロバイダエッジ（T-PES）のラベル・エッジ・ルータ（のLER）とすることができる。図1において、セクション4に記載されています-PW、ノードB及びCは、LSPのためのLSRまたはMS-PW用のスイッチングPES（S-PES）です。 MIPは、物理リンクとすることができる隣接ノードを接続するリンクをノードB及びCに存在し、AおよびDに存在するかもしれないのMEPは、（サブ）のLSP / SPMEs、またはサーバレイヤパス層は、ノードA及びDに存在します。
This functional model defines the relationships between all OAM entities from a maintenance perspective and it allows each Maintenance Entity to provide monitoring and management for the (sub-)layer network under its responsibility and efficient localization of problems.
この機能モデルは、保守の観点から、すべてのOAMエンティティ間の関係を定義し、各保守エンティティは、その責任と問題の効率的な局在下（サブ）レイヤネットワークの監視と管理を提供することを可能にします。
An MPLS-TP Maintenance Entity Group may be defined to monitor the transport path for fault and/or performance management.
MPLS-TPメンテナンスエンティティグループは、障害および/またはパフォーマンス管理のための搬送経路を監視するように定義することができます。
The MEPs that form a MEG bound the scope of an OAM flow to the MEG (i.e., within the domain of the transport path that is being monitored and managed). There are two exceptions to this:
MEGを形成したMEPは、MEGのOAMフローの範囲を結合し（すなわち、監視および管理されている搬送経路のドメイン内）。これには2つの例外があります。
1) A misbranching fault may cause OAM packets to be delivered to a MEP that is not in the MEG of origin.
1）misbranching障害がOAMパケットが起源のMEGにないMEPに送達させることができます。
2) An out-of-band return path may be used between a MIP or a MEP and the originating MEP.
2）アウトオブバンドリターンパスがMIPまたはMEPと発信MEPとの間で使用されてもよいです。
In case of a unidirectional point-to-point transport path, a single unidirectional Maintenance Entity is defined to monitor it.
一方向のポイント・ツー・ポイントの搬送経路の場合には、単一の一方向の保守エンティティは、それを監視するために定義されています。
In case of associated bidirectional point-to-point transport paths, two independent unidirectional Maintenance Entities are defined to independently monitor each direction. This has implications for transactions that terminate at or query a MIP, as a return path from MIP to the originating MEP does not necessarily exist in the MEG.
関連する双方向ポイントツーポイント搬送路の場合には、二つの独立した一方向保守エンティティはそれぞれ独立して方向を監視するために定義されています。これは、MIPに由来MEPへの戻り経路が必ずしもMEGに存在しないように、で終端またはMIPをクエリトランザクションの意味を有します。
In case of co-routed bidirectional point-to-point transport paths, a single bidirectional Maintenance Entity is defined to monitor both directions congruently.
共ルーティング双方向ポイントツーポイント搬送路の場合には、単一の双方向メンテナンスエンティティは合同両方向を監視するために定義されています。
In case of unidirectional point-to-multipoint transport paths, a single unidirectional Maintenance Entity for each leaf is defined to monitor the transport path from the root to that leaf.
一方向のポイント・ツー・マルチポイント搬送路の場合には、各リーフのための単一の一方向保守エンティティは、そのルートからリーフまでの搬送経路を監視するために定義されています。
In all cases, portions of the transport path may be monitored by the instantiation of SPMEs (see Section 3.2).
全ての場合において、搬送路の部分はSPMEsのインスタンスによって監視することができる（3.2節を参照）。
The reference model for the P2MP MEG is represented in Figure 2.
P2MP MEGのための参照モデルは、図2に示されています。
+-+
/--|D|
/ +-+
+-+
/--|C|
+-+ +-+/ +-+\ +-+
|A|----|B| \--|E|
+-+ +-+\ +-+ +-+
\--|F|
+-+
Figure 2: Reference Model for P2MP MEG
図2：P2MP MEGのための参照モデル
In the case of P2MP transport paths, the OAM measurements are independent for each ME (A-D, A-E, and A-F):
P2MP搬送路の場合には、OAM測定は各ME（A-D、-E、およびA-F）のために独立しています。
o Fault conditions - some faults may impact more than one ME depending on where the failure is located;
Oフォルト条件 - いくつかの障害は、MEが障害がある場所に応じて複数に影響を与え得ます。
o Packet loss - packet dropping may impact more than one ME depending from where the packets are lost;
Oパケット損失 - パケットのドロップがMEは、パケットが失われたところから応じつ以上に影響を与え得ます。
o Packet delay - will be unique per ME.
Oパケット遅延は - MEごとに一意になります。
Each leaf (i.e., D, E, and F) terminates OAM flows to monitor the ME between itself and the root while the root (i.e., A) generates OAM packets common to all the MEs of the P2MP MEG. All nodes may implement a MIP in the corresponding MEG.
各リーフ（即ち、D、E、およびF）は、OAMは、ルート（即ち、A）はP2MP MEGの全てのMEにOAMパケットが共通発生する。自体とルート間MEを監視するように流れ、終了しますすべてのノードは、対応するMEGにMIPを実装することができます。
In order to verify and maintain performance and quality guarantees, there is a need to apply OAM functionality not only on a transport path granularity (e.g., LSP or MS-PW), but also on arbitrary parts of transport paths, defined as tandem connections, between any two arbitrary points along a transport path.
性能と品質保証を確認し、維持するために、タンデム接続として定義されて搬送路粒度（例えば、LSPまたはMS-PW）上だけでなく、搬送路の任意の部分だけでなくOAM機能を適用する必要があります、搬送経路に沿った任意の任意の2点間です。
Sub-Path Maintenance Elements (SPMEs), as defined in [8], are hierarchical LSPs instantiated to provide monitoring of a portion of a set of transport paths (LSPs or MS-PWs) that follow the same path between the ingress and the egress of the SPME. The operational aspects of instantiating SPMEs are out of scope of this memo.
サブパスメンテナンス要素（SPMEs）で定義されるように[8]、入口および出口の間に同じ経路をたどる搬送路（のLSPまたはMS-のPW）のセットの部分のモニタリングを提供するためにインスタンス化された階層のLSPでありますSPMEの。インスタンス化SPMEsの運用面では、このメモの範囲外です。
SPMEs can also be employed to meet the requirement to provide tandem connection monitoring (TCM), as defined by ITU-T Recommendation G.805 [20].
SPMEsはまた、ITU-T勧告G.805 [20]によって定義されるように、タンデム接続監視（TCM）を提供するための要件を満たすために使用することができます。
TCM for a given path segment of a transport path is implemented by creating an SPME that has a 1:1 association with the path segment of the transport path that is to be monitored.
監視される搬送路の路セグメントと1関連：搬送経路の所定の経路セグメントのTCMは1を有するSPMEを作成することによって実現されます。
In the TCM case, this means that the SPME used to provide TCM can carry one and only one transport path, thus allowing direct correlation between all fault management and performance monitoring information gathered for the SPME and the monitored path segment of the end-to-end transport path.
TCMの場合、これは、SPMEは、TCMは、唯一の搬送路、従ってSPME用に収集されたすべての障害管理及び性能監視情報とエンドツーの監視経路セグメントの間に直接的な相関関係を可能に運ぶことができる提供するために使用されることを意味します搬送経路を終了します。
There are a number of implications to this approach:
このアプローチへの影響の数があります。
1) The SPME would use the uniform model [23] of Traffic Class (TC) code point copying between sub-layers for Diffserv such that the E2E markings and PHB treatment for the transport path were preserved by the SPMEs.
1）SPMEは、搬送路用E2EマーキングおよびPHB処理がSPMEsによって保存されたようにDiffservのための副層との間のトラフィッククラス（TC）コードポイントコピーの均一なモデル[23]を使用します。
2) The SPME normally would use the short-pipe model for TTL handling [6] (no TTL copying between sub-layers) such that the TTL distance to the MIPs for the E2E entity would not be impacted by the presence of the SPME, but it should be possible for an operator to specify use of the uniform model.
2）SPMEは、通常、E2EエンティティのためのMIPのTTL距離はSPMEの存在によって影響されないように）（[6]取り扱いTTLのためのサブ層との間にはTTLコピーを短管モデルを使用しないであろう、オペレータは、均一モデルの使用を指定するが、それは可能なはずです。
Note that points 1 and 2 above assume that the TTL copying mode and TC copying modes are independently configurable for an LSP.
1及び2ポイント（注）上記のTTLコピーモード及びTCコピーモードがLSPのために独立して設定可能であると仮定する。
The TTL distance to the MIPs plays a critical role for delivering packets to these MIPs as described in Section 3.4.
MIPへのTTLの距離は、3.4節で説明したようにこれらのMIPにパケットを提供するための重要な役割を果たしています。
There are specific issues with the use of the uniform model of TTL copying for an SPME:
SPME用TTLコピーの統一モデルを用いた具体的な問題があります。
1. A MIP in the SPME sub-layer is not part of the transport-path MEG; hence, only an out-of-band return path for OAM originating in the transport-path MEG that addressed an SPME MIP might be available.
SPMEサブレイヤ1. A MIPは、搬送路MEGの一部ではありません。したがって、SPME MIPが利用可能であるかもしれない対処輸送パスMEGに起因OAMのための唯一のアウトオブバンドリターンパス。
2. The instantiation of a lower-level MEG or protection-switching actions within a lower-level MEG may change the TTL distances to MIPs in the higher-level MEGs.
2.低レベルMEGまたは下位MEG内でプロテクションスイッチング動作のインスタンス化は、より高いレベルのメガバイトでのMIPにTTL距離を変更することができます。
The end points of the SPME are MEPs and limit the scope of an OAM flow within the MEG that the MEPs belong to (i.e., within the domain of the SPME that is being monitored and managed).
SPMEのエンドポイントは、のMEPであるとのMEPが属するMEG内のOAMフローの範囲を限定する（すなわち、監視及び管理されているSPMEのドメイン内）。
When considering SPMEs, it is important to consider that the following properties apply to all MPLS-TP MEGs (regardless of whether they instrument LSPs, SPMEs, or MS-PWs):
SPMEsを考えるとき、次のプロパティが（関係なく、楽器のLSP、SPMEs、またはMS-PWのかどうかの）すべてのMPLS-TPのメガバイトに適用することを考慮することが重要です。
o They can be nested but not overlapped, e.g., a MEG may cover a path segment of another MEG and may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. However, when MEGs are nested, the MEPs and MIPs in the SPME are no longer part of the encompassing MEG.
Oそれらは重複ネストなくすることができ、例えば、MEGは、MEG他の経路セグメントを覆ってもよいし、また、経路セグメントの端部（S）のノード（複数可）のフォワーディングエンジン（単数または複数）を含むことができます。メガバイトがネストされているときしかし、SPMEでのMEPとMIPは、包括的なMEGには含まれていません。
o It is possible that MEPs of MEGs that are nested reside on a single node but again are implemented in such a way that they do not overlap.
Oネストされているメガバイトの欧州議会議員は、単一ノード上に存在するが、再び彼らは重複しないように実装されている可能性があります。
o Each OAM flow is associated with a single MEG.
O各OAMフローは、単一のMEGと関連しています。
o When an SPME is instantiated after the transport path has been instantiated, the TTL distance to the MIPs may change for the short-pipe model of TTL copying, and may change for the uniform model if the SPME is not co-routed with the original path.
O搬送経路がインスタンス化された後、SPMEがインスタンス化されるときに、のMIPのTTL距離はTTLコピーの短管モデルのために変更することができる、及びSPMEは、元と共ルーティングされない場合は、均一なモデルに変更することができます道。
MEG End Points (MEPs) are the source and sink points of a MEG. In the context of an MPLS-TP LSP, only LERs can implement MEPs, while in the context of an SPME, any LSR of the MPLS-TP LSP can be an LER of SPMEs that contributes to the overall monitoring infrastructure of the transport path. Regarding PWs, only T-PEs can implement MEPs; while for SPMEs supporting one or more PWs, both T-PEs and S-PEs can implement SPME MEPs. Any MPLS-TP LSR can implement a MEP for an MPLS-TP Section.
MEGエンドポイント（MEPが）MEGのソースおよびシンクポイントです。 SPMEの文脈において、MPLS-TP LSPのLSRは、搬送経路の全体的な監視インフラストラクチャに寄与するSPMEsのLERすることができるがMPLS-TP LSPの文脈では、唯一のLERは、のMEPを実装することができます。 PWSは、唯一のT-PEが議員を実装することができますについて。一の以上のPWを支持SPMEsためながら、T-PEとS-PEの両方がSPMEのMEPを実装することができます。任意のMPLS-TPのLSRは、MPLS-TPのセクションのためのMEPを実装することができます。
MEPs are responsible for originating almost all of the proactive and on-demand monitoring OAM functionality for the MEG. There is a separate class of notifications (such as Lock Report (LKR) and Alarm Indication Signal (AIS)) that are originated by intermediate nodes and triggered by server-layer events. A MEP is capable of originating and terminating OAM packets for fault management and performance monitoring. These OAM packets are carried within the Generic Associated Channel (G-ACh) with the proper encapsulation and an appropriate channel type as defined in RFC 5586 [7]. A MEP terminates all the OAM packets it receives from the MEG it belongs to and silently discards those that do not. (Note that in the particular case of Connectivity Verification (CV) processing, a CV packet from an incorrect MEG will result in a mis-connectivity defect and there are further actions taken.) The MEG the OAM packet belongs to is associated with the MPLS or PW label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the case of an MPLS-TP Section, the MEG is inferred from the port on which an OAM packet was received with the GAL at the top of the label stack.
議員は、ほとんどすべてのMEGのための積極的かつオンデマンド監視OAM機能の発信を担当しています。中間ノードによって発信およびサーバーレイヤイベントによってトリガされている（例えばロック報告書（LKR）とアラーム表示信号（AIS）など）の通知の別のクラスがあります。 MEPは、発信することが可能であり、障害管理及び性能監視のためのOAMパケットを終了します。 RFC 5586で定義されるように、これらのOAMパケットは、適切なカプセル化された一般的な関連するチャネル（G-ACH）及び適切なチャネル型内に担持されている[7]。 MEPは、それが属していると静かにそうでないものを捨てるMEGから受信したすべてのOAMパケットを終了します。 MEG OAMパケットがMPLSに関連付けられているに属する（接続検証（CV）処理の特定の場合において、誤ったMEGからCVパケットが誤接続の欠陥をもたらすと取られ、さらにアクションが存在する。なお）またはPWラベルは、ラベルがMEGまたはOAMパケットの内容を推測するために使用されているかどうかを実装の選択肢があります。 MPLS-TPセクションの場合、MEGは、OAMパケットをラベルスタックの最上部にGALで受信されたポートから推測されます。
OAM packets may require the use of an available "out-of-band" return path (as defined in [8]). In such cases, sufficient information is required in the originating transaction such that the OAM reply packet can be constructed and properly forwarded to the originating MEP (e.g., IP address).
（[8]で定義されるように）OAMパケットは、利用可能な「アウトオブバンド」リターンパスの使用を必要とし得ます。このような場合には、十分な情報をOAMリプライパケットを構築し、適切に発信MEP（例えば、IPアドレス）に転送することができるように、元のトランザクションにおいて必要とされます。
Each OAM solution document will further detail the applicability of the tools it defines as a proactive or on-demand mechanism as well as its usage when:
各OAMソリューション文書は、それがその使用するときだけでなく、積極的またはオンデマンドメカニズムとして定義ツールの適用詳細を促進します。
o The "in-band" return path exists and it is used.
O「帯域内」リターンパスが存在し、それが使用されます。
o An "out-of-band" return path exists and it is used.
「アウトオブバンド」リターンパスが存在し、それが使用され、O。
o Any return path does not exist or is not used.
O任意のリターンパスが存在しないか、使用されていません。
Once a MEG is configured, the operator can configure which proactive OAM functions to use on the MEG, but the MEPs are always enabled.
MEGを設定すると、オペレーターはMEGに使用するOAM機能を積極的にどの設定できますが、議員は常に有効になっています。
MEPs terminate all OAM packets received from the associated MEG. As the MEP corresponds to the termination of the forwarding path for a MEG at the given (sub-)layer, OAM packets never leak outside of a MEG in a properly configured fault-free implementation.
MEPは、関連MEGから受信したすべてのOAMパケットを終了します。 MEPは、所与の（サブ）レイヤでMEGの転送経路の終端に対応するように、OAMパケットが適切に設定故障のない実装でMEGの外部に漏れることはありません。
A MEP of an MPLS-TP transport path coincides with transport path termination and monitors it for failures or performance degradation (e.g., based on packet counts) in an end-to-end scope. Note that both the source MEP and sink MEP coincide with transport paths' source and sink terminations.
MPLS-TP搬送路のMEPは、搬送路の終端に一致し、エンドツーエンドスコープの障害又は性能低下（例えば、パケット数に基づいて）のためにそれを監視します。両方のソースMEPことに注意してくださいとMEPは、搬送路ソースとシンク終端に一致シンク。
The MEPs of an SPME are not necessarily coincident with the termination of the MPLS-TP transport path. They are used to monitor a path segment of the transport path for failures or performance degradation (e.g., based on packet counts) only within the boundary of the MEG for the SPME.
SPMEのMEPがMPLS-TPの搬送経路の終端と必ずしも一致しません。彼らは、障害や性能劣化の搬送経路の経路セグメントを監視するために使用されている（例えば、パケット数に基づく）のみSPME用MEGの境界内。
An MPLS-TP sink MEP passes a fault indication to its client (sub-)layer network as a consequent action of fault detection. When the client layer is not MPLS-TP, the consequent actions in the client layer (e.g., ignore or generate client-layer-specific OAM notifications) are outside the scope of this document.
MPLS-TPシンクMEPは、故障検出の結果としての作用としてのクライアント（サブ）レイヤネットワークに障害表示を渡します。クライアント層は、MPLS-TPでない場合、クライアント層における結果としてのアクション（例えば、クライアント層固有OAM通知を無視するか、または生成する）この文書の範囲外です。
A node hosting a MEP can either support per-node MEP or per-interface MEP(s). A per-node MEP resides in an unspecified location within the node, while a per-interface MEP resides on a specific side of the forwarding engine. In particular, a per-interface MEP is called an "Up MEP" or a "Down MEP" depending on its location relative to the forwarding engine. An "Up MEP" transmits OAM packets towards, and receives them from, the direction of the forwarding engine, while a "Down MEP" receives OAM packets from, and transmits them towards, the direction of a server layer.
MEPをホストノード缶サポートノードごとのMEPまたはインターフェイス単位MEP（S）のいずれか。インターフェイスごとのMEPは、フォワーディングエンジンの特定の側に存在しながら、ノード単位のMEPは、ノード内の不特定の場所に存在します。具体的には、インターフェースごとのMEPは、「アップMEP」または転送エンジンに対する位置に応じて、「ダウンMEP」と呼ばれています。 「アップMEPは」向かってOAMパケットを送信し、「ダウンMEPは、」からOAMパケットを受信し、サーバ層の方向に向かってそれらを送信しながら、フォワーディングエンジンの方向からそれらを受信します。
Source node Up MEP Destination node Up MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| MEP | | | | | | MEP |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(1) (2)
Source node Down MEP Destination node Down MEP
------------------------ ------------------------
| | | |
|----- -----| |----- -----|
| | | MEP | | MEP | | |
| | ---- | | | | ---- | |
| In |->-| FW |->-| Out |->- ->-| In |->-| FW |->-| Out |
| i/f | ---- | i/f | | i/f | ---- | i/f |
|----- -----| |----- -----|
| | | |
------------------------ ------------------------
(3) (4)
Figure 3: Examples of Per-Interface MEPs
図3：インターフェイス単位の議員の例
Figure 3 describes four examples of per-interface Up MEPs: an Up Source MEP in a source node (case 1), an Up Sink MEP in a destination node (case 2), a Down Source MEP in a source node (case 3), and a Down Sink MEP in a destination node (case 4).
ソースノード（ケース1）、宛先ノードにアップシンクMEP（ケース2）、ソースノードにおけるダウンソースMEP（ケース3）中にソースMEP：図3は、インターフェースごとの最大のMEPの4つの例を記載しています、および宛先ノードにおけるダウンシンクMEP（ケース4）。
The usage of per-interface Up MEPs extends the coverage of the ME for both fault and performance monitoring closer to the edge of the domain and determines that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes.
インターフェースごとの最大のMEPの使用は、近い領域のエッジに障害およびパフォーマンス監視の両方のためのMEのカバレッジを拡張し、故障や性能劣化の位置は、ノード内、または2つの隣接ノード間のリンク上にあると判断します。
Each OAM solution document will further detail the implications of the tools it defines when used with per-interface or per-node MEPs, if necessary.
各OAM溶液文書を詳細に、必要に応じて、インターフェイス単位またはノードのMEPで使用した場合、それは定義ツールの影響をさらにあろう。
It may occur that multiple MEPs for the same MEG are on the same node, and are all Up MEPs, each on one side of the forwarding engine, such that the MEG is entirely internal to the node.
同じMEGのための複数のMEPが同じノード上にある、およびMEGのノードに完全に内部にあるように、転送エンジンの一の側にそれぞれ、すべての最大のMEPであることが起こり得ます。
It should be noted that an ME may span nodes that implement per-node MEPs and per-interface MEPs. This guarantees backward compatibility with most of the existing LSRs that can implement only a per-node MEP. In fact, in many current implementations, label operations are largely performed on the ingress interface; hence, the exposure of the GAL as top label will occur at the ingress interface.
MEごとのノードのMEPとインターフェイス単位のMEPを実装するノードにまたがってもよいことに留意すべきです。これは、ノードごとのMEPを実装することができ、既存のLSRのほとんどとの下位互換性を保証しています。実際に、多くの現在の実装では、ラベル操作は、主に入力インターフェイス上で行われます。したがって、トップラベルとしてGALの露光は、入力インターフェイスで発生します。
Note that a MEP can only exist at the beginning and end of a (sub-)layer in MPLS-TP. If there is a need to monitor some portion of that LSP or PW, a new sub-layer (in the form of an SPME) must be created that permits MEPs and associated MEGs to be created.
MEPは、MPLS-TPに（サブ）レイヤの開始時と終了時にのみ存在することに留意されたいです。そのLSPまたはPWの一部を監視する必要がある場合、（SPMEの形態で）新たなサブ層を作成するのMEPおよび関連メガバイトを可能にするように作成されなければなりません。
In the case where an intermediate node sends an OAM packet to a MEP, it uses the top label of the stack at that point.
中間ノードはMEPにOAMパケットを送信する場合には、その時点でスタックのトップラベルを使用します。
A MEG Intermediate Point (MIP) is a function located at a point between the MEPs of a MEG for a PW, LSP, or SPME.
MEGの中間点（MIP）PW、LSP、またはSPME用MEGのMEPの間の点に位置する関数です。
A MIP is capable of reacting to some OAM packets and forwarding all the other OAM packets while ensuring fate-sharing with user data packets. However, a MIP does not initiate unsolicited OAM packets, but may be addressed by OAM packets initiated by one of the MEPs of the MEG. A MIP can generate OAM packets only in response to OAM packets that it receives from the MEG it belongs to. The OAM packets generated by the MIP are sent to the originating MEP.
MIPは、いくつかのOAMパケットに反応し、ユーザ・データ・パケットと運命共有を確保しつつ、他のすべてのOAMパケットを転送することが可能です。しかし、MIPは迷惑OAMパケットを開始しませんが、MEGの欧州議会議員の1によって開始OAMパケットによって対処することができます。 MIPは、それが属するMEGから受信したOAMパケットに応答して、OAMパケットを生成することができます。 MIPによって生成されたOAMパケットは、発信MEPに送信されます。
An intermediate node within a MEG can either:
MEG内の中間ノードのいずれかを実行できます。
o support per-node MIPs (i.e., a single MIP per node in an unspecified location within the node); or
OサポートノードごとのMIPS（すなわち、ノード内の不特定の場所にノードごとに単一のMIP）。または
o support per-interface MIPs (i.e., two or more MIPs per node on both sides of the forwarding engine).
OサポートインターフェースごとのMIPS（すなわち、フォワーディングエンジンの両側のノードごとに2つ以上のMIP）。
Support of per-interface or per-node MIPs is an implementation choice. It is also possible that a node could support per-interface MIPs on some MEGs and per-node MIPs on other MEGs for which it is a transit node.
インターフェイスごと、またはノードのMIPのサポートは、実装の選択です。ノードが中継ノードであるため、他のメガ上のいくつかのメガおよびノード単位のMIP上のインターフェイス単位のMIPをサポートすることができることも可能です。
Intermediate node
------------------------
| |
|----- -----|
| MIP | | MIP |
| | ---- | |
->-| In |->-| FW |->-| Out |->-
| i/f | ---- | i/f |
|----- -----|
| |
------------------------
Figure 4: Example of Per-Interface MIPs
図4：インターフェイス単位のMIPの例
Figure 4 describes an example of two per-interface MIPs at an intermediate node of a point-to-point MEG.
図4は、ポイントツーポイントMEGの中間ノードにある2つのインターフェイス単位のMIPの例について説明します。
Using per-interface MIPs allows the network operator to determine that the location of a failure or performance degradation is within a node or on a link between two adjacent nodes.
インターフェイス単位のMIPを使用すると、ネットワークオペレータは、故障や性能劣化の位置は、ノード内、または2つの隣接ノード間のリンク上にあることを判断することができます。
When sending an OAM packet to a MIP, the source MEP should set the TTL field to indicate the number of hops necessary to reach the node where the MIP resides.
MIPにOAMパケットを送信するとき、ソースMEPは、MIPが存在するノードに到達するために必要なホップの数を示すために、TTLフィールドを設定しなければなりません。
The source MEP should also include target MIP information in the OAM packets sent to a MIP to allow proper identification of the MIP within the node. The MEG the OAM packet belongs to is associated with the MPLS label, whether the label is used to infer the MEG or the content of the OAM packet is an implementation choice. In the latter case, the MPLS label is checked to be the expected one.
ソースMEPは、ノード内のMIPの適切な識別を可能にするために、MIPに送られるOAMパケット内のターゲットMIP情報を含むべきです。 MEG OAMパケットは、ラベルは、MEGを推測するために使用されるか、OAMパケットの内容は、実装選択であるかどうか、MPLSラベルに関連付けられているに属します。後者の場合、MPLSラベルは予想一つであることが確認されています。
The use of TTL expiry to deliver OAM packets to a specific MIP is not a fully reliable delivery mechanism because the TTL distance of a MIP from a MEP can change. Any MPLS-TP node silently discards any OAM packet that is received with an expired TTL and that is not addressed to any of its MIPs or MEPs. An MPLS-TP node that does not support OAM is also expected to silently discard any received OAM packet.
MEPからMIPのTTLの距離が変化することができるので、特定のMIPにOAMパケットを配信するTTLの期限切れの使用は、完全に信頼できる配信メカニズムはありません。任意のMPLS-TPノードは静か期限切れTTLで受信され、それはそののMIPまたはのMEPのいずれにも対処されていない任意のOAMパケットを廃棄します。 OAMをサポートしていないMPLS-TPノードは、また、静かに任意の受信したOAMパケットを破棄することが期待されます。
Packets directed to a MIP may not necessarily carry specific MIP identification information beyond that of TTL distance. In this case, a MIP would promiscuously respond to all MEP queries on its MEG. This capability could be used for discovery functions (e.g., route tracing as defined in Section 6.4) or when it is desirable to leave to the originating MEP the job of correlating TTL and MIP identifiers and noting changes or irregularities (via comparison with information previously extracted from the network).
MIPに向けられたパケットは、必ずしもTTL距離のものを超える特定MIP識別情報を搬送しないことができます。この場合、MIPは、無差別にそのMEG上のすべてのMEPクエリに応答することになります。この機能は、発見機能を使用することができる（例えば、セクション6.4で定義されるようにトレースルート）又はそれが由来MEP TTLおよびMIP識別子を相関し、変更又は凹凸を注目のジョブに残すことが望ましい場合（以前に抽出された情報との比較を介してネットワークから）。
MIPs are associated to the MEG they belong to, and their identity is unique within the MEG. However, their identity is not necessarily unique to the MEG, e.g., all nodal MIPs in a node can have a common identity.
MIPは、彼らが属するMEGに関連付けられている、と彼らのアイデンティティは、MEG内で一意です。しかし、彼らのアイデンティティは、例えば、ノード内のすべての節点のMIPは、共通のアイデンティティを持つことができ、必ずしもMEGに固有のものではありません。
A node hosting a MEP can also support per-interface Up MEPs and per-interface MIPs on either side of the forwarding engine.
MEPをホストしているノードは、インターフェースごとの最大のMEP及び転送エンジンの両側のインターフェイス単位のMIPをサポートすることができます。
Once a MEG is configured, the operator can enable/disable the MIPs on the nodes within the MEG. All the intermediate nodes and possibly the end nodes host MIP(s). Local policy allows them to be enabled per function and per MEG. The local policy is controlled by the management system, which may delegate it to the control plane. A disabled MIP silently discards any received OAM packets.
MEGが設定されると、オペレータは、MEG内のノード上のMIPを有効/無効にすることができます。全ての中間ノード、おそらくエンドノードホストMIP（S）。ローカルポリシーは、それらが機能ごとやMEGごとに有効にすることを可能にします。ローカルポリシーは、制御プレーンにそれを委任することができる管理システムによって制御されます。無効MIPは静かにどんな受信したOAMパケットを破棄します。
A server MEP is a MEP of a MEG that is either:
サーバMEPは、どちらかであるMEGのMEPであります：
o defined in a layer network that is "below", which is to say encapsulates and transports the MPLS-TP layer network being referenced; or
O封入を言うことで、参照されるMPLS-TP層ネットワークを輸送する「下」であるレイヤネットワーク、で定義されました。または
o defined in a sub-layer of the MPLS-TP layer network that is "below", which is to say encapsulates and transports the sub-layer being referenced.
O封入を言うことで、参照される副層を輸送する「下」であるMPLS-TP層ネットワークのサブ層、で定義されます。
A server MEP can coincide with a MIP or a MEP in the client (MPLS-TP) (sub-)layer network.
サーバMEPは、クライアント（MPLS-TP）（サブ）レイヤネットワークにおいてMIPまたはMEPと一致させることができます。
A server MEP also provides server-layer OAM indications to the client/server adaptation function between the client (MPLS-TP) (sub-)layer network and the server (sub-)layer network. The adaptation function maintains state on the mapping of MPLS-TP transport paths that are set up over that server (sub-)layer's transport path.
サーバMEPは、クライアント（MPLS-TP）（サブ）レイヤネットワークとサーバ（サブ）レイヤのネットワークとの間のクライアント/サーバ・アダプテーション機能にサーバー層OAM指示を提供します。適応機能は、サーバ（サブ）レイヤの搬送経路上に設定されているMPLS-TPの搬送路のマッピングに状態を維持します。
For example, a server MEP can be:
例えば、サーバMEPは、することができ：
o a non-MPLS MEP at a termination point of a physical link (e.g., 802.3, an SDH Virtual Circuit, or OTN Optical Data Unit (ODU)), for the MPLS-TP Section layer network, defined in Section 4.1;
セクション4.1で定義されたMPLS-TPセクションレイヤネットワークのため、物理リンク（例えば、802.3、SDH仮想回線、またはOTN光データユニット（ODU））の終了時点で、非MPLS MEP O。
o an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2;
セクション4.2で定義されたMPLS-TPのLSPのためのMPLS-TPセクションMEP O。
o an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
セクション4.3で定義されたMPLS-TPのPW用のMPLS-TP LSP MEP O。
o an MPLS-TP SPME MEP used for LSP path segment monitoring, as defined in Section 4.4, for MPLS-TP LSPs or higher-level SPMEs providing LSP path segment monitoring; or
LSPパスセグメントの監視提供MPLS-TP用のLSPまたは上位SPMEsため、セクション4.4で定義されるように、O MPLS-TP SPME MEPは、LSPパスセグメントの監視に使用しました。または
o an MPLS-TP SPME MEP used for PW path segment monitoring, as defined in Section 4.5, for MPLS-TP PWs or higher-level SPMEs providing PW path segment monitoring.
MPLS-TPのPWのために、4.5節で定義された、または上位SPMEsがPWパスセグメントの監視を提供するものとしてO MPLS-TP SPME MEPは、PWパスセグメントの監視のために使用しました。
The server MEP can run appropriate OAM functions for fault detection within the server (sub-)layer network and provides a fault indication to its client MPLS-TP layer network via the client/server adaptation function. When the server layer is not MPLS-TP, server MEP OAM functions are simply assumed to exist but are outside the scope of this document.
サーバMEPは、サーバ（サブ）レイヤネットワーク内の障害検出のための適切なOAM機能を実行し、クライアント/サーバー・アダプテーション機能を介して、クライアントMPLS-TP層ネットワークに障害表示を提供することができます。サーバ層がMPLS-TPでない場合、サーバMEPのOAM機能が単に存在すると仮定が、この文書の範囲外でれます。
When a control plane is not present, the management plane configures these functional components. Otherwise, they can be configured by either the management plane or the control plane.
制御プレーンが存在しない場合、管理プレーンは、これらの機能構成要素を構成します。それ以外の場合は、管理プレーンや制御プレーンのいずれかで構成することができます。
Local policy allows disabling the usage of any available "out-of-band" return path, as defined in [8], irrespective of what is requested by the node originating the OAM packet.
ローカルポリシーに関係なくOAMパケットを発信ノードによって要求されるものの、[8]で定義されるように、任意の利用可能な「アウトオブバンド」リターンパスの使用を無効にすることを可能にします。
SPMEs are usually instantiated when the transport path is created by either the management plane or the control plane (if present). Sometimes an SPME can be instantiated after the transport path is initially created.
搬送路は、管理プレーン又は制御プレーン（存在する場合）のいずれかによって作成されたときSPMEsは通常、インスタンス化されます。搬送経路が最初に作成された後、時々、SPMEをインスタンス化することができます。
All the traffic sent over a P2MP transport path, including OAM packets generated by a MEP, is sent (multicast) from the root to all the leaves. As a consequence:
P2MP搬送路を介して送信されるすべてのトラフィックは、MEPによって生成されたOAMパケットを含む、すべての葉に根から（マルチキャスト）に送信されます。結果として：
o To send an OAM packet to all leaves, the source MEP can send a single OAM packet that will be delivered by the forwarding plane to all the leaves and processed by all the leaves. Hence, a single OAM packet can simultaneously instrument all the MEs in a P2MP MEG.
すべてのリーフへのOAMパケットを送信するために、Oは、ソースMEPは、すべての葉、すべてのリーフに転送プレーンによって送達され処理される単一のOAMパケットを送信することができます。したがって、単一のOAMパケットが同時に器具P2MP MEG内のすべてのME缶。
o To send an OAM packet to a single leaf, the source MEP sends a single OAM packet that will be delivered by the forwarding plane to all the leaves but contains sufficient information to identify a target leaf, and therefore is processed only by the target leaf and can be silently discarded by the other leaves.
単一のリーフにOAMパケットを送信するためにO、ソースMEPは、すべてのリーフに転送プレーンによって配信される単一のOAMパケットを送信するが、ターゲットの葉を識別するために十分な情報を含むので、ターゲットのみリーフによって処理されますそして静かに他の葉で破棄することができます。
o To send an OAM packet to a single MIP, the source MEP sends a single OAM packet with the TTL field indicating the number of hops necessary to reach the node where the MIP resides. This packet will be delivered by the forwarding plane to all intermediate nodes at the same TTL distance of the target MIP and to any leaf that is located at a shorter distance. The OAM packet must contain sufficient information to identify the target MIP and therefore is processed only by the target MIP and can be silently discarded by the others.
単一MIPにOAMパケットを送信するために、Oは、ソースMEPは、MIPが存在するノードに到達するのに必要なホップの数を示すTTLフィールドを有する単一のOAMパケットを送信します。このパケットは、ターゲットMIPの同じTTL距離で短い距離に配置されている任意のリーフへのすべての中間ノードに転送プレーンによって送達されるであろう。 OAMパケットは、ターゲットMIPを識別するために十分な情報が含まれている必要があり、したがって、ターゲットMIPによってのみ処理され、静かに他のユーザーによって廃棄することができます。
o In order to send an OAM packet to M leaves (i.e., a subset of all the leaves), the source MEP sends M different OAM packets targeted to each individual leaf in the group of M leaves. Aggregating or subsetting mechanisms are outside the scope of this document.
O M葉にOAMパケットを送信するために（すなわち、全ての葉のサブセット）は、ソースMEPは、M葉のグループ内の個々の葉を標的とするM個の異なるOAMパケットを送信します。凝集またはサブセット化機構は、この文書の範囲外です。
A bud node with a Down MEP or a per-node MEP will both terminate and relay OAM packets. Similar to how fault coverage is maximized by the explicit utilization of Up MEPs, the same is true for MEPs on a bud node.
ダウンMEPまたはノードごとのMEPとの芽ノードがOAMパケットを終了し、中継する両方。故障検出率が最大のMEPの明示的な利用によって最大化される方法と同様に、同じことが芽のノード上のMEPについても同様です。
P2MP paths are unidirectional; therefore, any return path to an originating MEP for on-demand transactions will be out-of-band. A mechanism to target "on-demand" transactions to a single MEP or MIP is required as it relieves the originating MEP of an arbitrarily large processing load and of the requirement to filter and discard undesired responses. This is because normally TTL exhaustion will address all MIPs at a given distance from the source, and failure to exhaust TTL will address all MEPs.
P2MP経路が一方向です。そのため、オンデマンドの取引のための元のMEPへのリターンパスは、帯域外となります。それは望ましくない応答をフィルタリングし、廃棄する任意の大きな処理負荷のと要求の発信元MEPを軽減するように、単一のMEPまたはMIPに「オンデマンド」のトランザクションを標的化する機構が必要です。通常TTL枯渇ソースから所定の距離に全てのMIPに対処し、TTLを排気する障害は、すべてのMEPに対処するためです。
Segment monitoring, like any in-service monitoring, in a transport network should meet the following network objectives:
トランスポートネットワーク内の任意のインサービス監視のようなセグメントの監視では、次のネットワークの目的を満たす必要があります。
1. The monitoring and maintenance of existing transport paths has to be conducted in service without traffic disruption.
1.既存の搬送路の監視およびメンテナンスは、トラフィックを中断することなくサービスで行われなければなりません。
2. Segment monitoring must not modify the forwarding of the segment portion of the transport path.
2.セグメントのモニタリングは、搬送経路のセグメント部分の転送を変更してはなりません。
SPMEs defined in Section 3.2 meet the above two objectives, when they are pre-configured or pre-instantiated as exemplified in Section 3.6. However, sometimes pre-design and pre-configuration of all the considered patterns of SPME are not preferable in real operation due to the burden of design works, a number of header consumptions, bandwidth consumption, and so on.
これらは事前構成またはセクション3.6に例示されるように事前にインスタンス化されるとき、セクション3.2で定義されたSPMEsは、上記の二つの目的を満たします。しかし、時には、SPMEの全考えパターンの予備設計及び事前設定が原因ように設計作品、ヘッダ消費の数、帯域幅消費の負担に実動作に好ましくない。
When SPMEs are configured or instantiated after the transport path has been created, network objective (1) can be met: application and removal of SPME to a faultless monitored transport entity can be performed in such a way as not to introduce any loss of traffic, e.g., by using a non-disruptive "make before break" technique.
SPMEs構成またはインスタンス化されるときの搬送経路を作成した後、（1）ネットワークの目的を満たすことができる：SPMEの適用および除去をなどのトラフィックの損失を導入しないような方法で行うことができる欠陥のない監視トランスポートエンティティに、例えば、無停止「にするブレークする前に、」技術を用いて。
However, network objective (2) cannot be met due to new assignment of MPLS labels. As a consequence, generally speaking, the results of SPME monitoring are not necessarily correlated with the behavior of traffic in the monitored entity when it does not use SPME. For example, application of SPME to a problematic/faulty monitoring entity might "fix" the problem encountered by the latter -- for as long as SPME is applied. And vice versa, application of SPME to a faultless monitored entity may result in making it faulty -- again, as long as SPME is applied.
しかし、ネットワークの目的は、（2）により、MPLSラベルの新しい割り当てを満たすことができません。その結果、一般的に言えば、SPMEのモニタリングの結果は、必ずしもそれがSPMEを使用していない監視対象エンティティにおけるトラフィックの振る舞いと相関していません。例えば、問題/故障監視エンティティにSPMEのアプリケーションは、後者が遭遇する問題を「修正」かもしれない - 限りSPMEが印加されるため。再び、限りSPMEが適用されるとして - そして、その逆は、非の打ち所のない監視対象のエンティティへのSPMEの適用は、障害のあるそれを作ることがあります。
Support for a more sophisticated segment-monitoring mechanism (temporal and hitless segment monitoring) to efficiently meet the two network objectives may be necessary.
効率的に2つのネットワークの目的を達成するためのより洗練されたセグメント監視機構（時間およびヒットレスセグメントモニタリング）のためのサポートが必要であり得ます。
One possible option to instantiate non-intrusive segment monitoring without the use of SPMEs would require the MIPs selected as monitoring end points to implement enhanced functionality and state for the monitored transport path.
SPMEsを使用せずに非侵入型セグメントの監視をインスタンス化するための一つの可能なオプションは、監視搬送路の拡張機能と状態を実現するためにエンドポイントを監視するように選択されたMIPを必要とするであろう。
For example, the MIPs need to be configured with the TTL distance to the peer or with the address of the peer, when out-of-band return paths are used.
例えば、MIPはピアへTTL距離またはアウトオブバンドリターンパスが使用されているピアのアドレスで構成する必要があります。
A further issue that would need to be considered is events that result in changing the TTL distance to the peer monitoring entity, such as protection events that may temporarily invalidate OAM information gleaned from the use of this technique.
考慮される必要があろうさらなる問題は、一時的にこの技術の使用から収集OAM情報を無効にすることができる保護イベントとしてピアモニタリングエンティティにTTL距離を変化させることにつながるイベント、です。
Further considerations on this technique are outside the scope of this document.
この技術のさらなる考慮事項は、この文書の範囲外です。
The reference model for the MPLS-TP OAM framework builds upon the concept of a MEG, and its associated MEPs and MIPs, to support the functional requirements specified in RFC 5860 [11].
MPLS-TP OAMフレームワークのための参照モデルは、MEGの概念に基づいて構築、およびその関連のMEPおよびMIPは、RFC 5860で指定された機能要件をサポートするために[11]。
The following MPLS-TP MEGs are specified in this document:
次のMPLS-TPのメガはこの文書で指定されています。
o A Section Maintenance Entity Group (SMEG), allowing monitoring and management of MPLS-TP Sections (between MPLS LSRs).
第保守エンティティグループ（SMEG）O、（MPLS LSRの間）MPLS-TPセクションの監視および管理を可能にします。
o An LSP Maintenance Entity Group (LMEG), allowing monitoring and management of an end-to-end LSP (between LERs).
LSP保守エンティティグループ（LMEG）O、（のLER間）のエンドツーエンドのLSPの監視および管理を可能にします。
o A PW Maintenance Entity Group (PMEG), allowing monitoring and management of an end-to-end Single-Segment Pseudowire (SS-PW) or MS-PW (between T-PEs).
PW保守エンティティグループ（PMEG）O、エンドツーエンドの単一セグメント疑似回線（SS-PW）又は（T-PE間）MS-PWの監視および管理を可能にします。
o An LSP SPME ME Group (LSMEG), allowing monitoring and management of an SPME (between a given pair of LERs and/or LSRs along an LSP).
O LSP SPME MEグループ（LSMEG）、（LSPに沿ってのLERおよび/またはLSRの所与の対の間の）SPMEの監視および管理を可能にします。
o A PW SPME ME Group (PSMEG), allowing monitoring and management of an SPME (between a given pair of T-PEs and/or S-PEs along an (MS-)PW).
PW SPME MEグループ（PSMEG）O、（T-PES及び/又は（MS-）PWに沿ってS-PEの所与の対の間の）SPMEの監視および管理を可能にします。
The MEGs specified in this MPLS-TP OAM framework are compliant with the architecture framework for MPLS-TP [8] that includes both MS-PWs [4] and LSPs [1].
このMPLS-TPのOAMフレームワークで指定されたメガバイトは、MPLS-TPのためのアーキテクチャ・フレームワークに準拠している[8] MS-のPWの両方を含むこと[4]とのLSP [1]。
Hierarchical LSPs are also supported in the form of SPMEs. In this case, each LSP in the hierarchy is a different sub-layer network that can be monitored, independently from higher- and lower-level LSPs in the hierarchy, on an end-to-end basis (from LER to LER) by an SPME. It is possible to monitor a portion of a hierarchical LSP by instantiating a hierarchical SPME between any LERs/LSRs along the hierarchical LSP.
階層LSPはまたSPMEsの形でサポートされています。この場合には、階層内の各LSPは、によって（LERにLERから）エンドツーエンドベースで、階層内higher-と低レベルのLSPから独立して、監視することができる異なるサブ層ネットワークでありますSPME。階層LSPに沿った任意のLER / LSRの間の階層SPMEをインスタンス化することによって階層LSPの部分を監視することができます。
Native |<------------------ MS-PW1Z ---------------->| Native
Layer | | Layer
Service | |<LSP13>| |<-LSP3X->| |<LSPXZ>| | Service
(AC1) V V V V V V V V (AC2)
+----+ +---+ +----+ +----+ +---+ +----+
+----+ |T-PE| |LSR| |S-PE| |S-PE| |LSR| |T-PE| +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| | | |=======| |=========| |=======| | | |
| CE1|--|.......PW13......|...PW3X..|......PWXZ.......|---|CE2 |
| | | |=======| |=========| |=======| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<--- Domain 1 -->| |<--- Domain Z -->|
^----------------- PW1Z PMEG ----------------^
^--- PW13 PSMEG --^ ^--- PWXZ PSMEG --^
^-------^ ^-------^
LSP13 LMEG LSPXZ LMEG
^--^ ^--^ ^---------^ ^--^ ^--^
Sec12 Sec23 Sec3X SecXY SecYZ
SMEG SMEG SMEG SMEG SMEG
^---^ ME
^ MEP
==== LSP
.... PW
T-PE 1: Terminating Provider Edge 1 LSR 2: Label Switching Router 2 S-PE 3: Switching Provider Edge 3 S-PE X: Switching Provider Edge X LSR Y: Label Switching Router Y T-PE Z: Terminating Provider Edge Z
T-PE 1：終了プロバイダエッジ1 LSR 2：ラベルスイッチングルータ2 S-PE 3：スイッチングプロバイダーエッジ3 S-PE X：スイッチングプロバイダーエッジX LSR Y：ラベルスイッチングルータY T-PE Z：終端プロバイダエッジZ
Figure 5: Reference Model for the MPLS-TP OAM Framework
図5：MPLS-TP OAMフレームワークのための参照モデル
Figure 5 depicts a high-level reference model for the MPLS-TP OAM framework. The figure depicts portions of two MPLS-TP-enabled network domains, Domain 1 and Domain Z. In Domain 1, T-PE 1 is adjacent to LSR 2 via the MPLS-TP Section Sec12, and LSR 2 is adjacent to S-PE 3 via the MPLS-TP Section Sec23. Similarly, in Domain Z, S-PE X is adjacent to LSR Y via the MPLS-TP Section SecXY, and LSR Y is adjacent to T-PE Z via the MPLS-TP Section SecYZ. In addition, S-PE 3 is adjacent to S-PE X via the MPLS-TP Section Sec3X.
図5は、MPLS-TP OAMフレームワークの高レベルの参照モデルを示します。この図は、2つのMPLS-TP対応ネットワークドメインの部分を示す、ドメイン1及びドメインZ.ドメイン1において、T-PE 1は、MPLS-TPセクションSEC12介しLSR 2に隣接し、そしてLSR 2は、S-PEに隣接していますMPLS-TP節Sec23経由して3。同様に、ドメインZに、S-PE Xは、MPLS-TPセクションSecXY介しLSR Yに隣接し、そしてLSR Yは、MPLS-TPセクションSecYZ介してT-PE Zに隣接しています。また、S-PE 3は、MPLS-TPセクションSec3Xを介してS-PE Xに隣接しています。
Figure 5 also shows a bidirectional MS-PW (MS-PW1Z) between AC1 on T-PE1 and AC2 on T-PE Z. The MS-PW consists of three bidirectional PW path segments: 1) PW13 path segment between T-PE 1 and S-PE 3 via the bidirectional LSP13 LSP, 2) PW3X path segment between S-PE 3 and S-PE X via the bidirectional LSP3X LSP, and 3) PWXZ path segment between S-PE X and T-PE Z via the bidirectional LSPXZ LSP.
T-PE 1との間の1）PW13パスセグメント：図5はまた、T-PE Z.ザMS-PW三個の双方向PWの経路セグメントから構成上のT-PE1とAC2にAC1間の双方向MS-PW（MS-PW1Z）を示します双方向LSP13 LSPを介してS-PE X及びT-PE Z間の双方向LSP3X LSPを介してS-PE 3およびS-PE Xとの間の2）PW3X経路セグメント、および3）PWXZパス・セグメントを介してS-PE 3双方向LSPXZ LSP。
The MPLS-TP OAM procedures that apply to a MEG are expected to operate independently from procedures on other MEGs. Yet, this does not preclude that multiple MEGs may be affected simultaneously by the same network condition -- for example, a fiber cut event.
MEGに適用されるMPLS-TPのOAM手順は、他のメガ上の手順から独立して動作することが期待されます。例えば、ファイバ切断イベント - まだ、これは複数のメガバイトが同じネットワーク条件によって同時に影響を受ける可能性があることを排除するものではありません。
Note that there are no constraints imposed by this OAM framework on the number or type (P2P, P2MP, LSP, or PW), of MEGs that may be instantiated on a particular node. In particular, when looking at Figure 5, it should be possible to configure one or more MEPs on the same node if that node is the end point of one or more MEGs.
特定のノードでインスタンス化することができるメガバイトの数や種類（P2P、P2MP、LSP、またはPW）上でこのOAMフレームワークによって課さない制約が存在しないことに留意されたいです。図5を見ると、特に、そのノードは、1つ以上のメガバイトのエンドポイントである場合には、同じノード上の一の以上のMEPを構成することが可能であるべきです。
Figure 5 does not describe a PW3X PSMEG because typically SPMEs are used to monitor an OAM domain (like PW13 and PWXZ PSMEGs) rather than the segment between two OAM domains. However, the OAM framework does not pose any constraints on the way SPMEs are instantiated as long as they are not overlapping.
典型的SPMEsはむしろ2つのOAMドメインの間のセグメントよりも（PW13とPWXZ PSMEGs等）OAMドメインを監視するために使用されているため、図5はPW3X PSMEGを記載していません。しかし、OAMフレームワークは限りが重複していないとしてインスタンス化される方法SPMEs上の任意の制約をもたらすことはありません。
The subsections below define the MEGs specified in this MPLS-TP OAM architecture framework document. Unless otherwise stated, all references to domains, LSRs, MPLS-TP Sections, LSPs, pseudowires, and MEGs in this section are made in relation to those shown in Figure 5.
以下のサブセクションでは、このMPLS-TP OAMアーキテクチャフレームワーク文書で指定されたメガを定義します。特に明記しない限り、このセクションのドメイン、のLSR、MPLS-TPセクション、LSPを、スードワイヤ、およびメガバイトへのすべての参照は、図5に示したものに関連してなされます。
An MPLS-TP Section MEG (SMEG) is an MPLS-TP maintenance entity intended to monitor an MPLS-TP Section. An SMEG may be configured on any MPLS-TP section. SMEG OAM packets must fate-share with the user data packets sent over the monitored MPLS-TP Section.
MPLS-TPセクションMEG（SMEG）は、MPLS-TPセクションをモニターすることを意図するものでMPLS-TP保守エンティティです。 SMEGは、任意のMPLS-TP部に構成されてもよいです。 SMEG OAMパケットを監視し、MPLS-TPのセクションを介して送信されるユーザデータパケットと運命-共有する必要があります。
An SMEG is intended to be deployed for applications where it is preferable to monitor the link between topologically adjacent (next hop in this layer network) MPLS-TP LSRs rather than monitoring the individual LSP or PW path segments traversing the MPLS-TP Section and where the server-layer technology does not provide adequate OAM capabilities.
SMEGが、むしろ個々のLSPを監視またはPW経路セグメントがMPLS-TPセクションを通過し、ここでよりMPLS-TPのLSRトポロジー的隣接（この層のネットワークにおけるネクストホップ）との間のリンクを監視することが望ましい用途に展開されるように意図されていますサーバー層技術は、適切なOAM機能を提供していません。
Figure 5 shows five Section MEGs configured in the network between AC1 and AC2:
図5は、AC1とAC2との間のネットワークで構成された5セクションメガバイトを示しています。
1. Sec12 MEG associated with the MPLS-TP Section between T-PE 1 and LSR 2,
T-PE 1とLSR 2との間のMPLS-TPのセクションに関連付けられた1 SEC12 MEG、
2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and S-PE 3,
LSR 2及びS-PE 3間のMPLS-TPセクションに関連付けられた2 Sec23 MEG、
3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and S-PE X,
S-PE 3およびS-PE Xとの間のMPLS-TPのセクションに関連付けられた3 Sec3X MEG、
4. SecXY MEG associated with the MPLS-TP Section between S-PE X and LSR Y, and
4. SecXY MEG S-PE XおよびLSR Y、との間のMPLS-TPセクションに関連付けられています
5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and T-PE Z
LSR Y及びT-PE Zとの間のMPLS-TPセクションに関連付けられている5 SecYZ MEG
An MPLS-TP LSP MEG (LMEG) is an MPLS-TP maintenance entity group intended to monitor an end-to-end LSP between its LERs. An LMEG may be configured on any MPLS LSP. LMEG OAM packets must fate-share with user data packets sent over the monitored MPLS-TP LSP.
MPLS-TP LSP MEG（LMEG）は、のLERとの間のエンドツーエンドのLSPを監視することを意図するものでMPLS-TP保守エンティティグループです。 LMEGは、任意のMPLS LSPに構成されてもよいです。 LMEG OAMパケットを監視し、MPLS-TP LSPを介して送信されるユーザデータパケットと運命-共有する必要があります。
An LMEG is intended to be deployed in scenarios where it is desirable to monitor an entire LSP between its LERs, rather than, say, monitoring individual PWs.
LMEGは、個々のPWを監視し、そののLER間全体LSPを監視することが望ましいシナリオではなく、たとえば、に配備されることが意図されます。
Figure 5 depicts two LMEGs configured in the network between AC1 and AC2: 1) the LSP13 LMEG between T-PE 1 and S-PE 3, and 2) the LSPXZ LMEG between S-PE X and T-PE Z. Note that the presence of a LSP3X LMEG in such a configuration is optional, and hence, not precluded by this framework. For instance, the network operator may prefer to monitor the MPLS-TP Section between the two LSRs rather than the individual LSPs.
1）T-PE 1とS-PE 3、との間のLSP13 LMEG 2）S-PE X及びT-PE Z.間LSPXZ LMEGことに注意してください。図5はAC1とAC2との間のネットワークで構成された2つのLMEGsを示しますこのような構成でLSP3X LMEGの存在は任意であり、従って、このフレームワークによって除外されません。例えば、ネットワークオペレータは、二つのLSRよりもむしろ個々のLSPの間でMPLS-TPセクションを監視することを好むことができます。
An MPLS-TP PW MEG (PMEG) is an MPLS-TP maintenance entity intended to monitor a SS-PW or MS-PW between its T-PEs. A PMEG can be configured on any SS-PW or MS-PW. PMEG OAM packets must fate-share with the user data packets sent over the monitored PW.
MPLS-TP PW MEG（PMEG）はT-PE間のSS-PWまたはMS-PWを監視することを意図するものでMPLS-TP保守エンティティです。 PMEGは、SS-PWまたはMS-PW任意に設定することができます。 PMEG OAMパケットが監視PWを介して送信されるユーザデータパケットと運命-共有する必要があります。
A PMEG is intended to be deployed in scenarios where it is desirable to monitor an entire PW between a pair of MPLS-TP-enabled T-PEs rather than monitoring the LSP that aggregates multiple PWs between PEs.
PMEGは、かなりのPE間の複数のPWを集約LSPを監視よりMPLS-TP-有効T-PEの対の間に全体のPWを監視することが望ましいシナリオで展開されるように意図されています。
Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments (PW13, PW3X, and PWXZ) and its associated end-to-end PMEG (PW1Z PMEG).
図5は、MS-PW（MS-PW1Z）が3つのパスセグメント（PW13、PW3X、及びPWXZ）からなるとそれに関連するエンドツーエンドPMEG（PW1Z PMEG）を示します。
An MPLS-TP LSP SPME MEG (LSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an LSP between the MEPs instantiated for the SPME, independent from the end-to-end monitoring (LMEG). An LSMEG can monitor an LSP path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment.
MPLS-TP LSP SPME MEG（LSMEG）は、エンド・ツー・エンドの監視から独立SPMEのためにインスタンス化のMEPとの間のLSPの任意の部分を監視することを意図関連保守エンティティグループ（LMEGとMPLS-TP SPMEであります）。 LSMEGはLSPパスセグメントを監視することができ、そしてそれはまた、経路セグメントの端部（S）のノード（複数可）のフォワーディングエンジン（単数または複数）を含むことができます。
When an SPME is established between non-adjacent LSRs, the edges of the SPME become adjacent at the LSP sub-layer network and any LSR that was previously in between becomes an LSR for the SPME.
SPMEは非隣接のLSR間で確立されたときに、SPMEのエッジはSPMEためLSRとなる間に以前にあったLSPサブレイヤネットワークと任意LSRに隣接なります。
Multiple hierarchical LSMEGs can be configured on any LSP. LSMEG OAM packets must fate-share with the user data packets sent over the monitored LSP path segment.
複数の階層LSMEGsはどのLSP上で設定することができます。 LSMEG OAMパケットは、監視LSPパス・セグメントを介して送信されるユーザデータパケットと運命-共有しなければなりません。
A LSME can be defined between the following entities:
LSMEは、以下のエンティティ間で定義することができます。
o The LER and LSR of a given LSP.
所与LSPのLERとLSR O。
o Any two LSRs of a given LSP.
所与LSPのいずれか2つのLSR O。
An LSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an LSP or set of LSPs rather than the entire LSP itself, for example, when there is a need to monitor a part of an LSP that extends beyond the administrative boundaries of an MPLS-TP-enabled administrative domain.
そのLSPの一部を監視する必要がある場合LSMEGは、例えばLSPまたはLSPのセット全体ではなくLSP自体の一部の動作を監視することが望ましいシナリオで展開されるように意図されていますMPLS-TP-有効な管理ドメインの管理境界を越えて延びています。
|<-------------------- PW1Z ------------------->|
| |
| |<-------------LSP1Z LSP------------->| |
| |<-LSP13->| |<LSP3X>| |<-LSPXZ->| |
V V V V V V V V
+----+ +---+ +----+ +----+ +---+ +----+
+----+ | PE | |LSR| |DBN | |DBN | |LSR| | PE | +----+
| | | 1 | | 2 | | 3 | | X | | Y | | Z | | |
| |AC1| |=====================================| |AC2| |
| CE1|---|.....................PW1Z......................|---|CE2 |
| | | |=====================================| | | |
| | | | | | | | | | | | | | | |
+----+ | | | | | | | | | | | | +----+
+----+ +---+ +----+ +----+ +---+ +----+
. . . .
| | | |
|<---- Domain 1 --->| |<---- Domain Z --->|
^---------^ ^---------^
LSP13 LSMEG LSPXZ LSMEG
^-------------------------------------^
LSP1Z LMEG
DBN: Domain Border Node
DBN：ドメイン境界のノード
PE 1: Provider Edge 1 LSR 2: Label Switching Router 2 DBN 3: Domain Border Node 3 DBN X: Domain Border Node X LSR Y: Label Switching Router Y PE Z: Provider Edge Z
PE 1：プロバイダエッジ1 LSR 2：ラベルスイッチングルータ2 DBN 3：ドメイン境界ノード3 DBN X：ドメイン境界ノードX LSR Y：ラベルスイッチングルーターY PE Z：プロバイダエッジZ
Figure 6: MPLS-TP LSP SPME MEG (LSMEG)
図6：MPLS-TP LSP SPME ME（LSMEG）
Figure 6 depicts a variation of the reference model in Figure 5 where there is an end-to-end LSP (LSP1Z) between PE 1 and PE Z. LSP1Z consists of, at least, three LSP Concatenated Segments: LSP13, LSP3X, and LSPXZ. In this scenario, there are two separate LSMEGs configured to monitor the LSP1Z: 1) a LSMEG monitoring the LSP13 Concatenated Segment on Domain 1 (LSP13 LSMEG), and 2) a LSMEG monitoring the LSPXZ Concatenated Segment on Domain Z (LSPXZ LSMEG).
PE 1とPE Z. LSP1Z間のエンドツーエンドLSP（LSP1Z）は、から成るがある場合図6は、図5における参照モデルの変化を示す少なくとも三個のLSP連結セグメント：LSP13、LSP3X、及びLSPXZ 。このシナリオでは、LSP1Zを監視するように構成された2つの別々のLSMEGsがある：ドメイン1（LSP13 LSMEG）にLSP13連結セグメントを監視1）LSMEG、およびドメインZ（LSPXZ LSMEG）にLSPXZ連結セグメントを監視2）LSMEG。
It is worth noticing that LSMEGs can coexist with the LMEG monitoring the end-to-end LSP and that LSMEG MEPs and LMEG MEPs can be coincident in the same node (e.g., PE 1 node supports both the LSP1Z LMEG MEP and the LSP13 LSMEG MEP).
それはLSMEGsはLMEGは、エンドツーエンドのLSPを監視すると共存できることとLSMEGのMEPとLMEGのMEPが同じノード（例えば、で一致することができることは注目に値するであり、PE 1つのノードはLSP1Z LMEG MEPとLSP13 LSMEG MEPの両方をサポート）。
An MPLS-TP MS-PW SPME Monitoring MEG (PSMEG) is an MPLS-TP SPME with an associated maintenance entity group intended to monitor an arbitrary part of an MS-PW between the MEPs instantiated for the SPME, independently of the end-to-end monitoring (PMEG). A PSMEG can monitor a PW path segment, and it may also include the forwarding engine(s) of the node(s) at the edge(s) of the path segment. A PSMEG is no different than an SPME; it is simply named as such to discuss SPMEs specifically in a PW context.
MEG監視MPLS-TP MS-PW SPME（PSMEG）はSPMEのためにインスタンス化のMEPとの間MS-PWの任意の部分を監視することを意図関連保守エンティティグループとMPLS-TP SPMEであり、独立してエンドツーエンドの末端（PMEG）を監視します。 PSMEGは、PWパスセグメントを監視することができ、そしてそれはまた、経路セグメントの端部（S）のノード（複数可）のフォワーディングエンジン（単数または複数）を含むことができます。 PSMEGはSPMEよりも違いはありません。単にPWの文脈で特異的にSPMEsを議論するような名前が付けられます。
When SPME is established between non-adjacent S-PEs, the edges of the SPME become adjacent at the MS-PW sub-layer network, and any S-PE that was previously in between becomes an LSR for the SPME.
SPME非隣接S-PE間で確立されると、SPMEのエッジはMS-PWサブレイヤネットワークにおける隣接なり、SPMEためLSRとなる間に以前にあった任意のS-PE。
S-PE placement is typically dictated by considerations other than OAM. S-PEs will frequently reside at operational boundaries such as the transition from distributed control plane (CP) to centralized Network Management System (NMS) control or at a routing area boundary. As such, the architecture would appear not to have the flexibility that arbitrary placement of SPME segments would imply. Support for an arbitrary placement of PSMEG would require the definition of additional PW sub-layering. Multiple hierarchical PSMEGs can be configured on any MS-PW. PSMEG OAM packets fate-share with the user data packets sent over the monitored PW path Segment.
S-PEの配置は、典型的には、OAM以外の考慮事項によって決定されます。 S-PEはしばしば、ネットワーク管理システム（NMS）管理を集中する分散制御プレーン（CP）からの遷移として、またはルーティングエリア境界での動作の境界に存在します。このように、アーキテクチャは、SPMEセグメントの任意の配置を意味するものであろうと柔軟性を持っていないと思われます。 PSMEGの任意の配置のためのサポートが追加PWサブレイヤーの定義が必要となります。複数の階層PSMEGsは、任意のMS-PWに構成することができます。 PSMEG OAMは、監視PWパスセグメントを介して送信されるユーザデータパケットと運命シェアをパケット。
A PSMEG does not add hierarchical components to the MPLS architecture; it defines the role of existing components for the purposes of discussing OAM functionality.
PSMEGは、MPLSアーキテクチャの階層のコンポーネントを追加しません。それは、OAM機能を議論する目的のために既存のコンポーネントの役割を定義します。
A PSME can be defined between the following entities:
PSMEは、以下のエンティティ間で定義することができます。
o The T-PE and any S-PE of a given MS-PW.
O T-PEと所与のMS-PWの任意のS-PE。
o Any two S-PEs of a given MS-PW.
所与のMS-PWの任意の2つのS-PES O。
Note that, in line with the SPME description in Section 3.2, when a PW SPME is instantiated after the MS-PW has been instantiated, the TTL distance of the MIPs may change and MIPs in the PW SPME are no longer part of the encompassing MEG. This means that the S-PE nodes hosting these MIPs are no longer S-PEs but P nodes at the SPME LSP level. The consequences are that the S-PEs hosting the PSMEG MEPs become adjacent S-PEs. This is no different than the operation of SPMEs in general.
MS-PWがインスタンス化された後PW SPMEがインスタンス化されるときに、のMIPのTTLの距離が変化してもよいし、PW SPMEでのMIPが包含MEGのもはや一部でない、セクション3.2でSPMEの説明に沿って、なお。これは、S-PEは、これらのMIPは、もはやSPME LSPレベルでのS-PESが、Pノードでホスティングないノードことを意味します。結果はPSMEGの欧州議会議員をホスティングしているS-PEは、隣接するS-PESになるということです。これは、一般的にSPMEsの動作よりも違いはありません。
A PSMEG is intended to be deployed in scenarios where it is preferable to monitor the behavior of a part of an MS-PW rather than the entire end-to-end PW itself, for example, when monitoring an MS-
PSMEGは、例えば、MS-PWの一部ではなく全体のエンドツーエンドのPW自体の挙動を監視することが望ましいシナリオで展開されるように意図され、MS-を監視する場合
PW path segment within a given network domain of an inter-domain MS-PW.
ドメイン間MS-PWの所与のネットワークドメイン内のPWパスセグメント。
Figure 5 depicts an MS-PW (MS-PW1Z) consisting of three path segments: PW13, PW3X, and PWXZ with two separate PSMEGs: 1) a PSMEG monitoring the PW13 MS-PW path segment on Domain 1 (PW13 PSMEG) and 2) a PSMEG monitoring the PWXZ MS-PW path segment on Domain Z with (PWXZ PSMEG).
図5は、MS-PW（MS-PW1Z）が3つのパスセグメントからなる示す2つの別々のPSMEGsとPW13、PW3X、及びPWXZ：1）PSMEGドメイン1（PW13 PSMEG）にPW13 MS-PWの経路セグメントを監視し、2 ）（PWXZ PSMEG）とドメインZにPWXZ MS-PWの経路セグメントを監視PSMEG。
It is worth noticing that PSMEGs can coexist with the PMEG monitoring the end-to-end MS-PW and that PSMEG MEPs and PMEG MEPs can be coincident in the same node (e.g., T-PE 1 node supports both the PW1Z PMEG MEP and the PW13 PSMEG MEP).
それをPSMEGsはPMEGは、エンドツーエンドのMS-PWを監視することと共存できることは注目に値するとPSMEGのMEPとPMEGのMEPは、同じノード（例えば、で一致させることができ、T-PE 1つのノードは両方をサポートPW1Z PMEG MEPとPW13 PSMEG MEP）。
Multilink techniques are in use today and are expected to continue to be used in future deployments. These techniques include Ethernet link aggregation [22] and the use of link bundling for MPLS [18] where the option to spread traffic over component links is supported and enabled. While the use of link bundling can be controlled at the MPLS-TP layer, use of link aggregation (or any server-layer-specific multilink) is not necessarily under the control of the MPLS-TP layer. Other techniques may emerge in the future. These techniques frequently share the characteristic that an LSP may be spread over a set of component links and therefore be reordered, but no flow within the LSP is reordered (except when very infrequent and minimally disruptive load rebalancing occurs).
マルチリンク技術は、今日使用されているし、将来の展開で使用され続けると予想されます。これらの技術は、コンポーネントリンク上でトラフィックを分散するためのオプションがサポートされ、有効になっているイーサネットリンクアグリゲーション[22]とMPLSのためのバンドリングリンクの使用[18]が挙げられます。リンクバンドリングの使用は、MPLS-TP層で制御することができるが、リンクアグリゲーション（または任意のサーバーレイヤ固有マルチリンク）の使用は、MPLS-TP層の制御下にある必要はありません。他の技術は、将来的に出現することがあります。これらの技術は、しばしばLSPコンポーネントリンクのセットに広がることができ、従って並べ替えることが、LSP内には流れは（非常に稀及び最小破壊荷重・リバランスが発生した場合を除いて）並べ替えされないという特徴を共有します。
The use of multilink techniques may be prohibited or permitted in any particular deployment. If multilink techniques are used, the deployment can be considered to be only partially MPLS-TP compliant; however, this is unlikely to prevent their use.
マルチ技術の使用は、任意の特定の配備で禁止または許可することができます。マルチリンク技術が使用される場合、展開は部分的にしかMPLS-TP準拠するように考えることができます。しかし、これは彼らの使用を防止することはほとんどありません。
The implications for OAM are that not all components of a multilink will be exercised, independent server-layer OAM being required to exercise the aggregated link components. This has further implications for MIP and MEP placement, as per-interface MIPs or Down MEPs on a multilink interface are akin to a layer violation, as they instrument at the granularity of the server layer. The implications for reduced OAM loss measurement functionality are documented in Sections 5.5.3 and 6.2.3.
OAMのための含意は、マルチリンクのすべてのコンポーネントが行使されないことを、独立したサーバレイヤOAMは、集約リンクコンポーネントを行使するために必要とされています。マルチリンクインターフェイス上のインターフェイス単位のMIPまたは下のMEPは、サーバ層の粒度で、それらの機器として、層の違反に似ているので、これは、MIPとMEPの配置のため、さらに意味を持っています。減少OAM損失測定機能のための含意はセクション5.5.3および6.2.3に記載されています。
In this document, proactive monitoring refers to OAM operations that are either configured to be carried out periodically and continuously or preconfigured to act on certain events such as alarm signals.
この文書では、積極的な監視は、いずれかの定期的かつ継続的に行うか、そのような警報信号などの特定のイベントに作用するように事前設定されるように構成されているOAM操作を指します。
Proactive monitoring is usually performed "in-service". Such transactions are universally MEP to MEP in operation, while notifications can be node to node (e.g., some MS-PW transactions) or node to MEPs (e.g., AIS). The control and measurement considerations are:
プロアクティブ監視は通常、「インサービス」を行っています。そのような取引は、通知がのMEP（例えば、AIS）のノードに、ノード（例えば、いくつかのMS-PW取引）またはノードすることができるが、動作時にMEPする普遍MEPです。制御と測定の考慮事項は、次のとおりです。
1. Proactive monitoring for a MEG is typically configured at the creation time of the transport path.
MEG 1.予防的モニタリングは、典型的には、搬送路の作成時に設定されています。
2. The operational characteristics of in-band measurement transactions (e.g., CV, Loss Measurement (LM), etc.) are configured at the MEPs.
2.インバンド測定トランザクションが（例えば、CVは、損失測定（LM）、等）のMEPに設定されているの動作特性。
3. Server-layer events are reported by OAM packets originating at intermediate nodes.
3.サーバ層のイベントが中間ノードから発信OAMパケットによって報告されています。
4. The measurements resulting from proactive monitoring are typically reported outside of the MEG (e.g., to a management system) as notification events such as faults or indications of performance degradations (such as signal degrade conditions).
4.積極的な監視から生じる測定は、典型的には、MEGの外に報告されている（例えば、管理システムに）そのような障害や性能劣化の指標として通知イベントとして（例えば信号などの条件を劣化させます）。
5. The measurements resulting from proactive monitoring may be periodically harvested by an NMS.
5.積極的な監視から得測定は、定期的にNMSによって採取することができます。
Proactive fault reporting is assumed to be subject to unreliable delivery and soft-state, and it needs to operate in cases where a return path is not available or faulty. Therefore, periodic repetition is assumed to be used for reliability, instead of handshaking.
予防的な障害報告は信頼性のない送達およびソフト状態の対象であると仮定し、それはリターンパスが利用可能であるか、または故障していない場合で動作する必要があります。したがって、周期的な繰り返しではなく、ハンドシェイクのため、信頼性のために使用することを想定しています。
Delay measurement also requires periodic repetition to allow estimation of the packet delay variation for the MEG.
遅延測定もMEGのためのパケット遅延変動の推定を可能にするために、定期的に繰り返しが必要です。
For statically provisioned transport paths, the above information is statically configured; for dynamically established transport paths, the configuration information is signaled via the control plane or configured via the management plane.
静的プロビジョニング搬送路のために、上記の情報は、静的に構成されています。動的に確立されたトランスポートパスに対して、設定情報は、制御プレーンを介してシグナリングされるか、管理プレーンを介して構成される。
The operator may enable/disable some of the consequent actions defined in Section 5.1.2.
オペレータは、有効/ 5.1.2項で定義され、その結果としての行動の一部を無効化することができます。
Proactive Continuity Check functions, as required in Section 2.2.2 of RFC 5860 [11], are used to detect a loss of continuity (LOC) defect between two MEPs in a MEG.
RFC 5860のセクション2.2.2に、必要に応じて[11]、積極的な導通チェック機能は、MEG内の2つのMEP間の連続性の喪失（LOC）の欠陥を検出するために使用されます。
Proactive Connectivity Verification functions, as required in Section 2.2.3 of RFC 5860 [11], are used to detect an unexpected connectivity defect between two MEGs (e.g., mismerging or misconnection), as well as unexpected connectivity within the MEG with an unexpected MEP.
RFC 5860のセクション2.2.3に、必要に応じて積極的な接続検証関数は、[11]は、予想外のMEPとMEG内の二つのメガ（例えば、mismergingまたは誤接続）、ならびに予想外の接続の間の予期しない接続の欠陥を検出するために使用されます。
Both functions are based on the (proactive) generation, at the same rate, of OAM packets by the source MEP that are processed by the peer sink MEP(s). As a consequence, in order to save OAM bandwidth consumption, CV, when used, is linked with CC into Continuity Check and Connectivity Verification (CC-V) OAM packets.
両方の機能は、ピア・シンクMEP（S）によって処理され、ソースMEPによってOAMパケットの同じ速度で、（積極的な）生成に基づいています。その結果、OAM帯域幅の消費を節約するために、CVは、使用時に、導通チェックや接続検証（CC-V）OAMパケットにCCとリンクされています。
In order to perform proactive Connectivity Verification, each CC-V OAM packet also includes a globally unique Source MEP identifier, whose value needs to be configured on the source MEP and on the peer sink MEP(s). In some cases, to avoid the need to configure the globally unique Source MEP identifier, it is preferable to perform only proactive Continuity Check. In this case, the CC-V OAM packet does not need to include any globally unique Source MEP identifier. Therefore, a MEG can be monitored only for CC or for both CC and CV. CC-V OAM packets used for CC-only monitoring are called CC OAM packets, while CC-V OAM packets used for both CC and CV are called CV OAM packets.
プロアクティブ接続検証を行うために、各CC-VのOAMパケットはまた、その値は、ソースMEP上及びピアシンクMEP（複数可）に設定される必要があり、グローバルに一意なソースMEP識別子を含みます。いくつかのケースでは、グローバルに一意のソースMEP識別子を設定する必要性を回避するために、唯一の積極的な連続性チェックを行うことが好ましいです。この場合、CC-VのOAMパケットは、任意のグローバルにユニークなソースMEP識別子を含める必要はありません。したがって、MEGは、CCまたはCCおよびCVの両方のためだけに監視することができます。 CCおよびCVの両方のために使用されたCC-VのOAMパケットがCVのOAMパケットと呼ばれながら、CC-のみ監視するために使用されたCC-VのOAMパケットは、CCのOAMパケットと呼ばれます。
As a consequence, it is not possible to detect misconnections between two MEGs monitored only for continuity as neither the OAM packet type nor the OAM packet content provides sufficient information to disambiguate an invalid source. To expand:
結果として、OAMパケットタイプでもOAMパケットの内容でもないが、無効なソースを明確にするために十分な情報を提供して唯一の継続性について監視2メガバイトの間で誤接続を検出することはできません。拡大するために：
o For a CC OAM packet leaking into a CC monitored MEG - undetectable.
検出できない - O CCに漏れCCのOAMパケットの場合はMEGを監視しました。
o For a CV OAM packet leaking into a CC monitored MEG - reception of CV OAM packets instead of a CC OAM packets (e.g., with the additional Source MEP identifier) allows detecting the fault.
（追加のソースMEP識別子と、例えば）の代わりCCのOAMパケットのCV OAMパケットの受信障害を検出可能 - O CCに漏れCVのOAMパケットについてMEGを監視しました。
o For a CC OAM packet leaking into a CV monitored MEG - reception of CC OAM packets instead of CV OAM packets (e.g., lack of additional Source MEP identifier) allows detecting the fault.
CVに漏れCCのOAMパケットは、MEGを監視するためのO - の代わりにCV OAMパケットのCCのOAMパケットの受信（追加ソースMEP識別子、例えば、欠如）が故障を検出可能にします。
o For a CV OAM packet leaking into a CV monitored MEG - reception of CV OAM packets with different Source MEP identifier permits fault to be identified.
O CVに漏れのCV OAMパケットについてMEG監視 - 異なるソースMEP識別子とCVのOAMパケットの受信に障害を識別することを可能にします。
Having a common packet format for CC-V OAM packets would simplify parsing in a sink MEP to properly detect all the misconfiguration cases described above.
CC-VのOAMパケットのための共通のパケット・フォーマットを有する適切上述した全ての構成ミスのケースを検出するために、シンクMEPで解析を単純化するであろう。
MPLS-TP OAM supports different formats of MEP identifiers to address different environments. When an alternative to IP addressing is desired (e.g., MPLS-TP is deployed in transport network environments where consistent operations with other transport technologies defined by the ITU-T are required), the ITU Carrier Code (ICC)-based format for MEP identification is used: this format is under definition in [25]. When MPLS-TP is deployed in an environment where IP capabilities are available and desired for OAM, the IP-based MEP identification is used: this format is described in [24].
MPLS-TP OAMは、異なる環境に対処するためにMEP識別子の異なるフォーマットをサポートしています。 IPアドレス指定するための代替が望まれる場合（例えば、MPLS-TPは、ITU-Tによって定義された他のトランスポート技術と一致する操作が必要とされるトランスポート・ネットワーク環境で展開されている）、ITUキャリアコード（ICC）MEP同定のためのベースのフォーマット使用されている：このフォーマットは、[25]で定義です。 MPLS-TPはIP機能が利用可能な環境に配備し、OAMのために所望される場合、IPベースのMEPの識別が使用される：このフォーマットは、[24]に記載されています。
CC-V OAM packets are transmitted at a regular, operator-configurable rate. The default CC-V transmission periods are application dependent (see Section 5.1.3).
CC-VのOAMパケットは、通常、オペレータによる設定レートで送信されます。デフォルトのCC-Vの送信期間は、（5.1.3項を参照）に依存したアプリケーションです。
Proactive CC-V OAM packets are transmitted with the "minimum loss probability PHB" within the transport path (LSP, PW) they are monitoring. For E-LSPs, this PHB is configurable on the network operator's basis, while for L-LSPs this is determined as per RFC 3270 [23]. PHBs can be translated at the network borders by the same function that translates them for user data traffic. The implication is that CC-V fate-shares with much of the forwarding implementation, but not all aspects of PHB processing are exercised. Either on-demand tools are used for finer-grained fault finding or an implementation may utilize a CC-V flow per PHB to ensure a CC-V flow fate-shares with each individual PHB.
プロアクティブCC-VのOAMパケットは、それらが監視している搬送パス（LSP、PW）内の「最小損失確率PHB」で送信されます。 L-LSPのために、これは、RFC 3270 [23]に従って決定されるE-LSPのために、このPHBは、ネットワークオペレータのベースで構成可能です。 PHBは、ユーザデータトラフィックのためにそれらを変換すると同じ機能により、ネットワークの境界で翻訳することができます。含意は、転送の実装の多くが、PHB処理のすべての側面が行使されていないとのことCC-Vの運命 - 株です。オンデマンドのツールは、よりきめ細かい障害発見や実装に使用されているいずれかの個々のPHBとCC-Vフロー運命-株式を確保するためにPHBあたりCC-Vの流れを利用することができます。
In a co-routed or associated, bidirectional point-to-point transport path, when a MEP is enabled to generate proactive CC-V OAM packets with a configured transmission rate, it also expects to receive proactive CC-V OAM packets from its peer MEP at the same transmission rate. This is because a common SLA applies to all components of the transport path. In a unidirectional transport path (either point-to-point or point-to-multipoint), the source MEP is enabled only to generate CC-V OAM packets, while each sink MEP is configured to expect these packets at the configured rate.
MEPが設定伝送速度とプロアクティブCC-VのOAMパケットを生成することを可能にされるとき、共ルーティングまたは関連する、双方向ポイント・ツー・ポイントの搬送経路において、それはまた、ピアからの積極的なCC-VのOAMパケットを受信することを期待します同じ伝送レートでMEP。一般的なSLAは、搬送経路のすべてのコンポーネントに適用されるためです。各シンクMEPが設定速度でこれらのパケットを期待するように構成されている一方向搬送路（ポイントツーポイントまたはポイントツーマルチポイントのいずれか）において、ソースMEPは、CC-VのOAMパケットを生成するためにのみイネーブルされます。
MIPs, as well as intermediate nodes not supporting MPLS-TP OAM, are transparent to the proactive CC-V information and forward these proactive CC-V OAM packets as regular data packets.
MIPS、並びにMPLS-TP OAMをサポートしていない中間ノードは、プロアクティブCC-V情報に透明であり、通常のデータパケットとしてこれらの積極的なCC-VのOAMパケットを転送します。
During path setup and tear down, situations arise where CC-V checks would give rise to alarms, as the path is not fully instantiated. In order to avoid these spurious alarms, the following procedures are recommended. At initialization, the source MEP function (generating proactive CC-V packets) should be enabled prior to the corresponding sink MEP function (detecting continuity and connectivity defects). When disabling the CC-V proactive functionality, the sink MEP function should be disabled prior to the corresponding source MEP function.
パスが完全にインスタンス化されていないとして、CC-Vチェックは、アラームを引き起こすだろうどこパス設定や解体時には、状況が発生します。これらの偽のアラームを避けるために、以下の手順が推奨されています。初期化時に、ソースMEP機能（プロアクティブCC-Vパケットを生成する）、対応するシンクMEP機能に先立って有効にされるべきである（連続性および接続の欠陥を検出します）。 CC-V積極的な機能を無効にすると、シンクMEP機能は、対応するソースMEP機能する前に無効にする必要があります。
It should be noted that different encapsulations are possible for CC-V packets, and therefore it is possible that in case of misconfigurations or mis-connectivity, CC-V packets are received with an unexpected encapsulation.
異なるカプセル化は、CC-Vパケットに対して可能であることに留意すべきであり、したがって、設定ミスや誤接続の場合には、CC-Vパケットが予期しないカプセル化で受信されることが可能です。
There are practical limitations to detecting unexpected encapsulation. It is possible that there are misconfiguration or mis-connectivity scenarios where OAM packets can alias as payload, e.g., when a transport path can carry an arbitrary payload without a pseudowire.
予想外のカプセル化を検出することに実際的な制限があります。 OAMパケットをペイロードとしてエイリアスは、例えば、搬送経路が疑似回線なしで、任意のペイロードを運ぶことができ、設定ミスや誤接続のシナリオが存在することが可能です。
When CC-V packets are received with an unexpected encapsulation that can be parsed by a sink MEP, the CC-V packet is processed as if it were received with the correct encapsulation. If it is not a manifestation of a mis-connectivity defect, a warning is raised (see Section 5.1.1.4). Otherwise, the CC-V packet may be silently discarded as unrecognized and a LOC defect may be detected (see Section 5.1.1.1).
CC-VパケットがシンクMEPによって解析することができる予想外のカプセル化で受信されたとき、それが正しいカプセル化して受信されたかのように、CC-Vパケットが処理されます。それが誤接続不良の現れではない場合、警告が（セクション5.1.1.4を参照）が発生します。そうでない場合、CC-Vのパケットは暗黙認識できないとして廃棄されてもよく、LOC欠陥（セクション5.1.1.1を参照）を検出することができます。
The defect conditions are described in no specific order.
欠陥条件はありません特定の順序で記載されています。
Proactive CC-V functions allow a sink MEP to detect the defect conditions described in the following subsections. For all of the described defect cases, a sink MEP should notify the equipment fault management process of the detected defect.
プロアクティブCC-V機能は、シンクMEPは、以下のサブセクションで説明した欠陥状態を検出することを可能にします。説明欠陥事例のすべてについて、シンクMEPは、検出された欠陥の装置障害管理処理を通知しなければなりません。
Sequential consecutive loss of CC-V packets is considered indicative of an actual break and not of congestive loss or physical-layer degradation. The loss of 3 packets in a row (implying a detection interval that is 3.5 times the insertion time) is interpreted as a true break and a condition that will not clear by itself.
CC-Vパケットのシーケンシャルな連続的な損失は、うっ血性損失または物理層の劣化の実際の破断を示すとしないと考えられます。行の3つのパケット（3.5倍の挿入時間である検出間隔を意味する）の損失は、真のブレークと単独では明らかではないであろう条件として解釈されます。
A CC-V OAM packet is considered to carry an unexpected globally unique Source MEP identifier if it is a CC OAM packet received by a sink MEP monitoring the MEG for CV; it is a CV OAM packet received by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV but carrying a unique Source MEP identifier that is different that the expected one. Conversely, the CC-V packet is considered to have an expected globally unique Source MEP identifier; it is a CC OAM packet received by a sink MEP monitoring the MEG for CC, or it is a CV OAM packet received by a sink MEP monitoring the MEG for CV and carrying a unique Source MEP identifier that is equal to the expected one.
CC-VのOAMパケットは、それがCVのためのMEGを監視シンクMEPが受信したCCのOAMパケットの場合、予期しないグローバルに一意のソースMEP識別子を運ぶために考えられています。それは、CCのためのMEGを監視シンクMEPが受信したCV OAMパケットであるか、CVのためのMEGの監視が、1つを期待することを異なるユニークなソースMEP識別子を運ぶシンクMEPが受信したCV OAMパケットです。逆に、CC-Vパケットが予想されるグローバルに一意のソースMEP識別子を有すると考えられます。それは、CCのためのMEGを監視シンクMEPにより受信されたCCのOAMパケットであるか、CVのためのMEGを監視し、予想されるものと同じである固有のソースMEP識別子を運ぶシンクMEPにより受信されたCVのOAMパケットです。
When proactive CC-V is enabled, a sink MEP detects a loss of continuity (LOC) defect when it fails to receive proactive CC-V OAM packets from the source MEP.
プロアクティブCC-Vが有効になっている場合、それは、ソースMEPからの積極的なCC-VのOAMパケットの受信に失敗した場合、シンクMEPは、連続性の喪失（LOC）欠陥を検出します。
o Entry criteria: If no proactive CC-V OAM packets from the source MEP (and in the case of CV, this includes the requirement to have the expected globally unique Source MEP identifier) are received within the interval equal to 3.5 times the receiving MEP's configured CC-V reception period.
O登録基準：ソースMEPからのNOプロアクティブCC-VのOAMパケットの場合は（およびCVの場合、これは予想されるグローバルに一意のソースMEP識別子を有することが要件を含む）の3.5倍受信MEPのに等しい間隔内に受信されます構成されたCC-V受付期間。
o Exit criteria: A proactive CC-V OAM packet from the source MEP (and again in the case of CV, with the expected globally unique Source MEP identifier) is received.
O終了基準：（予想グローバルに一意のソースMEP識別子を持つと、再びCVの場合、）元MEPからの積極的なCC-VのOAMパケットが受信されます。
When a proactive CC-V OAM packet is received, a sink MEP identifies a mis-connectivity defect (e.g., mismerge, misconnection, or unintended looping) when the received packet carries an unexpected globally unique Source MEP identifier.
プロアクティブCC-VのOAMパケットを受信したときに受信したパケットが予期しないグローバル一意ソースMEP識別子を搬送するとき、シンクMEPは、誤接続の欠陥（例えば、mismerge、誤接続、又は意図しないループ）を特定します。
o Entry criteria: The sink MEP receives a proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier or with an unexpected encapsulation.
O登録基準：シンクMEPは想定外のグローバルに一意のソースMEP識別子または予期しないカプセル化して積極的なCC-VのOAMパケットを受信します。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with an unexpected globally unique Source MEP identifier for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with an unexpected globally unique Source MEP identifier since this defect has been raised. This requires the OAM packet to self-identify the CC-V periodicity, as not all MEPs can be expected to have knowledge of all MEGs.
O終了基準：シンクMEPは、少なくとも、パケットが予期しないで受信積極的なCC-VのOAMの3.5倍の最長伝送周期に等しい間隔のための予想外のグローバルにユニークなソースMEP識別子を持つ任意の積極的なCC-V OAMパケットを受信しませんこの欠陥以来、グローバルにユニークなソースMEP識別子が提起されています。いないすべてのMEPはすべてメガバイトの知識を持っていることが予想されるので、これは、自己識別CC-Vの周期にOAMパケットが必要です。
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with a transmission period different than the locally configured reception period, then a CC-V period misconfiguration defect is detected.
プロアクティブCC-VのOAMパケットが期待グローバル一意ソースMEP識別子ではなく、ローカルに構成された受信周期とは異なる送信周期で受信される場合には、CC-V期間の設定ミスの欠陥が検出されます。
o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with a transmission period different than its own CC-V-configured transmission period.
O参加基準：MEPが期待グローバルに一意のソースMEP識別子ではなく、独自のCC-V-構成された送信期間とは異なる送信周期でCC-V積極的なパケットを受信します。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an incorrect transmission period for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an incorrect transmission period since this defect has been raised.
O終了基準：シンクMEPは、少なくとも積極的なCC-V OAMの3.5倍の最長伝送周期に等しい間隔に予想されるグローバルに一意のソースMEP識別子と間違って送信周期を持つ任意の積極的なCC-VのOAMパケットを受信しません予想されるグローバルに一意のソースMEP識別子と、この欠陥以来、間違った送信周期で受信したパケットが提起されています。
If proactive CC-V OAM packets are received with the expected globally unique Source MEP identifier but with an unexpected encapsulation, then a CC-V unexpected encapsulation defect is detected.
積極的なCC-VのOAMパケットが期待されるグローバルに一意のソースMEP識別子でなく、予想外のカプセル化を使用して受信された場合には、CC-V予期しないカプセル化欠陥が検出されました。
It should be noted that there are practical limitations to detecting unexpected encapsulation (see Section 5.1.1).
これは予想外のカプセル化を検出することに実際的な制限があることに留意しなければならない（5.1.1項を参照してください）。
o Entry criteria: A MEP receives a CC-V proactive packet with the expected globally unique Source MEP identifier but with an unexpected encapsulation.
O参加基準：MEPが期待グローバルに一意のソースMEP識別子でなく、予想外のカプセル化を使用してCC-V積極的なパケットを受信します。
o Exit criteria: The sink MEP does not receive any proactive CC-V OAM packet with the expected globally unique Source MEP identifier and an unexpected encapsulation for an interval equal at least to 3.5 times the longest transmission period of the proactive CC-V OAM packets received with the expected globally unique Source MEP identifier and an unexpected encapsulation since this defect has been raised.
O終了基準：シンクMEPは予想グローバルに一意のソースMEP識別子と、少なくとも積極的なCC-VのOAMパケットの3.5倍の最長伝送周期に等しい間隔の予想外のカプセル化された任意の積極的なCC-VのOAMパケットを受信しませんこの欠陥が提起されているので、期待グローバルに一意のソースMEP識別子と予想外のカプセル化を受けました。
A sink MEP that detects any of the defect conditions defined in Section 5.1.1 declares a defect condition and performs the following consequent actions.
5.1.1項で定義された欠陥の条件のいずれかを検出するシンクMEPは、障害状態を宣言し、次の結果としてのアクションを実行します。
If a MEP detects a mis-connectivity defect, it blocks all the traffic (including also the user data packets) that it receives from the misconnected transport path.
MEPは、誤接続の欠陥を検出した場合、ブロックが誤って接続搬送路から受信する（また、ユーザ・データ・パケットを含む）すべてのトラフィック。
If a MEP detects a LOC defect that is not caused by a period misconfiguration, it should block all the traffic (including also the user data packets) that it receives from the transport path, if this consequent action has been enabled by the operator.
MEPは、周期設定ミスによって引き起こされないLOC欠陥を検出した場合、この結果としてのアクションがオペレータによって有効になっている場合には、搬送路から受信する（ユーザデータパケットも含む）のすべてのトラフィックをブロックしなければなりません。
It is worth noticing that the OAM requirements document [11] recommends that CC-V proactive monitoring be enabled on every MEG in order to reliably detect connectivity defects. However, CC-V proactive monitoring can be disabled by an operator for a MEG. In the event of a misconnection between a transport path that is proactively monitored for CC-V and a transport path that is not, the MEP of the former transport path will detect a LOC defect representing a connectivity problem (e.g., a misconnection with a transport path where CC-V proactive monitoring is not enabled) instead of a continuity problem, with a consequence of delivery of traffic to an incorrect destination. For these reasons, the traffic block consequent action is applied even when a LOC condition occurs. This block consequent action can be disabled through configuration. This deactivation of the block action may be used for activating or deactivating the monitoring when it is not possible to synchronize the function activation of the two peer MEPs.
これは、OAM要件ドキュメント[11]はCC-Vプロアクティブなモニタリングが確実に接続欠陥を検出するために、すべてのMEGで有効にすることをお勧めしていることに気付い価値があります。しかし、CC-Vプロアクティブな監視は、MEGのためのオペレータによって無効にすることができます。積極的にCC-Vとではありません搬送経路のために監視されて搬送路間の誤接続の際には、かつての搬送路のMEPは、接続の問題（例えば、輸送との誤接続を表すLOC欠陥を検出しますCC-Vプロアクティブな監視が有効になっていないパス）の代わりに、間違った宛先へのトラフィックの配信の結果との連続性の問題、。これらの理由から、トラフィックのブロック結果として生じるアクションはLOC条件が発生した場合でも適用されます。このブロック後件アクションは、設定によって無効にすることができます。ブロックアクションのこの不活性化は、2つのピアのMEPの機能の活性化を同期することができない場合に、監視を活性化または不活性化のために使用することができます。
If a MEP detects a LOC defect (Section 5.1.1.1) or a mis-connectivity defect (Section 5.1.1.2), it declares a signal fail condition of the ME.
MEPはLOC欠陥（セクション5.1.1.1）または誤接続の欠陥（セクション5.1.1.2）を検出した場合、信号がMEの条件に失敗宣言します。
It is a matter of local policy whether or not a MEP that detects a period misconfiguration defect (Section 5.1.1.3) declares a signal fail condition of the ME.
これは、期間の設定ミスの欠陥（セクション5.1.1.3）を検出MEPは、信号をMEの条件に失敗宣言するか否かのローカルポリシーの問題です。
The detection of an unexpected encapsulation defect does not have any consequent action: it is just a warning for the network operator. An implementation able to detect an unexpected encapsulation but not able to verify the source MEP ID may choose to declare a mis-connectivity defect.
予期しないカプセル化欠陥の検出は、任意の結果としてのアクションを持っていない：それはちょうどネットワーク事業者のための警告です。予想外のカプセル化を検出することができますが、誤接続の欠陥を宣言することもできますソースMEP IDを検証することはできません実現。
At all MEPs inside a MEG, the following configuration information needs to be configured when a proactive CC-V function is enabled:
MEG内のすべてのMEPで、次の設定情報は積極的なCC-Vの機能が有効になっている場合に設定する必要があります。
o MEG-ID: the MEG identifier to which the MEP belongs.
O MEG-ID：MEPが属するMEG識別子。
o MEP-ID: the MEP's own identity inside the MEG.
oMEP-IS：MEG内部のMEP自身のアイデンティティ。
o list of the other MEPs in the MEG. For a point-to-point MEG, the list would consist of the single MEP ID from which the OAM packets are expected. In case of the root MEP of a P2MP MEG, the list is composed of all the leaf MEP IDs inside the MEG. In case of the leaf MEP of a P2MP MEG, the list is composed of the root MEP ID (i.e., each leaf needs to know the root MEP ID from which it expects to receive the CC-V OAM packets).
MEG内の他のMEPのOリスト。ポイントツーポイントMEGのために、リストは、OAMパケットが期待され、そこから単一のMEP IDから成ります。 P2MP MEGのルートMEPの場合は、リストは、MEG内のすべてのリーフMEPのIDが構成されています。 P2MP MEGのリーフMEPの場合には、リストは、ルートMEPのIDで構成されている（すなわち、各リーフは、CC-VのOAMパケットを受信することを期待そこからルートMEP IDを知る必要があります）。
o PHB for E-LSPs. It identifies the per-hop behavior of a CC-V packet. Proactive CC-V packets are transmitted with the "minimum loss probability PHB" previously configured within a single network operator. This PHB is configurable on network operator's basis. PHBs can be translated at the network borders.
E-LSPのためのOのPHB。これは、CC-Vパケットのホップ単位動作を識別します。プロアクティブCC-Vパケットは、以前に単一のネットワークオペレータ内に構成「最小損失確率PHB」で送信されます。このPHBは、ネットワークオペレータの単位で設定可能です。 PHBは、ネットワークの境界で翻訳することができます。
o transmission rate. The default CC-V transmission periods are application dependent (depending on whether they are used to support fault management, performance monitoring, or protection-switching applications):
O伝送速度。デフォルトのCC-Vの送信期間は、アプリケーション（彼らは障害管理、パフォーマンス監視、または保護スイッチングアプリケーションをサポートするために使用されているかどうかに応じて）に依存しています：
* Fault Management: default transmission period is 1 s (i.e., transmission rate of 1 packet/second).
*障害管理：デフォルト送信周期は、1秒（1パケット/秒、すなわち、伝送速度）です。
* Performance Management: default transmission period is 100 ms (i.e., transmission rate of 10 packets/second). CC-V contributes to the accuracy of performance monitoring statistics by permitting the defect-free periods to be properly distinguished as described in Sections 5.5.1 and 5.6.1.
*パフォーマンス管理：デフォルト送信周期は、100ミリ秒（10個のパケット/秒、すなわち、伝送速度）です。 CC-Vは、セクション5.5.1および5.6.1に記載されるように適切に区別する欠陥のない期間を可能にすることにより、性能監視統計の精度に寄与する。
* Protection Switching: If protection switching with CC-V, defect entry criteria of 12 ms is required (for example, in conjunction with the requirement to support 50 ms recovery time as indicated in RFC 5654 [5]), then an implementation should use a default transmission period of 3.33 ms (i.e., transmission rate of 300 packets/second). Sometimes, the requirement of 50 ms recovery time is associated with the requirement for a CC-V defect entry criteria period of 35 ms; in these cases a transmission period of 10 ms (i.e., transmission rate of 100 packets/second) can be used. Furthermore, when there is no need for so small CC-V defect entry criteria periods, a larger transmission period can be used.
*保護スイッチング：保護は、CC-V、必要とされる12ミリ秒の欠陥エントリーの基準（例えば、50ミリ秒の回復時間をサポートするための要件と併せてRFCに示されるように5654 [5]）、その後、実装が使用すべきで切り替える場合3.33ミリ秒のデフォルトの送信期間（すなわち、300個のパケット/秒の伝送速度）。時々、50ミリ秒の回復時間の要件は、35ミリ秒のCC-V欠陥エントリー基準期間の要件に関連しています。これらの場合には10ミリ秒の送信期間（すなわち、100個のパケット/秒の伝送速度）を用いることができます。非常に小さいCC-V欠陥エントリー基準期間の必要がない場合また、より大きな送信期間を使用することができます。
It should be possible for the operator to configure these transmission rates for all applications, to satisfy specific network requirements.
オペレータは、特定のネットワーク要件を満たすために、すべてのアプリケーションのためにこれらの伝送レートを設定することが可能でなければなりません。
Note that the reception period is the same as the configured transmission rate.
受信期間が設定された送信レートと同じであることに留意されたいです。
For management-provisioned transport paths, the above parameters are statically configured; for dynamically signaled transport paths, the configuration information is distributed via the control plane.
管理プロビジョニング搬送路のため、上記のパラメータは、静的に構成されています。動的シグナリング搬送路のために、構成情報は、制御プレーンを介して配信されます。
The operator should be able to enable/disable some of the consequent actions. Which consequent actions can be enabled/disabled is described in Section 5.1.2.
オペレータは、その結果としての行動の一部を有効/無効にすることができるはずです。これは必然的なアクションは、セクション5.1.2で説明されて有効/無効にすることができます。
The Remote Defect Indication (RDI) function, as required in Section 2.2.9 of RFC 5860 [11], is an indicator that is transmitted by a sink MEP to communicate to its source MEP that a signal fail condition exists. In case of co-routed and associated bidirectional transport paths, RDI is associated with proactive CC-V, and the RDI indicator can be piggy-backed onto the CC-V packet. In case of unidirectional transport paths, the RDI indicator can be sent only using an out-of-band return path if it exists and its usage is enabled by policy actions.
RFC 5860のセクション2.2.9に、必要に応じてリモート障害表示（RDI）機能、[11]は、信号状態が存在する失敗そのソースMEPと通信するシンクMEPにより送信される指標です。同時ルーティングおよび関連する双方向搬送路の場合には、RDIは、積極的なCC-Vに関連付けられ、かつRDIインジケータはCC-Vのパケットにピギーバックすることができます。一方向搬送路の場合には、RDIインジケータは、それが存在し、その使用は、ポリシーアクションによって有効化されている場合のみ、帯域外のリターンパスを使用して送信することができます。
When a MEP detects a signal fail condition (e.g., in case of a continuity or connectivity defect), it should begin transmitting an RDI indicator to its peer MEP. When incorporated into CC-V, the RDI information will be included in all proactive CC-V packets that it generates for the duration of the signal fail condition's existence.
MEPは、信号が条件を失敗検出したときに（例えば、連続または接続不良の場合）、そのピアMEPにRDIインジケータの送信を開始すべきです。 CC-Vに組み込まれた場合には、RDI情報は、信号の持続時間は、条件の存在を失敗するためにそれが生成するすべての積極的なCC-Vパケットに含まれます。
A MEP that receives packets from a peer MEP with the RDI information should determine that its peer MEP has encountered a defect condition associated with a signal fail condition.
RDI情報をピアMEPからパケットを受信したMEPはピアMEPは、信号状態を失敗に関連した障害状態が発生したと判断すべきです。
MIPs as well as intermediate nodes not supporting MPLS-TP OAM are transparent to the RDI indicator and forward OAM packets that include the RDI indicator as regular data packets, i.e., the MIP should not perform any actions nor examine the indicator.
MIP並びにMPLS-TP OAMをサポートしていない中間ノードは、通常のデータ・パケット、すなわち、MIPは、任意のアクションを実行したりインジケータを調べるべきではないとしてRDIインジケータを含むRDI指標と前方OAMパケットに透明です。
When the signal fail condition clears, the MEP should stop transmitting the RDI indicator to its peer MEP. When incorporated into CC-V, the RDI indicator will not be set for subsequent transmission of proactive CC-V packets. A MEP should clear the RDI defect upon reception of an RDI indicator cleared.
信号条件がクリアできない場合、MEPはピアMEPにRDIインジケータの送信を停止すべきです。 CC-Vに組み込まれたときに、RDIインジケータはプロアクティブCC-Vパケットの後続の送信のために設定されません。 MEPはクリアRDIインジケータの受信時にRDI欠陥をクリアする必要があります。
In order to support RDI, the indication may be carried in a unique OAM packet or may be embedded in a CC-V packet. The in-band RDI transmission rate and PHB of the OAM packets carrying RDIs should be the same as that configured for CC-V to allow both far-end and near-end defect conditions being resolved in a timeframe that has the same order of magnitude. This timeframe is application specific as described in Section 5.1.3. Methods of the out-of-band return paths will dictate how out-of-band RDIs are transmitted.
RDIをサポートするために、指示はユニークOAMパケットで運ばれてもよいし、CC-Vパケットに埋め込まれていてもよいです。 RDISを運ぶOAMパケットの帯域内RDI伝送速度とPHBは、遠端と近端の両方欠陥条件が同じ大きさのオーダーを有する時間枠内で解決されてできるようにCC-V用に構成されたものと同じでなければなりません。 5.1.3項で説明したようにこの期間は、アプリケーション固有のものです。アウトオブバンドリターン・パスの方法は、アウトオブバンドRDISが送信されている方法を指示します。
The Alarm Reporting function, as required in Section 2.2.8 of RFC 5860 [11], relies upon an Alarm Indication Signal (AIS) packet to suppress alarms following detection of defect conditions at the server (sub-)layer.
RFC 5860のセクション2.2.8 [11]に必要に応じてアラームレポート機能は、サーバ（サブ）レイヤで、欠陥状態の検出次のアラームを抑制するためにアラーム表示信号（AIS）パケットに依存します。
When a server MEP asserts a signal fail condition, it notifies that to the co-located MPLS-TP client/server adaptation function that then generates OAM packets with AIS information in the downstream direction to allow the suppression of secondary alarms at the MPLS-TP MEP in the client (sub-)layer.
サーバMEPは、信号をアサートするときの条件を失敗、それは次に、下流方向におけるAIS情報とOAMパケットを生成し、同一位置にMPLS-TPクライアント/サーバ・アダプテーション機能はMPLS-TPで二次警報の抑制を可能にすることを通知しますクライアント（サブ）レイヤでのMEP。
The generation of packets with AIS information starts immediately when the server MEP asserts a signal fail condition. These periodic OAM packets, with AIS information, continue to be transmitted until the signal fail condition is cleared.
サーバMEPは、信号が条件に失敗したときにアサートAIS情報を含むパケットの生成が直ちに開始されます。信号は、条件がクリアされて失敗するまで、これらの定期的なOAMパケットは、AIS情報と、送信され続けています。
It is assumed that to avoid spurious alarm generation a MEP detecting a loss of continuity defect (see Section 5.1.1.1) will wait for a hold-off interval prior to asserting an alarm to the management system. Therefore, upon receiving an OAM packet with AIS information, an MPLS-TP MEP enters an AIS defect condition and suppresses reporting of alarms to the NMS on the loss of continuity with its peer MEP, but it does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of AIS condition.
連続性欠陥（セクション5.1.1.1を参照のこと）の損失を検出するMEPインターバル前管理システムにアラームをアサートするホールドオフを待つことになる偽のアラーム発生を回避することが想定されます。したがって、AIS情報とOAMパケットを受信すると、MPLS-TP MEPはAIS欠陥状態となり、そのピアMEPとの連続性の喪失にNMSにアラームの報告を抑制し、それはトラフィックをブロックしない搬送路から受け取りました。 MEPはAIS条件の非存在下で連続欠陥条件の喪失を検出すると連続アラーム発生の損失を再開する。
MIPs, as well as intermediate nodes, do not process AIS information and forward these AIS OAM packets as regular data packets.
MIPS、だけでなく、中間ノードは、AIS情報を処理し、通常のデータパケットとしてこれらのAIS OAMパケットを転送しません。
For example, let's consider a fiber cut between T-PE 1 and LSR 2 in the reference network of Figure 5. Assuming that all of the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of Sec12 SMEG, LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network, only the alarm associated to the fiber cut needs to be reported to an NMS, while all secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms).
たとえば、のは、図5で説明したメガのすべてが積極的なCC-Vが有効になっていると仮定すると、図5の基準ネットワークでT-PE 1とLSR 2との間のファイバ切断を考える、LOC欠陥がののMEPにより検出されますSEC12 SMEG、LSP13 LMEG、PW1 PSMEG、およびPW1Z PMEG。全ての二次アラームが抑制されるべきであるが、トランスポート・ネットワークでは、ファイバ切断に関連する唯一のアラームは、NMSに報告する必要がある（すなわち、NMSに報告又は二次アラームとして報告されていません）。
If the fiber cut is detected by the MEP in the physical layer (in LSR 2), LSR 2 can generate the proper alarm in the physical layer and suppress the secondary alarm associated with the LOC defect detected on Sec12 SMEG. As both MEPs reside within the same node, this process does not involve any external protocol exchange. Otherwise, if the physical layer does not have enough OAM capabilities to detect the fiber cut, the MEP of Sec12 SMEG in LSR 2 will report a LOC alarm.
ファイバカットが（LSR 2）物理層でMEPにより検出された場合、LSR 2は、物理層で適切なアラームを生成し、SEC12 SMEGで検出LOCの欠陥に関連した二次警報を抑制することができます。両方のMEPが同じノード内に存在するように、このプロセスは、任意の外部のプロトコル交換を必要としません。物理層は、ファイバ切断を検出するのに十分なOAM機能を持っていない場合はそれ以外の場合は、LSR 2におけるSEC12 SMEGのMEPはLOCアラームを報告します。
In both cases, the MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates AIS packets on the LSP13 LMEG in order to allow its MEP in S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm.
両方の場合において、LSR 2におけるSEC12 SMEGのMEPは、その後、LOC警報を抑制するためにS-PE 3におけるMEPを可能にするためにLSP13 LMEGにAISパケットを生成LSP13 LMEGの適応機能に通知します。 PW13 PSMEGのMEPがLSP13 LMEGのMEPと同じノード内に存在するので、S-PE 3はまた、PW13 PSMEGに二次アラームを抑制することができます。 S-PE 3におけるPW13 PSMEGのMEPはまた、そのMEP T-PEでZは、LOCのアラームを抑制することを可能にするためにPW1Z PMEGにAISパケットを生成することPW1Z PMEGの適応機能に通知します。
The generation of AIS packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the AIS generation).
MPLS-TPのクライアント（サブ）レイヤにおける各MEGのためのAISパケットの生成（すなわち、オペレータは、AIS生成を無効/有効にすることができる）構成です。
The AIS condition is cleared if no AIS packet has been received in 3.5 times the AIS transmission period.
何AISパケットが3.5倍AIS送信期間に受信されなかった場合、AIS条件がクリアされます。
The AIS transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established.
AIS送信期間は、伝統的に毎秒1であるが、より長い期間を設定するオプションも望ましいであろう。結果として、OAMパケットが自己識別適切な終了基準を確立することができるように送信期間をする必要があります。
AIS packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].
AISパケットは、単一のネットワーク事業者内の「最小損失確率PHB」で送信されます。 L-LSPのために、これは、RFC 3270 [23]に従って決定されるE-LSPのために、このPHBは、ネットワークオペレータのベースで構成可能です。
The Lock Reporting function, as required in Section 2.2.7 of RFC 5860 [11], relies upon a Lock Report (LKR) packet used to suppress alarms following administrative locking action in the server (sub-)layer.
RFC 5860のセクション2.2.7に、必要に応じて、機能を報告ロック[11]は、サーバ（サブ）レイヤで管理ロックアクション次のアラームを抑制するために使用されるロック報告（LKR）パケットに依存します。
When a server MEP is locked, the MPLS-TP client (sub-)layer adaptation function generates packets with LKR information to allow the suppression of secondary alarms at the MEPs in the client (sub-)layer. Again, it is assumed that there is a hold-off for any loss of continuity alarms in the client-layer MEPs downstream of the node originating the Lock Report. In case of client (sub-)layer co-routed bidirectional transport paths, the LKR information is sent on both directions. In case of client (sub-)layer unidirectional transport paths, the LKR information is sent only in the downstream direction. As a consequence, in case of client (sub-)layer point-to-multipoint transport paths, the LKR information is sent only to the
サーバMEPがロックされている場合、MPLS-TPのクライアント（サブ）レイヤアダプテーション機能は、クライアント（サブ）レイヤでのMEPで二次警報の抑制を可能にするLKR情報を持つパケットを生成します。ここでも、ロックレポートを発信ノードの下流のクライアント層のMEPの連続アラームの損失のためのホールドオフがあることが想定されます。クライアント（サブ）レイヤ共ルーティング双方向搬送路の場合には、LKR情報が両方向に送信されます。クライアントの場合には（サブ）一方向搬送路を層LKR情報が下流方向にのみ送信されます。その結果、クライアント（サブ）レイヤポイント・ツー・マルチポイント搬送路の場合には、LKR情報のみに送信されます
MEPs that are downstream from the server (sub-)layer that has been administratively locked. Client (sub-)layer associated bidirectional transport paths behave like co-routed bidirectional transport paths if the server (sub-)layer that has been administratively locked is used by both directions; otherwise, they behave like unidirectional transport paths.
管理上ロックされているサーバー（サブ）レイヤから下流にあるのMEP。クライアント（サブ）レイヤ関連する双方向搬送路を共ルーティング双方向搬送路のように振る舞うかの管理両方の方向で使用されているロックされたサーバ（サブ）層とそれ以外の場合は、一方向の搬送経路のように振る舞います。
The generation of packets with LKR information starts immediately when the server MEP is locked. These periodic packets, with LKR information, continue to be transmitted until the locked condition is cleared.
サーバMEPがロックされているときLKR情報を持つパケットの生成がすぐに開始されます。ロックされた状態が解消されるまで、これらの定期的なパケットは、LKR情報と、送信され続けています。
Upon receiving a packet with LKR information, an MPLS-TP MEP enters an LKR defect condition and suppresses the loss of continuity alarm associated with its peer MEP but does not block traffic received from the transport path. A MEP resumes loss of continuity alarm generation upon detecting loss of continuity defect conditions in the absence of the LKR condition.
LKR情報とパケットを受信すると、MPLS-TP MEPはLKR欠陥状態となり、そのピアMEPに関連した連続アラームの損失を抑制することができるが、搬送路から受信したトラフィックをブロックしません。 MEPはLKR条件の非存在下で連続欠陥条件の喪失を検出すると連続アラーム発生の損失を再開する。
MIPs, as well as intermediate nodes, do not process the LKR information; they forward these LKR OAM packets as regular data packets.
MIPS、ならびに中間ノード、LKR情報を処理していません。彼らは、通常のデータパケットとしてこれらのLKRのOAMパケットを転送します。
For example, let's consider the case where the MPLS-TP Section between T-PE 1 and LSR 2 in the reference network of Figure 5 is administratively locked at LSR 2 (in both directions).
例えば、T-PE 1と図5の基準ネットワークにおけるLSR 2との間のMPLS-TPセクションが管理（両方向に）LSR 2にロックされるのは、場合を考えます。
Assuming that all the MEGs described in Figure 5 have proactive CC-V enabled, a LOC defect is detected by the MEPs of LSP13 LMEG, PW1 PSMEG, and PW1Z PMEG; however, in a transport network all these secondary alarms should be suppressed (i.e., not reported to the NMS or reported as secondary alarms).
LOC欠陥がLSP13 LMEG、PW1 PSMEG、及びPW1Z PMEGののMEPにより検出され、図5で説明したすべてのメガがプロアクティブCC-Vが有効になっていると仮定すると。しかし、すべてのこれらの二次のアラームが抑制されるべきトランスポートネットワークに（すなわち、NMSに報告されていないか、二次警報として報告されます）。
The MEP of Sec12 SMEG in LSR 2 notifies the adaptation function for LSP13 LMEG that then generates LKR packets on the LSP13 LMEG in order to allow its MEPs in T-PE 1 and S-PE 3 to suppress the LOC alarm. S-PE 3 can also suppress the secondary alarm on PW13 PSMEG because the MEP of PW13 PSMEG resides within the same node as the MEP of LSP13 LMEG. The MEP of PW13 PSMEG in S-PE 3 also notifies the adaptation function for PW1Z PMEG that then generates AIS packets on PW1Z PMEG in order to allow its MEP in T-PE Z to suppress the LOC alarm.
LSR 2におけるSEC12 SMEGのMEPは、その後、T-PE 1とS-PE 3におけるのMEPはLOCのアラームを抑制することを可能にするためにLSP13 LMEGにLKRパケットを生成LSP13 LMEGの適応機能に通知します。 PW13 PSMEGのMEPがLSP13 LMEGのMEPと同じノード内に存在するので、S-PE 3はまた、PW13 PSMEGに二次アラームを抑制することができます。 S-PE 3におけるPW13 PSMEGのMEPはまた、そのMEP T-PEでZは、LOCのアラームを抑制することを可能にするためにPW1Z PMEGにAISパケットを生成することPW1Z PMEGの適応機能に通知します。
The generation of LKR packets for each MEG in the MPLS-TP client (sub-)layer is configurable (i.e., the operator can enable/disable the LKR generation).
MPLS-TPのクライアント（サブ）レイヤにおける各MEGのためのLKRパケットの生成は、設定可能である（すなわち、オペレータはLKRの生成を有効/無効にすることができます）。
The locked condition is cleared if no LKR packet has been received for 3.5 times the transmission period.
何LKRパケットが3.5倍の伝送期間に受信されなかった場合、ロック条件がクリアされます。
The LKR transmission period is traditionally one per second, but an option to configure longer periods would be also desirable. As a consequence, OAM packets need to self-identify the transmission period such that proper exit criteria can be established.
LKR送信期間は、伝統的に毎秒1であるが、より長い期間を設定するオプションも望ましいであろう。結果として、OAMパケットが自己識別適切な終了基準を確立することができるように送信期間をする必要があります。
LKR packets are transmitted with the "minimum loss probability PHB" within a single network operator. For E-LSPs, this PHB is configurable on network operator's basis, while for L-LSPs, this is determined as per RFC 3270 [23].
LKRパケットは、単一のネットワーク事業者内の「最小損失確率PHB」で送信されます。 L-LSPのために、これは、RFC 3270 [23]に従って決定されるE-LSPのために、このPHBは、ネットワークオペレータのベースで構成可能です。
Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring (PM) function in order to facilitate reporting of Quality of Service (QoS) information for a transport path as required in Section 2.2.11 of RFC 5860 [11]. LM is used to exchange counter values for the number of ingress and egress packets transmitted and received by the transport path monitored by a pair of MEPs.
パケットロス測定（LM）RFC 5860のセクション2.2.11に必要とされる搬送路のためのサービス品質（QoS）の情報の報告を容易にするために、MPLS-TPのパフォーマンスモニタリング（PM）機能でサポートされている機能の一つであります[11]。 LMは、議員の対によって監視搬送経路によって送受信入力および出力パケット数のカウンタ値を交換するために使用されます。
Proactive LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during the lifetime of the transport path. Each MEP performs measurements of its transmitted and received user data packets. These measurements are then correlated in real time with the peer MEP in the ME to derive the impact of packet loss on a number of performance metrics for the ME in the MEG. The LM transactions are issued such that the OAM packets will experience the same PHB scheduling class as the measured traffic while transiting between the MEPs in the ME.
プロアクティブLMは、定期的ピアMEPへと搬送経路の存続期間中にピアMEP（共ルーティングまたは双方向搬送路関連する場合）からのLMのOAMパケットを受信することにより、MEPからLMのOAMパケットを送信することによって行われます。各MEPは、その送信され、受信したユーザデータパケットの測定を行います。これらの測定値は、その後、MEGにおけるMEのパフォーマンス・メトリックの数にパケットロスの影響を導出するMEにおけるピアMEPとリアルタイムで相関されます。 LM取引は、ME内のMEPの間で通過しながら、OAMパケットを測定したトラフィックと同じPHBスケジューリングクラスを経験するように発行されています。
For a MEP, near-end packet loss refers to packet loss associated with incoming data packets (from the far-end MEP), while far-end packet loss refers to packet loss associated with egress data packets (towards the far-end MEP).
遠端パケットロスが（遠端MEPに向かって）出力データ・パケットに関連付けられたパケット損失を指すMEPは、近端パケットロスは、（遠端MEPからの）着信データ・パケットに関連付けられたパケット損失を指し。
Proactive LM can be operated in two ways:
プロアクティブLMは、2つの方法で操作することができます。
o One-way: a MEP sends an LM OAM packet to its peer MEP containing all the required information to facilitate near-end packet loss measurements at the peer MEP.
O一方向：MEPは、ピアMEPで近端パケット損失測定を容易にするために必要なすべての情報を含むピアMEPにLM OAMパケットを送信します。
o Two-way: a MEP sends an LM OAM packet with an LM request to its peer MEP, which replies with an LM OAM packet as an LM response. The request/response LM OAM packets contain all the required information to facilitate both near-end and far-end packet loss measurements from the viewpoint of the originating MEP.
O双方向：MEPは、LM応答としてLM OAMパケットで応答ピアMEPへLM要求にLM OAMパケットを送信します。要求/応答LMのOAMパケットは、発信元MEPの観点から近端と遠端の両方のパケット損失の測定を容易にするために必要なすべての情報を含んでいます。
One-way LM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way LM is applicable only to bidirectional (co-routed or associated) transport paths.
双方向LMのみを双方向に適用可能であるが、一方向LMは、（共ルーティングまたは関連）、（COルーティングまたは関連）搬送路搬送路単方向および双方向の両方に適用可能です。
MIPs, as well as intermediate nodes, do not process the LM information; they forward these proactive LM OAM packets as regular data packets.
MIPS、ならびに中間ノードは、LM情報を処理していません。彼らは、通常のデータパケットとしてこれらの積極的なLMのOAMパケットを転送します。
In order to support proactive LM, the transmission rate and, for E-LSPs, the PHB class (associated with the LM OAM packets originating from a MEP) need to be configured as part of the LM provisioning. LM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]), in order to maximize reliability of measurement within the traffic class.
プロアクティブLMをサポートするために、伝送速度と、E-LSPのために、（MEP由来LMのOAMパケットに関連付けられている）PHBクラスはLMプロビジョニングの一部として構成する必要があります。 LMのOAMパケットはトラフィッククラス内の測定の信頼性を最大にするために、（RFC 3260 [17]参照）を測定PHBスケジューリングクラス内の最も低いドロップ優先順位を与えるPHBで送信されるべきです。
If that PHB class is not an ordered aggregate where the ordering constraint is all packets with the PHB class being delivered in order, LM can produce inconsistent results.
そのPHBクラスは順序制約が順番に配信されるPHBクラスを持つすべてのパケットで注文した集計されていない場合、LMは、一貫性のない結果を生成することができます。
Performance monitoring (e.g., LM) is only relevant when the transport path is defect free. CC-V contributes to the accuracy of PM statistics by permitting the defect-free periods to be properly distinguished. Therefore, support of proactive LM has implications on the CC-V transmission period (see Section 5.1.3).
搬送路が無欠陥である場合にパフォーマンス監視（例えば、LMは）のみ関連します。 CC-Vを適切に識別できるように、欠陥のない期間を可能にすることにより、PMの統計情報の正確さに貢献しています。そのため、積極的なLMのサポートは、CC-Vの送信期間に影響します（5.1.3項を参照してください）。
If an implementation makes use of a hardware forwarding path that operates in parallel with an OAM processing path, whether hardware or software based, the packet and byte counts may be skewed if one or more packets can be processed before the OAM processing samples counters. If OAM is implemented in software, this error can be quite large.
実装は、ハードウェアまたはソフトウェアがベースのかどうか、OAM処理経路と並列に動作するハードウェア転送パスを利用する場合は、1つのまたは複数のパケットがOAM処理サンプルカウンタ前に処理することができれば、パケットおよびバイトカウントがスキューしてもよいです。 OAMは、ソフトウェアで実装されている場合は、このエラーは非常に大きくなることができます。
If multilink is used at the ingress or egress of a transport path, there may not be a single packet-processing engine where an LM packet can be injected or extracted as an atomic operation while having accurate packet and byte counts associated with the packet.
マルチリンクは、搬送路の入口または出口で使用される場合、パケットに関連付けられた正確なパケットおよびバイトカウントを有しながらLMパケットがアトミック動作として注入または抽出することができる単一のパケット処理エンジンがなくてもよいです。
In the case where multilink is encountered along the route of the transport path, the reordering of packets within the transport path can cause inaccurate LM results.
マルチリンクは、搬送路のルートに沿って発生した場合には、搬送路内のパケットの並べ替えが不正確なLM結果を引き起こす可能性があります。
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function in order to facilitate reporting of QoS information for a transport path as required in Section 2.2.12 of RFC 5860 [11]. Specifically, proactive DM is used to measure the long-term packet delay and packet delay variation in the transport path monitored by a pair of MEPs.
RFC 5860 [11]のセクション2.2.12に、必要に応じてパケット遅延測定（DM）は、搬送経路のQoS情報の報告を容易にするために、MPLS-TPのPM機能によってサポートされる機能の一つです。具体的には、積極的なDMはのMEPの対によって監視搬送経路における長期パケット遅延およびパケット遅延変動を測定するために使用されます。
Proactive DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval.
積極的なDMは、ピアMEPにMEPから周期DMのOAMパケットを送信することによって、および設定可能な時間間隔の間に（共ルーティングまたは双方向搬送路に関連する場合）ピアMEPからDMのOAMパケットを受信することにより行われます。
Proactive DM can be operated in two ways:
積極的なDMは、2つの方法で操作することができます。
o One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP by means outside the scope of this framework.
O一方向：MEPは、ピアMEPで一方向のパケット遅延及び/又は一方向のパケット遅延変動の測定を容易にするために必要なすべての情報を含むピアMEPにDMのOAMパケットを送信します。これは、このフレームワークの範囲外の手段によっていずれかのMEPに正確な時間同期が必要であることに留意されたいです。
o Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP.
O双方向：MEPは、DM応答としてDMのOAMパケットで応答ピアMEPへDM要求にDMのOAMパケットを送信します。要求/応答DMのOAMパケットは、発信元MEPの観点から双方向のパケット遅延及び/又は双方向パケット遅延変動の測定を容易にするために必要なすべての情報を含んでいます。
One-way DM is applicable to both unidirectional and bidirectional (co-routed or associated) transport paths, while two-way DM is applicable only to bidirectional (co-routed or associated) transport paths.
双方向DMのみを双方向に適用可能であるが、一方向のDMは、（共ルーティングまたは関連）、（COルーティングまたは関連）搬送路搬送路単方向および双方向の両方に適用可能です。
MIPs, as well as intermediate nodes, do not process the DM information; they forward these proactive DM OAM packets as regular data packets.
MIPS、ならびに中間ノードは、DM情報を処理していません。彼らは、通常のデータパケットとしてこれらの積極的なDMのOAMパケットを転送します。
In order to support proactive DM, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. DM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]).
積極的なDMをサポートするために、伝送速度と、E-LSPを、PHBのために（MEP由来DMのOAMパケットに関連付けられている）DMプロビジョニングの一部として構成する必要があります。 DMのOAMパケットは、（RFC 3260 [17]参照）を測定PHBスケジューリングクラス内の最も低いドロップ優先順位を与えるPHBで送信されるべきです。
Performance monitoring (e.g., DM) is only relevant when the transport path is defect free. CC-V contributes to the accuracy of PM statistics by permitting the defect-free periods to be properly distinguished. Therefore, support of proactive DM has implications on the CC-V transmission period (see Section 5.1.3).
搬送路が無欠陥である場合にパフォーマンス監視（例えば、DMは）のみ関連します。 CC-Vを適切に識別できるように、欠陥のない期間を可能にすることにより、PMの統計情報の正確さに貢献しています。そのため、積極的なDMのサポートは、CC-Vの送信期間に影響します（5.1.3項を参照してください）。
The Client Failure Indication (CFI) function, as required in Section 2.2.10 of RFC 5860 [11], is used to help process client defects and propagate a client signal defect condition from the process associated with the local attachment circuit where the defect was detected (typically the source adaptation function for the local client interface). It is propagated to the process associated with the far-end attachment circuit (typically the source adaptation function for the far-end client interface) for the same transmission path, in case the client of the transport path does not support a native defect/alarm indication mechanism, e.g., AIS.
RFC 5860のセクション2.2.10に、必要に応じてクライアントの障害表示（CFI）関数は、[11]は、プロセスクライアント欠陥を支援し、欠陥があったローカル接続回線に関連付けられているプロセスからクライアント信号障害状態を伝搬するために使用され検出された（ローカル・クライアント・インターフェースのための、典型的にはソースアダプテーション機能）。場合に、搬送路のクライアントがネイティブ欠陥/アラームをサポートしていない、同じ伝送パスの遠端接続回線（遠端クライアントインターフェイスの典型的には、ソースアダプテーション機能）に関連付けられたプロセスに伝播されます表示機構、例えば、AIS。
A source MEP starts transmitting a CFI to its peer MEP when it receives a local client signal defect notification via its local client signal fail indication. Mechanisms to detect local client signal fail defects are technology specific. Similarly, mechanisms to determine when to cease originating client signal fail indication are also technology specific.
ソースMEPは、そのローカルクライアント信号を介してローカルクライアント信号欠陥通知指示を失敗受信した場合、そのピアMEPにCFIの送信を開始します。ローカルクライアント信号を検出するためのメカニズムは欠陥が技術固有のもので失敗します。同様に、クライアント信号を発信し停止する表示を失敗したときに決定する機構もまた、技術固有のものです。
A sink MEP that has received a CFI reports this condition to its associated client process via its local CFI function. Consequent actions toward the client attachment circuit are technology specific.
CFIを受けたシンクMEPは、そのローカルCFI機能を介して、それに関連するクライアント・プロセスにこの状態を報告します。クライアントの接続回線に向けて、その結果としての行動は、技術固有のものです。
There needs to be a 1:1 correspondence between the client and the MEG; otherwise, when multiple clients are multiplexed over a transport path, the CFI packet requires additional information to permit the client instance to be identified.
1が存在する必要があります。クライアントとMEGの間に1対応。複数のクライアントが搬送経路上で多重化した場合、その他、CFIパケットを識別するために、クライアントのインスタンスを許可する追加情報が必要です。
MIPs, as well as intermediate nodes, do not process the CFI information; they forward these proactive CFI OAM packets as regular data packets.
MIPS、ならびに中間ノード、CFI情報を処理していません。彼らは、通常のデータパケットとしてこれらの積極的なCFI OAMパケットを転送します。
In order to support CFI indication, the CFI transmission rate and, for E-LSPs, the PHB of the CFI OAM packets should be configured as part of the CFI configuration.
CFI表示をサポートするために、E-LSPを、CFIのOAMパケットのPHBのためのCFI伝送レートとは、CFI構成の一部として構成されるべきです。
In contrast to proactive monitoring, on-demand monitoring is initiated manually and for a limited amount of time, usually for operations such as diagnostics to investigate a defect condition.
事前監視とは対照的に、オンデマンドの監視は、障害状態を調査する診断薬として通常動作のために、手動で時間の限られた量のために開始されます。
On-demand monitoring covers a combination of "in-service" and "out-of-service" monitoring functions. The control and measurement implications are:
オンデマンド監視は、「インサービス」および「アウトオブサービス」の監視機能の組み合わせをカバーしています。制御と測定の意味は以下のとおりです。
1. A MEG can be directed to perform an "on-demand" functions at arbitrary times in the lifetime of a transport path.
1. A MEGは、搬送路の寿命中の任意の時間に「オンデマンド」機能を実行するように指示することができます。
2. "Out-of-service" monitoring functions may require a priori configuration of both MEPs and intermediate nodes in the MEG (e.g., data-plane loopback) and the issuance of notifications into client layers of the transport path being removed from service (e.g., lock reporting)
2.「アウトオブサービス」の監視機能は、サービスから除去される搬送路のクライアント層にMEG中のMEPと中間ノードの両方の先験的な構成（例えば、データプレーンループバック）と通知の発行を必要とするかもしれません（例えば、レポーティングロック）
3. The measurements resulting from "on-demand" monitoring are typically harvested in real time, as they are frequently initiated manually. These do not necessarily require different harvesting mechanisms than for harvesting proactive monitoring telemetry.
彼らは頻繁に手動で開始されているとして、「オンデマンド」のモニタリングの結果3.測定値は、通常、リアルタイムで収穫されています。これらは、必ずしも積極的な監視テレメトリを収穫するためには異なる収穫メカニズムを必要としません。
The functions that are exclusively out-of-service are those described in Section 6.3. The remainder are applicable to both in-service and out-of-service transport paths.
専用のアウトオブサービスです機能は、セクション6.3に記載されているものです。残りは、サービスインとアウトオブサービス搬送路の両方に適用可能です。
The on-demand connectivity verification function, as required in Section 2.2.3 of RFC 5860 [11], is a transaction that flows from the originating MEP to a target MIP or MEP to verify the connectivity between these points.
オンデマンド接続性検証機能、RFC 5860のセクション2.2.3に、必要に応じて[11]、これらの点の間の接続を確認するために、ターゲットMIPまたはMEPに発信MEPから流入するトランザクションです。
Use of on-demand CV is dependent on the existence of a bidirectional ME or an associated return ME, or the availability of an out-of-band return path, because it requires the ability for target MIPs and MEPs to direct responses to the originating MEPs.
それは、発信に対する応答を指示するために、ターゲットのMIPとMEPのための能力を必要とするため、オンデマンドCVの使用は、ME双方向または関連するリターンME、またはアウトオブバンドリターンパスの利用可能性の有無に依存しています議員。
One possible use of on-demand CV would be to perform fault management without using proactive CC-V, in order to preserve network resources, e.g., bandwidth, processing time at switches. In this case, network management periodically invokes on-demand CV.
オンデマンドCVの一つの可能な用途は、スイッチでネットワークリソース、例えば、帯域幅、処理時間を維持するために、積極的なCC-Vを使用せずに、障害管理を行うことであろう。この場合は、ネットワーク管理は、定期的にオンデマンドCVを起動します。
An additional use of on-demand CV would be to detect and locate a problem of connectivity when a problem is suspected or known to be based on other tools. In this case, the functionality will be triggered by the network management in response to a status signal or alarm indication.
オンデマンドCVの追加の使用は問題が疑われるか、他のツールに基づいていることが知られているとき、接続の問題を検出し、見つけることであろう。この場合、機能は、ステータス信号または警報指示に応じて、ネットワーク管理によってトリガされます。
On-demand CV is based upon generation of on-demand CV packets that should uniquely identify the MEG that is being checked. The on-demand functionality may be used to check either an entire MEG (end-to-end) or between the originating MEP and a specific MIP. This functionality may not be available for associated bidirectional transport paths or unidirectional paths, as the MIP may not have a return path to the originating MEP for the on-demand CV transaction.
オンデマンドCVは一意にチェックされているMEGを識別する必要があり、オンデマンドCVパケットの生成に基づいています。オンデマンド機能は、MEG（エンドツーエンド）全体又は発信MEPと特定MIP間のどちらかをチェックするために使用することができます。 MIPは、オンデマンドCVトランザクションの発信元MEPにリターンパスを持っていない可能性があり、この機能は、関連する双方向搬送路または単方向経路のために利用可能ではないかもしれません。
When on-demand CV is invoked, the originating MEP issues a sequence of on-demand CV packets that uniquely identifies the MEG being verified. The number of packets and their transmission rate should be pre-configured at the originating MEP to take into account normal packet-loss conditions. The source MEP should use the mechanisms defined in Sections 3.3 and 3.4 when sending an on-demand CV packet to a target MEP or target MIP, respectively. The target MEP/MIP shall return a reply on-demand CV packet for each packet received. If the expected number of on-demand CV reply packets is not received at the originating MEP, this is an indication that a connectivity problem may exist.
オンデマンドCVが呼び出されたときに、発信MEP一意MEGが検証される識別オンデマンドCVパケットのシーケンスを発行します。パケットの数とそれらの伝送速度を考慮に通常のパケット損失条件を取るために元のMEPで事前に設定する必要があります。ソースMEPは、それぞれ、ターゲットMEPまたはMIP標的へのオンデマンドCVパケットを送信するとき、セクション3.3および3.4で定義されたメカニズムを使用する必要があります。ターゲットMEP / MIPは、受信した各パケットに対する応答のオンデマンドCVパケットを返します。オンデマンドCV応答パケットの期待数を発信MEPで受信されない場合、これは、接続の問題が存在し得ることを示しています。
On-demand CV should have the ability to carry padding such that a variety of MTU sizes can be originated to verify the MTU transport capability of the transport path.
オンデマンドCVは、MTUサイズの様々な搬送経路のMTUの輸送能力を確認するために起源することができるようなパディングを運ぶ能力を持つべきです。
MIPs that are not targeted by on-demand CV packets, as well as intermediate nodes, do not process the CV information; they forward these on-demand CV OAM packets as regular data packets.
オンデマンドCVパケットだけでなく、中間ノードの標的とされていないMIPは、CV情報を処理しません。彼らは、通常のデータパケットとしてこれらのオンデマンドCVのOAMパケットを転送します。
For on-demand CV, the originating MEP should support the configuration of the number of packets to be transmitted/received in each sequence of transmissions and their packet size.
オンデマンドCVのために、発信MEPが送信するパケットの数の構成をサポートしなければならない/送信およびそれらのパケットサイズの各シーケンスで受信されました。
In addition, when the CV packet is used to check connectivity toward a target MIP, the number of hops to reach the target MIP should be configured.
CVパケットがターゲットMIPに向かって接続を確認するために使用される場合に加えて、ターゲットMIPに到達するまでのホップ数が設定されるべきです。
For E-LSPs, the PHB of the on-demand CV packets should be configured as well. This permits the verification of correct operation of QoS queuing as well as connectivity.
E-LSPのために、オンデマンドCVパケットのPHBは、同様に設定する必要があります。これは正しいQoSキューイングの操作だけでなく、接続性の検証が可能になります。
On-demand Packet Loss Measurement (LM) is one of the capabilities supported by the MPLS-TP Performance Monitoring function in order to facilitate the diagnosis of QoS performance for a transport path, as required in Section 2.2.11 of RFC 5860 [11].
RFC 5860のセクション2.2.11に、必要に応じてオンデマンドパケット損失測定（LM）は、搬送経路のQoS性能の診断を容易にするために、MPLS-TPパフォーマンス監視機能によってサポートされる機能の一つである[11] 。
On-demand LM is very similar to proactive LM described in Section 5.5. This section focuses on the differences between on-demand and proactive LM.
オンデマンドLMはLMは、セクション5.5で説明した積極的なのは非常に似ています。このセクションでは、オンデマンドと積極的なLMとの違いに焦点を当てています。
On-demand LM is performed by periodically sending LM OAM packets from a MEP to a peer MEP and by receiving LM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a pre-defined monitoring period. Each MEP performs measurements of its transmitted and received user data packets. These measurements are then correlated to evaluate the packet-loss performance metrics of the transport path.
オンデマンドLMは、定期的ピアMEPおよび予め定義された監視期間中にピアMEP（共ルーティング場合又は関連する双方向搬送路）からLMのOAMパケットを受信することにより、MEPからLMのOAMパケットを送信することによって行われます。各MEPは、その送信され、受信したユーザデータパケットの測定を行います。これらの測定値は、その後、搬送経路のパケット損失パフォーマンスメトリックを評価するために相関されます。
Use of packet loss measurement in an out-of-service transport path requires a traffic source such as a test device that can inject synthetic traffic.
アウトオブサービス搬送経路におけるパケット損失測定の使用は、合成トラフィックを注入することができる試験装置として、トラフィックソースを必要とします。
In order to support on-demand LM, the beginning and duration of the LM procedures, the transmission rate, and, for E-LSPs, the PHB class (associated with the LM OAM packets originating from a MEP) must be configured as part of the on-demand LM provisioning. LM OAM packets should be transmitted with the PHB that yields the lowest drop precedence as described in Section 5.5.1.
オンデマンドE-LSPのために、（MEP由来LMのOAMパケットに関連付けられている）PHBクラスはの一部として設定する必要がありLM、LM手順の開始および持続時間、伝送速度、及び、サポートするためにオンデマンドLMプロビジョニング。 LMのOAMパケットは、セクション5.5.1に記載したように、最も低いドロップ優先順位を与えるPHBで送信されるべきです。
The same considerations described in Section 5.5.2 for the proactive LM are also applicable to on-demand LM implementations.
積極的なLMは、5.5.2項で説明したのと同じ考慮事項は、オンデマンドLMの実装に適用されます。
Multilink issues are as described in Section 5.5.3.
5.5.3項で説明したようにマルチリンクの問題があります。
Diagnostic tests are tests performed on a MEG that has been taken out of service.
診断テストは、サービスから取り出してきたMEGに行われた試験です。
Throughput estimation is an on-demand out-of-service function, as required in Section 2.2.5 of RFC 5860 [11], that allows verifying the bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before it is put in service.
スループット推定は、RFC 5860のセクション2.2.5に必要とされる、[11]、オンデマンドアウトオブサービス機能であることがある前に、MPLS-TPの搬送経路（LSPまたはPW）の帯域幅/スループットを検証可能にすることサービスに入れ。
Throughput estimation is performed between MEPs and between a MEP and a MIP. It can be performed in one-way or two-way modes.
スループット推定は議員の間とMEPとMIPの間で行われます。これは、一方向または双方向モードで実行することができます。
According to RFC 2544 [12], this test is performed by sending OAM test packets at increasing rates (up to the theoretical maximum), computing the percentage of OAM test packets received, and reporting the rate at which OAM test packets begin to drop. In general, this rate is dependent on the OAM test packet size.
RFC 2544 [12]によれば、この試験は、（理論上の最大値まで）増加速度でOAMテストパケットを送信し、受信したOAM試験パケットの割合を計算し、OAMテストパケットをドロップし始める速度を報告することによって行われます。一般的には、このレートは、OAMのテストパケットサイズに依存しています。
When configured to perform such tests, a source MEP inserts OAM test packets with a specified packet size and transmission pattern at a rate to exercise the throughput.
そのようなテストを実行するように構成された場合、ソースMEPは、スループットを行使するような速度で指定されたパケット・サイズ及び送信パターンとOAMテストパケットを挿入します。
The throughput test can create congestion within the network, thus impacting other transport paths. However, the test traffic should comply with the traffic profile of the transport path under test, so the impact of the test will not be worse than the impact caused by the customers, whose traffic would be sent over that transport path, sending the traffic at the maximum rate allowed by their traffic profiles. Therefore, throughput tests are not applicable to transport paths that do not have a defined traffic profile, such as LSPs in a context where statistical multiplexing is leveraged for network capacity dimensioning.
スループット試験は、このように他の搬送経路に影響を与える、ネットワーク内の輻輳を作成することができます。しかし、テストトラフィックは、テスト対象の搬送路のトラフィックプロファイルに準拠しなければならないので、テストの影響がでトラフィックを送信し、そのトラフィックその搬送経路を介して送信されるお客様に、によって引き起こされる影響よりも悪くはありませんそのトラフィックプロファイルによって許可された最大レート。したがって、スループット試験は、統計的多重化は、ネットワーク容量の寸法のために活用されている文脈でのLSPとして定義されたトラフィック・プロファイルを持っていないパスを、輸送には適用できません。
For a one-way test, the remote sink MEP receives the OAM test packets and calculates the packet loss. For a two-way test, the remote MEP loops the OAM test packets back to the original MEP, and the local sink MEP calculates the packet loss.
一方向の試験のために、遠隔シンクMEPは、OAM試験パケットを受信し、パケット損失を算出します。双方向テストのために、遠隔MEPは、元のMEPにOAMのテストパケットをループバック、およびローカルシンクMEPは、パケット損失を算出します。
It is worth noting that two-way throughput estimation is only applicable to bidirectional (co-routed or associated) transport paths and can only evaluate the minimum of available throughput of the two directions. In order to estimate the throughput of each direction uniquely, two one-way throughput estimation sessions have to be set up. One-way throughput estimation requires coordination between the transmitting and receiving test devices as described in Section 6 of RFC 2544 [12].
これは、搬送路（共同ルーティングまたは関連）双方向のスループット推定は、双方向にのみ適用されることは注目に値すると二方向のみの利用可能なスループットの最小値を評価することができます。一意各方向のスループットを推定するために、2つの一方向スループット推定セッションがセットアップされなければなりません。 RFC 2544 [12]の第6章に記載されているように一方向のスループット推定は、送信および受信テスト装置間の調整を必要とします。
It is also worth noting that if throughput estimation is performed on transport paths that transit oversubscribed links, the test may not produce comprehensive results if viewed in isolation because the impact of the test on the surrounding traffic needs to also be considered. Moreover, the estimation will only reflect the bandwidth available at the moment when the measure is made.
スループット推定がトランジットリンクをオーバーサブスクライブの搬送経路上で実行された場合、周囲の交通上のテストの影響も考慮する必要があるため、単独で見た場合、テストは包括的結果が得られないことがまた注目に値します。また、推定は唯一の対策が行われた時点で利用可能な帯域幅を反映します。
MIPs that are not targeted by on-demand test OAM packets, as well as intermediate nodes, do not process the throughput test information; they forward these on-demand test OAM packets as regular data packets.
オンデマンドテストOAMパケット、ならびに中間ノードによって標的とされていないMIPは、スループットテスト情報を処理していません。彼らは、通常のデータパケットとしてこれらのオンデマンドテストOAMパケットを転送します。
Throughput estimation is an out-of-service tool. The diagnosed MEG should be put into a locked state before the diagnostic test is started.
スループット推定はアウトオブサービスツールです。診断テストが開始される前に診断MEGは、ロックされた状態にする必要があります。
A MEG can be put into a locked state either via an NMS action or using the Lock Instruct OAM tool as defined in Section 7.
第7節で定義されたMEGは、ロックされた状態NMSアクション経由またはロックに指示OAMツールを使用してのいずれかに入れることができます。
At the transmitting MEP, provisioning is required for a test signal generator that is associated with the MEP. At a receiving MEP, provisioning is required for a test signal detector that is associated with the MEP.
送信MEPで、プロビジョニングがMEPに関連付けられているテスト信号発生器に必要とされます。受信MEPで、プロビジョニングがMEPに関連付けされたテスト信号検出のために必要とされます。
In order to ensure accurate measurement, care needs to be taken to enable throughput estimation only if all the MEPs within the MEG can process OAM test packets at the same rate as the payload data rates (see Section 6.3.1.2).
正確な測定を確保するために、ケアは、MEG内の全てのMEPは、ペイロード・データ・レート（セクション6.3.1.2を参照）と同じレートでOAMテストパケットを処理することができる場合にのみ、スループットの推定を可能にするために取られる必要があります。
If an implementation is able to process payload at much higher data rates than OAM test packets, then accurate measurement of throughput using OAM test packets is not achievable. Whether OAM packets can be processed at the same rate as payload is implementation dependent.
実装はOAMテストパケットペイロードよりはるかに高いデータレートを処理することができる場合、OAM試験パケットを用いてスループットの正確な測定が達成できません。 OAMパケットがペイロードと同じ速度で処理できるかどうかは実装依存です。
If multilink is used, then it may not be possible to perform throughput measurement, as the throughput test may not have a mechanism for utilizing more than one component link of the aggregated link.
マルチリンクが使用される場合、スループット試験は集約リンクの複数のコンポーネントのリンクを利用するための機構を有していなくてもよいように、スループット測定を行うことが可能ではないかもしれません。
Data-plane loopback is an out-of-service function, as required in Section 2.2.5 of RFC 5860 [11]. This function consists in placing a transport path, at either an intermediate or terminating node, into a data-plane loopback state, such that all traffic (including both payload and OAM) received on the looped back interface is sent on the reverse direction of the transport path. The traffic is looped back unmodified except for normal per-hop processing such as TTL decrement.
RFC 5860 [11]のセクション2.2.5に必要とされるデータプレーンループバックは、アウトオブサービス機能です。この関数は、逆方向に送信されるループバックインタフェースに（ペイロードとOAMの両方を含む）のすべてのトラフィックを受信するように、データプレーンループバック状態に、いずれかの中間または終端ノードで、搬送路を配置することからなります搬送路。トラフィックは、TTLの減少として、通常のホップごとの処理を除いて、未修飾ループバックされます。
The data-plane loopback function requires that the MEG is locked such that user data traffic is prevented from entering/exiting that MEG. Instead, test traffic is inserted at the ingress of the MEG. This test traffic can be generated from an internal process residing within the ingress node or injected by external test equipment connected to the ingress node.
データプレーンループバック機能は、MEGは、ユーザデータトラフィックが侵入することを防止するようにロックされることを必要と/そのMEGを出ます。代わりに、テストトラフィックは、MEGの入口で挿入されています。このテストトラフィックは、入口ノード内に存在する内部プロセスから生成または入力ノードに接続された外部テスト装置によって注入することができます。
It is also normal to disable proactive monitoring of the path as the MEP located upstream with respect to the node set in the data-plane loopback mode will see all the OAM packets originated by itself, and this may interfere with other measurements.
データプレーンループバックモードに設定されたノードに対して上流に位置MEPは、自身が発信すべてのOAMパケットが表示され、これは他の測定を妨害し得るように、パスの積極的な監視を無効にすることも通常です。
The only way to send an OAM packet (e.g., to remove the data-plane loopback state) to the MIPs or MEPs hosted by a node set in the data-plane loopback mode is via TTL expiry. It should also be noted that MIPs can be addressed with more than one TTL value on a co-routed bidirectional path set into data-plane loopback.
データプレーンループバックモードに設定されたノードによってホストされたMIPまたはのMEPにOAMパケット（例えば、データプレーンループバック状態を除去する）を送信する唯一の方法は、TTL満了によるものです。またのMIPは、データプレーンループバックにセット共ルーティング双方向パスに複数のTTL値に対処することができることに留意すべきです。
If the loopback function is to be performed at an intermediate node, it is only applicable to co-routed bidirectional paths. If the loopback is to be performed end to end, it is applicable to both co-routed bidirectional and associated bidirectional paths.
ループバック機能は、中間ノードで実行される場合、それは同時ルーティング双方向パスにのみ適用可能です。ループバックは、エンドツーエンドを実行する場合、それは同時ルーティング双方向および関連する双方向パスの両方に適用可能です。
It should be noted that data-plane loopback function itself is applied to data-plane loopback points that can reside on different interfaces from MIPs/MEPs. Where a node implements data-plane loopback capability and whether it implements it in more than one point is implementation dependent.
データプレーンのループバック機能自体がMIPを/のMEPとは異なるインターフェイス上に存在することができるデータプレーンループバックポイントに適用されることに留意すべきです。ノードは、データプレーンのループバック機能を実装して、複数の点でそれを実装しているかどうかは、実装依存です。
Data-plane loopback is an out-of-service tool. The MEG that defines a diagnosed transport path should be put into a locked state before the diagnostic test is started. However, a means is required to permit the originated test traffic to be inserted at the ingress MEP when data-plane loopback is performed.
データプレーンのループバックは、アウトオブサービスのツールです。診断テストが開始される前に診断搬送経路を定義するMEGがロック状態にする必要があります。ただし、手段は、データプレーンのループバックが実行されるとき入口MEPに挿入される発信検査トラフィックを許可する必要があります。
A transport path, at either an intermediate or terminating node, can be put into data-plane loopback state via an NMS action or using an OAM tool for data-plane loopback configuration.
搬送路は、いずれかの中間または終端ノードで、NMS作用を介して、データプレーンループバック状態に置くか、またはデータプレーンのループバック設定のためのOAMツールを使用することができます。
If the data-plane loopback point is set somewhere at an intermediate point of a co-routed bidirectional transport path, the side of the loopback function (east/west side or both sides) needs to be configured.
データプレーンループバックポイントが同時ルーティング双方向搬送路の途中でどこかに設定されている場合、ループバック機能（東/西の側又は両側）の側面を構成する必要があります。
It is often necessary to trace a route covered by a MEG from an originating MEP to the peer MEP(s) including all the MIPs in between. This may be conducted after provisioning an MPLS-TP transport path for, e.g., troubleshooting purposes such as fault localization.
その間のすべてのMIPを含むピアMEP（複数可）に由来MEPからMEGによって覆われた経路を追跡することがしばしば必要です。これは、障害の局在化などの目的のトラブルシューティングを行う、例えば、のためのMPLS-TPの搬送経路をプロビジョニングした後に行ってもよいです。
The route tracing function, as required in Section 2.2.4 of RFC 5860 [11], is providing this functionality. Based on the fate-sharing requirement of OAM flows, i.e., OAM packets receive the same forwarding treatment as data packets, route tracing is a basic means to perform connectivity verification and, to a much lesser degree, continuity check. For this function to work properly, a return path must be present.
RFC 5860のセクション2.2.4に必要とされる機能をトレースルートは、[11]は、この機能を提供しています。 OAMの運命共有要件に流れる基づいて、すなわち、OAMパケットは、はるかに低い程度に、導通チェックをルートトレースが接続性検証を実行するための基本的な手段であり、データパケットと同じ転送処理を受けると。この機能を正しく動作させるには、リターンパスが存在しなければなりません。
Route tracing might be implemented in different ways, and this document does not preclude any of them.
ルートトレースは異なる方法で実装されるかもしれない、と本書はそれらのいずれかを排除するものではありません。
Route tracing should always discover the full list of MIPs and of peer MEPs. In case a defect exists, the route tracing function will only be able to trace up to the defect, and it needs to be able to return the incomplete list of OAM entities that it was able to trace so that the fault can be localized.
ルートトレースは常にのMIPのとピアのMEPの完全なリストを発見する必要があります。欠陥が存在する場合には、ルートのトレース機能は、欠陥まで追跡することができます、そして障害を局所化することができるように追跡することができましたOAMエンティティの不完全なリストを返すことができる必要があります。
The configuration of the route tracing function must at least support the setting of the number of trace attempts before it gives up.
それはあきらめる前に、ルートのトレース機能の構成は、少なくとも微量の試行回数の設定をサポートしている必要があります。
Packet Delay Measurement (DM) is one of the capabilities supported by the MPLS-TP PM function in order to facilitate reporting of QoS information for a transport path, as required in Section 2.2.12 of RFC 5860 [11]. Specifically, on-demand DM is used to measure packet delay and packet delay variation in the transport path monitored by a pair of MEPs during a pre-defined monitoring period.
パケットRFC 5860のセクション2.2.12に、必要に応じて遅延測定（DM）は、搬送経路のQoS情報の報告を容易にするために、MPLS-TP PM機能によってサポートされる機能の一つである[11]。具体的には、オンデマンドDMは、事前定義された監視期間中のMEPの対によって監視搬送経路におけるパケット遅延およびパケット遅延変動を測定するために使用されます。
On-demand DM is performed by sending periodic DM OAM packets from a MEP to a peer MEP and by receiving DM OAM packets from the peer MEP (if a co-routed or associated bidirectional transport path) during a configurable time interval.
オンデマンドDMは、ピアMEPにMEPから周期DMのOAMパケットを送信することによって、および設定可能な時間間隔の間にピアMEP（共ルーティングまたは双方向搬送路に関連する場合）からDMのOAMパケットを受信することにより行われます。
On-demand DM can be operated in two modes:
オンデマンドDMは、2つのモードで動作させることができます。
o One-way: a MEP sends a DM OAM packet to its peer MEP containing all the required information to facilitate one-way packet delay and/or one-way packet delay variation measurements at the peer MEP. Note that this requires precise time synchronization at either MEP by means outside the scope of this framework.
O一方向：MEPは、ピアMEPで一方向のパケット遅延及び/又は一方向のパケット遅延変動の測定を容易にするために必要なすべての情報を含むピアMEPにDMのOAMパケットを送信します。これは、このフレームワークの範囲外の手段によっていずれかのMEPに正確な時間同期が必要であることに留意されたいです。
o Two-way: a MEP sends a DM OAM packet with a DM request to its peer MEP, which replies with a DM OAM packet as a DM response. The request/response DM OAM packets contain all the required information to facilitate two-way packet delay and/or two-way packet delay variation measurements from the viewpoint of the originating MEP.
O双方向：MEPは、DM応答としてDMのOAMパケットで応答ピアMEPへDM要求にDMのOAMパケットを送信します。要求/応答DMのOAMパケットは、発信元MEPの観点から双方向のパケット遅延及び/又は双方向パケット遅延変動の測定を容易にするために必要なすべての情報を含んでいます。
MIPs, as well as intermediate nodes, do not process the DM information; they forward these on-demand DM OAM packets as regular data packets.
MIPS、ならびに中間ノードは、DM情報を処理していません。彼らは、通常のデータパケットとしてこれらのオンデマンドDMのOAMパケットを転送します。
In order to support on-demand DM, the beginning and duration of the DM procedures, the transmission rate and, for E-LSPs, the PHB (associated with the DM OAM packets originating from a MEP) need to be configured as part of the DM provisioning. DM OAM packets should be transmitted with the PHB that yields the lowest drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]).
オンデマンドDM、DM手順の開始および持続時間、伝送レートをサポートするために、および、E-LSPを、PHBのために（MEP由来DMのOAMパケットに関連付けられている）の一部として構成する必要がありますDMプロビジョニング。 DMのOAMパケットは、（RFC 3260 [17]参照）を測定PHBスケジューリングクラス内の最も低いドロップ優先順位を与えるPHBで送信されるべきです。
In order to verify different performances between long and short packets (e.g., due to the processing time), it should be possible for the operator to configure the packet size of the on-demand OAM DM packet.
操作者は、オンデマンドのOAM DMパケットのパケットサイズを設定する（処理時間に例えば起因）ロングとショートパケット間の異なる性能を確認するために、それが可能でなければなりません。
The Lock Instruct (LKI) function, as required in Section 2.2.6 of RFC 5860 [11], is a command allowing a MEP to instruct the peer MEP(s) to put the MPLS-TP transport path into a locked condition.
RFC 5860のセクション2.2.6に、必要に応じてロック指示し（LKI）関数は、[11]は、ロックされた状態にMPLS-TP搬送路を配置するピアMEP（複数可）を指示するMEPを可能にするコマンドです。
This function allows single-side provisioning for administratively locking (and unlocking) an MPLS-TP transport path.
この機能は、管理ロック（ロック解除）するためのMPLS-TPの搬送経路を片面プロビジョニングを可能にします。
Note that it is also possible to administratively lock (and unlock) an MPLS-TP transport path using two-side provisioning, where the NMS administratively puts both MEPs into an administrative lock condition. In this case, the LKI function is not required/used.
NMSは、管理上の管理ロック状態に両方のMEPを入れ両面プロビジョニングを使用して、MPLS-TPの搬送経路が管理ロック（およびアンロック）することも可能であることに留意されたいです。この場合、LKI機能は使用/必要とされません。
MIPs, as well as intermediate nodes, do not process the Lock Instruct information; they forward these on-demand LKI OAM packets as regular data packets.
MIPS、だけでなく、中間ノードは、ロックに指示情報を処理しません。彼らは、通常のデータパケットとしてこれらのオンデマンドLKI OAMパケットを転送します。
A MEP, upon receiving a single-side administrative lock command from an NMS, sends an LKI request OAM packet to its peer MEP(s). It also puts the MPLS-TP transport path into a locked state and notifies its client (sub-)layer adaptation function upon the locked condition.
MEPは、NMSから片面の管理ロックコマンドを受信すると、ピアMEP（複数可）にLKI要求OAMパケットを送信します。また、ロック状態にMPLS-TPの搬送路を置くとそのクライアント（サブ）ロックされた条件に適応機能を層に伝えます。
A MEP, upon receiving an LKI request from its peer MEP, can either accept or reject the instruction and replies to the peer MEP with an LKI reply OAM packet indicating whether or not it has accepted the instruction. This requires either an in-band or out-of-band return path. The LKI reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative lock command.
MEPは、ピアMEPからLKI要求を受信すると、それは指示を受け付けたか否かを示すOAMパケットを返信LKIとピアMEPに命令および応答を受け入れるか拒否しますか。これは、インバンドまたはアウトオブバンドリターンパスのいずれかが必要です。 LKI応答はMEPが正しくNMSに片面管理ロックコマンドの実際の結果を報告できるようにするために必要とされています。
If the lock instruction has been accepted, it also puts the MPLS-TP transport path into a locked state and notifies its client (sub-)layer adaptation function upon the locked condition.
ロック指示を受け付けたならば、それはまた、ロック状態にMPLS-TPの搬送路を置くとそのクライアント（サブ）ロックされた条件に適応機能を層に伝えます。
Note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is started, as described in Section 5.4.
クライアント（サブ）レイヤはまた、ロックレポートクライアントのMPLS-TP（サブ）レイヤで（LKR）世代-TPをMPLSされている場合、セクション5.4で説明したように、起動していることに注意してください。
A MEP, upon receiving a single-side administrative unlock command from NMS, sends an LKI removal request OAM packet to its peer MEP(s).
MEPは、NMSから片面の管理ロック解除コマンドを受信すると、ピアMEP（複数可）にLKI除去要求OAMパケットを送信します。
The peer MEP, upon receiving an LKI removal request, can either accept or reject the removal instruction and replies with an LK removal reply OAM packet indicating whether or not it has accepted the instruction. The LKI removal reply is needed to allow the MEP to properly report to the NMS the actual result of the single-side administrative unlock command.
ピアMEPは、LKI削除リクエストを受信すると、承認または拒否除去命令を、それが指示を受け付けたか否かを示すLK除去リプライOAMパケットで応答することができます。 LKI除去応答はMEPが正しくNMSへのシングル・サイドの管理者ロック解除コマンドの実際の結果を報告できるようにするために必要とされています。
If the lock removal instruction has been accepted, it also clears the locked condition on the MPLS-TP transport path and notifies its client (sub-)layer adaptation function of this event.
ロック除去指示を受け付けたならば、それはまた、MPLS-TPの搬送経路上のロック状態をクリアし、そのクライアント（サブ）このイベントの適応機能を層に伝えます。
The MEP that has initiated the LKI clear procedure, upon receiving a positive LKI removal reply, also clears the locked condition on the MPLS-TP transport path and notifies this event to its client (sub-)layer adaptation function.
正LKI除去応答を受信すると、LKI明確な手続きを開始したMEPは、また、MPLS-TPの搬送経路上のロック状態をクリアし、そのクライアント（サブ）適応機能を層にこのイベントを通知します。
Note that if the client (sub-)layer is also MPLS-TP, Lock Report (LKR) generation at the client MPLS-TP (sub-)layer is terminated, as described in Section 5.4.
クライアント（サブ）レイヤはまた、ロックレポートクライアントのMPLS-TP（サブ）レイヤで（LKR）世代-TPをMPLSされている場合、セクション5.4で説明したように、終了されることに注意してください。
A number of security considerations are important in the context of OAM applications.
セキュリティの考慮事項の数は、OAMアプリケーションのコンテキストにおいて重要です。
OAM traffic can reveal sensitive information, such as performance data and details, about the current state of the network. Insertion or modification of OAM transactions can mask the true operational state of the network, and in the case of transactions for administration control, such as lock or data-plane loopback instructions, these can be used for explicit denial-of-service attacks. The effect of such attacks is mitigated only by the fact that, for in-band messaging, the managed entities whose state can be masked is limited to those that transit the point of malicious access to the network internals due to the fate-sharing nature of OAM messaging. This is not true when an out-of-band return path is employed.
OAMトラフィックは、ネットワークの現在の状態については、このような性能データや詳細など、機密情報を明らかにすることができます。 OAMトランザクションの挿入または変更はネットワークの真の動作状態をマスクすることができ、そのようなロックまたはデータプレーンループバック命令として管理制御のための取引の場合には、これらは、明示的なサービス拒否攻撃のために使用することができます。このような攻撃の効果は唯一、インバンドメッセージングのために状態マスクすることができ、管理エンティティがそのトランジットそれらによるの運命共有自然へのネットワーク内部への悪意のあるアクセスのポイントに制限されているという事実によって軽減されますOAMメッセージ。アウトオブバンドのリターンパスが採用されるとき、これは真実ではありません。
The sensitivity of OAM data therefore suggests that one solution is that some form of authentication, authorization, and encryption is in place. This will prevent unauthorized access to vital equipment, and it will prevent third parties from learning about sensitive information about the transport network. However, it should be observed that the combination of the frequency of some OAM transactions, the need for timeliness of OAM transaction exchange, and all permutations of unique MEP to MEP, MEP to MIP, and intermediate-system-originated transactions mitigates against the practical establishment and maintenance of a large number of security associations per MEG either in advance or as required.
OAMデータの感度は、したがって、一つの解決策は、認証、許可、および暗号化のいくつかのフォームが所定の位置にあることであることを示唆しています。これは重要な機器への不正アクセスを防ぐことができます、そして、それはトランスポートネットワークに関する機密情報についての学習から第三者を防ぐことができます。しかし、MEP、MIPにMEP、および中間システム由来の取引にはいくつかのOAM取引の周波数の組み合わせ、OAM取引交換の適時の必要性、そしてユニークなMEPの全ての順列が実用に対して軽減することが観察されなければなりません事前にまたは必要に応じていずれかのMEGあたりのセキュリティアソシエーションの多数の確立と維持。
For this reason, it is assumed that the internal links of the network are physically secured from malicious access such that OAM transactions scoped to fault and performance management of individual MEGs are not encumbered with additional security. Further, it is assumed in multi-provider cases where OAM transactions originate outside of an individual provider's trusted domain that filtering mechanisms or further encapsulation will need to constrain the potential impact of malicious transactions. Mechanisms that the framework does not specify might be subject to additional security considerations.
このため、ネットワークの内部リンクが物理的にOAM取引が故障するスコープと、個々のメガのパフォーマンス管理は、追加のセキュリティを妨げないように、悪意のあるアクセスから保護されているものとします。さらに、それは、OAMトランザクションがフィルタリングメカニズムまたはさらにカプセル化が悪意のあるトランザクションの潜在的な影響を制限する必要がある個人プロバイダの信頼されたドメインの外側発信マルチプロバイダの場合に想定されます。フレームワークが指定されていないメカニズムは、追加のセキュリティ問題を受けるかもしれません。
In case of misconfiguration, some nodes can receive OAM packets that they cannot recognize. In such a case, these OAM packets should be silently discarded in order to avoid malfunctions whose effects may be similar to malicious attacks (e.g., degraded performance or even failure). Further considerations about data-plane attacks via G-ACh are provided in RFC 5921 [8].
設定ミスの場合には、いくつかのノードは、彼らが認識できないOAMパケットを受信することができます。このような場合には、これらのOAMパケットがサイレント効果悪意のある攻撃（例えば、性能劣化あるいは故障）と類似していてもよい誤動作を回避するために、廃棄されるべきです。 G-ACHを介して、データプレーン攻撃についてのさらなる考察は、RFC 5921に設けられている[8]。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the Ad Hoc Group on MPLS-TP in ITU-T) involved in the definition and specification of the MPLS Transport Profile.
著者は、MPLSトランスポートプロファイルの定義や仕様に関わるチーム（合同ワーキングチーム、IETFでのMPLSの相互運用性設計チーム、およびITU-TにおけるMPLS-TPのアドホックグループ）のすべてのメンバーに感謝したいと思います。
The editors gratefully acknowledge the contributions of Adrian Farrel, Yoshinori Koike, Luca Martini, Yuji Tochio, and Manuel Paul for the definition of per-interface MIPs and MEPs.
編集者は感謝インターフェイス単位のMIPおよびMEPの定義のためのエードリアンファレル、義則小池、ルカ・マルティーニ、雄二栃尾、そしてマヌエル・ポールの貢献を認めます。
The editors gratefully acknowledge the contributions of Malcolm Betts, Yoshinori Koike, Xiao Min, and Maarten Vissers for the Lock Report and Lock Instruct descriptions.
編集者は感謝のロックレポートやロックに指示説明のためのマルコムベッツ、義則小池、シャオミン、およびマールテンVissersの貢献を認めます。
The authors would also like to thank Alessandro D'Alessandro, Loa Andersson, Malcolm Betts, Dave Black, Stewart Bryant, Rui Costa, Xuehui Dai, John Drake, Adrian Farrel, Dan Frost, Xia Liang, Liu Gouman, Peng He, Russ Housley, Feng Huang, Su Hui, Yoshionori Koike, Thomas Morin, George Swallow, Yuji Tochio, Curtis Villamizar, Maarten Vissers, and Xuequin Wei for their comments and enhancements to the text.
著者らはまた、アレッサンドロ・ダレッサンドロ、ロア・アンダーソン、マルコムベッツ、デイブ・ブラック、スチュワートブライアント、ルイ・コスタ、Xuehui大、ジョン・ドレイク、エードリアンファレル、ダンフロスト、夏梁、劉Gouman、鵬氏、ラスHousleyに感謝したいと思います、テキストへのコメントや機能強化のための風水黄、蘇ホイ、Yoshionori小池、トーマス・モラン、ジョージくん、雄二栃尾、カーティスVillamizar、マールテンVissers、およびXuequin魏。
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[1]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[2] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[2]ブライアント、S.編、及びP.パテ編、 "擬似ワイヤエミュレーションエッジ・ツー・エッジ（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[3] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[3]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
[4] Bocci, M. and S. Bryant, "An Architecture for Multi-Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009.
[4]ボッチ、M.およびS.ブライアント、「マルチセグメント疑似回線エミュレーションエッジ・ツー・エッジのためのアーキテクチャ」、RFC 5659、2009年10月。
[5] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[5]ニーヴン、ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654 2009年9月。
[6] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[6] Agarwalさん、P.とB. Akyolは、RFC 3443、2003年1月 "時間は、マルチプロトコルラベルスイッチング（MPLS）ネットワークにおける（TTL）処理を生きるために"。
[7] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[7]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、RFC 5586、2009年6月。
[8] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[8]ボッチ、M.編、ブライアント、S.、エド。、霜、D.、編、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、RFC 5921、 2010年7月。
[9] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport Profile User-to-Network and Network-to-Network Interfaces", RFC 6215, April 2011.
[9]ボッチ、M.、Levrau、L.、およびD.フロスト、 "MPLSトランスポートプロファイルユーザ・ネットワーク間およびネットワーク間のインタフェース"、RFC 6215、2011年4月。
[10] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
[10]フロスト、D.、エド。、ブライアント、S.、エド。、およびM.ボッチ、エド。、 "MPLS交通データプレーンのアーキテクチャプロフィール"、RFC 5960、2010年8月。
[11] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[11] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "運用、管理、およびMPLS交通ネットワークのメンテナンス（OAM）のための要件"、RFC 5860、2010年5月。
[12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[12]ブラドナー、S.とJ. McQuaid、 "ネットワークの相互接続デバイスのためのベンチマーキング方法論"、RFC 2544、1999年3月。
[13] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[13]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[14] ITU-T Recommendation G.806 (01/09), "Characteristics of transport equipment - Description methodology and generic functionality", January 2009.
[14] ITU-T勧告G.806（01/09）、 "輸送用機器の特性 - 説明の方法論と一般的な機能"、2009年1月。
[15] Sprecher, N. and L. Fang, "An Overview of the OAM Tool Set for MPLS based Transport Networks", Work in Progress, June 2011.
[15] Sprecher、N.およびL.牙、「MPLSベースのトランスポートネットワークのためのOAMツールセットの概要」、進歩、2011年6月での作業。
[16] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[16]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.ブラック、RFC 2474、1998年12月 "IPv4とIPv6ヘッダーの差別化されたサービス分野（DSフィールド）の定義"。
[17] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[17]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[18] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[18] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSにおけるリンクバンドルトラフィックエンジニアリング（TE）"、RFC 4201、2005年10月。
[19] ITU-T Recommendation G.707/Y.1322 (01/07), "Network node interface for the synchronous digital hierarchy (SDH)", January 2007.
[19] ITU-T勧告G.707 / Y.1322（01/07）、 "同期デジタル階層（SDH）のためのネットワークノードインタフェース"、2007年1月。
[20] ITU-T Recommendation G.805 (03/00), "Generic functional architecture of transport networks", March 2000.
[20] ITU-T勧告G.805（03/00）、 "トランスポート・ネットワークの一般的な機能アーキテクチャ" 2000年3月。
[21] ITU-T Recommendation Y.1731 (02/08), "OAM functions and mechanisms for Ethernet based networks", February 2008.
[21] ITU-T勧告Y.1731（02/08）、 "イーサネットベースのネットワークのためのOAM機能およびメカニズム" 2008年2月。
[22] IEEE Standard 802.1AX-2008, "IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation", November 2008.
[22] IEEE標準802.1AX-2008、 "地方とメトロポリタンエリアネットワークのIEEE標準 - リンクアグリゲーション"、2008年11月。
[23] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[23]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[24]ボッチ、M.、ツバメ、G.、およびE.グレー、 "MPLSトランスポートプロファイル（MPLS-TP）識別子"、RFC 6370、2011年9月。
[25] Winter, R., Ed., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", Work in Progress, July 2011.
[25]冬、R.、エド。、進歩、2011年7月で、仕事バンHelvoort、H.、およびM.ベッツ、 "ITU-Tの表記法に続きMPLS-TP識別子"。
Ben Niven-Jenkins Velocix
ベン・ニーヴン、ジェンキンスVelocix
EMail: ben@niven-jenkins.co.uk
メールアドレス：ben@niven-jenkins.co.uk
Annamaria Fulignoli Ericsson
Annamaria Fulignoliエリクソン
EMail: annamaria.fulignoli@ericsson.com
メールアドレス：annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Alcatel-Lucent
エンリケ・ヘルナンデス・バレンシアアルカテル・ルーセント
EMail: Enrique.Hernandez@alcatel-lucent.com
メールアドレス：Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Alcatel-Lucent
リーフェンLevrauアルカテル・ルーセント
EMail: Lieven.Levrau@alcatel-lucent.com
メールアドレス：Lieven.Levrau@alcatel-lucent.com
Vincenzo Sestito Alcatel-Lucent
ヴィンチェンツォSestitoアルカテル・ルーセント
EMail: Vincenzo.Sestito@alcatel-lucent.com
メールアドレス：Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nokia Siemens Networks
Nuritのスポークスマンノキア・シーメンス・ネットワークス
EMail: nurit.sprecher@nsn.com
メールアドレス：nurit.sprecher@nsn.com
Huub van Helvoort Huawei Technologies
HuubバンHelvoort華為技術
EMail: hhelvoort@huawei.com
メールアドレス：hhelvoort@huawei.com
Martin Vigoureux Alcatel-Lucent
マーティン・ヘイルアルカテル・ルーセント
EMail: Martin.Vigoureux@alcatel-lucent.com
メールアドレス：Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Nokia Siemens Networks
Yaacovヴェンガルテンノキア・シーメンス・ネットワークス
EMail: yaacov.weingarten@nsn.com
メールアドレス：yaacov.weingarten@nsn.com
Rolf Winter NEC
ロルフ・冬NEC
EMail: Rolf.Winter@nw.neclab.eu
メールアドレス：Rolf.Winter@nw.neclab.eu
Authors' Addresses
著者のアドレス
Dave Allan Ericsson
デイブ・アラン・エリクソン
EMail: david.i.allan@ericsson.com
メールアドレス：david.i.allan@ericsson.com
Italo Busi Alcatel-Lucent
イタロBUSIアルカテル・ルーセント
EMail: Italo.Busi@alcatel-lucent.com
メールアドレス：Italo.Busi@alcatel-lucent.com