[要約] 要約：RFC 6669は、MPLSベースのトランスポートネットワークの運用、管理、および保守（OAM）ツールセットの概要を提供しています。目的：このRFCの目的は、MPLSベースのトランスポートネットワークにおけるOAMの重要性を説明し、効果的なツールセットの開発と実装を促進することです。
Internet Engineering Task Force (IETF) N. Sprecher
Request for Comments: 6669 Nokia Siemens Networks
Category: Informational L. Fang
ISSN: 2070-1721 Cisco Systems
July 2012
An Overview of the Operations, Administration, and Maintenance (OAM) Toolset for MPLS-Based Transport Networks
MPLSベースのトランスポートネットワークの運用、管理、および保守（OAM）ツールセットの概要
Abstract
概要
This document provides an overview of the Operations, Administration, and Maintenance (OAM) toolset for MPLS-based transport networks. The toolset consists of a comprehensive set of fault management and performance monitoring capabilities (operating in the data plane) that are appropriate for transport networks as required in RFC 5860 and support the network and services at different nested levels. This overview includes a brief recap of the MPLS Transport Profile (MPLS-TP) OAM requirements and functions and the generic mechanisms created in the MPLS data plane that allow the OAM packets to run in-band and share their fate with data packets. The protocol definitions for each of the MPLS-TP OAM tools are defined in separate documents (RFCs or Working Group documents), which are referenced by this document.
このドキュメントでは、MPLSベースのトランスポートネットワーク用の運用、管理、および保守（OAM）ツールセットの概要について説明します。ツールセットは、RFC 5860で要求されるトランスポートネットワークに適しており、ネストされたさまざまなレベルでネットワークとサービスをサポートする包括的な障害管理機能とパフォーマンス監視機能（データプレーンで動作）で構成されています。この概要には、MPLSトランスポートプロファイル（MPLS-TP）OAMの要件と機能、およびMPLSデータプレーンで作成されたOAMパケットをインバンドで実行し、その運命をデータパケットと共有できるようにする一般的なメカニズムの簡単な要約が含まれます。各MPLS-TP OAMツールのプロトコル定義は、このドキュメントで参照されている個別のドキュメント（RFCまたはワーキンググループドキュメント）で定義されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc6669.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6669で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Acronyms ...................................................5
2. Basic OAM Infrastructure Functionality ..........................6
3. MPLS-TP OAM Functions ...........................................8
3.1. Continuity Check and Connectivity Verification .............8
3.1.1. Documents for CC-CV Tools ...........................8
3.2. Remote Defect Indication ...................................8
3.2.1. Documents for RDI ...................................9
3.3. Route Tracing ..............................................9
3.3.1. Documents for Route Tracing .........................9
3.4. Alarm Reporting ............................................9
3.4.1. Documents for Alarm Reporting .......................9
3.5. Lock Instruct ..............................................9
3.5.1. Documents for Lock Instruct ........................10
3.6. Lock Reporting ............................................10
3.6.1. Documents for Lock Reporting .......................10
3.7. Diagnostic ................................................10
3.7.1. Documents for Diagnostic Testing ...................10
3.8. Packet Loss Measurement ...................................10
3.8.1. Documents for Packet Loss Measurement ..............11
3.9. Packet Delay Measurement ..................................11
3.9.1. Documents for Delay Measurement ....................11
4. MPLS-TP OAM Documents Guide ....................................12
5. OAM Toolset Applicability and Utilization ......................13
5.1. Connectivity Check and Connectivity Verification ..........14
5.2. Diagnostic Tests and Lock Instruct ........................14
5.3. Lock Reporting ............................................15
5.4. Alarm Reporting and Link Down Indication ..................15
5.5. Remote Defect Indication ..................................16
5.6. Packet Loss and Delay Measurement .........................17
6. Security Considerations ........................................18
7. Acknowledgements ...............................................18
8. References .....................................................19
8.1. Normative References ......................................19
8.2. Informative References ....................................20
Contributors ......................................................21
The MPLS Transport Profile (MPLS-TP) architectural framework is defined in [RFC5921], and it describes a common set of protocol functions that supports the operational models and capabilities typical of such transport networks.
MPLSトランスポートプロファイル（MPLS-TP）のアーキテクチャフレームワークは[RFC5921]で定義されており、そのようなトランスポートネットワークの典型的な運用モデルと機能をサポートするプロトコル機能の一般的なセットについて説明しています。
Operations, Administration, and Maintenance (OAM) plays a significant role in carrier networks. It provides methods for fault management and performance monitoring in both the transport and service layers, in order to improve their ability to support services with guaranteed and strict Service Level Agreements (SLAs) while reducing their operational costs.
運用、管理、および保守（OAM）は、キャリアネットワークで重要な役割を果たします。トランスポート層とサービス層の両方で障害管理とパフォーマンス監視を行う方法を提供し、運用コストを削減しながら、保証された厳格なサービスレベルアグリーメント（SLA）でサービスをサポートする能力を向上させます。
[RFC5654], in general, and [RFC5860], in particular, define a set of requirements for the OAM functionality for MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and Sections.
[RFC5654]は一般的に、[RFC5860]は特に、MPLS-TPラベルスイッチドパス（LSP）、疑似配線（PW）、およびセクションのOAM機能に対する一連の要件を定義しています。
The OAM solution, developed by the joint IETF and ITU-T MPLS-TP project, has three objectives:
IETFとITU-T MPLS-TPの共同プロジェクトによって開発されたOAMソリューションには、3つの目的があります。
o The OAM toolset should be developed based on existing MPLS architecture, technology, and toolsets.
o OAMツールセットは、既存のMPLSアーキテクチャ、テクノロジー、およびツールセットに基づいて開発する必要があります。
o The OAM operational experience should be similar to that in other transport networks.
o OAMの運用経験は、他のトランスポートネットワークと同様です。
o The OAM toolset developed for MPLS-based transport networks needs to be fully interoperable with existing MPLS OAM tools as documented in Section 2.1.5. of [RFC5860].
o MPLSベースのトランスポートネットワーク用に開発されたOAMツールセットは、セクション2.1.5で説明されているように、既存のMPLS OAMツールと完全に相互運用できる必要があります。 [RFC5860]の。
The MPLS-TP OAM toolset is based on the following existing tools:
MPLS-TP OAMツールセットは、次の既存のツールに基づいています。
o LSP ping, as defined in [RFC4379].
o [RFC4379]で定義されているLSP ping。
o Bidirectional Forwarding Detection (BFD), as defined in [RFC5880] and refined in [RFC5884].
o [RFC5880]で定義され、[RFC5884]で改良された双方向転送検出（BFD）。
o ITU-T OAM for the Ethernet toolset, as defined in [Y.1731]. This has been used as functionality guidelines for the performance measurement tools that were not previously supported in MPLS.
o [Y.1731]で定義されている、イーサネットツールセット用のITU-T OAM。これは、以前はMPLSでサポートされていなかったパフォーマンス測定ツールの機能ガイドラインとして使用されています。
Note that certain extensions and adjustments have been specified, relative to the existing MPLS tools, in order to conform to the transport environment and the requirements of MPLS-TP. However, compatibility with the existing MPLS tools has been maintained.
トランスポート環境とMPLS-TPの要件に準拠するために、既存のMPLSツールに対して特定の拡張機能と調整が指定されていることに注意してください。ただし、既存のMPLSツールとの互換性は維持されています。
This document provides an overview of the MPLS-TP OAM toolset, which consists of tools for MPLS-TP fault management and performance monitoring. This overview includes a brief recap of MPLS-TP OAM requirements, their functions, and the generic mechanisms used to support the MPLS-TP OAM operation.
このドキュメントでは、MPLS-TP障害管理とパフォーマンス監視のためのツールで構成されるMPLS-TP OAMツールセットの概要について説明します。この概要には、MPLS-TP OAM要件、その機能、およびMPLS-TP OAM動作のサポートに使用される一般的なメカニズムの簡単な要約が含まれています。
The protocol definitions for individual MPLS-TP OAM tools are specified in separate RFCs (or Working Group documents), which are referenced by this document.
個々のMPLS-TP OAMツールのプロトコル定義は、このドキュメントで参照されている個別のRFC（またはワーキンググループドキュメント）で指定されています。
In addition, this document includes a table that cross-references the solution documents of the OAM functionality supported. Finally, the document presents the applicability and utilization of each tool in the MPLS-TP OAM toolset.
さらに、このドキュメントには、サポートされているOAM機能のソリューションドキュメントを相互参照する表が含まれています。最後に、このドキュメントでは、MPLS-TP OAMツールセットの各ツールの適用性と利用状況を示しています。
This document uses the following acronyms:
このドキュメントでは、次の頭字語を使用しています。
ACH Associated Channel Header AIS Alarm Indication Signal BFD Bidirectional Forwarding Detection CC-CV Continuity Check and Connectivity Verification DM Delay Measurement FM Fault Management G-ACh Generic Associated Channel GAL G-ACh Label GMPLS Generalized Multiprotocol Label Switching IANA Internet Assigned Numbers Authority LDI Link Down Indication LKR Lock Report LM Loss Measurement LOC Loss of Continuity LSP Label Switched Path MEP Maintenance Entity Group End Point MEG Maintenance Entity Group MIP Maintenance Entity Group Intermediate Point MPLS Multiprotocol Label Switching MPLS-TP Transport Profile for MPLS OAM Operations, Administration, and Maintenance PM Performance Monitoring PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type, Length, Value VCCV Virtual Circuit Connectivity Verification
ACH関連チャネルヘッダーAISアラーム表示信号BFD双方向転送検出CC-CV導通チェックおよび接続性検証DM遅延測定FM障害管理G-ACh汎用関連チャネルGAL G-AChラベルGMPLS一般化マルチプロトコルラベルスイッチングIANAインターネット割り当て番号オーソリティLDIリンクダウンインジケーションLKRロックレポートLM損失測定LOC導通損失LSPラベルスイッチドパスMEPメンテナンスエンティティグループエンドポイントMEGメンテナンスエンティティグループMIPメンテナンスエンティティグループ中間ポイントMPLSマルチプロトコルラベルスイッチングMPLS OAM運用、管理、およびメンテナンスPMのMPLS-TPトランスポートプロファイルPerformance Monitoring PW Pseudowire RDI Remote Defect Indication SLA Service Level Agreement TLV Type、Length、Value VCCV Virtual Circuit Connectivity Verification
[RFC5860] defines a set of requirements for OAM architecture and general principles of operations, which are evaluated below:
[RFC5860]は、OAMアーキテクチャの一連の要件と操作の一般原則を定義します。これらは以下で評価されます。
[RFC5860] requires that --
[RFC5860]はそれを必要とします-
o OAM mechanisms in MPLS-TP are independent of the transmission media and the client service being emulated by the PW ([RFC5860], Section 2.1.2).
o MPLS-TPのOAMメカニズムは、PWによってエミュレートされる伝送メディアとクライアントサービスから独立しています（[RFC5860]、セクション2.1.2）。
o MPLS-TP OAM must be able to support both an IP-based and non-IP-based environment. If the network is IP based, i.e., IP routing and forwarding are available, then it must be possible to choose to make use of IP capabilities. On the other hand, in environments where IP functionality is not available, the OAM tools must still be able to operate independent of IP forwarding and routing ([RFC5860], Section 2.1.4). It is required to have OAM interoperability between distinct domains materializing the environments ([RFC5860], Section 2.1.5).
o MPLS-TP OAMは、IPベースの環境と非IPベースの環境の両方をサポートできる必要があります。ネットワークがIPベースの場合、つまりIPルーティングと転送が利用可能な場合、IP機能を利用することを選択できる必要があります。一方、IP機能が利用できない環境では、OAMツールはIP転送およびルーティングとは無関係に動作できる必要があります（[RFC5860]、セクション2.1.4）。環境を具体化する個別のドメイン間のOAM相互運用性が必要です（[RFC5860]、セクション2.1.5）。
o All OAM protocols support identification information, at least in the form of IP addressing structure, and are extensible to support additional identification schemes ([RFC5860], Section 2.1.4).
o すべてのOAMプロトコルは、少なくともIPアドレッシング構造の形式で識別情報をサポートし、追加の識別スキームをサポートするように拡張できます（[RFC5860]、セクション2.1.4）。
o OAM packets and the user traffic are congruent (i.e., OAM packets are transmitted in-band) and there is a need to differentiate OAM packets from user-plane packets [RFC5860], Section 2.1.3. Inherent in this requirement is the principle that full operation of the MPLS-TP OAM must be possible independently of the control or management plane used to operate the network [RFC5860], Section 2.1.3.
o OAMパケットとユーザートラフィックは合同で（つまり、OAMパケットは帯域内で送信されます）、OAMパケットとユーザープレーンパケットを区別する必要があります[RFC5860]、セクション2.1.3。この要件に固有の原則は、MPLS-TP OAMの完全な運用が、ネットワークの運用に使用される制御または管理プレーン[RFC5860]、セクション2.1.3とは無関係に可能でなければならないという原則です。
o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections ([RFC5860], Section 2.1.1). The applicability of particular MPLS-TP OAM functions to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, is described in [RFC5860], Section 2.2. In addition, MPLS-TP OAM supports these LSPs and PWs when they span either single or multiple domains ([RFC5860], Section 2.1.1).
o MPLS-TP OAMは、ポイントツーポイントの双方向PW、ポイントツーポイントのコルーテッド双方向LSP、およびポイントツーポイントの双方向セクション（[RFC5860]、セクション2.1.1）をサポートしています。特定のMPLS-TP OAM機能の、ポイントツーポイント関連の双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPへの適用性については、[RFC5860]のセクション2.2で説明しています。さらに、MPLS-TP OAMは、これらのLSPとPWが単一または複数のドメインにまたがる場合にサポートします（[RFC5860]、セクション2.1.1）。
o OAM packets may be directed to an intermediate point of an LSP/PW ([RFC5860], Sections 2.2.3, 2.2.4, and 2.2.5).
o OAMパケットは、LSP / PW（[RFC5860]、セクション2.2.3、2.2.4、および2.2.5）の中間ポイントに送信される場合があります。
[RFC5860], Section 2.2 recommends that any protocol solution meeting one or more functional requirement(s) be the same for PWs, LSPs, and Sections.
[RFC5860]、セクション2.2では、1つ以上の機能要件を満たすプロトコルソリューションは、PW、LSP、およびセクションで同じであることを推奨しています。
The following document set addresses the basic requirements listed above:
次のドキュメントセットは、上記の基本的な要件に対応しています。
o [RFC6371] describes the architectural framework for conformance to the basic requirements listed above. It also defines the basic relationships between the MPLS structures, e.g., LSP, PW, and the structures necessary for OAM functionality, i.e., the Maintenance Entity Group (MEG), its end points, and intermediate points.
o [RFC6371]は、上記の基本要件に準拠するためのアーキテクチャフレームワークについて説明しています。また、LSP、PWなどのMPLS構造と、OAM機能に必要な構造（メンテナンスエンティティグループ（MEG）、そのエンドポイント、中間ポイントなど）との間の基本的な関係も定義します。
o [RFC5586] specifies the use of the MPLS-TP in-band control channels. It generalizes the applicability of the PW ACH to MPLS LSPs and Sections by defining a Generic Associated Channel (G-ACh). The G-ACh allows control packets to be multiplexed transparently over LSPs and Sections similar to that of PW VCCV [RFC5085]. The Generic Association Label (GAL) is defined by assigning a reserved MPLS label value and is used to identify the OAM control packets. The value of the ACH Channel Type field indicates the specific protocol carried on the associated control channel. Each MPLS-TP OAM protocol has an IANA-assigned channel type allocated to it.
o [RFC5586]は、MPLS-TPインバンド制御チャネルの使用を指定します。ジェネリック関連チャネル（G-ACh）を定義することにより、MPLS LSPおよびセクションへのPW ACHの適用性を一般化します。 G-AChを使用すると、PW VCCV [RFC5085]と同様のLSPおよびセクションを介して制御パケットを透過的に多重化できます。 Generic Association Label（GAL）は、予約済みMPLSラベル値を割り当てることによって定義され、OAM制御パケットを識別するために使用されます。 ACH Channel Typeフィールドの値は、関連する制御チャネルで伝送される特定のプロトコルを示します。各MPLS-TP OAMプロトコルには、IANAによって割り当てられたチャネルタイプが割り当てられています。
[RFC5085] defines an Associated Channel Header (ACH) that provides a PW associated control channel between a PW's end points, over which OAM and other control messages can be exchanged. [RFC5586] generalizes the PW Associated Channel Header (ACH) to provide common in-band control channels also at the LSP and MPLS-TP link levels. The G-ACh allows control packets to be multiplexed transparently over the same LSP or MPLS-TP link as in PW VCCV. Multiple control channels can exist between end points.
[RFC5085]は、PWのエンドポイント間でPWに関連する制御チャネルを提供する関連チャネルヘッダー（ACH）を定義します。このチャネルを介して、OAMおよび他の制御メッセージを交換できます。 [RFC5586]は、PW関連チャネルヘッダー（ACH）を一般化して、LSPおよびMPLS-TPリンクレベルでも共通の帯域内制御チャネルを提供します。 G-AChを使用すると、PW VCCVと同じLSPまたはMPLS-TPリンクを介して制御パケットを透過的に多重化できます。エンドポイント間には複数の制御チャネルが存在できます。
[RFC5085] also defines a label-based exception mechanism that helps a Label Switching Router (LSR) to identify the control packets and direct them to the appropriate entity for processing. The use of G-ACh and GAL provides the necessary mechanisms to allow OAM packets to run in-band and share their fate with data packets. It is expected that all of the OAM protocols will be used in conjunction with this Generic Associated Channel.
[RFC5085]はまた、ラベルスイッチングルーター（LSR）が制御パケットを識別し、それらを処理のために適切なエンティティに転送するのに役立つラベルベースの例外メカニズムを定義します。 G-AChとGALを使用すると、OAMパケットをインバンドで実行し、運命をデータパケットと共有するために必要なメカニズムが提供されます。すべてのOAMプロトコルは、このGeneric Associated Channelと組み合わせて使用されることが予想されます。
o [RFC6370] provides an IP-based identifier set for MPLS-TP that can be used to identify the transport entities in the network and referenced by the different OAM protocols.
o [RFC6370]は、ネットワーク内のトランスポートエンティティの識別に使用でき、さまざまなOAMプロトコルで参照できるMPLS-TPのIPベースの識別子セットを提供します。
Note: [MPLS-TP-ITU-Idents] augments that set of identifiers to include identifier information in a format used by the ITU-T. Other identifier sets may be defined as well.
注：[MPLS-TP-ITU-Idents]は、IDのセットを拡張して、ITU-Tが使用する形式でID情報を含めます。他の識別子セットも定義できます。
The following sections discuss the OAM functions that are required in [RFC5860] and expanded upon in [RFC6371].
以下のセクションでは、[RFC5860]で必要とされ、[RFC6371]で拡張されたOAM機能について説明します。
Continuity Check and Connectivity Verification (CC-CV) are OAM operations generally used in tandem and complement each other. These functions are generally run proactively, but may also be used on-demand for diagnoses of a specific condition. [RFC5860] states that the function should allow the MEPs to proactively monitor the liveliness and connectivity of a transport path (LSP, PW, or a Section) between them. In on-demand mode, this function should support monitoring between the MEPs and between a MEP and MIP. Note that as specified in [RFC6371], Sections 3.3 and 3.4, a MEP and a MIP can reside in an unspecified location within a node, or in a particular interface on a specific side of the forwarding engine.
Continuity Check and Connectivity Verification（CC-CV）は、一般にタンデムで使用され、相互に補完し合うOAM操作です。これらの機能は通常、事前に実行されますが、特定の状態の診断にオンデマンドで使用することもできます。 [RFC5860]は、MEPがそれらの間のトランスポートパス（LSP、PW、またはセクション）の活性と接続をプロアクティブに監視できるようにする機能であると述べています。オンデマンドモードでは、この機能はMEP間およびMEPとMIP間のモニタリングをサポートする必要があります。 [RFC6371]のセクション3.3と3.4で指定されているように、MEPとMIPはノード内の指定されていない場所、または転送エンジンの特定の側の特定のインターフェイスに常駐できることに注意してください。
[RFC6371] highlights the need for the CC-CV messages to include unique identification of the MEG that is being monitored and the MEP that originated the message. The function, both proactively and in on-demand mode, needs to be transmitted at regular transmission rates pre-configured by the operator.
[RFC6371]は、CC-CVメッセージに、監視されているMEGとメッセージを発信したMEPの一意のIDを含める必要性を強調しています。この機能は、プロアクティブにもオンデマンドモードにも、オペレーターが事前に構成した通常の送信レートで送信する必要があります。
[RFC6428] defines BFD extensions to support proactive CC-CV applications.
[RFC6428]は、プロアクティブなCC-CVアプリケーションをサポートするためのBFD拡張を定義しています。
[RFC6426] provides LSP ping extensions that are used to implement on-demand connectivity verification.
[RFC6426]は、オンデマンド接続検証の実装に使用されるLSP ping拡張機能を提供します。
Both of these tools will be used within the basic functionality framework described in Section 2.
これらのツールはどちらも、セクション2で説明する基本的な機能フレームワーク内で使用されます。
Remote Defect Indication (RDI) is used by a path end point to report that a defect is detected on a bidirectional connection to its peer end point. [RFC5860] points out that this function may be applied to a unidirectional LSP only if a return path exists. [RFC6371] points out that this function is associated with the proactive CC-CV function.
Remote Defect Indication（RDI）は、パスエンドポイントがピアエンドポイントへの双方向接続で障害が検出されたことを報告するために使用されます。 [RFC5860]は、この機能は、リターンパスが存在する場合にのみ単方向LSPに適用できることを指摘しています。 [RFC6371]は、この機能がプロアクティブCC-CV機能に関連付けられていることを指摘しています。
[RFC6428] provides an extension for BFD that includes the RDI indication in the BFD format and a specification of how this indication is to be used.
[RFC6428]は、BFD形式のRDI表示と、この表示の使用方法の仕様を含むBFDの拡張機能を提供します。
[RFC5860] defines the need for functionality that would allow a path end point to identify the intermediate points (if any) and end point(s) along the path (LSP, PW, or a Section). This function would be used in on-demand mode. Normally, this path will be used for bidirectional PW, LSP, and Sections; however, unidirectional paths may be supported only if a return path exists.
[RFC5860]は、パスのエンドポイントがパスに沿った中間ポイント（存在する場合）とエンドポイントを特定できるようにする機能の必要性を定義しています（LSP、PW、またはセクション）。この関数は、オンデマンドモードで使用されます。通常、このパスは双方向のPW、LSP、およびセクションに使用されます。ただし、単方向パスは、リターンパスが存在する場合にのみサポートされます。
[RFC6426] specifies that the LSP ping enhancements for MPLS-TP on-demand connectivity verification include information on the use of LSP ping for route tracing of an MPLS-TP path.
[RFC6426]は、MPLS-TPオンデマンド接続検証のLSP ping拡張に、MPLS-TPパスのルートトレースにLSP pingを使用することに関する情報が含まれていることを指定しています。
Alarm Reporting is a function used by an intermediate point of a path (LSP or PW) to report to the end points of the path that a fault exists on the path. [RFC6371] states that this may occur as a result of a defect condition discovered at a server layer. The intermediate point generates an Alarm Indication Signal (AIS) that continues until the fault is cleared. The consequent action of this function is detailed in [RFC6371].
アラームレポートは、パスの中間点（LSPまたはPW）によって使用される機能であり、パスに障害が存在することをパスのエンドポイントに報告します。 [RFC6371]は、これはサーバー層で発見された障害状態の結果として発生する可能性があると述べています。中間点は、障害がクリアされるまで続くアラーム表示信号（AIS）を生成します。この関数の結果として生じるアクションは[RFC6371]で詳述されています。
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. This protocol uses all of the basic mechanisms detailed in Section 2.
MPLS-TPは、[RFC6427]で文書化されているこの機能に対処するための新しいプロトコルを定義しています。このプロトコルは、セクション2で詳述されているすべての基本メカニズムを使用します。
The Lock Instruct function is an administrative control tool that allows a path end point to instruct its peer end point to lock the path (LSP, PW, or Section). The tool is necessary to support single-side provisioning for administrative locking, according to [RFC6371]. This function is used on-demand.
Lock Instruct機能は、パスエンドポイントがパス（LSP、PW、またはセクション）をロックするようにピアエンドポイントに指示できるようにする管理制御ツールです。 [RFC6371]によると、このツールは管理ロックの片側プロビジョニングをサポートするために必要です。この機能はオンデマンドで使用されます。
[RFC6435] describes the details of a new ACH-based protocol format for this functionality.
[RFC6435]は、この機能の新しいACHベースのプロトコル形式の詳細を説明しています。
Lock Reporting, defined in [RFC5860], is similar to the Alarm Reporting function described above. It is used by an intermediate point to notify the end points of a transport path (LSP or PW) that an administrative lock condition exists for the transport path.
[RFC5860]で定義されているロックレポートは、上記のアラームレポート機能に似ています。これは、トランスポートパス（LSPまたはPW）のエンドポイントに、トランスポートパスの管理ロック状態が存在することを通知するために中間ポイントによって使用されます。
MPLS-TP defines a new protocol to address this functionality that is documented in [RFC6427]. This protocol uses all the basic mechanisms detailed in Section 2.
MPLS-TPは、[RFC6427]で文書化されているこの機能に対処するための新しいプロトコルを定義しています。このプロトコルは、セクション2で詳述されているすべての基本メカニズムを使用します。
[RFC5860] indicates a need to provide an OAM function that would enable conducting different diagnostic tests on a PW, LSP, or Section. [RFC6371] provides two types of specific tests to be used through this functionality:
[RFC5860]は、PW、LSP、またはセクションでさまざまな診断テストを実行できるようにするOAM機能を提供する必要性を示しています。 [RFC6371]は、この機能を通じて使用される2種類の特定のテストを提供します：
o Throughput estimation - allowing the provider to verify the bandwidth/throughput of a transport path. This is an out-of-service tool that uses special packets of varying sizes to test the actual bandwidth and/or throughput of the path.
o スループットの見積もり-プロバイダーがトランスポートパスの帯域幅/スループットを確認できるようにします。これは、さまざまなサイズの特別なパケットを使用して、実際の帯域幅やパスのスループットをテストするサービス停止ツールです。
o Data-plane loopback - this out-of-service tool causes all traffic that reaches the target node, either a MEP or MIP, to be looped back to the originating MEP. For targeting MIPs, a co-routed bidirectional path is required.
o データプレーンループバック-このアウトオブサービスツールは、ターゲットノードに到達するすべてのトラフィックをMEPまたはMIPのいずれかで、元のMEPにループバックします。 MIPをターゲットにするには、同じルートの双方向パスが必要です。
[RFC6435] describes the details of a new ACH-based protocol format for the data-plane loopback functionality.
[RFC6435]は、データプレーンループバック機能の新しいACHベースのプロトコルフォーマットの詳細を説明しています。
The tool for throughput estimation is under study.
スループット推定のためのツールは現在調査中です。
Packet Loss Measurement is required by [RFC5860] to provide a quantification of the packet loss ratio on a transport path. This is the ratio of the number of user packets lost to the total number of user packets during a defined time interval. To employ this function, [RFC6371] defines that the two end points of the transport path should exchange counters of messages transmitted and received within a time period bounded by loss-measurement messages. The framework warns that there may be small errors in the computation, which result from various issues.
パケット損失測定は、[RFC5860]がトランスポートパス上のパケット損失率の定量化を提供するために必要です。これは、定義された時間間隔中に失われたユーザーパケットの数とユーザーパケットの総数の比率です。この機能を使用するために、[RFC6371]は、トランスポートパスの2つのエンドポイントが、損失測定メッセージによって制限された時間内に送受信されるメッセージのカウンターを交換する必要があることを定義しています。フレームワークは、さまざまな問題が原因で計算に小さなエラーが発生する可能性があることを警告します。
[RFC6374] describes the protocol formats and procedures for using the tool and enabling efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffice to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731].
[RFC6374]は、ツールを使用し、MPLSネットワークでのパケット損失、遅延、スループットの効率的かつ正確な測定を可能にするプロトコル形式と手順を説明しています。 [RFC6375]は、MPLS-TPの特定の要件を満たすのに十分な一般的なMPLS損失、遅延、およびスループット測定技術のプロファイルについて説明しています。ツールのロジックは、[Y.1731]で説明されている並列関数の動作に基づいていることに注意してください。
Packet Delay Measurement is a function that is used to measure the one-way or two-way delay of packet transmission between a pair of the end points of a path (PW, LSP, or Section), as described in [RFC5860], where:
パケット遅延測定は、[RFC5860]で説明されているように、パスのエンドポイントのペア（PW、LSP、またはセクション）間のパケット送信の一方向または双方向の遅延を測定するために使用される関数です。 ：
o One-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node.
o 一方向パケット遅延は、送信元ノードによるパケットの最初のビットの送信の開始から宛先ノードによるそのパケットの最後のビットの受信までに経過した時間です。
o Two-way packet delay is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node.
o 双方向パケット遅延とは、送信元ノードがパケットの最初のビットの送信を開始してから、ループバックが実行されたときに、同じ送信元ノードがループバックされたパケットの最後のビットを受信するまでの時間です。パケットの宛先ノード。
[RFC6371] describes how the tool could be used (both in proactive and on-demand modes) for either one-way or two-way measurement. However, it warns that the one-way delay option requires precise time synchronization between the end points.
[RFC6371]は、一方向または双方向の測定にツールをどのように使用できるかを示しています（プロアクティブモードとオンデマンドモードの両方で）。ただし、一方向の遅延オプションでは、エンドポイント間の正確な時間同期が必要であることを警告しています。
[RFC6374] describes the protocol formats and procedures for using the tool and enabling efficient and accurate measurement of packet loss, delay, and throughput in MPLS networks. [RFC6375] describes a profile of the general MPLS loss, delay, and throughput measurement techniques that suffices to meet the specific requirements of MPLS-TP. Note that the tool logic is based on the behavior of the parallel function described in [Y.1731].
[RFC6374]は、ツールを使用し、MPLSネットワークでのパケット損失、遅延、スループットの効率的かつ正確な測定を可能にするプロトコル形式と手順を説明しています。 [RFC6375]は、MPLS-TPの特定の要件を満たすのに十分な一般的なMPLS損失、遅延、およびスループット測定技術のプロファイルについて説明しています。ツールのロジックは、[Y.1731]で説明されている並列関数の動作に基づいていることに注意してください。
The complete MPLS-TP OAM protocol suite is covered by a small set of existing IETF documents. This set of documents may be expanded in the future to cover additional OAM functionality. In order to allow the reader to understand this set of documents, a cross-reference of the existing documents (RFCs or Working Group documents) for the initial phase of the specification of MPLS-based transport networks is provided below.
完全なMPLS-TP OAMプロトコルスイートは、既存のIETFドキュメントの小さなセットでカバーされています。この一連のドキュメントは、追加のOAM機能をカバーするために将来拡張される可能性があります。読者がこの一連のドキュメントを理解できるように、MPLSベースのトランスポートネットワークの仕様の初期段階における既存のドキュメント（RFCまたはワーキンググループドキュメント）の相互参照を以下に示します。
[RFC5586] provides a specification of the basic structure of protocol messages for in-band data-plane OAM in an MPLS environment.
[RFC5586]は、MPLS環境でのインバンドデータプレーンOAMのプロトコルメッセージの基本構造の仕様を提供します。
[RFC6370] provides definitions of different formats that may be used within OAM protocol messages to identify the network elements of an MPLS-based transport network.
[RFC6370]は、MPLSベースのトランスポートネットワークのネットワーク要素を識別するためにOAMプロトコルメッセージ内で使用できるさまざまなフォーマットの定義を提供します。
The following table (Table 1) provides the summary of proactive MPLS-TP OAM Fault Management toolset functions, the associated tool/protocol, and the corresponding RFCs in which they are defined.
次の表（表1）は、プロアクティブなMPLS-TP OAM障害管理ツールセット機能、関連するツール/プロトコル、およびそれらが定義されている対応するRFCの概要を示しています。
+--------------------------+-------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+--------------------------+-------------------------------+---------+
| Continuity Check and | Bidirectional Forwarding |[RFC6428]|
| Connectivity | Detection (BFD) | |
| Verification | | |
+--------------------------+-------------------------------+---------+
| Remote Defect Indication | Flag in Bidirectional |[RFC6428]|
| (RDI) | Forwarding Detection (BFD) | |
| | message | |
+--------------------------+-------------------------------+---------+
| Alarm Indication Signal | G-ACh-based AIS message |[RFC6427]|
| (AIS) | | |
+--------------------------+-------------------------------+---------+
| Link Down Indication | Flag in AIS message |[RFC6427]|
| (LDI) | | |
+--------------------------+-------------------------------+---------+
| Lock Reporting (LKR) | G-ACh-based LKR message |[RFC6427]|
| | | |
+--------------------------+-------------------------------+---------+
Table 1. Proactive Fault Management OAM Toolset
表1.プロアクティブな障害管理OAMツールセット
The following table (Table 2) provides an overview of the on-demand MPLS-TP OAM Fault Management toolset functions, the associated tool/protocol, and the corresponding RFCs in which they are defined.
次の表（表2）は、オンデマンドMPLS-TP OAM障害管理ツールセットの機能、関連するツール/プロトコル、およびそれらが定義されている対応するRFCの概要を示しています。
+------------------------+---------------------------------+---------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+------------------------+---------------------------------+---------+
| Connectivity | LSP Ping |[RFC6426]|
| Verification | | |
+------------------------+---------------------------------+---------+
| Lock Instruct (LI) | (1) G-ACh-based Loopback, |[RFC6426]|
| | (2) Lock Instruct (LI) | |
+------------------------+---------------------------------+---------+
| Lock Report (LKR) | Flag in AIS message |[RFC6426]|
| | | |
+------------------------+---------------------------------+---------+
Table 2. On Demand Fault Management OAM Toolset
表2.オンデマンドの障害管理OAMツールセット
The following table (Table 3) provides the Performance Monitoring Functions, the associated tool/protocol definitions, and the corresponding RFCs in which they are defined.
次の表（表3）は、パフォーマンス監視機能、関連するツール/プロトコル定義、およびそれらが定義されている対応するRFCを示しています。
+----------------------+--------------------------+-----------------+
| OAM Functions | OAM Tools/Protocols | RFCs |
+----------------------+--------------------------+-----------------+
| Packet Loss | G-ACh-based LM & DM | [RFC6374] |
| Measurement (LM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Packet Delay | G-ACh-based LM & DM | [RFC6374] |
| Measurement (DM) | query messages | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Throughput | derived from Loss | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
| Delay Variation | derived from Delay | [RFC6374] |
| Measurement | Measurement | [RFC6375] |
+----------------------+--------------------------+-----------------+
Table 3. Performance Monitoring OAM Toolset
表3. Performance Monitoring OAMツールセット
The following subsections present the MPLS-TP OAM toolset from the perspective of the specified protocols and identifies the required functionality that is supported by the particular protocol.
以下のサブセクションでは、指定されたプロトコルの観点からMPLS-TP OAMツールセットを示し、特定のプロトコルでサポートされる必要な機能を識別します。
Proactive Continuity Check and Connectivity Verification (CC-CV) functions are used to detect loss of continuity (LOC) and unintended connectivity between two MEPs. Loss of connectivity, mis-merging, mis-connectivity, or unexpected Maintenance Entity Group End Points (MEPs) can be detected using the CC-CV tools. See Sections 3.1, 3.2, 3.3 in this document for CC-CV protocol references.
プロアクティブな導通チェックおよび接続性検証（CC-CV）機能は、2つのMEP間の導通性損失（LOC）および意図しない接続を検出するために使用されます。 CC-CVツールを使用して、接続の喪失、誤ったマージ、誤った接続、または予期しないメンテナンスエンティティグループのエンドポイント（MEP）を検出できます。 CC-CVプロトコルリファレンスについては、このドキュメントのセクション3.1、3.2、3.3を参照してください。
The CC-CV tools are used to support MPLS-TP fault management, performance management, and protection switching. Proactive CC-CV control packets are sent by the source MEP to the sink MEP. The sink-MEP monitors the arrival of the CC-CV control packets and detects the defect. For bidirectional transport paths, the CC-CV protocol is usually transmitted simultaneously in both directions.
CC-CVツールは、MPLS-TP障害管理、パフォーマンス管理、および保護切り替えをサポートするために使用されます。プロアクティブCC-CV制御パケットは、ソースMEPによってシンクMEPに送信されます。シンクMEPは、CC-CV制御パケットの到着を監視し、障害を検出します。双方向トランスポートパスの場合、CC-CVプロトコルは通常、双方向で同時に送信されます。
The transmission interval of the CC-CV control packets can be configured. For example:
CC-CV制御パケットの送信間隔を設定できます。例えば：
o 3.3 ms is the default interval for protection switching.
o 3.3 msは、保護切り替えのデフォルトの間隔です。
o 100 ms is the default interval for performance monitoring.
o 100ミリ秒がパフォーマンス監視のデフォルトの間隔です。
o 1 s is the default interval for fault management.
o 障害管理のデフォルトの間隔は1秒です。
[RFC6435] describes a protocol that provides a mechanism to Lock and Unlock traffic (e.g., data and control traffic or specific OAM traffic) at a specific LSR on the path of the MPLS-TP LSP to allow loopback of the traffic to the source.
[RFC6435]は、MPLS-TP LSPのパス上の特定のLSRでトラフィックをロックおよびロック解除するメカニズム（データおよび制御トラフィックまたは特定のOAMトラフィックなど）を提供して、ソースへのトラフィックのループバックを可能にするプロトコルを記述しています。
These diagnostic functions apply to associated bidirectional MPLS-TP LSPs, including MPLS-TP LSPs, bidirectional RSVP-Traffic Engineering (RSVP-TE) tunnels (which is relevant for the MPLS-TP dynamic control-plane option with GMPLS), and single-segment and multi-segment Pseudowires. [RFC6435] provides the protocol definition for diagnostic tests functions.
これらの診断機能は、MPLS-TP LSP、双方向RSVP-Traffic Engineering（RSVP-TE）トンネル（GMPLSのMPLS-TPダイナミックコントロールプレーンオプションに関連する）、およびシングル-を含む、関連する双方向MPLS-TP LSPに適用されます。セグメントおよびマルチセグメントの疑似配線。 [RFC6435]は、診断テスト機能のプロトコル定義を提供します。
[RFC6435] defines a mechanism where a lock instruction is sent by a management application to both ends of a point-to-point LSP, requesting them to take the LSP out-of-service. When an end point gets the management request, it locks the LSP and sends a Lock Instruct message to the other end of the LSP. The Lock Instruct message is carried in a Generic ACH message and is sent periodically. The time between successive messages is no longer than the value set in the Refresh Timer field of the Lock Instruct message. An LSP end point keeps the LSP locked while it is either receiving the periodic Lock Instruct messages or has an in-force lock instruction from the management application.
[RFC6435]は、管理アプリケーションからポイントツーポイントLSPの両端にロック命令が送信され、LSPをサービス停止にするよう要求するメカニズムを定義しています。エンドポイントが管理要求を受け取ると、LSPをロックし、LSPのもう一方の端にLock Instructメッセージを送信します。 Lock InstructメッセージはGeneric ACHメッセージで運ばれ、定期的に送信されます。連続するメッセージ間の時間は、Lock Instructメッセージの[Refresh Timer]フィールドに設定された値を超えません。 LSPエンドポイントは、定期的なLock Instructメッセージを受信している間、または管理アプリケーションから強制ロック命令を受け取っている間、LSPをロックしたままにします。
Note that since the management application will receive a management plane response from both ends of the LSP confirming that the LSP has been locked, there is no requirement for the Lock Instruct message to have a response. Therefore, [RFC6435] does not define a Lock Instruct response message.
管理アプリケーションは、LSPがロックされていることを確認するLSPの両端から管理プレーン応答を受信するため、Lock Instructメッセージに応答がある必要はないことに注意してください。したがって、[RFC6435]はLock Instruct応答メッセージを定義していません。
The loopback operations include:
ループバック操作には次のものがあります。
o Lock: take an LSP out of service for maintenance.
o ロック：LSPを保守のためにサービスから外します。
o Unlock: Restore a previously locked LSP to service.
o ロック解除：以前にロックされたLSPをサービスに復元します。
o Set_Full_Loopback and Set_OAM_Loopback.
o Set_Full_LoopbackおよびSet_OAM_Loopback。
o Unset_Full_Loopback and Set_OAM_Loopback.
o Unset_Full_LoopbackおよびSet_OAM_Loopback。
Operators can use the loopback mode to test the connectivity or performance (loss, delay, delay variation, and throughput) of a given LSP up to a specific node on the path of the LSP.
オペレーターはループバックモードを使用して、LSPのパス上の特定のノードまでの特定のLSPの接続またはパフォーマンス（損失、遅延、遅延変動、およびスループット）をテストできます。
The Lock Report (LKR) function is used to communicate to the MEPS of the client (sub-)layer MEPs the administrative locking of a server (sub-)layer MEP, and consequential interruption of data traffic forwarding in the client layer. See Section 3.6 in this document for Lock Reporting protocol references.
Lock Report（LKR）機能は、クライアント（サブ）レイヤーMEPのMEPSに、サーバー（サブ）レイヤーMEPの管理ロック、および結果としてクライアントレイヤーでのデータトラフィック転送の中断を伝達するために使用されます。 Lock Reportingプロトコルのリファレンスについては、このドキュメントのセクション3.6を参照してください。
When an operator is taking the LSP out of service for maintenance or another operational reason, using the LKR function can help to distinguish the condition as administrative locking from a defect condition.
オペレーターが保守またはその他の運用上の理由でLSPをサービスから外しているときに、LKR機能を使用すると、管理ロックとしての状態と障害状態を区別するのに役立ちます。
The Lock Report function may also serve the purpose of alarm suppression in the MPLS-TP network above the level at which the Lock has occurred. The receipt of an LKR message may be treated as the equivalent of the loss of continuity at the client layer.
ロックレポート機能は、MPLS-TPネットワークで、ロックが発生したレベルより上のアラーム抑制の目的にも役立ちます。 LKRメッセージの受信は、クライアント層での連続性の喪失と同等に扱われることがあります。
Alarm Indication Signal (AIS) message is used to suppress alarms following detection of defect conditions at the server (sub-)layer. When the Link Down Indication (LDI) is set, the AIS message may be used to trigger recovery mechanisms.
アラーム表示信号（AIS）メッセージは、サーバー（サブ）レイヤーでの障害状態の検出に続くアラームを抑制するために使用されます。 Link Down Indication（LDI）が設定されている場合、AISメッセージを使用して回復メカニズムをトリガーできます。
When a server MEP detects the failure, it asserts LOC or signal fail, which sets the flag up to generate an OAM packet with the AIS message. The AIS message is forwarded to the downstream sink MEP in the client layer. This enables the client layer to suppress the generation of secondary alarms.
サーバーMEPが障害を検出すると、LOCまたは信号障害をアサートし、フラグを立てて、AISメッセージを含むOAMパケットを生成します。 AISメッセージは、クライアントレイヤーのダウンストリームシンクMEPに転送されます。これにより、クライアント層はセカンダリアラームの生成を抑制できます。
An LDI flag is defined in the AIS message. The LDI flag is set in the AIS message in response to detecting a fatal failure in the server layer. Receipt of an AIS message with this flag set may be interpreted by a MEP as an indication of signal fail at the client layer.
LDIフラグはAISメッセージで定義されます。 LDIフラグは、サーバー層での致命的な障害の検出に応答して、AISメッセージで設定されます。このフラグが設定されたAISメッセージの受信は、クライアント層での信号障害の指示としてMEPによって解釈される場合があります。
The protocols for AIS and LDI are defined in [RFC6427].
AISとLDIのプロトコルは[RFC6427]で定義されています。
Fault OAM messages are generated by intermediate nodes where an LSP is switched and propagated to the end points (MEPs).
障害OAMメッセージは、LSPが切り替えられてエンドポイント（MEP）に伝達される中間ノードによって生成されます。
From a practical point of view, when both proactive Continuity Check functions and LDI are used, one may consider running the proactive Continuity Check functions at a slower rate (e.g., longer BFD hello intervals), and reply on LDI to trigger fast protection switch over upon failure detection in a given LSP.
実用的な観点から見ると、プロアクティブな導通チェック機能とLDIの両方を使用する場合は、プロアクティブな導通チェック機能を低速で実行し（BFD hello間隔を長くするなど）、LDIに応答して高速保護切り替えをトリガーすることを検討できます。特定のLSPで障害が検出されたとき。
The Remote Defect Indication (RDI) function enables an end point to report to its peer end point that a fault or defect condition is detected on the PW, LSP, or Section.
リモート障害表示（RDI）機能により、エンドポイントは、PW、LSP、またはセクションで障害または欠陥状態が検出されたことをピアエンドポイントに報告できます。
The RDI OAM function is supported by the use of BFD control packets [RFC6428]. RDI is only used for bidirectional connections and is associated with proactive CC-CV activation.
RDI OAM機能は、BFD制御パケット[RFC6428]の使用によってサポートされています。 RDIは双方向接続でのみ使用され、プロアクティブなCC-CVアクティベーションに関連付けられています。
When an end point (MEP) detects a signal failure condition, it sets the flag up by setting the diagnostic field of the BFD control packet to a particular value to indicate the failure condition on the associated PW, LSP, or Section. Additionally, the BFD control packet is transmitted with the failure flag up to the other end point (its peer MEP).
エンドポイント（MEP）が信号障害状態を検出すると、BFD制御パケットの診断フィールドを特定の値に設定してフラグを設定し、関連するPW、LSP、またはセクションの障害状態を示します。さらに、BFD制御パケットは、障害フラグとともに他のエンドポイント（そのピアMEP）まで送信されます。
The RDI function can be used to facilitate protection switching by synchronizing the two end points when unidirectional failure occurs and is detected by one end.
RDI機能を使用すると、片方向の障害が発生し、一方の端で検出されたときに、2つのエンドポイントを同期させることにより、保護切り替えを容易にすることができます。
The packet loss and delay measurement toolset enables operators to measure the quality of the packet transmission over a PW, LSP, or Section. Section 3.8 in this document defines the protocols for packet loss measurement, and Section 3.9 defines the protocols for packet delay measurement.
パケット損失および遅延測定ツールセットにより、オペレーターはPW、LSP、またはセクションを介したパケット伝送の品質を測定できます。このドキュメントのセクション3.8は、パケット損失測定のプロトコルを定義し、セクション3.9は、パケット遅延測定のプロトコルを定義します。
The loss and delay protocols have the following characteristics and capabilities:
損失および遅延プロトコルには、次の特性と機能があります。
o They support the measurement of packet loss, delay, and throughput over Label Switched Paths (LSPs), Pseudowires, and MPLS Sections.
o これらは、ラベルスイッチドパス（LSP）、疑似配線、およびMPLSセクションでのパケット損失、遅延、およびスループットの測定をサポートします。
o The same LM and DM protocols can be used for both continuous/proactive and selective/on-demand measurements.
o 同じLMおよびDMプロトコルを、連続/プロアクティブ測定と選択/オンデマンド測定の両方に使用できます。
o The LM and DM protocols use a simple query/response model for bidirectional measurement that allows a single node -- the querier -- to measure the loss or delay in both directions.
o LMおよびDMプロトコルは、単一ノード（クエリア）が両方向の損失または遅延を測定できるようにする双方向測定用の単純なクエリ/応答モデルを使用します。
o The LM and DM protocols use query messages for unidirectional loss and delay measurement. The measurement can either be carried out at the downstream node(s), or at the querier if an out-of-band return path is available.
o LMおよびDMプロトコルは、クエリメッセージを使用して、一方向の損失と遅延を測定します。測定は、ダウンストリームノードで、または帯域外のリターンパスが利用可能な場合はクエリアで実行できます。
o The LM and DM protocols do not require that the transmit-and-receive interfaces be the same when performing bidirectional measurement.
o LMプロトコルとDMプロトコルでは、双方向測定を実行するときに、送受信インターフェースが同じである必要はありません。
o The LM supports test-message-based measurement (i.e., inferred mode) as well as measurement based on data-plane counters (i.e., direct mode).
o LMは、テストメッセージベースの測定（つまり、推定モード）と、データプレーンカウンターに基づく測定（つまり、ダイレクトモード）をサポートしています。
o The LM protocol supports both 32-bit and 64-bit counters.
o LMプロトコルは、32ビットと64ビットの両方のカウンターをサポートしています。
o The LM protocol supports measurement in terms of both packet counts and octet counts; although for simplicity, only packet counters are currently included in the MPLS-TP profile.
o LMプロトコルは、パケット数とオクテット数の両方で測定をサポートします。ただし、簡単にするために、現在MPLS-TPプロファイルにはパケットカウンタのみが含まれています。
o The LM protocol can be used to measure channel throughput as well as packet loss.
o LMプロトコルは、チャネルスループットとパケット損失の測定に使用できます。
o The DM protocol supports varying the measurement message size in order to measure delays associated with different packet sizes.
o DMプロトコルは、さまざまなパケットサイズに関連する遅延を測定するために、測定メッセージサイズの変更をサポートしています。
o The DM protocol uses IEEE 1588 timestamps [IEEE1588] by default but also supports other timestamp formats, such as NTP.
o DMプロトコルは、デフォルトでIEEE 1588タイムスタンプ[IEEE1588]を使用しますが、NTPなどの他のタイムスタンプ形式もサポートします。
This document, as an overview of MPLS OAM tools, does not by itself raise any particular security considerations.
このドキュメントは、MPLS OAMツールの概要として、それ自体で特定のセキュリティ上の考慮事項を提起するものではありません。
The general security considerations are provided in [RFC5920] and [MPLS-TP-SEC]. Security considerations for each function within the OAM toolset have been recorded in each document that specifies a particular functionality.
セキュリティに関する一般的な考慮事項は、[RFC5920]および[MPLS-TP-SEC]で提供されています。 OAMツールセット内の各機能のセキュリティに関する考慮事項は、特定の機能を指定する各ドキュメントに記録されています。
In general, OAM is always an area where the security risk is high. For example, confidential information may be intercepted by attackers to gain access to networks; therefore, authentication, authorization, and encryption must be enforced to prevent security breaches.
一般に、OAMは常にセキュリティリスクが高い領域です。たとえば、ネットワークにアクセスするために機密情報が攻撃者に傍受される可能性があります。したがって、セキュリティ違反を防ぐために、認証、承認、暗号化を実施する必要があります。
It is also important to strictly follow operational security procedures. For example, in the case of MPLS-TP static provisioning, the operator interacts directly with the Network Management System (NMS) and devices, and it is critical in order to prevent human errors and malicious attacks.
運用上のセキュリティ手順に厳密に従うことも重要です。たとえば、MPLS-TP静的プロビジョニングの場合、オペレーターはネットワーク管理システム（NMS）およびデバイスと直接対話するため、人的エラーや悪意のある攻撃を防ぐために重要です。
Since MPLS-TP OAM uses G-ACh, the security risks and mitigations described in [RFC5085] also apply here. In short, messages on the G-ACh could be intercepted, or false G-ACh packets could be inserted.
MPLS-TP OAMはG-AChを使用するため、[RFC5085]で説明されているセキュリティリスクと緩和策もここに適用されます。つまり、G-ACh上のメッセージが傍受されたり、偽のG-AChパケットが挿入されたりする可能性があります。
Additionally, DoS attacks can be mounted by flooding G-ACh messages to peer devices. To mitigate this type of attack, throttling mechanisms or rate limits can be used. For more details, please see [RFC5085].
さらに、G-AChメッセージをピアデバイスにフラッディングすることにより、DoS攻撃を開始できます。このタイプの攻撃を緩和するには、スロットリングメカニズムまたはレート制限を使用できます。詳細については、[RFC5085]を参照してください。
The authors would like to thank the MPLS-TP experts from both the IETF and ITU-T for their helpful comments. In particular, we would like to thank Loa Andersson and the Area Directors for their suggestions and enhancements to the text.
著者は、IETFとITU-Tの両方のMPLS-TPエキスパートに有益なコメントを提供してくれたことに感謝します。特に、テキストへの提案と拡張について、ロアアンダーソンとエリアディレクターに感謝します。
Thanks to Tom Petch for useful comments and discussions.
有用なコメントと議論をしてくれたTom Petchに感謝します。
Thanks to Rui Costa for his review and comments, which helped improve this document.
このドキュメントの改善に役立ったレビューとコメントを提供してくれたRui Costaに感謝します。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Detecting Multi-Protocol Label Switched（MPLS）Data Plane Failures」、RFC 4379、2006年2月。
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5085] Nadeau、T.、Ed。およびC. Pignataro、Ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：A Control Channel for Pseudowires」、RFC 5085、2007年12月。
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[RFC5586] Bocci、M.、Ed。、Vigoureux、M.、Ed。、and S. Bryant、Ed。、 "MPLS Generic Associated Channel"、RFC 5586、June 2009。
[RFC5654] 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.
[RFC5654] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、and S. Ueno、 "Requirements of an MPLS Transport Profile"、RFC 5654 、2009年9月。
[RFC5860] 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.
[RFC5860] 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 。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880] Katz、D。およびD. Ward、「Bidirectional Forwarding Detection（BFD）」、RFC 5880、2010年6月。
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC5884] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[RFC5921] 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.
[RFC5921] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、and L. Berger、 "A Framework for MPLS in Transport Networks"、RFC 5921、 2010年7月。
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6370] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（MPLS-TP）Identifiers」、RFC 6370、2011年9月。
[RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[RFC6371] Busi、I.、Ed。およびD. Allan、Ed。、「Operations、Administration、and Maintenance Framework for MPLS-Based Transport Networks」、RFC 6371、2011年9月。
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, September 2011.
[RFC6374] Frost、D。およびS. Bryant、「MPLSネットワークのパケット損失および遅延測定」、RFC 6374、2011年9月。
[RFC6375] Frost, D., Ed., and S. Bryant, Ed., "A Packet Loss and Delay Measurement Profile for MPLS-Based Transport Networks", RFC 6375, September 2011.
[RFC6375] Frost、D。、編、およびS. Bryant、編、「MPLSベースのトランスポートネットワークのパケット損失および遅延測定プロファイル」、RFC 6375、2011年9月。
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS On-Demand Connectivity Verification and Route Tracing", RFC 6426, November 2011.
[RFC6426]グレイ、E、バハドゥール、N、ブトロス、S、およびRアガーワル、「MPLSオンデマンド接続検証およびルートトレース」、RFC 6426、2011年11月。
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[RFC6427] Swallow、G.、Ed。、Fulignoli、A.、Ed。、Vigoureux、M.、Ed。、Boutros、S.、and D. Ward、 "MPLS Fault Management Operations、Administration、and Maintenance（OAM） "、RFC 6427、2011年11月。
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, November 2011.
[RFC6428]アラン、D。、エド。
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, November 2011.
[RFC6435] Boutros、S.、Ed。、Sivabalan、S.、Ed。、Aggarwal、R.、Ed。、Vigoureux、M.、Ed。、and X. Dai、Ed。、 "MPLS Transport Profile Lock Instruct andループバック機能」、RFC 6435、2011年11月。
[IEEE1588] IEEE, "1588-2008 IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", March 2008.
[IEEE1588] IEEE、「ネットワーク測定および制御システム用の高精度クロック同期プロトコルの1588-2008 IEEE標準」、2008年3月。
[MPLS-TP-ITU-Idents] Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP Identifiers Following ITU-T Conventions", Work in Progress, March 2012.
[MPLS-TP-ITU-Idents] Winter、R.、van Helvoort、H。、およびM. Betts、「ITU-T規則に従ったMPLS-TP識別子」、作業中、2012年3月。
[MPLS-TP-SEC] Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP Security Framework", Work in Progress, March 2012.
[MPLS-TP-SEC] Fang、L.、Niven-Jenkins、B。、およびS. Mansfield、「MPLS-TP Security Framework」、Work in Progress、2012年3月。
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[RFC5920] Fang、L。、編、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[Y.1731] International Telecommunications Union - Standardization, "OAM functions and mechanisms for Ethernet based networks", ITU Y.1731, May 2006.
[Y.1731]国際電気通信連合-標準化、「イーサネットベースのネットワークのOAM機能とメカニズム」、ITU Y.1731、2006年5月。
Contributors
貢献者
Elisa Bellagamba Ericsson Yaacov Weingarten Nokia Siemens Networks Dan Frost Cisco Nabil Bitar Verizon Raymond Zhang Alcatel Lucent Lei Wang Telenor Kam Lee Yap XO Communications John Drake Juniper Yaakov Stein RAD Anamaria Fulignoli Ericsson Italo Busi Alcatel Lucent Huub van Helvoort Huawei Thomas Nadeau Computer Associate Henry Yu TW Telecom Mach Chen Huawei Manuel Paul Deutsche Telekom
Elisa Bellagamba Ericsson Yaacov Weingarten Nokia Siemens Networks Dan Frost Cisco Nabil Bitar Verizon Raymond Zhang Alcatel Lucent Lei Wang Telenor Kam Lee Yap XO Communications John Drake Juniper Yaakov Stein RAD Anamaria Fulignoli Ericsson Italo Busi Alcatel Lucent Huub Van Navodua Helvoort Hua Helvoor Associate Telecom Mach Chen Huawei Manuel Paul Deutsche Telekom
Authors' Addresses
著者のアドレス
Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel
ぬりｔ Ｓｐれちぇｒ のきあ しえめんｓ ねとぉｒｋｓ ３ はながｒ Ｓｔ。 ねゔぇ ね’えまん Ｂ ほｄ はしゃろん、 ４５２４１ いｓらえｌ
EMail: nurit.sprecher@nsn.com
Luyuan Fang Cisco Systems 111 Wood Avenue South Iselin, NJ 08830 USA
Luyuan Fang Cisco Systems 111 Wood Avenue South Iselin、NJ 08830 USA
EMail: lufang@cisco.com