[要約] RFC 5860は、MPLSトランスポートネットワークにおける運用、管理、および保守（OAM）の要件を定義しています。このRFCの目的は、MPLSネットワークの信頼性と効率性を向上させるために、OAM機能の標準化と統一を提供することです。
Internet Engineering Task Force (IETF) M. Vigoureux, Ed.
Request for Comments: 5860 Alcatel-Lucent
Category: Standards Track D. Ward, Ed.
ISSN: 2070-1721 Juniper Networks
M. Betts, Ed.
M. C. Betts Consulting Ltd.
May 2010
Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks
MPLS輸送ネットワークの運用、管理、およびメンテナンス（OAM）の要件
Abstract
概要
This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections.
このドキュメントには、MPLS輸送プロファイルの運用、管理、およびメンテナンスのアーキテクチャおよび機能的要件がリストされています。これらの要件は、擬似ワイヤ、ラベルスイッチ付きパス、およびセクションに適用されます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（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/rfc5860.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5860で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 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
1.1. Scope of This Document . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language and Terminology . . . . . . . . . . 4
2. OAM Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architectural Requirements . . . . . . . . . . . . . . . . 6
2.1.1. Scope of OAM . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Independence . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Data Plane . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. OAM and IP Capabilities . . . . . . . . . . . . . . . 7
2.1.5. Interoperability and Interworking . . . . . . . . . . 8
2.1.6. Configuration . . . . . . . . . . . . . . . . . . . . 8
2.2. Functional Requirements . . . . . . . . . . . . . . . . . 9
2.2.1. General Requirements . . . . . . . . . . . . . . . . . 9
2.2.2. Continuity Checks . . . . . . . . . . . . . . . . . . 10
2.2.3. Connectivity Verifications . . . . . . . . . . . . . . 10
2.2.4. Route Tracing . . . . . . . . . . . . . . . . . . . . 11
2.2.5. Diagnostic Tests . . . . . . . . . . . . . . . . . . . 11
2.2.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . 11
2.2.7. Lock Reporting . . . . . . . . . . . . . . . . . . . . 12
2.2.8. Alarm Reporting . . . . . . . . . . . . . . . . . . . 12
2.2.9. Remote Defect Indication . . . . . . . . . . . . . . . 13
2.2.10. Client Failure Indication . . . . . . . . . . . . . . 13
2.2.11. Packet Loss Measurement . . . . . . . . . . . . . . . 13
2.2.12. Packet Delay Measurement . . . . . . . . . . . . . . . 14
3. Congestion Considerations . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 16
In the context of MPLS Transport Profile (MPLS-TP, see [9] and [1]), the rationales for Operations, Administration, and Maintenance (OAM) are twofold as it can serve:
MPLSトランスポートプロファイル（MPLS-TP、[9]および[1]を参照）のコンテキストでは、運用、管理、およびメンテナンスの理論的根拠（OAM）は2倍になります。
o as a network-oriented functionality, used by a transport network operator to monitor his network infrastructure and to implement internal mechanisms in order to enhance the general behavior and the level of performance of his network (e.g., protection mechanism in case of node or link failure). As an example, fault localization is typically associated with this use case.
o ネットワークインフラストラクチャを監視し、内部メカニズムを実装するためにトランスポートネットワークオペレーターが使用するネットワーク指向の機能として、彼のネットワークの一般的な動作とパフォーマンスのレベルを強化するために（例えば、ノードまたはリンク障害の場合の保護メカニズム）。例として、障害の局在は通常、このユースケースに関連付けられています。
o as a service-oriented functionality, used by a transport service provider to monitor services offered to end customers in order to be able to react rapidly in case of a problem and to be able to verify some of the Service Level Agreement (SLA) parameters (e.g., using performance monitoring) negotiated with the end customers. Note that a transport service could be provided over several networks or administrative domains that may not all be owned and managed by the same transport service provider.
o サービス指向の機能として、輸送サービスプロバイダーが、問題の場合に迅速に対応し、サービスレベル契約（SLA）パラメーターの一部を検証できるように、エンド顧客に提供されるサービスを監視するために使用されます（たとえば、パフォーマンス監視を使用する）エンド顧客と交渉された。すべてが同じ輸送サービスプロバイダーによって所有および管理されているわけではないいくつかのネットワークまたは管理ドメインに輸送サービスを提供できることに注意してください。
More generally, OAM is an important and fundamental functionality in transport networks as it contributes to:
より一般的には、OAMは次の貢献に貢献するため、輸送ネットワークの重要かつ基本的な機能です。
o the reduction of operational complexity and costs, by allowing for efficient and automatic detection, localization, and handling and diagnosis of defects, as well as by minimizing service interruptions and operational repair times.
o 効率的かつ自動的な検出、ローカリゼーション、および欠陥の取り扱いと診断を可能にすることにより、およびサービスの中断と運用の修復時間を最小限に抑えることにより、運用上の複雑さとコストの削減。
o the enhancement of network availability, by ensuring that defects (for example, those resulting in misdirected customer traffic) and faults are detected, diagnosed, and dealt with before a customer reports the problem.
o 顧客が問題を報告する前に、欠陥（たとえば、誤った方向の顧客トラフィックをもたらすもの）と障害が検出され、診断され、対処されることを確認することにより、ネットワークの可用性の向上。
o meeting service and performance objectives, as the OAM functionality allows for SLA verification in a multi-maintenance domain environment and allows for the determination of service degradation due, for example, to packet delay or packet loss.
o OAM機能によりマルチメンテナンスドメイン環境でのSLA検証が可能になり、たとえばパケットの遅延やパケットの損失によるサービス劣化の決定が可能になるため、サービスとパフォーマンスの目標を満たすことができます。
This document lists architectural and functional requirements for the OAM functionality of MPLS-TP. These requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), and Sections.
このドキュメントには、MPLS-TPのOAM機能のアーキテクチャおよび機能要件がリストされています。これらの要件は、Pseudowires（PWS）、ラベルスイッチ付きパス（LSP）、およびセクションに適用されます。
These requirements are derived from the set of requirements specified by ITU-T and published in the ITU-T Supplement Y.Sup4 [10].
これらの要件は、ITU-Tで指定された一連の要件から導き出され、ITU-TサプリメントY.SUP4 [10]に公開されています。
By covering transport specificities, these requirements complement those identified in RFC 4377 [11]; yet, some requirements may be similar.
輸送の特異性をカバーすることにより、これらの要件はRFC 4377 [11]で特定された要件を補完します。しかし、いくつかの要件は同様かもしれません。
This document only lists architectural and functional OAM requirements. It does not detail the implications of their applicability to the various types (e.g., point-to-point, point-to-multipoint, unidirectional, bidirectional, etc.) of PWs, LSPs, and Sections. Furthermore, this document does not provide requirements on how the protocol solution(s) should behave to achieve the functional objectives. Please see [12] for further information.
このドキュメントには、アーキテクチャおよび機能的なOAM要件のみがリストされています。PWS、LSP、およびセクションのさまざまなタイプ（ポイントツーポイント、ポイントツーマルチポイント、単方向、双方向など）への適用性の影響を詳述しません。さらに、このドキュメントでは、機能目的を達成するためにプロトコルソリューションが動作する方法に関する要件を提供しません。詳細については、[12]を参照してください。
Note that the OAM functions identified in this document may be used for fault-management, performance-monitoring, and/or protection-switching applications. For example, connectivity verification can be used for fault management by detecting failure conditions, but may also be used for performance monitoring through its contribution to the evaluation of performance metrics (e.g., unavailability time). Nevertheless, it is outside the scope of this document to specify which function should be used for which application.
このドキュメントで特定されたOAM関数は、障害管理、パフォーマンス監視、および/または保護スイッチングアプリケーションに使用できることに注意してください。たとえば、接続性の検証は、故障条件を検出することにより障害管理に使用できますが、パフォーマンスメトリックの評価への貢献（例：利用不能時間）を通じてパフォーマンスモニタリングにも使用できます。それにもかかわらず、このドキュメントの範囲外で、どの機能を使用するかを指定する必要があるかどうかを指定します。
Note also that it is anticipated that implementers may wish to implement OAM message handling in hardware. Although not a requirement, this fact could be taken as a design consideration.
また、実装者はハードウェアにOAMメッセージ処理を実装したいと予想されることに注意してください。要件ではありませんが、この事実は設計上の考慮事項とみなすことができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Although this document is not a protocol specification, the use of this language clarifies the instructions to protocol designers producing solutions that satisfy the requirements set out in this document.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。このドキュメントはプロトコル仕様ではありませんが、この言語の使用は、このドキュメントで定められた要件を満たすソリューションを作成するプロトコル設計者への指示を明確にします。
In this document, we:
このドキュメントでは、
o refer to the inability of a function to perform a required action as a fault. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions. See also ITU-T G.806 [3].
o 必要なアクションを障害として実行できないことを参照してください。これには、予防的なメンテナンス、外部リソースの不足、および計画されたアクションによる不能は含まれません。ITU-T G.806 [3]も参照してください。
o refer to the situation in which the density of anomalies has reached a level where the ability to perform a required function has been interrupted as a defect. See also ITU-T G.806 [3].
o 異常の密度が、必要な関数を実行する能力が欠陥として中断されたレベルに達した状況を参照してください。ITU-T G.806 [3]も参照してください。
o refer to OAM actions that are carried out continuously or at least over long periods of time, permitting proactive reporting of fault and/or performance results as proactive OAM.
o 長期間にわたって継続的または少なくとも長期間にわたって実行されるOAMアクションを参照して、障害および/またはパフォーマンス結果のプロアクティブな報告を積極的なOAMとして許可します。
o refer to OAM actions that are initiated via manual intervention for a limited time to carry out troubleshooting as on-demand OAM.
o オンデマンドOAMとしてトラブルシューティングを実行するために、限られた時間のために手動介入を介して開始されるOAMアクションを参照してください。
o refer to a Label Edge Router (LER), for a given LSP or Section, and to a PW Terminating Provider Edge (T-PE), for a given PW, as an End Point. Further, we refer to a Label Switching Router (LSR), for a given LSP, and to a PW Switching Provider Edge (S-PE), for a given PW, as an Intermediate Point. This document does not make a distinction between End Points (e.g., source and destination) as it can be inferred from the context of the sentences.
o 特定のLSPまたはセクションのラベルエッジルーター（LER）、および特定のPWのPW終端プロバイダーエッジ（T-PE）をエンドポイントとして参照してください。さらに、特定のLSPのラベルスイッチングルーター（LSR）、および特定のPWのPWスイッチングプロバイダーエッジ（S-PE）を中間点として参照します。このドキュメントは、文のコンテキストから推測できるため、エンドポイント（ソースや宛先など）を区別しません。
o use the term "node" as a general reference to End Points and Intermediate Points.
o エンドポイントと中間点への一般的な参照として「ノード」という用語を使用します。
o refer to both segment and concatenated segments as segments (see [1] for definitions relating to the term "segment" as well as for other definitions relating to MPLS-TP).
o セグメントと連結セグメントの両方をセグメントとして参照してください（「セグメント」という用語とMPLS-TPに関連する他の定義についての定義については[1]を参照）。
o refer to both single segment PWs and multi-segment PWs as PWs.
o 単一セグメントPWとマルチセグメントPWの両方をPWSとして参照してください。
o refer to both bidirectional associated LSPs and bidirectional co-routed LSPs as bidirectional LSPs.
o 双方向関連LSPと双方向の共逆LSPの両方を双方向LSPとして参照してください。
This section lists the requirements by which the OAM functionality of MPLS-TP should abide.
このセクションには、MPLS-TPのOAM機能が順守する要件をリストします。
The requirements listed below may be met by one or more OAM protocols; the definition or selection of these protocols is outside the scope of this document.
以下にリストされている要件は、1つ以上のOAMプロトコルによって満たされる場合があります。これらのプロトコルの定義または選択は、このドキュメントの範囲外です。
RFC 5654 [1] states (Requirement #2) that the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards. This general requirement applies to MPLS-TP OAM. MPLS-TP OAM is defined in this document through a set of functional requirements. These requirements will be met by protocol solutions defined in other documents. The way in which those protocols are operated and the way in which a network operator can control and use the MPLS-TP OAM functions SHOULD be as similar as possible to the mechanisms and techniques used to operate OAM in other transport technologies.
RFC 5654 [1]は、MPLS-TP設計が合理的に可能な限り、既存のMPLS標準を再利用する必要があると述べています。この一般的な要件は、MPLS-TP OAMに適用されます。MPLS-TP OAMは、一連の機能要件を通じてこのドキュメントで定義されています。これらの要件は、他のドキュメントで定義されたプロトコルソリューションによって満たされます。これらのプロトコルが操作される方法と、ネットワークオペレーターがMPLS-TP OAM関数を制御および使用できる方法は、他の輸送技術でOAMを動作させるために使用されるメカニズムと技術と可能な限り似ている必要があります。
The protocol solution(s) developed to meet the requirements identified in this document MUST at least be applicable to point-to-point bidirectional PWs, point-to-point co-routed bidirectional LSPs, and point-to-point bidirectional Sections. Section 2.2 provides additional information with regard to the applicability to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
このドキュメントで特定された要件を満たすために開発されたプロトコルソリューションは、少なくともポイントツーポイントの双方向PWS、ポイントツーポイントの共有双方向LSP、およびポイントツーポイント双方向セクションに適用する必要があります。セクション2.2は、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPへの適用性に関する追加情報を提供します。
The service emulated by a PW may span multiple domains. An LSP may also span multiple domains. The protocol solution(s) MUST be applicable to end-to-end and to segments. More generally, it MUST be possible to operate OAM functions on a per-domain basis and across multiple domains.
PWによってエミュレートされたサービスは、複数のドメインにまたがる場合があります。LSPも複数のドメインにまたがる場合があります。プロトコルソリューションは、エンドツーエンドおよびセグメントに適用する必要があります。より一般的には、ドメインごとに、複数のドメインでOAM機能を操作できる必要があります。
Since LSPs may be stacked, the protocol solution(s) MUST be applicable on any LSP, regardless of the label stack depth. Furthermore, it MUST be possible to estimate OAM fault and performance metrics of a single PW or LSP segment or of an aggregate of PW or LSP segments.
LSPは積み重ねられる可能性があるため、ラベルスタックの深さに関係なく、プロトコルソリューションは任意のLSPに適用する必要があります。さらに、単一のPWまたはLSPセグメント、またはPWまたはLSPセグメントの骨材のOAM障害とパフォーマンスメトリックを推定することが可能である必要があります。
The protocol solution(s) SHOULD be independent of the underlying tunneling or point-to-point technology or transmission media.
プロトコルソリューションは、基礎となるトンネリングまたはポイントツーポイントテクノロジーまたはトランスミッションメディアから独立している必要があります。
The protocol solution(s) SHOULD be independent of the service a PW may emulate.
プロトコルソリューションは、PWがエミュレートするサービスとは独立している必要があります。
Any OAM function operated on a PW, LSP, or Section SHOULD be independent of the OAM function(s) operated on a different PW, LSP, or Section. In other words, only the OAM functions operated on a given LSP (for example) should be used to achieve the OAM objectives for that LSP.
PW、LSP、またはセクションで動作するOAM関数は、異なるPW、LSP、またはセクションで動作するOAM関数とは無関係である必要があります。つまり、特定のLSP（たとえば）で動作したOAM関数のみを使用して、そのLSPのOAM目標を達成する必要があります。
The protocol solution(s) MUST support the capability to be concurrently and independently operated end-to-end and on segments. Therefore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) operated on the end-to-end PW or LSP. It SHOULD also be possible to distinguish an OAM packet running over a segment of a PW or LSP from another OAM packet running on the end-to-end PW or LSP.
プロトコルソリューションは、エンドツーエンドおよびセグメントで同時に独立して動作する機能をサポートする必要があります。したがって、PWまたはLSPのセグメントに適用されるOAM関数は、エンドツーエンドのPWまたはLSPで動作するOAM関数とは無関係である必要があります。また、エンドツーエンドのPWまたはLSPで実行されている別のOAMパケットからPWまたはLSPのセグメントを実行しているOAMパケットを区別することも可能です。
Furthermore, any OAM function applied to segment(s) of a PW or LSP SHOULD be independent of the OAM function(s) applied to other segment(s) of the same PW or LSP.
さらに、PWまたはLSPのセグメントに適用されるOAM関数は、同じPWまたはLSPの他のセグメントに適用されるOAM関数とは無関係である必要があります。
Note: Independence should not be understood in terms of isolation as there can be interactions between OAM functions operated, for example, on two different LSPs.
注：たとえば、2つの異なるLSPで動作するOAM関数間の相互作用がある可能性があるため、独立性は分離の観点から理解されるべきではありません。
OAM functions operate in the data plane. OAM packets MUST run in-band; that is, OAM packets for a specific PW, LSP, or Section MUST follow the exact same data path as user traffic of that PW, LSP, or Section. This is often referred to as fate sharing.
OAM関数はデータプレーンで動作します。OAMパケットはバンド内で実行する必要があります。つまり、特定のPW、LSP、またはセクションのOAMパケットは、そのPW、LSP、またはセクションのユーザートラフィックとまったく同じデータパスに従う必要があります。これはしばしば運命共有と呼ばれます。
It MUST be possible to discriminate user traffic from OAM packets. This includes a means to differentiate OAM packets from user traffic as well as the capability to apply specific treatment to OAM packets, at the nodes processing these OAM packets.
ユーザートラフィックをOAMパケットから差別することが可能である必要があります。これには、OAMパケットをユーザートラフィックから区別する手段と、これらのOAMパケットを処理するノードで、OAMパケットに特定の処理を適用する機能が含まれます。
As part of the design of OAM protocol solution(s) for MPLS-TP, a mechanism for enabling the encapsulation and differentiation of OAM messages on a PW, LSP, or Section, MUST be provided. Such mechanism SHOULD also support the encapsulation and differentiation of existing IP/MPLS and PW OAM messages.
MPLS-TPのOAMプロトコルソリューションの設計の一部として、PW、LSP、またはセクションでOAMメッセージのカプセル化と分化を可能にするメカニズムを提供する必要があります。このようなメカニズムは、既存のIP/MPLSおよびPW OAMメッセージのカプセル化と区別もサポートする必要があります。
There are environments where IP capabilities are present in the data plane. IP/MPLS environments are examples of such environments. There are also environments where IP capabilities may not be present in the data plane. MPLS-TP environments are examples of environments where IP capabilities might or might not be present.
データプレーンにIP機能が存在する環境があります。IP/MPLS環境は、そのような環境の例です。データプレーンにIP機能が存在しない環境もあります。MPLS-TP環境は、IP機能が存在する場合と存在しない可能性のある環境の例です。
Note: Presence or absence of IP capabilities is deployment scenario dependent.
注：IP機能の有無は、展開シナリオに依存しています。
It MUST be possible to deploy the OAM functionality in any of these environments. As a result, it MUST be possible to operate OAM functions with or without relying on IP capabilities, and it MUST be possible to choose to make use of IP capabilities when these are present.
これらの環境のいずれかでOAM機能を展開することが可能である必要があります。その結果、IP機能に依存しても依存せずにOAM関数を操作することが可能である必要があり、これらが存在するときにIP機能を使用することを選択できる必要があります。
Furthermore, the mechanism required for enabling the encapsulation and differentiation of OAM messages (see Section 2.1.3) MUST support the capability to differentiate OAM messages of an OAM function operated by relying on IP capabilities (e.g., using encapsulation in an IP header) from OAM messages of an OAM function operated without relying on any IP capability.
さらに、OAMメッセージのカプセル化と区別を有効にするために必要なメカニズム（セクション2.1.3を参照）は、IP機能に依存することで動作するOAM関数のOAMメッセージを区別する機能をサポートする必要があります（例：IPヘッダーでのカプセル化の使用）。OAM機能のOAMメッセージは、IP機能に依存せずに動作します。
Note that IP capabilities include the capability to form a standard IP header, to encapsulate a payload in an IP header, to parse and analyze the fields of an IP header, and to take actions based on the content of these fields.
IP機能には、標準のIPヘッダーを形成し、IPヘッダーのペイロードをカプセル化し、IPヘッダーのフィールドを解析および分析し、これらのフィールドのコンテンツに基づいてアクションを実行する機能が含まれることに注意してください。
For certain functions, OAM messages need to incorporate identification information (e.g., of source and/or destination nodes). The protocol solution(s) MUST at least support identification information in the form of an IP addressing structure and MUST also be extensible to support additional identification schemes.
特定の機能については、OAMメッセージが識別情報（例：ソースおよび/または宛先ノードの）を組み込む必要があります。プロトコルソリューションは、少なくともIPアドレス指定構造の形で識別情報をサポートする必要があり、追加の識別スキームをサポートするために拡張可能でなければなりません。
It is REQUIRED that OAM interoperability is achieved between distinct domains materializing the environments described in Section 2.1.4. It is also REQUIRED that the first two requirements of Section 2.1.4 still hold and MUST still be met when interoperability is achieved.
セクション2.1.4で説明されている環境を具体化する明確なドメイン間でOAMの相互運用性が達成される必要があります。また、セクション2.1.4の最初の2つの要件がまだ保持され、相互運用性が達成された場合でも満たされなければならないことも必要です。
When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14]).
MPLS-TPがIPルーティングおよび転送機能で実行される場合、既存のIP/MPLSおよびPW OAMプロトコルを操作できる必要があります（例：LSP-Ping [4]、MPLS-BFD [13]、VCCV [5]、およびVCCV-BFD [14]）。
OAM functions MUST operate and be configurable even in the absence of a control plane. Conversely, it SHOULD be possible to configure as well as enable/disable the capability to operate OAM functions as part of connectivity management, and it SHOULD also be possible to configure as well as enable/disable the capability to operate OAM functions after connectivity has been established.
OAM関数は、コントロールプレーンがない場合でも動作し、構成可能でなければなりません。逆に、接続管理の一環としてOAM関数を動作させる機能を構成し、有効化/無効にすることができるはずです。また、接続性の後にOAM機能を操作する機能を構成し、有効化/無効にすることも可能です。設立。
In the latter case, the customer MUST NOT perceive service degradation as a result of OAM enabling/disabling. Ideally, OAM enabling/disabling should take place without introducing any customer impairments (e.g., no customer packet losses). Procedures aimed to prevent any traffic impairment MUST be defined for the enabling/ disabling of OAM functions.
後者の場合、顧客は、OAMを有効化/無効にした結果としてサービスの劣化を認識してはなりません。理想的には、OAM有効化/無効化は、顧客の障害を導入せずに行う必要があります（たとえば、顧客パケットの損失はありません）。OAM関数の有効化/無効化のために、交通障害を防ぐことを目的とした手順が定義されなければなりません。
Means for configuring OAM functions and for connectivity management are outside the scope of this document.
OAM機能の構成と接続管理の手段は、このドキュメントの範囲外です。
Hereafter are listed the required functionalities composing the MPLS-TP OAM toolset. The list may not be exhaustive and as such the OAM mechanisms developed in support of the identified requirements SHALL be extensible and thus SHALL NOT preclude the definition of additional OAM functionalities, in the future.
以下には、MPLS-TP OAMツールセットを構成する必要な機能がリストされています。リストは網羅的ではない可能性があり、そのため、特定された要件をサポートするために開発されたOAMメカニズムは拡張可能であるため、将来、追加のOAM機能の定義を排除してはなりません。
The design of OAM mechanisms for MPLS-TP, MUST allow for the ability to support experimental OAM functions. These functions MUST be disabled by default.
MPLS-TPのOAMメカニズムの設計により、実験的なOAM機能をサポートする能力が必要です。これらの機能は、デフォルトで無効にする必要があります。
The use of any OAM function MUST be optional and it MUST be possible to select the set of OAM function(s) to use on any PW, LSP, or Section.
任意のOAM関数の使用はオプションである必要があり、PW、LSP、またはセクションで使用するOAM関数のセットを選択できる必要があります。
It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), be the same for PWs, LSPs, and Sections.
1つ以上の機能的要件を満たすプロトコルソリューションは、PWS、LSP、およびセクションで同じであることをお勧めします。
It is RECOMMENDED that any protocol solution, meeting one or more functional requirement(s), effectively provides a fully featured function; that is, a function that is applicable to all the cases identified for that functionality. In that context, protocol solution(s) MUST state their applicability.
1つ以上の機能的要件を満たすプロトコルソリューションは、完全に機能する機能を効果的に提供することをお勧めします。つまり、その機能について特定されたすべてのケースに適用可能な関数です。その文脈では、プロトコルソリューションは適用可能性を述べる必要があります。
Unless otherwise stated, the OAM functionalities MUST NOT rely on user traffic; that is, only OAM messages MUST be used to achieve the objectives.
特に明記しない限り、OAM機能はユーザートラフィックに依存してはなりません。つまり、目標を達成するためにOAMメッセージのみを使用する必要があります。
For the on-demand OAM functions, the result of which may vary depending on packet size, it SHOULD be possible to perform these functions using different packet sizes.
オンデマンドOAM関数の場合、その結果はパケットサイズによって異なる場合があります。異なるパケットサイズを使用してこれらの機能を実行できるはずです。
If a defect or fault occurs on a PW, LSP, or Section, mechanisms MUST be provided to detect it, diagnose it, localize it, and notify the appropriate nodes. Mechanisms SHOULD exist such that corrective actions can be taken.
PW、LSP、またはセクションで欠陥または障害が発生した場合、それを検出し、診断し、ローカライズし、適切なノードに通知するためにメカニズムを提供する必要があります。是正措置を講じることができるようにメカニズムが存在する必要があります。
Furthermore, mechanisms MUST be available for a service provider to be aware of a fault or defect affecting the service(s) he provides, even if the fault or defect is located outside of his domain.
さらに、サービスプロバイダーが、障害または欠陥がドメインの外側にある場合でも、彼が提供するサービスに影響を与える障害または欠陥を認識するためには、メカニズムを利用できる必要があります。
Protocol solution(s) developed to meet these requirements may rely on information exchange. Information exchange between various nodes involved in the operation of an OAM function SHOULD be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes.
これらの要件を満たすために開発されたプロトコルソリューションは、情報交換に依存する場合があります。OAM関数の動作に関与するさまざまなノード間の情報交換は、たとえば、欠陥や障害が適切に検出されたり、状態の変更が適切なノードによって効果的に知られているように信頼できる必要があります。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to monitor the liveness of a PW, LSP, or Section.
MPLS-TP OAMツールセットは、エンドポイントがPW、LSP、またはセクションの活性を監視できるようにする機能を提供する必要があります。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
This function SHOULD be performed proactively.
この関数は積極的に実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP, or Section.
MPLS-TP OAMツールセットは、予想されるPW、LSP、またはセクションによって特定のエンドポイントに接続されているかどうかを判断するためのエンドポイントを有効にする機能を提供する必要があります。
This function SHOULD be performed proactively between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で積極的に実行する必要があります。
This function SHOULD be performed on-demand between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
この関数は、PWSとLSPのエンドポイントと中間点の間、およびPWS、LSP、およびセクションのエンドポイント間で需要を実行する必要があります。
The protocol solution(s) developed to perform this function proactively MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を積極的に実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
The protocol solution(s) developed to perform this function on-demand MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびリターンパスが存在する場合のポイントツーマルチポイントLSPにも適用される場合があります。
The MPLS-TP OAM toolset MUST provide functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP, or Section, and more generally to trace the route of a PW, LSP, or Section. The information collected MUST include identifiers related to the nodes and interfaces composing that route.
MPLS-TP OAMツールセットは、エンドポイントがPW、LSP、またはセクションに沿って中間体（もしあれば）とエンドポイントを発見できるようにする機能を提供する必要があります。またはセクション。収集された情報には、そのルートを構成するノードとインターフェイスに関連する識別子を含める必要があります。
This function SHOULD be performed on-demand.
この関数は、オンデマンドで実行する必要があります。
This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
この関数は、PWSとLSPのエンドポイントと中間点、およびPWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs, and point-to-multipoint LSPs in case a return path exists.
この関数を実行するために開発されたプロトコルソリューションは、リターンパスが存在する場合に、ポイントツーポイント関連の双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用される場合があります。
The MPLS-TP OAM toolset MUST provide a function to enable conducting diagnostic tests on a PW, LSP, or Section. An example of such a diagnostic test consists of performing a loop-back function at a node such that all OAM and data traffic are looped back to the originating End Point. Another example of such diagnostic test consists in estimating the bandwidth of, e.g., an LSP.
MPLS-TP OAMツールセットは、PW、LSP、またはセクションで診断テストを実施できるようにする機能を提供する必要があります。このような診断テストの例は、すべてのOAMとデータトラフィックが発信エンドポイントにループされるように、ノードでループバック関数を実行することで構成されています。このような診断テストの別の例は、LSPの帯域幅を推定することにあります。
This function SHOULD be performed on-demand.
この関数は、オンデマンドで実行する必要があります。
This function SHOULD be performed between End Points and Intermediate Points of PWs and LSPs, and between End Points of PWs, LSPs, and Sections.
この関数は、PWSとLSPのエンドポイントと中間点、およびPWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MAY also apply to point-to-point associated bidirectional LSPs, to point-to-point unidirectional LSPs and point-to-multipoint LSPs, in case a return path exists.
この関数を実行するために開発されたプロトコルソリューションは、リターンパスが存在する場合に備えて、ポイントツーポイントに関連する双方向LSPに適用される場合があります。
The MPLS-TP OAM toolset MUST provide functionality to enable an End Point of a PW, LSP, or Section to instruct its associated End Point(s) to lock the PW, LSP, or Section. Note that lock corresponds to an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the PW, LSP, or Section) can be mapped on that PW, LSP, or Section.
MPLS-TP OAMツールセットは、PW、LSP、またはセクションのエンドポイントを有効にして、関連するエンドポイント（S）にPW、LSP、またはセクションをロックするよう指示する機能を提供する必要があります。ロックは、そのPW、LSP、またはセクションでマッピングできる場合（PW、LSP、またはセクションに特化したOAM（PW、LSP、またはセクション）のみがテストトラフィックのみが予想される管理ステータスに対応することに注意してください。
This function SHOULD be performed on-demand.
この関数は、オンデマンドで実行する必要があります。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
Based on the tunneling capabilities of MPLS, there are cases where Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) of another LSP on which the former is mapped/tunneled. Further, it may happen that the tunnel LSP is out of service as a result of a lock action on that tunnel LSP. By means outside of the scope of this document, the Intermediate Point(s) of the PW or LSP may be aware of this condition. The MPLS-TP OAM toolset MUST provide a function to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP.
MPLSのトンネル機能に基づいて、PWまたはLSPの中間点が、前者がマッピング/トンネリングされている別のLSPのエンドポイントと一致する場合があります。さらに、トンネルLSPがそのトンネルLSPでのロックアクションの結果として、トンネルLSPが使用されていないことがあります。このドキュメントの範囲外では、PWまたはLSPの中間点がこの状態を認識している可能性があります。MPLS-TP OAMツールセットは、PWまたはLSPの中間点が同じPWまたはLSPのエンドポイントに報告できるようにする機能を提供する必要があります。
This function SHOULD be performed proactively.
この関数は積極的に実行する必要があります。
This function SHOULD be performed between Intermediate Points and End Points of PWs and LSPs.
この関数は、PWSとLSPの中間点とエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
Based on the tunneling capabilities of MPLS, there are cases where Intermediate Point(s) of a PW or of an LSP coincide with End Point(s) of another LSP on which the former is mapped/tunneled. Further, it may happen that the tunnel LSP be out of service as a result of a fault on that tunnel LSP. By means outside of the scope of this document, the Intermediate Point(s) of the PW or LSP may be aware of this condition. The MPLS-TP OAM toolset MUST provide functionality to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a fault or defect condition indirectly affecting that PW or LSP.
MPLSのトンネル機能に基づいて、PWまたはLSPの中間点が、前者がマッピング/トンネリングされている別のLSPのエンドポイントと一致する場合があります。さらに、そのトンネルLSPの障害の結果として、トンネルLSPが使用されていないことがあります。このドキュメントの範囲外では、PWまたはLSPの中間点がこの状態を認識している可能性があります。MPLS-TP OAMツールセットは、PWまたはLSPの中間点を同じPWまたはLSPのエンドポイントに報告できるように機能を提供する必要があります。
This function SHOULD be performed proactively.
この関数は積極的に実行する必要があります。
This function SHOULD be performed between Intermediate Points and End Points of PWs and LSPs.
この関数は、PWSとLSPの中間点とエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
The MPLS-TP OAM toolset MUST provide a function to enable an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the End Points.
MPLS-TP OAMツールセットは、エンドポイントが関連するエンドポイントに、PW、LSP、またはそれらがエンドポイントであるセクションで検出する障害または欠陥状態を報告できるようにする機能を提供する必要があります。
This function SHOULD be performed proactively.
この関数は積極的に実行する必要があります。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs and MAY also apply to point-to-point unidirectional LSPs and point-to-multipoint LSPs in case a return path exists.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSPにも適用する必要があり、リターンパスが存在する場合にポイントツーポイント単方向LSPおよびポイントツーマルチポイントLSPに適用することもできます。
The MPLS-TP OAM toolset MUST provide a function to enable the propagation, from edge to edge of an MPLS-TP network, of information pertaining to a client (i.e., external to the MPLS-TP network) defect or fault condition detected at an End Point of a PW or LSP, if the client layer OAM functionality does not provide an alarm notification/propagation functionality.
MPLS-TP OAMツールセットは、MPLS-TPネットワークのエッジからエッジまで、クライアントに関連する情報（つまり、MPLS-TPネットワークの外部）の欠陥または障害状態の伝播を有効にする機能を提供する必要があります。クライアントレイヤーOAM機能がアラーム通知/伝播機能を提供しない場合、PWまたはLSPのエンドポイント。
This function SHOULD be performed proactively.
この関数は積極的に実行する必要があります。
This function SHOULD be performed between End Points of PWs and LSPs.
この関数は、PWSとLSPのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
The MPLS-TP OAM toolset MUST provide a function to enable the quantification of packet loss ratio over a PW, LSP, or Section.
MPLS-TP OAMツールセットは、PW、LSP、またはセクションでパケット損失比の定量化を可能にする機能を提供する必要があります。
The loss of a packet is defined in RFC2680 [6] (see Section 2.4). This definition is used here.
パケットの損失は、RFC2680 [6]で定義されています（セクション2.4を参照）。この定義はここで使用されます。
Packet-loss ratio is defined here to be the ratio of the number of user packets lost to the total number of user packets sent during a defined time interval.
ここでは、定義された時間間隔中に送信されたユーザーパケットの総数と失われたユーザーパケットの数の比率であるため、パケットロス比はここで定義されています。
This function MAY either be performed proactively or on-demand.
この関数は、積極的にまたはオンデマンドで実行できます。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
It SHOULD be possible to rely on user traffic to perform this functionality.
この機能を実行するためにユーザートラフィックに頼ることができるはずです。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。
The MPLS-TP OAM toolset MUST provide a function to enable the quantification of the one-way, and if appropriate, the two-way, delay of a PW, LSP, or Section.
MPLS-TP OAMツールセットは、一方向の定量化を有効にするための関数を提供する必要があります。必要に応じて、双方向、PW、LSP、またはセクションの遅延を提供する必要があります。
o The one-way delay is defined in [7] to be the time elapsed from the start of transmission of the first bit of a packet by an End Point until the reception of the last bit of that packet by the other End Point.
o 一元配置遅延は、[7]で定義されており、エンドポイントごとにパケットの最初のビットの送信の開始から、そのパケットの最後のビットがもう一方のエンドポイントで受信されるまでの時間であると定義されています。
o The two-way delay is defined in [8] to be the time elapsed from the start of transmission of the first bit of a packet by an End Point until the reception of the last bit of that packet by the same End Point.
o 双方向の遅延は、[8]で定義されており、エンドポイントごとにパケットの最初のビットの送信の開始から、同じエンドポイントでそのパケットの最後のビットを受信するまでの時間になります。
Two-way delay may be quantified using data traffic loopback at the remote End Point of the PW, LSP, or Section (see Section 2.2.5).
双方向遅延は、PW、LSP、またはセクションのリモートエンドポイントでデータトラフィックループバックを使用して定量化できます（セクション2.2.5を参照）。
Accurate quantification of one-way delay may require clock synchronization, the means for which are outside the scope of this document.
一元配置遅延の正確な定量化には、このドキュメントの範囲外にある手段が必要になる場合があります。
This function SHOULD be performed on-demand and MAY be performed proactively.
この関数はオンデマンドで実行され、積極的に実行される場合があります。
This function SHOULD be performed between End Points of PWs, LSPs, and Sections.
この関数は、PWS、LSP、およびセクションのエンドポイント間で実行する必要があります。
The protocol solution(s) developed to perform this function MUST also apply to point-to-point associated bidirectional LSPs, point-to-point unidirectional LSPs, and point-to-multipoint LSPs, but only to enable the quantification of the one-way delay.
この関数を実行するために開発されたプロトコルソリューションは、ポイントツーポイントに関連する双方向LSP、ポイントツーポイント単方向LSP、およびポイントツーマルチポイントLSPにも適用する必要があります。方法遅延。
A mechanism (e.g., rate limiting) MUST be provided to prevent OAM packets from causing congestion in the Packet Switched Network.
OAMパケットがパケットスイッチされたネットワークに渋滞を引き起こすのを防ぐために、メカニズム（レート制限など）を提供する必要があります。
This document, in itself, does not imply any security consideration but OAM, as such, is subject to several security considerations. OAM messages can reveal sensitive information such as passwords, performance data and details about, e.g., the network topology.
このドキュメント自体は、セキュリティの考慮を暗示するものではなく、OAMそのため、いくつかのセキュリティに関する考慮事項の対象となります。OAMメッセージは、パスワード、パフォーマンスデータ、たとえばネットワークトポロジに関する詳細などの機密情報を明らかにすることができます。
The nature of OAM therefore suggests having some form of authentication, authorization, and encryption in place. This will prevent unauthorized access to MPLS-TP equipment and it will prevent third parties from learning about sensitive information about the transport network.
したがって、OAMの性質は、何らかの形の認証、承認、および暗号化が整っていることを示唆しています。これにより、MPLS-TP機器への不正アクセスが妨げられ、第三者が輸送ネットワークに関する機密情報について学習することができなくなります。
OAM systems (network management stations) SHOULD be designed such that OAM functions cannot be accessed without authorization.
OAMシステム（ネットワーク管理ステーション）は、許可なしにOAM機能にアクセスできないように設計する必要があります。
OAM protocol solutions MUST include the facility for OAM messages to authenticated to prove their origin and to make sure that they are destined for the receiving node. The use of such facilities MUST be configurable.
OAMプロトコルソリューションには、OAMメッセージの施設を含めて、その起源を証明し、受信ノードに運命づけられていることを確認するために認証されている必要があります。そのような施設の使用は構成可能でなければなりません。
An OAM packet received over a PW, LSP, or Section MUST NOT be forwarded beyond the End Point of that PW, LSP, or Section, so as to avoid that the OAM packet leaves the current administrative domain.
PW、LSP、またはセクションで受信したOAMパケットは、OAMパケットが現在の管理ドメインを離れることを避けるために、そのPW、LSP、またはセクションのエンドポイントを超えて転送しないでください。
The editors gratefully acknowledge the contributions of Matthew Bocci, Italo Busi, Thomas Dietz, Annamaria Fulignoli, Huub van Helvoort, Enrique Hernandez-Valencia, Wataru Imajuku, Kam Lam, Marc Lasserre, Lieven Levrau, Han Li, Julien Meuric, Philippe Niger, Benjamin Niven-Jenkins, Jing Ruiquan, Nurit Sprecher, Yuji Tochio, Satoshi Ueno, and Yaacov Weingarten.
編集者は、マシュー・ボッチ、イタロ・ビシ、トーマス・ディーツ、アナマリア・フリニョーリ、フーブ・ヴァン・ヘルヴォルト、エンリケ・ヘルナンデス・ヴァレンシア、ワタル・イマジュク、カム・ラム、マーク・ラッサル、リーヴェン・レヴルー、ハン・リア、ジュリエン・ミュリッピ・ニーガー、フィリエン・ミュリッピ・ニーガン、Niven-Jenkins、Jing Ruiquan、Nurit Sprecher、Yuji Tochio、Satoshi Ueno、Yaacov Weingarten。
The authors would like to thank all members of the teams (the Joint Working Team, the MPLS Interoperability Design Team in IETF, and the MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and specification of MPLS-TP.
著者は、MPLS-TPの定義と仕様に関与するチームのすべてのメンバー（共同作業チーム、IETFのMPLS相互運用性設計チーム、およびITU-TのMPLS-TP Ad Hocグループ）に感謝したいと思います。
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[1] Niven-Jenkins、B.、Brungard、D.、Betts、M.、Sprecher、N。、およびS. Ueno、「MPLS輸送プロファイルの要件」、RFC 5654、2009年9月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] ITU-T Recommendation G.806, "Characteristics of transport equipment - Description methodology and generic functionality", 2009.
[3] ITU -Tの推奨G.806、「輸送機器の特性 - 説明方法と一般的な機能」、2009。
[4] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[4] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[5] Nadeau、T。およびC. Pignataro、「Pseudowire仮想回路接続検証（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
[6] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999.
[6] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一元配置パケット損失メトリック」、RFC 2680、1999年9月。
[7] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999.
[7] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの一方向遅延メトリック」、RFC 2679、1999年9月。
[8] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999.
[8] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、1999年9月。
[9] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", Work in Progress, May 2010.
[9] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、およびL. Berger、「輸送ネットワークにおけるMPLSのフレームワーク」、2010年5月の進行中の作業。
[10] ITU-T Supplement Y.Sup4, "ITU-T Y.1300-series: Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", 2008.
[10] ITU-TサプリメントY.SUP4、「ITU-T Y.1300シリーズ：T-MPLS OAMの輸送要件とIETF MPLSテクノロジーの適用に関する考慮事項」、2008年。
[11] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[11] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「Multi-Protocol Label Switched（MPLS）ネットワークの運用および管理（OAM）要件」、RFC 4377、2006年2月。
[12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.
[12] Busi、I.、ed。、Niven-Jenkins、B.、ed。、およびD. Allan、ed。、「MPLS-TP OAM Framework」、Work in Progress、2010年4月。
[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[13] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「BFD for MPLS LSP」、2008年6月、進行中の作業。
[14] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", Work in Progress, July 2009.
[14] ナドー、T。、編およびC. Pignataro、ed。、「Pseudowire仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、2009年7月、進行中の作業。
Authors' Addresses
著者のアドレス
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Martin Vigoureux（編集者）Alcatel-Lucent Route de Villejust Nozay 91620フランス
EMail: martin.vigoureux@alcatel-lucent.com
David Ward (editor) Juniper Networks
David Ward（編集者）ジュニパーネットワーク
EMail: dward@juniper.net
Malcolm Betts (editor) M. C. Betts Consulting Ltd.
Malcolm Betts（編集者）M。C. Betts Consulting Ltd.
EMail: malcolm.betts@rogers.com