[要約] RFC 6371は、MPLSベースのトランスポートネットワークの運用、管理、および保守のためのフレームワークを提供しています。このRFCの目的は、ネットワークの信頼性と効率性を向上させるためのガイドラインを提供することです。
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
MPLSベースの輸送ネットワークの運用、管理、およびメンテナンスフレームワーク
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）およびPSEUDOWIRE（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およびPSEUDOWIREエミュレーションエッジ（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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 [1]、RFC 3985 [2]、およびRFC 5659 [4]で定義されているPseudowire（PW）データプレーンアーキテクチャ。
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
[15]に沿って、既存のMPLS OAMメカニズムが可能な限り使用され、既存のメカニズムが要件を満たすのに十分でない場合にのみ、拡張または新しいOAMメカニズムが定義されます。このフレームワークで説明されているいくつかの拡張機能は、終了する可能性があります
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.
意欲的な能力として、いくつかの実装では破壊的に実現できないと判断される場合があります。拡張機能は、既存の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フレームワークは、必要なOAM関数と、RFC 5860のMPLS-TP 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-PWS）、およびサブパスメンテナンス要素（SPME）に適用できます。共同ルートおよび関連する双方向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パケットは、ユーザーデータパケットと同じ転送処理（つまり、運命シェア）の対象となります。、トラフィックのクラスが監視されている状態で、一般的なホップ前の動作（PHB）スケジューリングクラス（PSC）エンドツーエンド（E2E）が必要になる場合があります。Labelのみの有名PSC LSP（L-LSP）の場合、1つのクラスのトラフィックのみを監視する必要があるため、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パケットは、LSP、SPME、およびセクション、またはRFC 5085のACHコンストラクトのRFC 5586 [7]の汎用関連チャネルラベル（GAL）および関連するチャネルヘッダー（ACH）コンストラクトを使用して、使用済みのデータパケットと区別できます[3]およびRFC 5586 [7] for（ms-）pw。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では、OAM関数をセクション、LSP、MS-PW、およびそのSPMEに適用するための参照モデルについて説明します。
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 [11]で定義されているOAM関数のプロトコル中立記述を提供し、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 MPLSおよびPWE3アーキテクチャ内にMPLS輸送プロファイルを含めるための共同インターネットエンジニアリングタスクフォース（IETF） /国際電気通信連合電気通信標準化セクター（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 PW ME Group
PSC PHB Scheduling Class
PSC PHBスケジューリングクラス
PSME PW SPME ME
psme pw spme me
PSMEG PW SPME ME Group
PSMEG PW SPME MEグループ
PW Pseudowire
PW Pseudowire
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].
このドキュメントでは、RFC 5654 [5]で定義されている用語を使用しています。
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]).
このドキュメントでは、「LSP」という用語を使用して、サービスLSPまたはトランスポートLSP（RFC 5921 [8]で定義されている）を示します。
This document uses the term 'Section' exclusively to refer to the n=0 case of the term 'Section' defined in RFC 5960 [10].
このドキュメントでは、「セクション」という用語のみを使用して、RFC 5960 [10]で定義されている用語「セクション」のn = 0の場合を参照しています。
This document uses the term 'Sub-Path Maintenance Element (SPME)' as defined in RFC 5921 [8].
このドキュメントでは、RFC 5921 [8]で定義されている「サブパスメンテナンス要素（SPME）」という用語を使用しています。
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パケットを送信する唯一の方法は、ノードがMIPSまたはMEPをホストしているかどうかに関係なく、Time to Live（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の中間ノード。このようなノードは、2つのドメインの端に存在するか、別の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のトラフィックをトランジングします。中間ノードは、下流の中間ノードまたはMEPに向けられたOAMフローを発生する場合があります。
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）：2つのポイント（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ドメインのセクションまたは輸送パスを維持および監視する1つ以上のメンテナンスエンティティのセット。
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）および終端（Sink MEP）OAMパケットを開始できます。MEPSは、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間のMEG内にあります（セクション3.3の詳細）。
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 Flow：MEGの1つの方向を計算する特定のソースMEP（または、データプレーンループバックの特別な場合の両方）を計算するすべての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および/または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.
MEPの発生：OAMトランザクションパケット（ターゲットMIP/MEPに向かって）を発信するMEPで、そのターゲットMIP/MEPからの帯域または帯域外の返信が期待されます。発信元MEPは常にバンド内のOAMリクエストパケットを生成し、ターゲットMIP/MEPによって返されるOAM Replyパケットのみを期待およびプロセスします。
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：MEPは、関連するMEGから受け取ったパケットを終了して処理すると、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：MEPは、OAMパケットのソースMEPとして機能し、関連するMEGの輸送パスにパケットを挿入します。
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：OAMトランザクションパケットのターゲットと、OAMトランザクションを開始した発信元MEPに返信する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.
UP 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
MPLS-TP OAMは、メンテナンスおよび監視操作が適用される輸送経路の2つのポイント間の関係を定義するメンテナンスエンティティ（MES）のコンテキストで動作します。メンテナンスエンティティを定義する2つのポイントは、メンテナンスエンティティグループエンドポイント（MEP）と呼ばれます。同じ輸送経路に属し、維持および監視されている1つ以上のMESのコレクション
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.
グループは、メンテナンスエンティティグループ（MEG）として知られています。MEPの間には、メンテナンスエンティティグループ中間点（MIP）と呼ばれるゼロ以上の中間点があります。MEPとMIPはMEGに関連付けられており、MEGで複数のMEによって共有できます。
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エンティティへのインスタンス化については、セクション4で説明します。図1では、ノードAとDは、LSPのラベルエッジルーター（LERS）またはMSの終端プロバイダーエッジ（T-PE）にラベルを付けることができます。-PW、ノードB、およびCは、LSPのLSRSまたはMS-PWのPES（S-PES）を切り替えます。MEPはノードAとDに存在し、MIPはノードBとCに存在し、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は、OAMフローの範囲をMEGに結合します（つまり、監視および管理されている輸送パスのドメイン内）。これには2つの例外があります。
1) A misbranching fault may cause OAM packets to be delivered to a MEP that is not in the MEG of origin.
1) 間違った分岐障害により、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.
関連する双方向のポイントツーポイント輸送経路の場合、各方向を独立して監視するために、2つの独立した単方向メンテナンスエンティティが定義されています。これは、MIPから発生するMEPへのリターンパスが必ずしもMEGに存在するわけではないため、MIPで終了または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).
すべての場合において、輸送経路の一部は、SPMEのインスタンス化によって監視される場合があります（セクション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メグの参照モデル
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、A-E、A-F）ごとに独立しています。
o Fault conditions - some faults may impact more than one ME depending on where the failure is located;
o 障害条件 - 障害がどこにあるかに応じて、いくつかの障害が複数の私に影響を与える可能性があります。
o Packet loss - packet dropping may impact more than one ME depending from where the packets are lost;
o パケットの損失 - パケットのドロップは、パケットが失われる場所から複数の私に影響を与える可能性があります。
o Packet delay - will be unique per ME.
o パケット遅延 - 私に一意になります。
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フローを終了し、それ自体とルートの間のMEを監視し、ルート（つまり、A）はP2MPメグのすべてのMESに共通するOAMパケットを生成します。すべてのノードは、対応する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.
[8]で定義されているサブパスメンテナンス要素（SPME）は、インスタンス化された階層LSPであり、侵入と出口の間の同じパスに従う一連の輸送パス（LSPまたはMS-PWS）の一部の監視を提供します。SPMEの。インスタンス化SPMEの運用上の側面は、このメモの範囲外です。
SPMEs can also be employed to meet the requirement to provide tandem connection monitoring (TCM), as defined by ITU-T Recommendation G.805 [20].
SPMEは、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.
輸送パスの特定のパスセグメントのTCMは、監視される輸送パスのパスセグメントと1：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の場合、これは、TCMを提供するために使用されるSPMEが1つの輸送パスのみを運ぶことができることを意味します。したがって、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処理がSPMEによって保存されるように、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は通常、TTLハンドリング[6]（サブレイヤー間でTTLコピーなし）に短パイプモデルを使用して、E2EエンティティのMIPSまでのTTL距離がSPMEの存在によって影響を受けることはありませんが、オペレーターが均一なモデルの使用を指定できるはずです。
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.
MIPSまでの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.
1. SPMEサブレイヤーのMIPは、輸送パスメグの一部ではありません。したがって、SPME MIPに対処した輸送パスメグに由来する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または保護スイッチングアクションのインスタンス化により、高レベルのMEGのTTL距離がMIPに変化する場合があります。
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のエンドポイントはMEPSであり、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):
SPMEを検討する場合、次のプロパティがすべてのMPLS-TPメグに適用されることを考慮することが重要です（LSP、SPME、またはMS-PWSを機器にするかどうかに関係なく）：
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のパスセグメントをカバーする場合があり、パスセグメントのエッジにノードの転送エンジンを含めることもあります。ただし、Megsがネストされると、SPMEのMEPとMIPSは、もはや包括的な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 ネストされているMEGSのMEPは、単一のノードに存在するが、再び重複しないように実装される可能性があります。
o Each OAM flow is associated with a single MEG.
o 各OAMの流れは、単一のメグに関連付けられています。
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がインスタンス化されると、MIPSまでの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のソースとシンクポイントです。MPLS-TP LSPのコンテキストでは、LERのみがMEPを実装できますが、SPMEのコンテキストでは、MPLS-TP LSPのLSRは、輸送パスの全体的な監視インフラストラクチャに寄与するSPMEのLERになります。PWSに関しては、T-PEのみがMEPを実装できます。1つ以上のPWSをサポートするSPMEの場合、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.
MEPは、MEGのプロアクティブおよびオンデマンドモニタリングOAM機能のほぼすべてを発信する責任があります。中間ノードから発信され、サーバーレイヤーイベントによってトリガーされる、個別のクラスの通知（ロックレポート（LKR）やアラーム表示信号（AIS）など）があります。 MEPは、障害管理とパフォーマンス監視のためにOAMパケットを発信および終了することができます。これらのOAMパケットは、適切なカプセル化とRFC 5586で定義されている適切なチャネルタイプを備えたジェネリック関連チャネル（G-ach）内で運ばれます[7]。 MEPは、それが属するMEGから受信するすべてのOAMパケットを終了し、静かに廃棄しないものを捨てます。 （接続検証の特定の場合（CV）処理の場合、間違ったMEGからのCVパケットは誤接続性の欠陥をもたらし、さらなるアクションが行われます。）OAMパケットが属するMEGはMPLSに関連付けられています。またはPWラベルは、ラベルがMEGを推測するために使用されるか、OAMパケットのコンテンツを推測するかどうかが実装の選択です。 MPLS-TPセクションの場合、MEGは、ラベルスタックの上部にGALとともにOAMパケットが受信されたポートから推測されます。
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).
OAMパケットには、利用可能な「バンド外」リターンパスを使用する必要があります（[8]で定義されています）。そのような場合、OAM Replyパケットを構築し、発信元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関数を構成できますが、MEPは常に有効になります。
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をサポートできます。ノードごとのMEPはノード内の不特定の場所に存在し、インターフェイスごとのMEPは転送エンジンの特定の側にあります。特に、インターフェイスごとのMEPは、転送エンジンに比べて位置に応じて「UP MEP」または「ダウンMEP」と呼ばれます。「Up 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：インターフェイスごとのMEPの例
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).
図3は、インターフェイスごとの4つの例を示しています。UPMEP：ソースノードのUPソースMEP（ケース1）、宛先ノードのUPシンクMEP（ケース2）、ソースノードのダウンソースMEP（ケース3）、および宛先ノードのダウンシンク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.
インターフェイスアップMEPSの使用は、ドメインの端に近い障害とパフォーマンスモニタリングの両方の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が同じノード上にあり、すべてMEPが転送エンジンの片側にあるため、MEGが完全にノードの内部になることがあります。
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.
MPLS-TPの（サブ）レイヤーの最初と終了時にのみMEPが存在できることに注意してください。そのLSPまたはPWの一部を監視する必要がある場合は、MEPと関連するMEGを作成できる新しいサブレイヤー（SPMEの形式）を作成する必要があります。
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.
中間ノードがOAMパケットをMEPに送信する場合、その時点でスタックのトップラベルを使用します。
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のMEPの1つによって開始されたOAMパケットによって対処される場合があります。MIPは、属するMEGから受信するOAMパケットに応じてOAMパケットを生成できます。MIPによって生成されたOAMパケットは、発信元MEPに送信されます。
An intermediate node within a MEG can either:
メグ内の中間ノードは次のとおりです。
o support per-node MIPs (i.e., a single MIP per node in an unspecified location within the node); or
o ノードごとのサポート（つまり、ノード内の不特定の場所にあるノードごとに単一のMIP）;また
o support per-interface MIPs (i.e., two or more MIPs per node on both sides of the forwarding engine).
o インターフェイスごとのMIPSをサポートします（つまり、転送エンジンの両側のノードごとに2つ以上のMIPS）。
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.
インターフェイスごとまたはノードごとのMIPSのサポートは、実装の選択肢です。また、ノードがインターフェイスごとのMIPSをサポートしている可能性もあります。一部のメグでは、トランジットノードである他のメグでノードごとのMIPSをサポートできます。
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は、ポイントツーポイントメグの中間ノードでの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.
OAMパケットをMIPに送信するとき、ソースMEPはTTLフィールドを設定して、MIPが存在するノードに到達するために必要なホップ数を示す必要があります。
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情報も含める必要があります。OAMパケットに属するMEGは、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距離が変化する可能性があるため、OAMパケットを特定のMIPに配信するためにTTL有効期限を使用することは、完全に信頼性の高い配信メカニズムではありません。MPLS-TPノードは、期限切れのTTLで受信されたOAMパケットを静かに破棄し、MIPやMEPのいずれにも対処されていません。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で定義されているルートトレースなど）に使用できます。または、TTLとMIPの識別子を相関させ、変更または不規則性を記載している（以前に抽出された情報との比較を介して、元のMEPに任せることが望ましい場合）に使用できます。ネットワークから）。
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内でユニークです。ただし、それらのアイデンティティは必ずしもMEGに固有のものではありません。たとえば、ノード内のすべてのNODAL MIPは共通のアイデンティティを持つことができます。
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をホストします。ローカルポリシーを使用すると、機能ごとと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;
o 物理リンクの終了点での非MPLS MEP（例：802.3、SDH仮想回路、またはOTN光データユニット（ODU））、セクション4.1で定義されたMPLS-TPセクションレイヤーネットワークの場合。
o an MPLS-TP Section MEP for MPLS-TP LSPs, defined in Section 4.2;
o セクション4.2で定義されているMPLS-TP LSPのMPLS-TPセクションMEP。
o an MPLS-TP LSP MEP for MPLS-TP PWs, defined in Section 4.3;
o セクション4.3で定義されているMPLS-TP PWS用のMPLS-TP LSP MEP。
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
o セクション4.4で定義されているLSPパスセグメント監視に使用されるMPLS-TP SPME MEP、MPLS-TP LSPまたはLSPパスセグメント監視を提供する高レベルのSPMEの場合。また
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.
o MPLS-TP 4.5で定義されているMPLS-TP PWSまたはPW PATHセグメント監視を提供する高レベルSPMEのPWパスセグメント監視に使用されるMPLS-TP SPME MEP。
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.
SPMEは通常、輸送パスが管理プレーンまたはコントロールプレーン（存在する場合）によって作成されるとインスタンス化されます。輸送経路が最初に作成された後、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:
MEPによって生成されたOAMパケットを含むP2MPトランスポートパスに送信されるすべてのトラフィックは、ルートからすべての葉に送信されます（マルチキャスト）。結果として：
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.
o すべての葉にOAMパケットを送信するために、ソースMEPは、すべての葉に転送面で配信され、すべての葉で処理される1つのOAMパケットを送信できます。したがって、単一のOAMパケットは、P2MPメグですべてのMESを同時に計算できます。
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.
o OAMパケットを単一の葉に送信するために、ソースMEPは、すべての葉に転送面によって配信される1つの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.
o OAMパケットを単一のMIPに送信するために、Source MEPはTTLフィールドに単一のOAMパケットを送信し、MIPが存在するノードに到達するために必要なホップ数を示します。このパケットは、ターゲットMIPの同じTTL距離にあるすべての中間ノードとより短い距離にある葉に転送面によって配信されます。OAMパケットには、ターゲットMIPを識別するのに十分な情報が含まれている必要があります。したがって、ターゲット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 OAMパケットをM葉（つまり、すべての葉のサブセット）に送信するために、ソース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パケットを終了および中継します。UP 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またはMIPへの「オンデマンド」トランザクションをターゲットにするメカニズムが必要です。これは、任意に大きな処理負荷と、望ましくない応答をフィルタリングおよび破棄するための要件の発生MEPを緩和するためです。これは、通常、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.2で定義されているSPMESは、セクション3.6で例示されているように事前に構成または事前に導入されている場合、上記の2つの目的を満たしています。ただし、設計作業の負担、多くのヘッダー消費、帯域幅の消費など、実際の動作では、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.
輸送パスが作成された後にSPMEが構成またはインスタンス化された場合、ネットワーク目的（1）を満たすことができます。たとえば、破壊的でない「ブレイク前に作る」テクニックを使用することにより。
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.
ただし、MPLSラベルの新しい割り当てのため、ネットワーク目的（2）を満たすことはできません。結果として、一般的に言えば、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.
SPMEを使用せずに非侵入セグメントモニタリングをインスタンス化する1つの可能なオプションでは、監視エンドポイントとして選択されたMIPSが強化された機能性を実装し、監視された輸送パスの状態を実装する必要があります。
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.
たとえば、MIPSは、帯域外の戻りパスを使用する場合、ピアまでの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フレームワークの参照モデルは、RFC 5860で指定された機能要件をサポートするために、MEGとそれに関連するMEPとMIPの概念に基づいています[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).
o MPLS-TPセクション（MPLS LSRの間）の監視と管理を可能にするセクションメンテナンスエンティティグループ（SMEG）。
o An LSP Maintenance Entity Group (LMEG), allowing monitoring and management of an end-to-end LSP (between LERs).
o LSPメンテナンスエンティティグループ（LMEG）。エンドツーエンドLSP（LERS間）の監視と管理を可能にします。
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).
o PWメンテナンスエンティティグループ（PMEG）。エンドツーエンドのシングルセグメントPseudowire（SS-PW）またはMS-PW（T-PESの間）の監視と管理を可能にします。
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）。SPMEの監視と管理を可能にします（LSPに沿ったLERSおよび/またはLSRの特定のペア間）。
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).
o PW SPME MEグループ（PSMEG）。SPMEの監視と管理を可能にします（（MS-）PWに沿ったT-PESおよび/またはS-PEの特定のペアの間）。
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フレームワークで指定されているMEGSは、MS-PWS [4]とLSP [1]の両方を含むMPLS-TP [8]のアーキテクチャフレームワークに準拠しています。
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もSPMEの形でサポートされています。この場合、階層内の各LSPは、階層の高レベルおよび低レベルのLSPから独立して、エンドツーエンドベースで（LERからLERまで）監視できる異なるサブレイヤーネットワークであり、spme。階層LSPに沿って任意のLERS/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に隣接しています。3 MPLS-TPセクションSEC23を介して。同様に、ドメイン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.
図5は、T-PE1のAC1とT-PE ZのAC2の間の双方向MS-PW（MS-PW1Z）も示しています。MS-PWは、3つの双方向PWパスセグメントで構成されています。双方向LSP13 LSPを介したS-PE 3、2）双方向LSP3X LSPを介したS-PE 3とS-PE Xの間のPW3Xパスセグメント、および3）S-PE XとT-PE Zの間のPWXZパスセグメント双方向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手順は、他のMEGの手順から独立して動作することが期待されています。しかし、これは、複数のメグが同じネットワーク条件、たとえばファイバーカットイベントによって同時に影響を受ける可能性があることを排除するものではありません。
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つ以上のMEGのエンドポイントである場合、同じノードで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.
図5は、通常、SPMEが2つのOAMドメイン間のセグメントではなくOAMドメイン（PW13やPWXZ PSMEGなど）を監視するために使用されるため、PW3X PSMEGを説明していません。ただし、OAMフレームワークは、SPMEが重複していない限り、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アーキテクチャフレームワークドキュメントで指定されたMEGを定義しています。特に明記しない限り、このセクションのドメイン、LSR、MPLS-TPセクション、LSP、擬似ワイヤ、およびMEGへのすべての参照は、図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 LSRS間のリンクを監視することが望ましいアプリケーション用に展開されることを目的としています。サーバー層テクノロジーは、適切な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,
1. T-PE 1とLSR 2の間のMPLS-TPセクションに関連するSEC12 MEG、
2. Sec23 MEG associated with the MPLS-TP Section between LSR 2 and S-PE 3,
2. LSR 2とS-PE 3の間のMPLS-TPセクションに関連するSEC23 MEG、
3. Sec3X MEG associated with the MPLS-TP Section between S-PE 3 and S-PE X,
3. S-PE 3とS-PE Xの間のMPLS-TPセクションに関連付けられたSEC3X MEG、
4. SecXY MEG associated with the MPLS-TP Section between S-PE X and LSR Y, and
4. S-PE XとLSR Yの間のMPLS-TPセクションに関連付けられたSECXY MEGと
5. SecYZ MEG associated with the MPLS-TP Section between LSR Y and T-PE Z
5. LSR YとT-PE Zの間のMPLS-TPセクションに関連付けられた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は、たとえば個々のPWSを監視するのではなく、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.
図5は、AC1とAC2の間でネットワークで構成された2つのLMEGを示しています。このような構成におけるLSP3X LMEGの存在はオプションであり、したがって、このフレームワークによって排除されません。たとえば、ネットワークオペレーターは、個々のLSPではなく、2つのLSRの間の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は、3つのパスセグメント（PW13、PW3X、およびPWXZ）とそれに関連するエンドツーエンドPMEG（PW1Z PMEG）で構成されるMS-PW（MS-PW1Z）を示しています。
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）は、エンドツーエンドモニタリング（LMege-to-Endモニタリングとは無関係に、SPMEにインスタンス化されたMEPSの間のLSPの任意の部分を監視することを目的とした関連するメンテナンスエンティティグループを持つMPLS-TP SPME））。LSMEGはLSPパスセグメントを監視できます。また、パスセグメントのエッジにあるノードの転送エンジンを含めることもできます。
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.
非隣接LSRの間にSPMEが確立されると、SPMEのエッジがLSPサブレイヤーネットワークで隣接し、以前にあったLSRはSPMEの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.
複数の階層LSMEGを任意のLSPで構成できます。LSMEG OAMパケットは、監視されているLSPパスセグメントに送信されたユーザーデータパケットを使用して運命を剃る必要があります。
A LSME can be defined between the following entities:
LSMEは、次のエンティティ間で定義できます。
o The LER and LSR of a given LSP.
o 特定のLSPのLERとLSR。
o Any two LSRs of a given LSP.
o 特定のLSPの2つのLSR。
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.
LSMEGは、たとえば、LSP自体ではなく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 MEG（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).
図6は、PE 1とPE Zの間にエンドツーエンドのLSP（LSP1Z）がある図5の参照モデルのバリエーションを示しています。LSP1Zは、少なくとも3つのLSP連合セグメント：LSP13、LSP3X、およびLSPXZで構成されています。。このシナリオでは、LSP1Zを監視するように構成された2つの個別のLSMEGがあります：1）ドメイン1（LSP13 LSMEG）のLSP13連結セグメントを監視するLSMEG（2）ドメインZ（LSPXZ LSMEG）のLSPXZコンダン化セグメントを監視する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).
LSMEGがLMEGがエンドツーエンドLSPを監視することができ、LSMEG MEPSと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.
MPLS-TP MS-PW SPMEモニタリングMEG（PSMEG）は、エンドツーとは無関係に、SPMEのMEPSの間のMS-PWの任意の部分を監視することを目的とした関連するメンテナンスエンティティグループを持つMPLS-TP SPMEであるMPLS-TP SPMEです。-ENDモニタリング（PMEG）。PSMEGはPWパスセグメントを監視できます。また、パスセグメントのエッジにあるノードの転送エンジンを含めることもできます。PSMEGはSPMEと違いはありません。SPMEが特にPWコンテキストで議論することは、単にそのように名前が付けられています。
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.
非隣接S-PEの間にSPMEが確立されると、SPMEのエッジがMS-PWサブレイヤーネットワークで隣接し、以前にあったSPEはSPMEのLSRになります。
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は、分散制御プレーン（CP）から集中ネットワーク管理システム（NMS）制御またはルーティングエリアの境界に移行するなどの運用境界に頻繁に存在します。そのため、アーキテクチャは、SPMEセグメントのarbitrary意的な配置が暗示される柔軟性を持たないように見えます。PSMEGの任意の配置をサポートするには、追加のPWサブレイアリングの定義が必要です。複数の階層PSMegを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.
o 特定のMS-PWの2つのS-PE。
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.
セクション3.2のSPME説明に沿って、MS-PWがインスタンス化された後にPW SPMEがインスタンス化された場合、MIPのTTL距離が変化し、PW SPMEのMIPSが変化する可能性があることに注意してください。。これは、これらのMIPをホストするS-PEノードは、もはやS-PEではなく、SPME LSPレベルでのPノードであることを意味します。その結果、PSMEG MEPをホストするS-PESが隣接するS-PEになります。これは、一般的なSPMEの動作と変わりません。
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-MS-を監視するときに、エンドツーエンドPW自体ではなく、MS-PWの一部の動作を監視することが望ましいシナリオに展開されることを目的としています。
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は、3つのパスセグメントのMS-PW（MS-PW1Z）を示しています：PW13、PW3X、およびPWXZが2つの個別のPSMEGを備えたPWXZ：1）ドメイン1（PW13 PSMEG）のPW13 MS-PWパスセグメントを監視するPSMEGと2）ドメインZのPWXZ MS-PWパスセグメント（PWXZ PSMEG）を監視する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).
PSMEGが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またはMEPSがサーバーレイヤーの粒度で装備するため、レイヤー違反に似ているため、これは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からMEPを動作させますが、通知はノードへのノード（MS-PWトランザクションなど）またはMEPへのノード（AIなど）です。制御と測定の考慮事項は次のとおりです。
1. Proactive monitoring for a MEG is typically configured at the creation time of the transport path.
1. MEGの積極的な監視は、通常、輸送経路の作成時に構成されます。
2. The operational characteristics of in-band measurement transactions (e.g., CV, Loss Measurement (LM), etc.) are configured at the MEPs.
2. In帯域測定トランザクション（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]のセクション2.2.2で必要なプロアクティブな連続性チェック機能は、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 [11]のセクション2.2.3で必要なプロアクティブ接続検証関数は、2つのメグ間の予期しない接続性欠陥（例えば、ミスマーグやミスコメントなど）と、予期しないMEPを使用してMEG内の予期しない接続性を検出するために使用されます。。
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によって処理されるソースMEPによるOAMパケットの（プロアクティブな）生成に基づいています。結果として、OAM帯域幅の消費を節約するために、CVは使用すると、CCと連続チェックおよび接続検証（CC-V）OAMパケットにリンクされます。
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のみの監視に使用されるCC-V OAMパケットはCC OAMパケットと呼ばれ、CCとCVの両方に使用されるCC-V OAMパケットはCV 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監視されたMEGに漏れているCC OAMパケットの場合 - 検出不能。
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.
o CC監視されたMEGに漏れているCV OAMパケットの場合、CC OAMパケットの代わりにCV OAMパケットの受信（追加のソースMEP識別子を使用）を使用すると、障害を検出できます。
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.
o CV監視されたMEGに漏れているCC OAMパケットの場合、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監視されたMEGに漏れているCV OAMパケットの場合 - さまざまなソース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で定義された他の輸送技術と一貫した操作が必要です）、MEP識別用のITUキャリアコード（ICC）ベースの形式が必要です）使用：この形式は[25]の定義の下にあります。MPLS-TPがOAMにIP機能が利用可能で望ましい環境に展開されると、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」と送信されます。E-LSPの場合、このPHBはネットワークオペレーターベースで構成できますが、L-LSPの場合、これはRFC 3270 [23]に従って決定されます。PHBは、ユーザーデータトラフィックに変換するのと同じ関数によってネットワーク境界で翻訳できます。意味は、転送の実装の多くを伴うCC-Vの運命シェアがありますが、PHB処理のすべての側面が行使されるわけではありません。いずれかのオンデマンドツールは、より細かい粒子の断層発見に使用されるか、実装により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はCC-V OAMパケットを生成するためにのみ有効になり、各シンクMEPは構成されたレートでこれらのパケットを期待するように構成されています。
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.
MPLS-TP OAMをサポートしていない中間ノードと同様に、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
パスのセットアップと解体中に、パスが完全にインスタンス化されていないため、CC-Vチェックがアラームを引き起こす状況が発生します。これらのスプリアスアラームを回避するために、次の手順が推奨されます。初期化時に、ソースMEP関数（生成
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.
対応するシンクMEP関数（連続性と接続性の欠陥の検出）の前に、プロアクティブなCC-Vパケット）を有効にする必要があります。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
CC-V OAMパケットは、CVのMEGを監視するシンクMEPが受け取ったCC OAMパケットである場合、予期しないグローバルにユニークなソースMEP識別子を運ぶと見なされます。これは、CCのMEGを監視するシンクMEPが受け取ったCV OAMパケットです。または、CVのMEGを監視するシンクMEPが受け取ったCV OAMパケットですが、予想されるものとは異なるユニークなソースMEP識別子を運ぶことができます。逆に、CC-Vパケットは、予想されるグローバルにユニークなソースMEP識別子があると見なされます。受信したCC OAMパケットです
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のMEGを監視するシンクMEPによって、または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は、ソースMEPからプロアクティブなCC-V OAMパケットを受け取らない場合、連続性（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からプロアクティブなCC-V OAMパケットがない場合（およびCVの場合、これには、予想されるグローバルに一意のソースMEP識別子を持つための要件が含まれます）は、受信MEPの構成の3.5倍に等しい間隔内で受信されます。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からのプロアクティブなCC-V OAMパケット（また、CVの場合、予想されるグローバルに一意のソースMEP識別子が受信されます）が受信されます。
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、Misconection、または意図しないループ）を識別します。
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がすべてのMEGの知識を持つことが期待できるわけではないため、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.
予想されるグローバルに一意のソースMEP識別子でプロアクティブなCC-V OAMパケットが受信されますが、ローカルで構成された受信期間とは異なる送信期間がある場合、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は、予想されるグローバルに一意のソース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.
予想されるグローバルに一意のソースMEP識別子でプロアクティブなCC-V OAMパケットが受信されたが、予期しないカプセル化がある場合、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]は、接続性の欠陥を確実に検出するために、すべてのMEGでCC-Vのプロアクティブモニタリングを有効にすることを推奨することに注意する価値があります。ただし、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.
これは、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.
o MEP-ID：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).
o MEGの他のMEPのリスト。ポイントツーポイント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.
o E-LSPの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ミリ秒の欠陥エントリ基準が必要です（たとえば、RFC 5654 [5]に示されている50ミリ秒の回復時間をサポートする要件と併せて）、実装はAを使用する必要があります。3.33ミリ秒のデフォルト送信期間（つまり、300パケット/秒の伝送速度）。50 msの回復時間の要件が、35 msの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 [11]のセクション2.2.9で要求されるリモート欠陥表示（RDI）関数は、シンク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が信号障害条件を検出した場合（たとえば、連続性または接続性の欠陥の場合）、RDIインジケーターのPEER MEPへの送信を開始する必要があります。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.
MPLS-TP OAMをサポートしていない中間ノードと同様に、RDIインジケーターとRDIインジケーターを通常のデータパケットとして含めるフォワードOAMパケット、つまりMIPはアクションを実行したり、インジケータを調べたりするべきではありません。
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は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パケットに埋め込まれます。RDIを運ぶOAMパケットの帯域RDI伝送速度とPHBは、CC-Vで構成されたものと同じである必要があります。。この時間枠は、セクション5.1.3で説明されているようにアプリケーション固有です。バンド外のリターンパスの方法は、帯域外のRDIがどのように送信されるかを決定します。
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 [11]のセクション2.2.8で必要なアラーム報告関数は、サーバー（サブ）レイヤーでの欠陥条件の検出後、アラーム表示信号（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が信号障害条件をアサートすると、Co-Located MPLS-TPクライアント/サーバー適応関数に、MPLS-TPでの二次アラームの抑制を可能にするために、AIS情報を下流方向にOAMパケットを生成することが通知されます。クライアント（サブ）レイヤーの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.
AIS情報を使用したパケットの生成は、サーバーMEPが信号障害条件を主張するとすぐに開始されます。AIS情報を使用したこれらの周期的なOAMパケットは、信号障害条件がクリアされるまで送信され続けます。
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.
偽のアラーム生成を回避するために、連続性欠陥の損失を検出するMEP（セクション5.1.1.1を参照）は、管理システムにアラームをアラームする前に、ホールドオフ間隔を待つと想定されています。したがって、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の参照ネットワークでT-PE 1とLSR 2の間のファイバーカットを考えてみましょう。図5に記載されているすべてのMEGがプロアクティブなCC-Vを有効にしていると仮定して、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,
ファイバーカットが物理層のMEPによって検出された場合（LSR 2）、LSR 2は物理層に適切なアラームを生成し、SEC12 SMEGで検出されたLOC欠陥に関連する二次アラームを抑制できます。両方のMEPが同じノード内に存在するため、このプロセスには外部プロトコル交換は含まれません。さもないと、
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.
物理層にファイバーカットを検出するのに十分な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は、LSP13 LMEGの適応関数に通知し、LSP13 LMEGのAISパケットを生成して、S-PE 3のMEPがLOCアラームを抑制できるようにします。S-PE 3は、PW13 PSMEGのMEPがLSP13 LMEGのMEPと同じノード内に存在するため、PW13 PSMEGの二次アラームを抑制することもできます。S-PE 3のPW13 PSMEGのMEPは、PW1Z PMEGの適応関数を通知し、PW1Z PMEGでAISパケットを生成して、T-PE ZのMEPがLOCアラームを抑制できるようにします。
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条件は、AIS伝送期間の3.5倍で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秒あたり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」が送信されます。E-LSPの場合、このPHBはネットワークオペレーターベースで構成できますが、L-LSPの場合、これはRFC 3270 [23]に従って決定されます。
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 [11]のセクション2.2.7で必要なロックレポート機能は、サーバー（サブ）レイヤーでの管理ロックアクション後のアラームを抑制するために使用されるロックレポート（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クライアント（サブ）レイヤー適応関数は、LKR情報を含むパケットを生成し、クライアント（サブ）レイヤーのMEPで二次アラームを抑制することができます。繰り返しますが、ロックレポートを発信するノードの下流のクライアントレイヤー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.
LKR情報を使用したパケットの生成は、サーバーMEPがロックされるとすぐに始まります。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).
たとえば、図5の参照ネットワークのT-PE 1と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).
図5に記載されているすべてのMEGがプロアクティブなCC-Vを有効にしていると仮定すると、LSP13 LMEG、PW1 PSMEG、およびPW1Z PMEGのMEPによってLOC欠陥が検出されます。ただし、輸送ネットワークでは、これらすべての二次アラームを抑制する必要があります（つまり、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は、LSP13 LMEGの適応関数を通知し、LSP13 LMEGでLKRパケットを生成して、T-PE 1およびS-PE 3のMEPを許可してLOCアラームを抑制します。S-PE 3は、PW13 PSMEGのMEPがLSP13 LMEGのMEPと同じノード内に存在するため、PW13 PSMEGの二次アラームを抑制することもできます。S-PE 3のPW13 PSMEGのMEPは、PW1Z PMEGの適応関数を通知し、PW1Z PMEGでAISパケットを生成して、T-PE ZのMEPがLOCアラームを抑制できるようにします。
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秒あたり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」が送信されます。E-LSPの場合、このPHBはネットワークオペレーターベースで構成できますが、L-LSPの場合、これはRFC 3270 [23]に従って決定されます。
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）関数によってサポートされる機能の1つです。[11]。LMは、MEPのペアで監視されている輸送パスによって送信および受信されたイングレスパケットと出力パケットの数をカウンター値を交換するために使用されます。
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.
Proactive LMは、輸送経路の寿命中にPEER MEP（共同ルートまたは関連する双方向輸送経路の場合）からLM OAMパケットをPEER MEPに定期的に送信し、PEER MEPからLM OAMパケットを受信することにより実行されます。各MEPは、送信されたユーザーデータパケットの測定値を実行します。これらの測定は、MEのMEのPEER MEPとリアルタイムで相関して、MEGのMEの多くのパフォーマンスメトリックに対するパケット損失の影響を導き出します。LMトランザクションは、OAMパケットがMEのMEP間を通過しながら測定されたトラフィックと同じ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でのニアエンドパケット損失測定を容易にするために、必要なすべての情報を含むLM OAMパケットをピアMEPに送信します。
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
o 双方向：MEPは、LMリクエストを備えたLM OAMパケットをピアMEPに送信します。これは、LM応答としてLM OAMパケットで応答します。リクエスト/応答LM OAMパケットにはすべての必要なものが含まれています
information to facilitate both near-end and far-end packet loss measurements from the viewpoint of the originating MEP.
原始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は双方向（共通または関連する）輸送経路にのみ適用できます。
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の場合、PHBクラス（MEPから発生するLM OAMパケットに関連付けられている）をLMプロビジョニングの一部として構成する必要があります。LM OAMパケットは、トラフィッククラス内の測定の信頼性を最大化するために、測定されたPHBスケジューリングクラス内で最も低い低下の優先順位を生成するPHBで送信する必要があります（RFC 3260 [17]を参照）。
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処理パスと並行して動作するハードウェア転送パスを使用している場合、OAM処理サンプルカウンターの前に1つ以上のパケットを処理できる場合、パケットとバイト数を歪む可能性があります。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.
パケット遅延測定（DM）は、RFC 5860のセクション2.2.12で必要に応じて輸送パスのQoS情報の報告を容易にするために、MPLS-TP PM関数によってサポートされる機能の1つです[11]。具体的には、プロアクティブな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は、定期的なDM OAMパケットをMEPからピアMEPに送信し、構成可能な時間間隔中にピア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での一元配置パケット遅延および/または一元配置パケット遅延変動測定を容易にするために、必要なすべての情報を含むDM OAMパケットをピアMEPに送信します。これには、このフレームワークの範囲外の手段により、いずれかの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パケットには、双方向パケットの遅延および/または双方向パケット遅延変動測定を促進するために必要なすべての情報が含まれています。
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は双方向（共通または関連する）輸送経路にのみ適用できます。
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
プロアクティブなDMをサポートするには、伝送速度、およびE-LSPの場合、PHB（MEPに由来するDM OAMパケットに関連する）をDMプロビジョニングの一部として構成する必要があります。DM OAMパケットには、最低のPHBで送信する必要があります
drop precedence within the measured PHB Scheduling Class (see RFC 3260 [17]).
測定されたPHBスケジューリングクラス内の優先順位を落とします（RFC 3260 [17]を参照）。
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 [11]のセクション2.2.10で必要なクライアント障害表示（CFI）関数は、クライアントの欠陥を処理し、欠陥があるローカルアタッチメント回路に関連するプロセスからクライアント信号欠陥条件を伝播するのを支援するために使用されます。検出されました（通常、ローカルクライアントインターフェイスのソース適応関数）。トランスポートパスのクライアントがネイティブの欠陥/アラームをサポートしていない場合に備えて、同じ伝送パスのファーエンドアタッチメント回路（通常はファーエンドクライアントインターフェイスのソース適応関数）に関連するプロセスに伝播されます。適応メカニズム、例えば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は、ローカルクライアント信号障害表示を介してローカルクライアント信号欠陥通知を受け取ると、CFIをピアMEPに送信し始めます。ローカルクライアント信号の失敗を検出するメカニズムは、テクノロジー固有です。同様に、クライアント信号障害の表示をいつ停止するかを決定するメカニズムもテクノロジー固有です。
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.
クライアントとMEGの間に1：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の表示をサポートするために、CFI伝送速度、およびE-LSPの場合、CFI OAMパケットのPHBを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. 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 [11]のセクション2.2.3で必要なオンデマンド接続検証関数は、これらのポイント間の接続性を検証するために、発生MEPからターゲットMIPまたは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.
オンデマンドCVの使用は、双方向のMEまたは関連する返品MEの存在、または帯域外のリターンパスの可用性に依存します。これは、ターゲットMIPとMEPが発信元に応答する能力を必要とするためです。MEP。
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の使用可能な1つの使用は、ネットワークリソース、たとえば帯域幅、スイッチでの処理時間を保持するために、プロアクティブな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は、オンデマンドCVパケットをターゲットMEPまたはターゲットMIPにそれぞれ送信するときに、セクション3.3および3.4で定義されているメカニズムを使用する必要があります。ターゲットMEP/MIPは、受信した各パケットのオンデマンドCVパケットを返信するものとします。予想されるオンデマンドCV Replyパケットが発信される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].
オンデマンドパケット損失測定（LM）は、RFC 5860 [11]のセクション2.2.11で必要な輸送パスのQOSパフォーマンスの診断を促進するために、MPLS-TPパフォーマンス監視機能によってサポートされる機能の1つです。。
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は、セクション5.5で説明されているプロアクティブLMと非常によく似ています。このセクションでは、オンデマンドとプロアクティブ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からPEER 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.
オンデマンドLMをサポートするには、LM手順の開始と期間、伝送速度、およびE-LSPの場合、PHBクラス（MEPから発生するLM OAMパケットに関連付けられています）をの一部として構成する必要があります。オンデマンド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 [11]のセクション2.2.5で必要なオンデマンドサービス外機能であり、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間と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がOAMテストパケットを元のMEPに戻し、ローカルシンク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つの方向の利用可能なスループットの最小値を評価できることに注意してください。各方向のスループットを一意に推定するには、2つの一方向のスループット推定セッションを設定する必要があります。一元配置スループット推定には、RFC 2544のセクション6で説明されているように、送信および受信テストデバイス間の調整が必要です[12]。
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.
MEGは、NMSアクションを介して、またはセクション7で定義されているロック指示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がペイロードデータレートと同じレートでOAMテストパケットを処理できる場合にのみ、スループット推定を有効にするために注意する必要があります（セクション6.3.1.2を参照）。
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テストパケットを使用したスループットの正確な測定は達成できません。Payloadと同じレートで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
データプレーンループバックは、RFC 5860のセクション2.2.5で必要なサービス外の関数です[11]。この関数は、中間または終端のノードのいずれかで、すべてのトラフィック（両方を含むすべてのトラフィックを含むデータプレーンループバック状態に輸送パスを配置すること）で構成されています。
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.
ループバックインターフェイスで受信したペイロードと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がロックされることを必要とします。代わりに、テストトラフィックがメグの入り口に挿入されます。このテストトラフィックは、イングレスノード内に存在する内部プロセスから生成するか、イングレスノードに接続された外部テスト機器によって注入されます。
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パケットがそれ自体で発生するすべての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有効期限を介して行われます。また、MIPSは、データプレーンループバックに設定された共同双方向パスで複数の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.
データプレーンループバック機能自体は、MIPS/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.
多くの場合、MEGで覆われたルートを作成しているMEPから、その間のすべてのMIPを含むピアMEPまでのルートをトレースする必要があります。これは、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 [11]のセクション2.2.4で必要なルートトレース機能は、この機能を提供しています。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.
パケット遅延測定（DM）は、RFC 5860のセクション2.2.12で必要な輸送パスのQoS情報の報告を容易にするために、MPLS-TP PM関数によってサポートされる機能の1つです[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は、定期的なDM OAMパケットをMEPからピアMEPに送信し、設定可能な時間間隔中にピア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での一元配置パケット遅延および/または一元配置パケット遅延変動測定を容易にするために、必要なすべての情報を含むDM OAMパケットをピアMEPに送信します。これには、このフレームワークの範囲外の手段により、いずれかの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パケットには、双方向パケットの遅延および/または双方向パケット遅延変動測定を促進するために必要なすべての情報が含まれています。
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パケットは、測定されたPHBスケジューリングクラス内で最も低い低下の優先順位をもたらすPHBで送信する必要があります（RFC 3260 [17]を参照）。
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 [11]のセクション2.2.6で必要なロック指示（LKI）関数は、MEPがピアMEPにMPLS-TP輸送パスをロックされた条件に置くよう指示できるようにするコマンドです。
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を管理ロック条件に置く2つのプロビジョニングを使用して、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からシングルサイドの管理ロックコマンドを受信すると、LKIリクエストOAMパケットをピアMEPに送信します。また、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リクエストを受け取ったときに、指示を受け入れて拒否することができます。これには、インバンドまたはバンド外のリターンパスのいずれかが必要です。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である場合、セクション5.4で説明されているように、クライアントMPLS-TP（サブ）レイヤーでロックレポート（LKR）生成が開始されることに注意してください。
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からシングルサイドの管理ロック解除コマンドを受信すると、LKI削除リクエストOAMパケットをピアMEPに送信します。
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.
Peer MEPは、LKI削除要求を受け取ったときに、削除命令を受け入れるか拒否することができ、LK削除応答で返信して、命令を受け入れたかどうかを示す。MEPがNMSにシングルサイドの管理ロック解除コマンドの実際の結果を適切に報告できるようにするには、LKI削除応答が必要です。
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の明確な手順を開始したMEPは、肯定的なLKI除去応答を受け取ったときに、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である場合、セクション5.4で説明されているように、クライアントMPLS-TP（サブ）レイヤーのロックレポート（LKR）生成が終了することに注意してください。
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データの感度は、1つの解決策が、何らかの形の認証、承認、および暗号化が整っていることを示唆しています。これにより、重要な機器への不正アクセスが妨げられ、第三者が輸送ネットワークに関する機密情報について学ぶことができなくなります。ただし、一部のOAMトランザクションの頻度、OAMトランザクション交換の適時性の必要性、およびMEPからMEPへの一意のMEPのすべての順列、MEPからMIPへのすべての順列、および実用的なシステムに起因するトランザクションは、実用的なものに対して緩和されることが観察されるべきです。事前または必要に応じて、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
誤解の場合、一部のノードは、認識できないOAMパケットを受信できます。そのような場合、これらのOAMパケットは、効果がある誤動作を避けるために静かに廃棄する必要があります
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].
悪意のある攻撃に似ています（例：劣化したパフォーマンスや失敗さえ）。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.
編集者は、ロックレポートとロックインストラクションの説明のために、マルコムベッツ、ヨシノリコイーク、Xiaoミン、およびマルテンヴィッサーの貢献に感謝しています。
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 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、Xuequin Weiのコメントとテキストへの強化について。
[1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[1] Rosen、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] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、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] Bocci、M。およびS. Bryant、「マルチセグメントの擬似具体的エミュレーションエッジツーエッジのアーキテクチャ」、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] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「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。and B. Akyol、「マルチプロトコルラベルスイッチング（MPLS）ネットワークでのライブ（TTL）処理」、RFC 3443、2003年1月。
[7] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[7] Bocci、M.、ed。、vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、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] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、およびL. Berger、「輸送ネットワークにおけるMPLのフレームワーク」、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] Bocci、M.、Levrau、L。、およびD. Frost、「MPLS Transport Profileユーザーからネットワークへのインターフェイスとネットワーク間インターフェイス」、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] Frost、D.、ed。、Bryant、S.、ed。、およびM. Bocci、ed。、「MPLS Transport Profile Data Plane Architecture」、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.、Ed。、ed。、Ward、D.、ed。、およびM. Betts、ed。、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[12] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
[12] Bradner、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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. Fang、「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] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[17] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[17] Grossman、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. Berger、「MPLS Traffic Engineering（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 Standard 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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-Protocol Label Switching（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[24] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[24] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（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] Winter、R.、ed。、van Helvoort、H。、およびM. Betts、「ITU-T規則に続くMPLS-TP識別子」、2011年7月の作業。
Ben Niven-Jenkins Velocix
Ben Niven-Jenkins Velocix
EMail: ben@niven-jenkins.co.uk
Annamaria Fulignoli Ericsson
アナマリア・フリニョリ・エリクソン
EMail: annamaria.fulignoli@ericsson.com
Enrique Hernandez-Valencia Alcatel-Lucent
Enrique Hernandez-Valencia Alcatel-Lucent
EMail: Enrique.Hernandez@alcatel-lucent.com
Lieven Levrau Alcatel-Lucent
Lieven Levrau Alcatel-Lucent
EMail: Lieven.Levrau@alcatel-lucent.com
Vincenzo Sestito Alcatel-Lucent
Vincenzo Sestito Alcatel-Lucent
EMail: Vincenzo.Sestito@alcatel-lucent.com
Nurit Sprecher Nokia Siemens Networks
Nurit Sprecher Nokia Siemens Networks
EMail: nurit.sprecher@nsn.com
Huub van Helvoort Huawei Technologies
Huub Van Helvoort Huawei Technologies
EMail: hhelvoort@huawei.com
Martin Vigoureux Alcatel-Lucent
Martin Vigoureux Alcatel-Lucent
EMail: Martin.Vigoureux@alcatel-lucent.com
Yaacov Weingarten Nokia Siemens Networks
Yaacov Weingarten Nokia Siemensネットワーク
EMail: yaacov.weingarten@nsn.com
Rolf Winter NEC
ロルフ冬のnec
EMail: Rolf.Winter@nw.neclab.eu
Authors' Addresses
著者のアドレス
Dave Allan Ericsson
デイブ・アラン・エリクソン
EMail: david.i.allan@ericsson.com
Italo Busi Alcatel-Lucent
Italo busi alcatel-lucent
EMail: Italo.Busi@alcatel-lucent.com