[要約] 要約：RFC 4687は、ポイントツーマルチポイントMPLSネットワークのためのOAM（Operations and Management）要件について説明しています。 目的：このRFCの目的は、ポイントツーマルチポイントMPLSネットワークにおけるOAMの重要性を強調し、適切な要件を定義することです。
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
ポイントツーマルチポイントMPLSネットワークの運用と管理（OAM）要件
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).
Copyright（c）The Internet Society（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 LSPSと同様に、コントロールとデータプレーンの欠陥を検出、処理、診断する要件が重要です。
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.
このドキュメントでは、ポイントツーマルチポイント（P2MP）マルチプロトコルラベルスイッチング（MPLS）のデータプレーン操作と管理（OAM）の要件について説明します。このドキュメントは、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の要件は、ポイントツーポイントMPLの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 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
CE：顧客エッジDOS：サービス拒否ECMP：等しいコストマルチパスLDP：ラベル分布プロトコルLSP：ラベルスイッチングパスLSR：ラベルスイッチングルーターOAM：オペレーションと管理RSVP：リソース予約プロトコルP2MP：ポイントツーマルチポイント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.
このドキュメントは、これらの実現に基づいて構築され、MPLS OAM要件のステートメントを拡張して、P2MP MPLSの新しい領域をカバーします。つまり、このドキュメントは、特定のソリューションの開発に先立って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]のポイントツーポイントMPLについて説明した要件と類似しています。以下のサブセクションは[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には複数の出口があり、それらの出口へのパスはおそらく線形ではないでしょう（たとえば、木の構造がある場合があります）。単一のP2MP LSPの出口の数は不明であり、少数に縛られていないため、OAMサポートのために定義されたすべてのメカニズムは、LSPの経路の数と複雑さの複雑さで十分にスケーリングする必要があります。個々の出口に対処できるメカニズムは、ポイントツーポイントLSPの同様のメカニズムよりも悪化することはありませんが、多重出力が単一の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の欠陥を検出する機能は、そのLSPのトラフィックを切り替えるために使用される各LSRの手動、ホップバイホップのトラブルシューティングを必要としないはずであり、プロアクティブなOAM手順（継続的なパス接続とサービスレベルの合意などに依存する必要があります）測定メカニズム）。ソリューションは、[RFC4379]で指定されたものなど、このセクションの他の要件と矛盾しない[RFC4379]で指定されたものなど、ポイントツーポイントMPLのために開発された既存のソリューションと密接に連携して拡張または拡張または連携する必要があります。これにより、既存のソフトウェアとハードウェアの展開が活用されます。
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は、[RFC4379]などのツールによってLSPプロービングに追加のスケーリング懸念を導入する可能性があることに注意してください。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.
PATH特性評価関数[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.
E / A---B---C===D \ F
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.
図1. Cのデータパスと制御プレーン状態の分岐点であるが、Dのトポロジー分岐の例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.
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.
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よりも多くのアラームを引き起こす単一の障害の可能性ももたらします。これは、下流の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.
[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 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に適用される特定のOAM技術に固有のスケーラビリティ問題に適用される可能性のあるソリューションに影響することに注意してください。たとえば、何らかの形のプローブ要求に同時に応答する多数の出力の問題の解決策は、プローブの頻度を減らすことである可能性がありますが、これは障害を検出および/または報告する能力に影響する可能性があります。
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.
出口への障害通知が必要な場合、単一の障害が複数の通知を引き起こす可能性があります。すべてのメカニズムは、このスケーリングの問題を管理しながら、タイムリーに障害通知を提供し続ける必要があります。
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.
[RFC4377]で表現された要件と同じ要件は、障害の顧客検出に先立って自動修理およびオペレーターの介入に関してP2MP LSPに適用されます。
It should be observed that faults in P2MP LSPs MAY be recovered through techniques described in [P2MP-RSVP].
[P2MP-RSVP]に記載されている手法を通じて、P2MP LSPの障害が回収される可能性があることを観察する必要があります。
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関連MIBS [RFC3812]、[RFC3813]、[RFC3814]、[RFC3815]、[RFC3814]、[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 LSPSの適用を利用します。それらを拡張すると、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.
サービス拒否（DOS）を検出する能力（DOS）は、P2MP LSPSを信号するデータまたはコントロールプレーンに対して攻撃し、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が展開される場合、より複雑です。P2MP LSPをサポートするネットワーク内のトラフィックフローを理解するための基本は、ネットワーク内の各LSPのトラフィックが分岐する場所、つまりネットワーク内で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]と比較して新しいセキュリティの問題はありません。ただし、このドキュメントに記載されている要件を満たすために設計されたツールには、不正使用を防ぐための規定を含める必要があることを強調する価値があります。同様に、これらのツールは、そのような攻撃でそれらのツールが使用されている場合、オペレーターがサービス攻撃の拒否を防ぐことができる手段を提供する必要があります。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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「オペレーションと管理（OAM）要件マルチプロトコルラベルスイッチ（MPLS）ネットワーク」、RFC 4377、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.
[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] Yasukawa、S.、Farrel、A.、Ali、Z。、およびB. Fenner、「ポイントツーマルチポイント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] Aggarwal、R.、Papadimitriou、D。、およびS. Yasukawa、「Point to Multipoint Te LSPのRSVP-TEへの拡張」、2006年7月、進行中の作業。
[RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2", RFC3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「MPLS Traffic Engineering Management Information Base base」、RFC3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A. and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2", RFC3813, June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「MPLS Label Switchルーター管理情報ベースをSMIV2を使用した」、RFC3813、2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base", RFC3814, June 2004.
[RFC3814] Nadeau、T.、Srinivasan、C。、およびA. Viswanathan、「Multiprotocol Label Switching（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。、およびLuciani、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.ナドー、「マルチプロトコルラベルスイッチング（MPLS）運用および管理（OAM）のフレームワーク」、RFC 4378、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006.
[RFC4379] Kompella、K。およびG. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] Yasukawa、S.、ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
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.
著者は、この文書に関する貴重なコメントについて、次の個人に認め、感謝したいと考えています：Rahul Aggarwal、Neil Harrison、Ben Niven-Jenkins、およびDimitri Papadimitriou。
Authors' Addresses
著者のアドレス
Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Seisho Yasukawa NTT Corporation（R＆D戦略部）3-1、Otemachi 2-Chome Chiyodaku、東京100-8116日本
Phone: +81 3 5205 5341
EMail: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Daniel King Aria Networks Ltd.
ダニエルキングアリアネットワークスLtd.
Phone: +44 (0)1249 665923
EMail: daniel.king@aria-networks.com
Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
Thomas D. Nadeau Cisco Systems、Inc。1414 Massachusetts Ave. Boxborough、MA 01719
EMail: tnadeau@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。