Network Working Group S. Yasukawa
Request for Comments: 4687 NTT Corporation
Category: Informational A. Farrel
Old Dog Consulting
D. King
Aria Networks Ltd.
T. Nadeau
Cisco Systems, Inc.
September 2006
Operations and Management (OAM) Requirements
for Point-to-Multipoint MPLS Networks
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
マルチプロトコルラベルスイッチング（MPLS）は、ポイント・ツー・マルチポイントを包含するように拡張されました（P2MP）ラベルスイッチパス（LSP）。ポイントツーポイントMPLSのLSPと同様に、検出処理、制御及びデータプレーンの欠陥を診断するための要件は重要です。
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
P2MP MPLS LSPを、それらの欠陥を処理する方法の検出及び仕様に基づいてサービスを展開事業者にとって、このような欠陥は、MPLSネットワークの基礎に影響を与える可能性があるが、また、彼らのネットワークの顧客に対するサービスレベルの仕様コミットメントに影響を与える可能性があるだけでなくので、重要です。
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs.
この文書では、P2MP MPLS LSPのためのデータプレーンの運用と管理のための要件について説明します。これらの要件は、P2MP MPLS LSPのすべての形式に適用され、P2MP交通エンジニア（TE）のLSPとマルチキャストLSPを含んでいます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................3
2.2. Terminology ................................................3
2.3. Acronyms ...................................................3
3. Motivations .....................................................4
4. General Requirements ............................................4
4.1. Detection of Label Switch Path Defects .....................5
4.2. Diagnosis of a Broken Label Switch Path ....................6
4.3. Path Characterization ......................................6
4.4. Service Level Agreement Measurement ........................7
4.5. Frequency of OAM Execution .................................8
4.6. Alarm Suppression, Aggregation, and Layer Coordination .....8
4.7. Support for OAM Interworking for Fault Notification ........8
4.8. Error Detection and Recovery ...............................9
4.9. Standard Management Interfaces .............................9
4.10. Detection of Denial of Service Attacks ...................10
4.11. Per-LSP Accounting Requirements ..........................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
7. Acknowledgements ...............................................12
This document describes requirements for data plane operations and management (OAM) for point-to-multipoint (P2MP) Multi-Protocol Label Switching (MPLS). This document specifies OAM requirements for P2MP MPLS, as well as for applications of P2MP MPLS.
この文書では、ポイント・ツー・マルチポイントのためのデータ・プレーン・運用・管理（OAM）の要件について説明します（P2MP）マルチプロトコル・ラベル・スイッチング（MPLS）。この文書では、P2MP MPLS OAMのための要件を指定するだけでなく、P2MP MPLSのアプリケーションのため。
These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs [RFC4461] and [P2MP-RSVP], as well as multicast LDP LSPs [MCAST-LDP].
これらの要件は、P2MP MPLS LSPの全ての形態に適用され、P2MPトラヒックエンジニアリング（TE）のLSP [RFC4461]と[P2MP-RSVP]、ならびにマルチキャストLDPのLSP [MCAST-LDP]を含みます。
Note that the requirements for OAM for P2MP MPLS build heavily on the requirements for OAM for point-to-point MPLS. These latter requirements are described in [RFC4377] and are not repeated in this document.
P2MP MPLS OAMのための要件は、ポイントツーポイントMPLS OAMのための要件に大きく建てることに注意してください。これらの後者の要件は[RFC4377]に記載されており、本書では繰り返しません。
For a generic framework for OAM in MPLS networks, refer to [RFC4378].
MPLSネットワークにおけるOAMのための一般的な枠組みのために、[RFC4378]を参照。
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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The requirements in this document apply to OAM mechanism and protocol development, as opposed to the usual application of RFC 2119 requirements to an actual protocol, as this document does not specify a protocol.
この文書は、プロトコルを指定しないように、実際のプロトコルにRFC 2119の要件の通常のアプリケーションとは対照的に、この文書に記載されている要件は、OAMメカニズムとプロトコルの開発に適用されます。
Definitions of key terms for MPLS OAM are found in [RFC4377] and the reader is assumed to be familiar with those definitions, which are not repeated here.
MPLS OAMのための主要な用語の定義は、[RFC4377]に見出されており、読者はここでは繰り返さないそれらの定義、に精通しているものとします。
[RFC4461] includes some important definitions and terms for use within the context of P2MP MPLS. The reader should be familiar with at least the terminology section of that document.
[RFC4461]はP2MP MPLSの文脈内で使用するためのいくつかの重要な定義および用語を含みます。読者はその文書の少なくとも用語部に精通しなければなりません。
The following acronyms are used in this document.
以下の頭字語は、本書で使用されています。
CE: Customer Edge DoS: Denial of service ECMP: Equal Cost Multipath
CE：カスタマーエッジのDoS：サービスECMP拒否：イコールコストマルチパス
LDP: Label Distribution Protocol LSP: Label Switched Path LSR: Label Switching Router OAM: Operations and Management RSVP: Resource reSerVation Protocol P2MP: Point-to-Multipoint SP: Service Provider TE: Traffic Engineering
LDP：ラベル配布プロトコルLSP：ラベルスイッチパスLSR：運用と管理RSVP：リソース予約プロトコルP2MP：ラベルルータOAMスイッチングポイントツーマルチSP：サービスプロバイダTE：トラフィックエンジニアリング
OAM for MPLS networks has been established as a fundamental requirement both through operational experience and through its documentation in numerous Internet Drafts. Many such documents (for example, [RFC4379], [RFC3812], [RFC3813], [RFC3814], and [RFC3815]) developed specific solutions to individual issues or problems. Coordination of the full OAM requirements for MPLS was achieved by [RFC4377] in recognition of the fact that the previous piecemeal approach could lead to inconsistent and inefficient applicability of OAM techniques across the MPLS architecture, and might require significant modifications to operational procedures and systems in order to provide consistent and useful OAM functionality.
MPLSネットワークのためのOAMは、運用経験を通じて、数多くのインターネットドラフトでのドキュメントを通じて、両方の基本的な要件として確立されています。多くのそのような文書（例えば、[RFC4379]、[RFC3812]、[RFC3813]、[RFC3814]及び[RFC3815]）は、個々の問題や課題に固有のソリューションを開発しました。 MPLSのための完全なOAM要件の調整は、前の断片的なアプローチは、MPLSアーキテクチャ全体でOAM技術の矛盾や非効率的な適用可能性につながる可能性、および運用手順やシステム内に重大な変更を必要とするかもしれないという事実を認識して、[RFC4377]によって達成されました一貫性のある便利なOAM機能を提供するため。
This document builds on these realizations and extends the statements of MPLS OAM requirements to cover the new area of P2MP MPLS. That is, this document captures the requirements for P2MP MPLS OAM in advance of the development of specific solutions.
この文書では、これらの実現の上に構築し、P2MP MPLSの新しい領域をカバーするためにMPLS OAM要件のステートメントを拡張します。つまり、この文書は、特定のソリューションの開発に先立って、P2MP MPLS OAMの要件をキャプチャします。
Nevertheless, at the time of writing, some effort had already been expended to extend existing MPLS OAM solutions to cover P2MP MPLS (for example, [P2MP-LSP-PING]). While this approach of extending existing solutions may be reasonable, in order to ensure a consistent OAM framework it is necessary to articulate the full set of requirements in a single document. This will facilitate a uniform set of MPLS OAM solutions spanning multiple MPLS deployments and concurrent applications.
それにも関わらず、書き込み時には、いくつかの努力はすでにP2MP MPLS（例えば、[P2MP-LSP-PING]）をカバーするために、既存のMPLS OAMソリューションを拡張するために費やされていました。既存のソリューションを拡張するこのアプローチは合理的かもしれないが、一貫したOAMフレームワークを確保するためには、単一の文書内の要件の完全なセットを明確にする必要があります。これは、複数のMPLSの展開と並行アプリケーションにまたがるMPLS OAMソリューションの均一な集合を促進します。
The general requirements described in this section are similar to those described for point-to-point MPLS in [RFC4377]. The subsections below do not repeat material from [RFC4377], but simply give references to that document.
このセクションで説明する一般的な要件は、[RFC4377]にポイント・ツー・ポイントMPLSについて記載したものと同様です。以下のサブセクションでは、[RFC4377]から材料を繰り返し、単にその文書への参照を与えることはありません。
However, where the requirements for P2MP MPLS OAM differ from or are more extensive than those expressed in [RFC4377], additional text is supplied.
しかし、ここでP2MP MPLS OAMの要件は異なるか、[RFC4377]で表現されるものよりも広範であり、追加のテキストが供給されます。
In general, it should be noted that P2MP LSPs introduce a scalability issue with respect to OAM that is not present in point-to-point MPLS. That is, an individual P2MP LSP will have more than one egress and the path to those egresses will very probably not be linear (for example, it may have a tree structure). Since the number of egresses for a single P2MP LSP is unknown and not bounded by any small number, it follows that all mechanisms defined for OAM support MUST scale well with the number of egresses and the complexity of the path of the LSP. Mechanisms that are able to deal with individual egresses will scale no worse than similar mechanisms for point-to-point LSPs, but it is desirable to develop mechanisms that are able to leverage the fact that multiple egresses are associated with a single LSP, and so achieve better scaling.
一般的には、P2MPのLSPをポイントツーポイントMPLSには存在しないOAMに対してスケーラビリティの問題を導入することに留意すべきです。すなわち、個々のP2MP LSPは、複数の出口を有し、それらegressesへのパスが非常におそらく（例えば、それがツリー構造を有していてもよい）、直鎖状ではありません、です。単一のP2MP LSPのためegressesの数が不明と任意の小さな数で囲まれないので、OAMをサポートするために定義されたすべてのメカニズムがegressesの数とLSPの経路の複雑さとうまくスケーリングしなければならないことになります。個々egressesに対処することができるメカニズムは、ポイント・ツー・ポイントのLSPのための同様のメカニズムよりも悪いスケーリングしないであろうが、複数egressesが単一のLSPに関連しているという事実を利用することができるメカニズムを開発することが望ましい、などより良いスケーリングを実現。
The ability to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP, and SHOULD rely on proactive OAM procedures (such as continuous path connectivity and Service Level Agreement (SLA) measurement mechanisms). Any solutions SHOULD either extend or work in close conjunction with existing solutions developed for point-to-point MPLS, such as those specified in [RFC4379] where this requirement is not contradicted by the other requirements in this section. This will leverage existing software and hardware deployments.
P2MP LSPの欠陥を検出する能力は、マニュアルを必要としない場合には、各LSRのホップバイホップトラブルシューティングは、そのLSPのトラフィックを切り替えるために使用され、このような連続経路の接続性とサービスレベル契約などのプロアクティブOAM手順（（SLAに依存しているべきです）測定メカニズム）。任意の解決策は、この要件は、このセクションの他の要件と矛盾していない[RFC4379]で指定されたもののようなポイント・ツー・ポイントMPLS用に開発された既存のソリューションとの緊密な連動して拡張したり、動作するはずのいずれか。これは、既存のソフトウェアとハードウェアの展開を活用します。
Note that P2MP LSPs may introduce additional scaling concerns for LSP probing by tools such as [RFC4379]. As the number of leaves of a P2MP LSP increases it potentially becomes more expensive to inspect the LSP to detect defects. Any tool developed for this purpose MUST be cognitive of this issue and MUST include techniques to reduce the scaling impact of an increase in the number of leaves. Nevertheless, it should also be noted that the introduction of additional leaves may mean that the use of techniques such as [RFC4379] are less appropriate for defect detection with P2MP LSPs, while the technique may still remain useful for defect diagnosis as described in the next section.
P2MPのLSPは、LSPは、[RFC4379]などのツールによってプロービングするための付加的なスケーリングの問題を導入し得ることに留意されたいです。 P2MP LSPの葉の数が増加するにつれて、それは潜在的欠陥を検出するためにLSPを検査するために、より高価になります。この目的のために開発された任意のツールは、この問題の認知なければならず、葉数の増加のスケーリングへの影響を軽減するための技術を含まなければなりません。それにもかかわらず、また、付加的な葉の導入技術は、依然として欠陥診断のために有用なままであるかもしれない次に記載されているような[RFC4379]などの技術の使用は、P2MP LSPを有する欠陥検出にはあまり適切であることを意味してもよいことに留意すべきですセクション。
Due to the above scaling concerns, LSRs or other network resources MUST NOT be overwhelmed by the operation of normal proactive OAM procedures, and measures taken to protect LSRs and network resources against being overwhelmed MUST NOT degrade the operational value or responsiveness of proactive OAM procedures. Note that reactive OAM may violate these limits (i.e., cause visible traffic degradation) if it is necessary or useful to try to fix whatever has gone wrong.
以上により、スケーリングの問題、のLSRまたは他のネットワークリソースへの通常の積極的なOAM手順の操作に圧倒されてはならない、と圧倒さに対してのLSRとネットワークリソースを保護するための対策は、プロアクティブOAM手順の動作値や応答性を低下させてはなりません。間違っているものは何でも解決しようとするために必要または有益である場合、反応OAMは、これらの制限に違反する可能性があります（すなわち、目に見えるトラフィックの劣化の原因となります）。
By "overwhelmed" we mean that it MUST NOT be possible for an LSR to be so busy handling proactive OAM that it is unable to continue to process control or data plane traffic at its advertised rate. Similarly, a network resource (such as a data link) MUST NOT be carrying so much proactive OAM traffic that it is unable to carry the advertised data rate. At the same time, it is important to configure proactive OAM, if it is in use, not to raise alarms caused by the failure to receive an OAM message if the component responsible for processing the messages is unable to process because other components are consuming too many system resources -- such alarms might turn out to be false.
「圧倒」とは、LSRはその広告を出した速度で制御やデータプレーントラフィックを処理し続けることができないので、忙しい取り扱い積極的OAMすることは可能であってはならないことを意味します。同様に、（データリンクなど）のネットワーク・リソースは、広告を出して、データレートを運ぶことができないことをそんなに積極的なOAMトラフィックを伝送してはなりません。それが使用されている場合、同時に、メッセージを処理するコンポーネントが他のコンポーネントがあまりにも消費しているため、処理できない場合OAMメッセージを受信するための障害によるアラームを生成しない、積極的なOAMを設定することが重要です多くのシステムリソース - などのアラームが偽であることが判明するかもしれません。
In practice, of course, the requirements in the previous paragraph may be met by careful specification of the anticipated data throughput of LSRs or data links. However, it should be recalled that proactive OAM procedures may be scaled linearly with the number of LSPs, and the number of LSPs is not necessarily a function of the available bandwidth in an LSR or on a data link.
実際には、当然のことながら、前の段落の要件は、のLSRまたはデータリンクの予想データスループットの慎重な仕様によって満たすことができます。しかし、積極的なOAM手順がLSPの数と共に直線的にスケーリングすることができる、およびLSPの数は必ずしもLSRまたはデータリンク上で利用可能な帯域幅の関数ではないことを想起すべきです。
The ability to diagnose a broken P2MP LSP and to isolate the failed component (i.e., link or node) in the path is REQUIRED. These functions include a path connectivity test that can test all branches and leaves of a P2MP LSP for reachability, as well as a path tracing function. Note that this requirement is distinct from the requirement to detect errors or failures described in the previous section. In practice, Detection and Diagnosis/Isolation MAY be performed by separate or the same mechanisms according to the way in which the other requirements are met.
壊れたP2MP LSPを診断するために、パスに障害が発生した成分（すなわち、リンクまたはノード）を単離する能力が必要とされます。これらの機能は、到達可能性のためのP2MP LSPのすべての枝と葉をテストすることができ、パス接続性試験、ならびにパストレース機能を含みます。この要件は、前のセクションで説明したエラーまたは障害を検出するための要件とは異なることに注意してください。実際には、検出および診断/単離は、他の要件が満たされている方法によれば、別々のまたは同一の機構によって行われてもよいです。
It MUST be possible for the operator (or an automated process) to stipulate a timeout after which the failure to see a response shall be flagged as an error.
オペレータ（または自動化されたプロセス）が故障応答がエラーとしてフラグを立てなければならない参照するに、その後のタイムアウトを規定することが可能でなければなりません。
Any mechanism developed to perform these functions is subject to the scalability concerns expressed in section 4.
これらの機能を実行するために開発された任意の機構は、セクション4で表現さスケーラビリティの問題の対象となります。
The path characterization function [RFC4377] is the ability to reveal details of LSR forwarding operations for P2MP LSPs. These details can then be compared later during subsequent testing relevant to OAM functionality. Therefore, LSRs supporting P2MP LSPs MUST provide mechanisms that allow operators to interrogate and characterize P2MP paths.
パスの特性関数[RFC4377]はP2MPのLSPのためのLSR転送動作の詳細を明らかにする能力です。これらの詳細は、OAM機能に関連するその後のテスト中に、後に比較することができます。したがって、P2MP LSPを支持するのLSRは、オペレータが、P2MP経路を調べると特徴付けるすることを可能にするメカニズムを提供しなければなりません。
Since P2MP paths are more complex than the paths of point-to-point LSPs, the scaling concerns expressed in section 4 apply.
P2MP経路は、ポイントツーポイントLSPの経路よりも複雑であるため、セクション4で発現スケーリングの問題が適用されます。
Note that path characterization SHOULD lead to the operator being able to determine the full tree for a P2MP LSP. That is, it is not sufficient to know the list of LSRs in the tree, but it is important to know their relative order and where the LSP branches.
そのパスの特性は、オペレータがP2MP LSPの完全なツリーを決定することができることにつながるはず注意。つまり、ツリー内のLSRのリストを知るには十分ではありません、ですが、それらの相対的な順序や場所LSPの枝を知ることが重要です。
Since, in some cases, the control plane state and data paths may branch at different points from the control plane and data plane topologies (for example, Figure 1), it is not sufficient to present the order of LSRs, but it is important that the branching points on that tree are clearly identified.
いくつかのケースでは、制御プレーン状態及びデータパスは、制御プレーンとデータプレーン・トポロジーの相違点（例えば、図1）で分岐することができる、あるので、のLSRの順序を提示するのに十分ではないが、それはすることが重要ですそのツリーの分岐点が明確に特定されています。
E
/
A---B---C===D
\
F
Figure 1. An example P2MP tree where the data path and control plane state branch at C, but the topology branches at D.
D.での図1のCのデータ経路と制御プレーン状態枝例P2MPツリーが、トポロジーの枝
A diagnostic tool that meets the path characterization requirements SHOULD collect information that is easy to process to determine the P2MP tree for a P2MP LSP, rather than provide information that must be post-processed with some complexity.
パスの特性要件を満たしている診断ツールは、P2MP LSPのためのP2MPツリーを決定するのではなく、いくつかの複雑で後処理しなければならない情報を提供するために、加工が容易である情報を収集する必要があります。
Mechanisms are required to measure the diverse aspects of Service Level Agreements for services that utilize P2MP LSPs. The aspects are listed in [RFC4377].
メカニズムはP2MPのLSPを活用したサービスのためのサービス・レベル・アグリーメントの多様な側面を測定するのに必要とされます。態様は、[RFC4377]に記載されています。
Service Level Agreements are often measured in terms of the quality and rate of data delivery. In the context of P2MP MPLS, data is delivered to multiple egress nodes. The mechanisms MUST, therefore, be capable of measuring the aspects of Service Level Agreements as they apply to each of the egress points to a P2MP LSP. At the same time, in order to diagnose issues with meeting Service Level Agreements, mechanisms SHOULD be provided to measure the aspects of the agreements at key points within the network such as at branch nodes on the P2MP tree.
サービスレベル契約は、多くの場合、データ配信の品質と速度の点で測定されています。 P2MP MPLSの文脈では、データは、複数の出口ノードに配信されます。それらはP2MP LSPの出口点のそれぞれに適用されるメカニズムは、したがって、サービス・レベル・アグリーメントの側面を測定することができなければなりません。同時に、サービスレベルアグリーメントを満たすの問題を診断するために、メカニズムは、P2MPツリーのブランチノードでなど、ネットワーク内のキーポイントで合意の側面を測定するために提供されるべきです。
As stipulated in [RFC4377], the operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements. This requirement is potentially more important in P2MP deployments where the effects of the execution of OAM functions can be potentially much greater than in a non-P2MP configuration. For example, a mechanism that causes each egress of a P2MP LSP to respond could result in a large burst of responses to a single OAM request.
[RFC4377]に規定されているとおり、オペレータは、特定の業務要件を満たすためにOAMパラメータを設定するための柔軟性を持たなければなりません。この要件は、OAM機能の実行の効果が潜在的に非P2MP構成よりもはるかに大きくすることができるP2MPの展開に潜在的に重要です。例えば、P2MP LSPの各出口が応答させる機構は、単一のOAM要求に対する応答の大きなバーストが生じる可能性があります。
Therefore, solutions produced SHOULD NOT impose any fixed limitations on the frequency of the execution of any OAM functions.
したがって、生成溶液は、任意のOAM機能の実行頻度に任意の固定された制限を課すべきではありません。
As described in [RFC4377], network elements MUST provide alarm suppression and aggregation mechanisms to prevent the generation of superfluous alarms within or across network layers. The same time constraint issues identified in [RFC4377] also apply to P2MP LSPs.
[RFC4377]に記載されているように、ネットワーク要素は、ネットワーク層内または横切って余分なアラームの発生を防止するアラーム抑制および凝集のメカニズムを提供しなければなりません。 [RFC4377]で特定され、同じ時間制約の問題もP2MPのLSPに適用されます。
A P2MP LSP also brings the possibility of a single fault causing a larger number of alarms than for a point-to-point LSP. This can happen because there are a larger number of downstream LSRs (for example, a larger number of egresses). The resultant multiplier in the number of alarms could cause swamping of the alarm management systems to which the alarms are reported, and serves as a multiplier to the number of potentially duplicate alarms raised by the network.
P2MP LSPはまた、ポイント・ツー・ポイントLSPよりもアラームの多数を引き起こす単一の障害の可能性をもたらします。 （例えば、egresses多数の）下流のLSRの多数があるので、これは起こることができます。アラームの数で結果乗数は、アラームが報告されると、アラーム管理システムのスワンピングを引き起こし、潜在的にネットワークで発生したアラームを複製の数と乗数として機能できます。
Alarm aggregation or limitation techniques MUST be applied within any solution, or be available within an implementation, so that this scaling issue can be reduced. Note that this requirement introduces a second dimension to the concept of alarm aggregation. Where previously it applied to the correlation and suppression of alarms generated by different network layers, it now also applies to similar techniques applied to alarms generated by multiple downstream LSRs.
このスケーリングの問題を低減することができるアラーム凝集または制限の技術は、任意の溶液内適用、または実装内で利用可能でなければなりません。この要件は、アラーム集約の概念に二次元を紹介することに注意してください。以前は、それが別のネットワーク層によって生成されたアラームの相関関係及び抑制に適用される場合、それは今、複数の下流のLSRによって生成されたアラームに適用される同様の技術に適用されます。
[RFC4377] specifies that an LSR supporting the interworking of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. This also applies to any LSR supporting P2MP LSPs. However, careful attention to the requirements for alarm suppression stipulated therein and in section 4.6 SHOULD be observed.
[RFC4377]はMPLS上の1つのまたは複数のネットワーク技術の相互動作をサポートするLSRはネイティブ技術のエラー条件にMPLS欠陥を変換することができなければならないことを指定します。また、これはP2MP LSPをサポートする任意のLSRに適用されます。しかし、そことセクション4.6に定めるアラーム抑制のための要件への細心の注意が観察されなければなりません。
Note that the time constraints for fault notification and alarm propagation affect the solutions that might be applied to the scalability problem inherent in certain OAM techniques applied to
障害通知とアラームの伝播のための時間の制約が適用、特定のOAM技術に固有のスケーラビリティの問題に適用される可能性があります解決策に影響を与えることに注意してください
P2MP LSPs. For example, a solution to the issue of a large number of egresses all responding to some form of probe request at the same time might be to make the probes less frequent -- but this might affect the ability to detect and/or report faults.
P2MPのLSPを。たとえば、すべて同時にプローブ要求のいくつかのフォームへの対応egressesの多数の問題を解決するには、プローブはそれほど頻繁にするかもしれない - しかし、これは障害を検出および/または報告する能力に影響を与える可能性があります。
Where fault notification to the egress is required, there is the possibility that a single fault will give rise to multiple notifications, one to each egress node of the P2MP that is downstream of the fault. Any mechanisms MUST manage this scaling issue while still continuing to deliver fault notifications in a timely manner.
出口への障害通知が要求される場合、単一の故障が、故障の下流にあるP2MPの各出口ノードに複数の通知を生じ、一方を与える可能性があります。まだタイムリーに障害通知を配信し続けている間、任意のメカニズムは、このスケーリングの問題を管理しなければなりません。
Where fault notification to the ingress is required, the mechanisms MUST ensure that the notification identifies the egress nodes of the P2MP LSP that are impacted (that is, those downstream of the fault) and does not falsely imply that all egress nodes are impacted.
入口に障害通知が要求される場合、機構は、通知が影響を受けるP2MP LSPの出口ノードを識別する（すなわち、障害の下流ものである）と誤ってすべての出力ノードが影響を受けることを意味しないことを保証しなければなりません。
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. As described in [RFC4377], these procedures will detect a broad range of defects, and SHOULD be operable where MPLS P2MP LSPs span multiple routing areas or multiple Service Provider domains.
ネットワーク要素による障害からの回復は、MPLS OAM手順によって容易にすることができます。 [RFC4377]に記載されているように、これらの手順は、欠陥の広い範囲を検出し、及びMPLS P2MPのLSPを、複数のルーティングエリア、または複数のサービスプロバイダドメインにまたがる場合に動作可能であるべきです。
The same requirements as those expressed in [RFC4377] with respect to automatic repair and operator intervention ahead of customer detection of faults apply to P2MP LSPs.
自動修復および前方P2MPのLSPに適用故障の顧客検出のオペレータの介入に対する[RFC4377]で表現されるものと同じ要件。
It should be observed that faults in P2MP LSPs MAY be recovered through techniques described in [P2MP-RSVP].
P2MPのLSPに故障が[P2MP-RSVP]に記載の技術により回収することができることが観察されるべきです。
The widespread deployment of MPLS requires common information modeling of management and control of OAM functionality. This is reflected in the integration of standard MPLS-related MIBs [RFC3812], [RFC3813], [RFC3814], [RFC3815] for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status.
MPLSの広範囲の展開は、OAM機能の管理および制御の一般的な情報モデリングが必要です。これは、障害、統計、および構成管理のための標準的なMPLS関連のMIBの統合[RFC3812]、[RFC3813]、[RFC3814]、[RFC3815]に反映されています。これらの標準インターフェースは、共通のプログラム・インタフェースの操作および管理機能へのアクセスとその状態をオペレータに提供します。
The standard MPLS-related MIB modules [RFC3812], [RFC3813], [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to support P2MP LSPs, the associated OAM functions on these LSPs, and the applications that utilize P2MP LSPs. Extending them will facilitate the reuse of existing management software both in LSRs and in management systems. In cases where the existing MIB modules cannot be extended, then new MIB modules MUST be created.
標準MPLS関連のMIBモジュール[RFC3812]、[RFC3813]、[RFC3814]及び[RFC3815]はP2MP LSPを、これらのLSPに関連するOAM機能、およびP2MP LSPを利用するアプリケーションをサポートするために、可能な限り延長すべきです。それらを拡張するのLSRにし、マネジメントシステムの両方で既存の管理ソフトウェアの再利用を促進します。既存のMIBモジュールを拡張することができない場合には、その後、新しいMIBモジュールを作成する必要があります。
The ability to detect denial of service (DoS) attacks against the data or control planes that signal P2MP LSPs MUST be part of any security management related to MPLS OAM tools or techniques.
P2MP LSPをデータ信号または制御プレーンに対するサービス拒否（DoS）攻撃の拒否を検出する能力は、MPLS OAMツールや技術に関連するセキュリティ管理の一部でなければなりません。
In an MPLS network where P2MP LSPs are in use, Service Providers can measure traffic from an LSR to the egress of the network using some MPLS-related MIB modules (see section 4.9), for example. Other interfaces MAY exist as well and enable the creation of traffic matrices so that it is possible to know how much traffic is traveling from where to where within the network.
P2MP用のLSPが使用されているMPLSネットワークでは、サービスプロバイダは、いくつかのMPLS関連のMIBモジュールを使用して、ネットワークの出口にLSRからのトラフィックを測定することができ、例えば、（セクション4.9を参照）。他のインタフェースも存在し、ネットワーク内のどこからどこへ移動しているどのくらいのトラフィックを知ることができるように、トラフィック行列の作成を可能にしてもよいです。
Analysis of traffic flows to produce a traffic matrix is more complicated where P2MP LSPs are deployed because there is no simple pairing relationship between an ingress and a single egress. Fundamental to understanding traffic flows within a network that supports P2MP LSPs will be the knowledge of where the traffic is branched for each LSP within the network, that is, where within the network the branch nodes for the LSPs are located and what their relationship is to links and other LSRs. Traffic flow and accounting tools MUST take this fact into account.
トラフィックの分析は、トラフィック行列を生成するために流れ、入口と単一の出口との間の単純なペアリング関係がないため、P2MPのLSPのが展開される場合、より複雑です。トラフィックを理解するための基本は、ネットワーク内のLSPのためのブランチノードが配置されている場所、トラフィックがネットワーク内の各LSPのために分岐している場所の知識となり、それは、あるP2MP LSPをサポートするネットワーク内を流れると何の関係がにありますリンクや他のLSR。トラフィックフローと会計ツールは、アカウントにこの事実を取る必要があります。
This document introduces no new security issues compared with [RFC4377]. It is worth highlighting, however, that any tool designed to satisfy the requirements described in this document MUST include provisions to prevent its unauthorized use. Likewise, these tools MUST provide a means by which an operator can prevent denial of service attacks if those tools are used in such an attack. LSP mis-merging is described in [RFC4377] where it is pointed out that it has security implications beyond simply being a network defect. It needs to be stressed that it is in the nature of P2MP traffic flows that any erroneous delivery (such as caused by LSP mis-merging) is likely to have more far-reaching consequences since the traffic will be mis-delivered to multiple receivers.
この文書では、[RFC4377]と比較して新たなセキュリティ問題を紹介しません。それは、この文書に記載されている要件を満たすように設計されたツールは、その不正使用を防止するための規定を含まなければならないこと、しかし、強調し価値があります。同様に、これらのツールは、これらのツールは、このような攻撃に使用されている場合、オペレータは、サービス拒否（DoS）攻撃を防ぐことができる手段を提供しなければなりません。 LSP誤マージは、単にネットワーク欠陥である超えてセキュリティに影響を有することが指摘されている[RFC4377]に記載されています。 P2MPトラフィックの自然の中で任意の誤った配送が（LSP誤合併によって引き起こされるような）トラフィックが複数の受信者に誤配信されますので、より遠大な影響を持っている可能性があることを流れていることを強調する必要があります。
As with the OAM functions described in [RFC4377], the performance of diagnostic functions and path characterization may involve the extraction of a significant amount of information about network construction. The network operator MAY consider this information private and wish to take steps to secure it, but further, the volume of this information may be considered as a threat to the integrity of the network if it is extracted in bulk. This issue may be greater in P2MP MPLS because of the potential for a large number of receivers on a single LSP and the consequent extensive path of the LSP.
[RFC4377]に記載のOAM機能を有するように、診断機能および経路の特性の性能は、ネットワーク構成に関する情報のかなりの量の抽出を含むことができます。ネットワークオペレータは、プライベート、この情報を考慮し、それを確保するための措置をとることを望むが、それが大量に抽出された場合は、さらに、この情報の量は、ネットワークの整合性に対する脅威とみなすことができるかもしれません。この問題は、単一のLSPとLSPの結果として広範囲の経路上の受信機の多数の潜在的なのP2MP MPLSに大きくてもよいです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4377] 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.
[RFC4377]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島は、RFC 4377 "操作とマルチプロトコルラベルの管理（OAM）要件（MPLS）ネットワークのスイッチ" 、2006年2月。
[MCAST-LDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, June 2006.
[MCAST-LDP] Minei、I.、エド。、Kompella、K.、Wijnands、I.、エド。、およびB.トーマス、「ラベル配布プロトコルの拡張ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルスイッチドパス」、進歩、2006年6月での作業。
[P2MP-LSP-PING] Yasukawa, S., Farrel, A., Ali, Z., and B. Fenner, "Detecting Data Plane Failures in Point-to-Multipoint MPLS Traffic Engineering - Extensions to LSP Ping", Work in Progress, April 2006.
[P2MP-LSP-PING]安川、S.、ファレル、A.、アリ、Z.、およびB.フェナー、 "ポイントツーマルチポイントMPLSトラフィックエンジニアリングでの検出データプレーン障害 - LSP pingに拡張機能"、での作業進捗状況、2006年4月。
[P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to RSVP-TE for Point to Multipoint TE LSPs", Work in Progress, July 2006.
[P2MP-RSVP]アガルワル、R.、Papadimitriou、D.、およびS.安川、進歩、2006年7月で仕事を "拡張機能は、TE LSPをポイントツーマルチポイントのため-TEをRSVPに"。
[RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", RFC3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.およびT.ナドー、 "SMIv2のを使用したMPLSトラフィックエンジニアリング管理情報ベース"、RFC3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", RFC3813, June 2004.
[RFC3813]スリニバサン、C.、Viswanathanの、A.およびT.ナドー、RFC3813、2004年6月の "MPLSラベルスイッチルータの管理情報ベースはSMIv2の使用" を参照してください。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", RFC3814, June 2004.
[RFC3814]ナドー、T.、スリニバサン、C.、およびA. Viswanathanの、 "マルチプロトコルラベルスイッチング（MPLS）FEC-TO-NHLFE（FTN）管理情報ベース"、RFC3814、2004年6月。
[RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J., "Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] Cucchiara、J.、Sjostrand、H.、およびルチアーニ、J.は、 "マルチプロトコルラベルのための管理オブジェクトの定義は、スイッチング（MPLS）、ラベル配布プロトコル（LDP）"、RFC 3815、2004年6月。
[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378]アラン、D.とT.ナドー、RFC 4378、2006年2月 "マルチプロトコルラベルスイッチング（MPLS）操作と管理（OAM）のためのフレームワーク"。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K.とG.ツバメ、2006年2月、RFC 4379 "を検出マルチプロトコルラベルは（MPLS）データプレーン障害をスイッチ"。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461]安川、S.、エド。、2006 4月には、RFC 4461、「ポイントツーマルチポイントトラフィック・エンジニアMPLSラベルのためのシグナリング要件は、スイッチパス（LSP）」。
The authors wish to acknowledge and thank the following individuals for their valuable comments on this document: Rahul Aggarwal, Neil Harrison, Ben Niven-Jenkins, and Dimitri Papadimitriou.
著者は認識したいと、このドキュメントの彼らの貴重なコメントのために以下の個人に感謝：ラウール・アガーウォール、ニールハリソン、ベン・ニーヴン・ジェンキンス、およびディミトリPapadimitriou。
Authors' Addresses
著者のアドレス
Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
せいしょ やすかわ んっｔ こｒぽらちおん （Ｒ＆Ｄ Ｓｔらてｇｙ でぱｒｔめんｔ） ３ー１、 おてまち ２ーちょめ ちよだく、 ときょ １００ー８１１６ じゃぱん
Phone: +81 3 5205 5341 EMail: s.yasukawa@hco.ntt.co.jp
電話：+81 3 5205 5341 Eメール：s.yasukawa@hco.ntt.co.jp
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
電話：+44（0）1978 860944 Eメール：adrian@olddog.co.uk
Daniel King Aria Networks Ltd.
ダニエル・キングアリアネットワークス株式会社
Phone: +44 (0)1249 665923 EMail: daniel.king@aria-networks.com
電話：+44（0）1249 665923 Eメール：daniel.king@aria-networks.com
Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
トーマスD.ナドー、シスコシステムズ、株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719
EMail: tnadeau@cisco.com
メールアドレス：tnadeau@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。