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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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.
問題が発生した場合に迅速に反応することができるようにすると、サービスレベル契約（SLA）のパラメータのいくつかを検証できるようにするために、顧客を終了するために提供されるサービスを監視するために、トランスポート・サービス・プロバイダーによって使用されるサービス指向の機能、などのO （例えば、パフォーマンスモニタを使用して）最終顧客と交渉。トランスポートサービスは、いくつかのネットワークまたは全て同じ伝送サービスプロバイダが所有し、管理することはできません管理ドメイン上で提供することができることに注意してください。
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.
OAM機能は、マルチメンテナンスドメイン環境内のSLAの検証を可能にし、パケット遅延やパケットロスのために、例えば、によるサービス低下の決定を可能にするように、会議サービスおよび性能目標O。
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機能のアーキテクチャおよび機能要件を示しています。これらの要件は、擬似回線（PWの）に適用され、ラベルはパス（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要件を示します。これは、様々なタイプへの適用のない詳細影響を行い（例えば、ポイントツーポイント、ポイントツーマルチポイント、単方向、双方向、等）のPW、のLSP、およびセクションの。さらに、このドキュメントは、プロトコル・ソリューション（s）は機能的目標を達成するためにどのように振る舞うべきかに関する要件を提供していません。詳細については[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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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エンドポイントとして、与えられたPWのために、ラベルエッジルータ（LER）に、指定されたLSPまたはセクションのため、およびPW終端プロバイダエッジ（T-PE）を指します。さらに、我々は、中間点として、ラベルスイッチングルータ（LSR）に、与えられたLSPのために、及びPWスイッチングプロバイダエッジ（S-PE）に、与えられたPWのために参照します。それは文章の文脈から推測できるように、このドキュメントは、エンドポイント（例えば、ソースおよび宛先）との間の区別をしません。
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（[1]用語「セグメント」に関する定義について、並びにMPLS-TPに関連する他の定義を参照）、セグメントとセグメントと連結されたセグメントの両方を指します。
o refer to both single segment PWs and multi-segment PWs as PWs.
どのようにどのようにANSどのように単一セグメントpoth参照セグメントをmylti-てみましょう。
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.
以下の要件は、一つ以上の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]の状態（要件＃2）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.
本書で特定された要件を満たすために開発されたプロトコル溶液（s）は、少なくともポイントツーポイント双方向のPW適用可能でなければなりません、ポイントツーポイントの同時ルーティング双方向の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は、複数のドメインにまたがることができます。プロトコル溶液（S）がエンドエンドにすると、セグメントに適用可能でなければなりません。より一般的には、ドメインごとに、複数のドメイン間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.
プロトコル溶液（S）は、基礎となるトンネリングまたはポイント・ツー・ポイント技術または伝送媒体と無関係であるべきです。
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機能は、OAM機能（複数可）の独立していなければならない異なるPW、LSP、またはセクション上で動作します。換言すれば、（例えば）所与の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.
さらに、任意のOAM機能は、OAM機能（複数可）の独立しているべきであるPWまたはLSPのセグメント（S）に印加される同じPW又はLSPの他のセグメント（S）に印加されます。
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.
注：二つの異なるの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プロトコル溶液（S）、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ヘッダでカプセル化を使用して、例えば、）IP機能に依存することによって動作OAM機能のOAMメッセージを区別する能力をサポートしなければならないから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メッセージ（例えば、ソース及び/又は宛先ノードの）識別情報を組み込む必要があります。プロトコル溶液（S）は、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.
OAMの相互運用性は、セクション2.1.4に記載した環境をマテリアライズ異なるドメイン間で達成されることが必要です。また、2.1.4項の最初の二つの要件がまだ保持し、相互運用性が実現されたときに、まだ満たさなければならないことが必要とされます。
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.
一つ以上の機能的要件（単数または複数）を満たす任意のプロトコル溶液は、のPW、の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.
一つ以上の機能的要件（単数または複数）を満たす任意のプロトコルの溶液は、効果的にフル機能の機能を提供することをお勧めします。それは、その機能のために識別されたすべてのケースに適用される機能です。その文脈では、プロトコル溶液（単数または複数）は、それらの適用可能性を述べなければなりません。
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.
さらに、メカニズムは、障害や欠陥が自分のドメインの外側に配置されている場合でも、サービス（S）、彼が提供して影響を与える障害や欠陥を認識するために、サービスプロバイダのために利用可能でなければなりません。
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.
この機能は、エンド・PWをポイント、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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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.
この機能は、エンド・PWをポイント、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.
この機能は、オンデマンドでエンドポイントおよびPWとのLSPの中間点の間およびPW、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.
積極的にこの機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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.
プロトコル溶液（S）が、リターンパスが存在する場合にも、ポイントツーポイントの単方向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、またはセクションに沿って、中間体（もしあれば）及びエンドポイントを発見するためにエンドポイントを有効にするために、より一般的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.
この機能は、エンドポイントおよびPWとのLSPの中間点の間およびPW、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.
この機能を実行するために開発されたプロトコル溶液（S）もポイントツーポイント双方向の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.
この機能は、エンドポイントおよびPWとのLSPの中間点の間およびPW、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.
プロトコル溶液（S）がこの機能を実行するために開発もポイントツーポイントの一方向性のLSPとポイントツーマルチポイントLSPを、戻り経路が存在する場合には、ポイント・ツー・ポイントに関連する双方向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、またはセクションをロックするために、その関連するエンドポイント（複数可）を指示する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.
この機能は、エンド・PWをポイント、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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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のエンドポイント（S）と一致する場合があります。また、トンネルLSPは、そのトンネルLSPのロックアクションの結果としてサービスの外であることが起こり得ます。この文書の範囲外の手段によって、PW又はLSPの中間点（複数）はこの状態を認識してもよいです。 MPLS-TPのOAMツールセットは、同じPWまたはLSP、間接的にその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.
この機能は、中間点およびPWと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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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のエンドポイント（S）と一致する場合があります。また、トンネルLSPは、そのトンネルLSPの障害の結果としてサービスの外であることが起こり得ます。この文書の範囲外の手段によって、PW又はLSPの中間点（複数）はこの状態を認識してもよいです。 MPLS-TPのOAMツールセットは、同じPWまたはLSP、間接的にその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.
この機能は、中間点およびPWと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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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.
この機能は、エンド・PWをポイント、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.
この機能を実行するために開発されたプロトコル溶液（S）もポイントツーポイント双方向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ネットワークの外部）欠陥又は故障状態がで検出しますPWまたはLSPのエンドポイント、クライアントレイヤのOAM機能はアラーム通知/伝播機能を提供しない場合。
This function SHOULD be performed proactively.
この機能は、積極的に行うべきです。
This function SHOULD be performed between End Points of PWs and LSPs.
この機能は、PWをし、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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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.
この機能は、エンド・PWをポイント、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.
この機能を実行するために開発されたプロトコル溶液（s）はまた、ポイント・ツー・ポイントに関連する双方向の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.
この機能は、エンド・PWをポイント、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.
この機能を実行するために開発されたプロトコル溶液（S）は、ポイント・ツー・ポイントに関連する双方向の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.
OAMパケットは、現在の管理ドメインを去ることを回避するように、パケットがPW、LSP、またはセクションを介して受信した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.
編集者は感謝マシューボッチ、イタロBUSI、トーマス・ディーツ、アンナマリアFulignoli、HuubバンHelvoort、エンリケ・ヘルナンデス - バレンシア、渉Imajuku、カムラム、マルク・Lasserre、リーフェンLevrau、ハンリー、ジュリアンMeuric、フィリップ・ニジェール、ベンジャミンの貢献を認めますニーヴン・ジェンキンス、ジンRuiquan、Nuritのスポークスマン裕二栃尾、聡上野、およびYaacovヴェンガルテン。
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の定義や仕様に関与（ITU-Tで合同ワーキングチーム、IETFでのMPLSの相互運用性設計チーム、およびMPLS-TPアドホックグループ）チームのすべてのメンバーに感謝したいと思います。
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[1]ニーヴン-ジェンキンス、B.、Brungard、D.、ベッツ、M.、Sprecher、N.、およびS.上野、 "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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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.ツバメは、RFC 4379、2006年2月 "検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[5] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[5]ナドー、T.とC. Pignataro、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"、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]ボッチ、M.編、ブライアント、S.、エド。、霜、D.、編、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、ProgressのWork 、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シリーズ：IETF MPLS技術の応用のためのT-MPLS OAMと配慮のための輸送要件に関する補足"、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.
、RFC 4377の "マルチプロトコルラベル（MPLS）ネットワークを交換するための運用管理（OAM）要件" [11]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島、2006年2月。
[12] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan, Ed., "MPLS-TP OAM Framework", Work in Progress, April 2010.
[12]ビジネスサービス、I.、編、ニーヴン・ジェンキンス、B.、編。、及びD.アラン編、 "MPLS-TP OAMフレームワーク"、進歩、2010年4月ワーク。
[13] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "BFD For MPLS LSPs", Work in Progress, June 2008.
[13]アガルワル、R.、Kompella、K.、ナドー、T.、およびG.ツバメ、 "MPLSのLSPについてBFD"、進歩、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、エド。、 "Pseudowireの仮想回線接続性検証（VCCV）のための双方向フォワーディング検出（BFD）"、進歩、2009年7月での作業。
Authors' Addresses
著者のアドレス
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
マーティン・ヘイル（編集者）アルカテル・ルーセントルートNozay 91620ヴィルジュフランス
EMail: martin.vigoureux@alcatel-lucent.com
メールアドレス：martin.vigoureux@alcatel-lucent.com
David Ward (editor) Juniper Networks
デビッド・ウォード（編集者）ジュニパーネットワークス
EMail: dward@juniper.net
メールアドレス：dward@juniper.net
Malcolm Betts (editor) M. C. Betts Consulting Ltd.
マルコムベッツ（エディタ）M. C.ベッツコンサルティング株式会社
EMail: malcolm.betts@rogers.com
メールアドレス：malcolm.betts@rogers.com