Network Working Group T. Nadeau
Request for Comments: 4377 M. Morrow
Category: Informational G. Swallow
Cisco Systems, Inc.
D. Allan
Nortel Networks
S. Matsushima
Japan Telecom
February 2006
Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (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
抽象
This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.
この文書は（MPLS）をマルチプロトコルラベルスイッチングのための操作と管理（OAM）要件を指定し、ならびにそのような擬似ワイヤ音声および仮想プライベートネットワークサービスとしてMPLSの用途のために。これらの要件は、MPLSネットワークを展開豊富な経験を持っているネットワークオペレータから収集されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Document Conventions ............................................2
3. Motivations .....................................................4
4. Requirements ....................................................4
5. Security Considerations ........................................11
6. References .....................................................12
7. Acknowledgements ...............................................13
This document describes requirements for user and data plane Operations and Management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This document specifies OAM requirements for MPLS, as well as for applications of MPLS.
この文書では、マルチプロトコルラベルスイッチングのためのユーザーとデータプレーン運用及び管理（OAM）の要件について説明します（MPLS）。これらの要件は、MPLSネットワークを展開豊富な経験を持っているネットワークオペレータから収集されています。この文書では、MPLSのためだけでなく、MPLSのアプリケーションのためのOAM要件を指定します。
Currently, there are no specific mechanisms proposed to address these requirements. The goal of this document is to identify a commonly applicable set of requirements for MPLS OAM at this time. Specifically, a set of requirements that apply to the most common set of MPLS networks deployed by service provider organizations at the time this document was written. These requirements can then be used as a base for network management tool development and to guide the evolution of currently specified tools, as well as the specification of OAM functions that are intrinsic to protocols used in MPLS networks.
現在、これらの要件に対処するために提案されている具体的なメカニズムは存在しません。このドキュメントの目標は、この時点でMPLS OAMのための要件の一般的に適用可能なセットを識別することです。具体的には、この文書が書かれた時点で、サービスプロバイダ機関によって展開MPLSネットワークの最も一般的なセットに適用される要件のセット。これらの要件は、ネットワーク管理ツールの開発のためのベースとして使用することができ、現在指定されたツールの進化だけでなく、MPLSネットワークで使用されるプロトコルに固有の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 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Queuing/buffering Latency: The delay caused by packet queuing (value is variable since it is dependent on the packet arrival rate, the packet length, and the link throughput).
キューイング/バッファリング遅延：パケットキューイングによる遅延（これはパケット到着率、パケット長、リンクのスループットに依存しているので、値は可変です）。
Probe-based-detection: Active measurement tool that can measure the consistency of an LSP [RFC4379].
プローブベースの検出：LSP [RFC4379]の整合性を測定することができるアクティブな測定ツール。
Defect: Any error condition that prevents a Label Switched Path (LSP) from functioning correctly. For example, loss of an Interior Gateway Protocol (IGP) path will most likely result in an LSP not being able to deliver traffic to its destination. Another example is the interruption of the path for a TE tunnel. These may be due to physical circuit failures or failure of switching nodes to operate as expected.
欠陥：正常に機能してからラベルスイッチパス（LSP）を防止する任意のエラー状態。例えば、内部ゲートウェイプロトコル（IGP）パスの損失は、LSPの中で最も可能性の高い結果がその宛先にトラフィックを配信することができないだろう。別の例では、TEトンネルのパスの中断です。これらは、物理的な回線障害や予想通り動作するようにスイッチングノードの故障に起因し得ます。
Multi-vendor/multi-provider network
operation typically requires agreed upon
definitions of defects (when it is broken
and when it is not) such that both
recovery procedures and service level
specification impact can be specified.
Head-end Label Switching Router (LSR): The beginning of an LSP. A head-end LSR is also referred to as an ingress LSR.
ヘッドエンドラベルスイッチングルータ（LSR）：LSPの始まり。ヘッドエンドLSRはまた、入口LSRと呼ばれます。
Tail-end Label Switching Router (LSR): The end of an LSP. A tail-end LSR is also referred to as an egress LSR.
テールエンドラベルスイッチングルータ（LSR）：LSPの終わり。テールエンドLSRはまた、出口LSRと呼ばれます。
Propagation Latency: The delay added by the propagation of the packet through the link (fixed value that depends on the distance of the link and the propagation speed).
伝搬遅延：（リンクの距離と伝播速度に依存する固定値）リンクを介してパケットの伝搬によって追加遅延。
Transmission Latency: The delay added by the transmission of the packet over the link, i.e., the time it takes to put the packet over the media (value that depends on the link throughput and packet length).
送信待ち時間：リンク上のパケットの伝送によって追加遅延、即ち、それはメディア（リンクスループットとパケット長に依存する値）を介してパケットを置くのに要する時間。
Processing Latency: The delay added by all the operations related to the switching of labeled packets (value is node implementation specific and may be considered fixed and constant for a given type of equipment).
処理レイテンシ：標識されたパケットのスイッチングに関連するすべての操作によって追加された遅延（値が特定のノードの実装であり、装置の指定された型の固定と定数と見なすことができます）。
Node Latency: The delay added by the network element resulting from of the sum of the transmission, processing, and queuing/buffering latency.
ノードのレイテンシ：送信、処理、及びキューイング/バッファリング待ち時間の和の起因するネットワーク要素によって追加遅延。
One-hop Delay: The fixed delay experienced by a packet to reach the next hop resulting from the of the propagation latency, the transmission latency, and the processing latency.
ワンホップ遅延：伝播遅延、伝送遅延、処理遅延の起因ネクストホップに到達するパケットが経験する固定遅延。
Minimum Path Latency: The sum of the one-hop delays experienced by the packet when traveling from the ingress to the egress LSR.
最小パスのレイテンシ：出口LSRへの侵入からの旅行の際のパケットによって経験された1ホップ遅延の合計。
Variable Path Latency: The variation in the sum of the delays experienced by packets transiting the path, otherwise know as jitter.
変数パスのレイテンシ：パスを通過するパケットが経験する遅延の合計の変動、そうでないジッタとして知っています。
ASBR: Autonomous System Border Router
ASBR：自律システム境界ルータ
CE: Customer Edge
CE：カスタマーエッジ
PE: Provider Edge
PE：プロバイダーエッジ
SP: Service Provider
SP：サービスプロバイダ
ECMP: Equal-Cost Multi-path
ECMP：等価コストマルチパス
LSP: Label Switched Path
LSP：ラベルスイッチパス
LSP Ping: Label Switched Path Ping
LSPのPing：ラベルスイッチパスのPing
LSR: Label Switching Router
LSR：ラベルスイッチングルータ
OAM: Operations and Management
OAM：運用と管理
RSVP: Resource reSerVation Protocol
RSVP：リソース予約プロトコル
LDP: Label Distribution Protocol
LDP：ラベル配布プロトコル
DoS: Denial of Service
DoS攻撃：サービス拒否
This document was created to provide requirements that could be used to create consistent and useful OAM functionality that meets operational requirements of those service providers (SPs) who have deployed or are deploying MPLS.
この文書は、展開しているか、MPLSを展開しているそれらのサービス・プロバイダ（SPS）の動作要件を満たして一貫性のある便利なOAM機能を作成するために使用できる要件を提供するために作成されました。
The following sections enumerate the OAM requirements gathered from service providers who have deployed MPLS and services based on MPLS networks. Each requirement is specified in detail to clarify its applicability. Although the requirements specified herein are defined by the IETF, they have been made consistent with requirements gathered by other standards bodies such as the ITU [Y1710].
次のセクションでは、MPLSネットワークに基づくMPLSおよびサービスを展開しているサービスプロバイダから収集OAM要件を列挙します。各要件は、その適用性を明確にするために詳細に指定されています。ここ指定された要件は、IETFによって定義されていますが、それらは、このようなITU [Y1710]など、他の標準化団体によって集められた要件に合致行われています。
The ability to detect defects in a broken LSP MUST not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP. For example, it is not desirable to manually visit each LSR along the data plane path transited by an LSP; instead, this function MUST be automated and able to be performed at some operator specified frequency from the origination point of that LSP. This implies solutions that are interoperable to allow for such automatic operation.
壊れたLSPの欠陥を検出する能力は、各LSRの手動ホップバイホップトラブルシューティングを必要としてはならないことLSPのトラフィックを切り替えるために使用されます。例えば、手動LSPによって遷移データプレーンパスに沿って各LSRを訪問することは望ましくありません。代わりに、この機能は、自動化され、そのLSPの起点からの周波数指定いくつかのオペレータで行うことができなければなりません。これは、このような自動運転を可能にするために相互運用可能なソリューションを意味します。
Furthermore, the automation of path liveliness is desired in cases where large numbers of LSPs might be tested. For example, automated ingress LSR to egress LSR testing functionality is desired for some LSPs. The goal is to detect LSP path defects before customers do, which requires detection and correction of LSP defects in a manner that is both predictable and within the constraints of the service level agreement under which the service is being offered. Simply put, the sum of the time it takes an OAM tool to detect a defect and the time needed for an operational support system to react to this defect, by possibly correcting it or notifying the customer, must fall within the bounds of the service level agreement in question.
また、パス活気の自動化は、LSPの多数は、試験される可能性がある場合に望ましいです。例えば、出口LSRテスト機能に自動化された入口LSRは、いくつかのLSPのために望まれています。目標は、予測可能なサービスが提供されているその下でサービスレベル契約の制約内でもある方法でLSP欠陥の検出と訂正を必要とする、顧客が行う前に、LSPパスの欠陥を検出することです。簡単に言えば、時間の合計は、それが欠陥を検出するOAMツールをとり、この欠陥に対処するための運用支援システムに必要な時間は、おそらくそれを修正するか、顧客に通知することにより、サービスレベルの範囲内に入らなければなりません問題の合意。
Synchronization of detection time bounds by tools used to detect broken LSPs is required. Failure to specify defect detection time bounds may result in an ambiguity in test results. If the time to detect broken LSPs is known, then automated responses can be specified with respect and regard to resiliency and service level specification reporting. Further, if synchronization of detection time bounds is possible, an operational framework can be established to guide the design and specification of MPLS applications.
壊れたLSPを検出するのに使用されるツールによる検出時間の境界の同期が必要とされます。欠陥検出時間範囲を指定しないと、テスト結果の曖昧さをもたらすことができます。壊れたLSPを検出するための時間が知られている場合は、自動化された応答は尊重し、弾力性とサービスレベル仕様の報告に関連して指定することができます。検出時間境界の同期が可能であればさらに、動作フレームワークは、MPLSアプリケーションの設計および仕様を導くために確立することができます。
Although an ICMP-based ping [RFC792] can be sent through an LSP as an IP payload, the use of this tool to verify the defect-free operation of an LSP has the potential of returning erroneous results (both positive and negative) for a number of reasons. For example, in some cases, because the ICMP traffic is based on legally addressable IP addressing, it is possible for ICMP messages that are originally transmitted inside of an LSP to "fall out of the LSP" at some point along the path. In these cases, since ICMP packets are routable, a falsely positive response may be returned. In other cases, where the data plane of a specific LSP needs to be tested, it is difficult to guarantee that traffic based on an ICMP ping header is parsed and hashed to the same equal-cost multi-paths (ECMP) as the data traffic.
ICMPベースのpingが[RFC792] IPペイロードとしてLSPを介して送信することができるが、LSPの欠陥のない動作を確認するために、このツールの使用がため（正と負の両方）誤った結果を返す可能性を有しますいくつかの理由。例えば、いくつかのケースでは、ICMPトラフィックは合法的にアドレス可能なIPアドレッシングに基づいているため、それがもともとのパスに沿っていくつかの点で、「LSPから落ちる」するLSPの内側に送信されたICMPメッセージのために可能です。 ICMPパケットがルーティング可能であるため、これらの場合では、偽陽性応答が返されてもよいです。特定LSPのデータプレーンを試験する必要がある他の場合には、ICMPピングヘッダに基づいてトラフィックを解析し、データトラフィックと同じ等価コストマルチパス（ECMP）にハッシュされることを保証することは困難です。
Any detection mechanisms that depend on receiving the status via a return path SHOULD provide multiple return options with the expectation that one of them will not be impacted by the original defect. An example of a case where a false negative might occur would be a mechanism that requires a functional MPLS return path. Since MPLS LSPs are unidirectional, it is possible that although the forward LSP, which is the LSP under test, might be functioning, the response from the destination LSR might be lost, thus giving the source LSR the false impression that the forward LSP is defective. However, if an alternate return path could be specified -- say IP for example -- then the source could specify this as the return path to the destination, and in this case, would receive a response indicating that the return LSP is defective.
リターンパスを介して受信状態に依存する検出メカニズムは、それらの一つは、元の欠陥によって影響されないことを期待して、複数のリターン・オプションを提供すべきです。偽陰性が発生する可能性がある場合の例は、機能MPLSリターンパスを必要とする機構であろう。 MPLSのLSPが単方向であるので、被試験LSPを順方向LSPは、機能するかもしれないが、先のLSRからの応答を前方LSPが不良であること、したがってソースLSRに誤った印象を与え、失われる可能性があることが可能です。代替リターンパスを指定することができた場合は、 - 例えば、IPを言う - 、ソースは目的地までのリターンパスとしてこれを指定することができ、この場合には、リターンLSPに欠陥があることを示す応答を受信します。
The OAM packet MUST follow the customer data path exactly in order to reflect path liveliness used by customer data. Particular cases of interest are forwarding mechanisms, such as ECMP scenarios within the operator's network, whereby flows are load-shared across parallel paths (i.e., equal IGP cost). Where the customer traffic may be spread over multiple paths, the ability to detect failures on any of the path permutations is required. Where the spreading mechanism is payload specific, payloads need to have forwarding that is common with the traffic under test. Satisfying these requirements introduces complexity into ensuring that ECMP connectivity permutations are exercised and that defect detection occurs in a reasonable amount of time.
OAMパケットは正確に顧客データが使用するパスの活気を反映するために、顧客データ・パスに従わなければなりません。フローは、負荷共有パラレルパス間（すなわち、等しいIGPコスト）であることにより、関心のある特定の場合には、オペレータのネットワーク内でこのようなECMPシナリオなどのメカニズムを、転送しています。顧客のトラフィックが複数のパスを介して拡散される場合は、パスの順列のいずれかに障害を検出する能力が必要とされます。拡散メカニズムは、ペイロード固有である場合には、ペイロードは、テスト対象のトラフィックと共通である転送を持っている必要があります。これらの要件を満たすことECMP接続順列が行使され、その欠陥検出が妥当な時間内に発生することを確実に複雑さを導入します。
The ability to diagnose a broken LSP and to isolate the failed component (i.e., link or node) in the path is required. For example, note that specifying recovery actions for mis-branching defects in an LDP network is a particularly difficult case. Diagnosis of defects and isolation of the failed component is best accomplished via a path trace function that can return the entire list of LSRs and links used by a certain LSP (or at least the set of LSRs/links up to the location of the defect). The tracing capability SHOULD include the ability to trace recursive paths, such as when nested LSPs are used. This path trace function MUST also be capable of diagnosing LSP mis-merging by permitting comparison of expected vs. actual forwarding behavior at any LSR in the path. The path trace capability SHOULD be capable of being executed from the head-end Label Switching Router (LSR) and may permit downstream path components to be traced from an intermediate mid-point LSR. Additionally, the path trace function MUST have the ability to support ECMP scenarios described in Section 4.1.
壊れたLSPを診断し、パスに障害が発生した成分（すなわち、リンクまたはノード）を単離する能力が必要とされます。例えば、LDPネットワークにおける誤分岐欠陥の回復アクションを指定することに注意することは特に困難なケースです。欠陥や故障した成分の単離の診断は、最良の特定のLSP（又は欠陥の位置までのLSR /リンクの少なくともセット）で使用されるのLSRとリンクの全体のリストを返すことができ、パストレース機能を介して達成されます。 。トレース機能は、ネストされたLSPが使用される場合のように再帰的な経路を追跡する能力を含むべきです。このパストレース機能は、経路内の任意のLSRでの実際の転送動作対予想の比較を可能にすることによって、LSP誤マージを診断することができなければなりません。パストレース機能は、ヘッドエンドラベルスイッチングルータ（LSR）から実行されることが可能であるべきであり、中間中点LSRから追跡される下流経路の構成要素を可能にすることができます。また、パストレース機能は、4.1節で説明したECMPシナリオをサポートする能力を持たなければなりません。
The path characterization function is the ability to reveal details of LSR forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. This includes but is not limited to:
パスの特性関数は、LSR転送動作の詳細を明らかにする能力です。これらの詳細は、OAM機能に関連するその後のテスト中に比較することができます。これには、これらに限定されません。
- consistent use of pipe or uniform time to live (TTL) models by an LSR [RFC3443].
- パイプ又はLSR [RFC3443]によって（TTL）モデルを生きるために、均一な時間の一貫した使用。
- sufficient details that allow the test origin to exercise all path permutations related to load spreading (e.g., ECMP).
- 試験起源（例えば、ECMP）を拡散ロードに関連するすべてのパスの順列を行使できるように十分詳細。
- stack operations performed by the LSR, such as pushes, pops, and TTL propagation at penultimate hop LSRs.
- 例えば、プッシュポップ、および最後から二番目のホップのLSRでTTL伝播としてLSRによって実行されるスタック操作、。
Mechanisms are required to measure the diverse aspects of Service Level Agreements, which include:
メカニズムを含めるサービスレベル契約の多様な側面を測定するのに必要とされています。
- latency - amount of time required for traffic to transit the network
- レイテンシー - トランジットネットワークへのトラフィックのために必要な時間
- packet loss
- パケットロス
- jitter - measurement of latency variation
- ジッタ - 待ち時間の変動の測定
- defect free forwarding - the service is considered to be available, or the service is unavailable and other aspects of performance measurement do not have meaning.
- 欠陥のないフォワーディング - サービスが利用可能であると考えられ、またはサービスが利用できないとパフォーマンス測定の他の態様は意味を持ちませんさ。
Such measurements can be made independently of the user traffic or via a hybrid of user traffic measurement and OAM probing.
そのような測定は、独立にユーザトラフィックまたはユーザトラフィック測定及びOAMプローブのハイブリッドを介して行うことができます。
At least one mechanism is required to measure the number of OAM packets. In addition, the ability to measure the quantitative aspects of LSPs, such as jitter, delay, latency, and loss, MUST be available in order to determine whether the traffic for a specific LSP is traveling within the operator-specified tolerances.
少なくとも一つのメカニズムは、OAMパケットの数を測定する必要があります。また、このようなジッタ、遅延、待ち時間、損失などのLSPの量的な側面を測定する能力は、特定のLSPのトラフィックは、オペレータが指定した許容範囲内で走行しているかどうかを決定するために利用可能でなければなりません。
Any method considered SHOULD be capable of measuring the latency of an LSP with minimal impact on network resources. See Section 2.1 for definitions of the various quantitative aspects of LSPs.
考え任意の方法は、ネットワークリソースへの影響を最小限に抑えながらLSPの待ち時間を測定することができなければなりません。 LSPの様々な定量的な側面の定義については、セクション2.1を参照してください。
The operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements.
オペレータは、特定の業務要件を満たすためにOAMパラメータを設定するための柔軟性を持たなければなりません。
This includes the frequency of the execution of any OAM functions. The ability to synchronize OAM operations is required to permit a consistent measurement of service level agreements. To elaborate, there are defect conditions, such as mis-branching or misdirection of traffic, for which probe-based detection mechanisms that incur significant mismatches in their detection frequency may result in flapping. This can be addressed either by synchronizing the rate or having the probes self-identify their probe rate. For example, when the probing mechanisms are bootstrapping, they might negotiate and ultimately agree on a probing rate, therefore providing a consistent probing frequency and avoiding the aforementioned problems.
これは、任意のOAM機能の実行頻度を含んでいます。 OAM動作を同期させる能力は、サービス・レベル・アグリーメントの一貫した測定を可能にするために必要とされます。詳述すると、それらの検出頻度に有意な不一致が発生プローブベースの検出メカニズムがフラッピングをもたらす可能性があるため、このような誤分岐またはトラフィックの誤った方向として欠陥条件があります。これは、速度を同期またはプローブは、それらのプローブ速度を自己識別有するいずれかによって対処することができます。したがって、一貫性のプロービング周波数を提供し、前述の問題を避け、プロービングメカニズムがブートストラップされたときに、例えば、彼らは交渉可能性があり、最終的には、プロービングレートに同意するものとします。
One observation would be that wide-spread deployment of MPLS, common implementation of monitoring tools, and the need for inter-carrier synchronization of defect and service level specification handling will drive specification of OAM parameters to commonly agreed on values. Such values will have to be harmonized with the surrounding technologies (e.g., SONET/SDH, ATM) to be useful. This will become particularly important as networks scale and mis-configuration can result in churn, alarm flapping, etc.
一つの観察は、MPLSの広範な展開、監視ツールの一般的な実装となり、欠陥およびサービスレベルの仕様の取り扱いのキャリア間の同期化の必要性は、一般的な値に合意するOAMパラメータの仕様を駆動します。そのような値が有用である（例えば、SONET / SDH、ATM）周囲の技術と調和しなければなりません。ネットワークの規模や設定ミスが解約、アラームフラッピングなどにつながることができますので、これは特に重要になります
Network elements MUST provide alarm suppression functionality that prevents the generation of a superfluous generation of alarms by simply discarding them (or not generating them in the first place), or by aggregating them together, thereby greatly reducing the number of notifications emitted. When viewed in conjunction with the requirement in Section 4.7 below, this typically requires fault notification to the LSP egress that may have specific time constraints if the application using the LSP independently implements path continuity testing (for example, ATM I.610 Continuity check (CC)[I610]). These constraints apply to LSPs that are monitored. The nature of MPLS applications allows for the possibility of having multiple MPLS applications attempt to respond to defects simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic Engineered tunnels where a failure occurs on the LSP carrying the Traffic Engineered tunnel. This failure would affect the VPN traffic that uses the tunnel's LSP. Mechanisms are required to coordinate network responses to defects.
ネットワーク要素は大幅放出された通知の数を減少させる、単にそれらを廃棄（または最初の場所でそれらを生成しない）によって、またはそれらを集約することによってアラームの余分な世代の発生を防止アラーム抑制機能を提供しなければなりません。以下のセクション4.7に要件と併せて見た場合、これは、典型的には、ATM I.610導通チェック（CCをLSPを使用するアプリケーションは、独立して、（例えばパス導通試験を実装する場合、特定の時間制約を有していてもよいLSPの出口に障害通知を必要とします）[I610]）。これらの制約は監視されているのLSPに適用されます。 MPLSアプリケーションの性質は、例えば、複数のMPLSアプリケーションが同時に欠陥に対応しようとする障害がトラヒックエンジニアリングトンネルを運ぶLSPで発生トラヒックエンジニアリングトンネルを利用するレイヤ3 MPLS VPNを有する可能性を可能にします。この失敗は、トンネルのLSPを使用してVPNトラフィックに影響を与えます。メカニズムは、欠陥へのネットワーク応答を調整するために必要とされています。
An LSR supporting the inter-working of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. For example, errors occurring over an MPLS transport LSP that supports an emulated ATM VC MUST translate errors into native ATM OAM Alarm Indication Signal (AIS) cells at the termination points of the LSP. The mechanism SHOULD consider possible bounded detection time parameters, e.g., a "hold off" function before reacting to synchronize with the OAM functions.
MPLS上の1つ以上のネットワーク技術の相互作業をサポートするLSRはネイティブ技術のエラー条件にMPLS欠陥を変換することができなければなりません。例えば、エミュレートされたATM VCをサポートするMPLS輸送LSP上に発生したエラーは、LSPの終端点でネイティブATM OAMアラーム表示信号（AIS）細胞中にエラーを変換しなければなりません。メカニズムは、OAM機能と同期するように反応する前に、例えば、「オフホールド」機能を可能に有界検出時間パラメータを考慮すべきです。
One goal would be alarm suppression by the upper layer using the LSP. As observed in Section 4.5, this requires that MPLS perform detection in a bounded timeframe in order to initiate alarm suppression prior to the upper layer independently detecting the defect.
一つの目標は、LSPを使用して上位層でアラームの抑制になります。 4.5節で観察されたように、これは、MPLSは、独立して、欠陥を検出する上位層の前にアラーム抑制を開始するために制限された時間枠内で検出を行うことを必要とします。
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. These procedures will detect a broader range of defects than that of simple link and node failures. Since MPLS LSPs may span multiple routing areas and service provider domains, fault recovery and error detection should be possible in these configurations as well as in the more simplified single-area/domain configurations.
ネットワーク要素による障害からの回復は、MPLS OAM手順によって容易にすることができます。これらの手順は、単純なリンクとノードの障害よりも欠陥の広い範囲を検出します。 MPLSのLSPは、複数のルーティングエリアとサービスプロバイダドメインにまたがる可能性があるため、障害回復と誤り検出は、これらの構成においても、より簡略化された単一領域/ドメイン構成で可能であるべきです。
Recovery from faults SHOULD be automatic. It is a requirement that faults SHOULD be detected (and possibly corrected) by the network operator prior to customers of the service in question detecting them.
障害からの回復は自動的に行われるべきです。これは、障害の前にそれらを検出し、当該サービスの顧客にネットワークオペレータによって検出された（そしておそらく修正）するべきである要件です。
The wide-spread deployment of MPLS requires common information modeling of management and control of OAM functionality. Evidence of this is reflected in the standard IETF MPLS-related MIB modules (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to Operations and Management functions and their statuses. However, gaps in coverage of MIB modules to OAM and other features exist; therefore, MIB modules corresponding to new protocol functions or network tools are required.
MPLSの普及展開はOAM機能の管理および制御の一般的な情報モデリングが必要です。これの証拠は、障害、統計、および構成管理のための標準的なIETF MPLS-関連MIBモジュール（例えば、[RFC3813]、[RFC3812]、[RFC3814]）に反映されます。これらの標準インターフェースは、運用および管理機能とそのステータスに共通のプログラム・インタフェースへのアクセスをオペレータに提供しています。しかし、OAMおよびその他の機能にMIBモジュールのカバレッジにギャップが存在します。従って、新しいプロトコル機能やネットワークツールに対応するMIBモジュールが必要とされます。
The ability to detect denial of service (DoS) attacks against the data or control planes MUST be part of any security management related to MPLS OAM tools or techniques.
データまたは制御プレーンに対してサービス拒否（DoS）攻撃の拒否を検出する能力は、MPLS OAMツールや技術に関連するセキュリティ管理の一部でなければなりません。
In an MPLS network, service providers can measure traffic from an LSR to the egress of the network using some MPLS related MIBs, for example. This means that it is reasonable to know how much traffic is traveling from location to location (i.e., a traffic matrix) by analyzing the flow of traffic. Therefore, traffic accounting in an MPLS network can be summarized as the following three items:
MPLSネットワークでは、サービスプロバイダは、例えば、いくつかのMPLS関連のMIBを使用してネットワークの出口にLSRからのトラフィックを測定することができます。トラフィックのフローを分析することによって（すなわち、トラフィック行列）場所から場所に移動しているどのくらいのトラフィックを知ることが妥当であることを意味します。したがって、MPLSネットワーク内のトラフィックアカウンティングは、次の3つの項目としてまとめることができます。
(1) Collecting information to design network
（1）ネットワークを設計するための情報を収集
For the purpose of optimized network design, a service
provider may offer the traffic information. Optimizing
network design needs this information.
(2) Providing a Service Level Specification
（2）サービスレベルの仕様を提供
Providers and their customers MAY need to verify high-level
service level specifications, either to continuously optimize
their networks, or to offer guaranteed bandwidth services.
Therefore, traffic accounting to monitor MPLS applications is
required.
(3) Inter-AS environment
（3）インターAS環境
Service providers that offer inter-AS services require
accounting of those services.
These three motivations need to satisfy the following:
これらの三つの動機は、以下を満たす必要があります。
- In (1) and (2), collection of information on a per-LSP
basis is a minimum level of granularity for collecting
accounting information at both of ingress and egress of an
LSP.
- In (3), SP's ASBR carry out interconnection functions as an intermediate LSR. Therefore, identifying a pair of ingress and egress LSRs using each LSP is needed to determine the cost of the service that a customer is using.
- （3）において、SPのASBRは、中間LSRとして相互接続機能を実行します。したがって、各LSPを使用して入力および出力のLSRの対を同定すること、顧客が使用しているサービスのコストを決定するために必要とされます。
Accounting on a per-LSP basis encompasses the following set of functions:
毎LSPに基づいて会計処理機能の次のセットを包含する。
(1) At an ingress LSR, accounting of traffic through LSPs that begin at each egress in question.
（1）入口LSRでは、当該の各出口で始まるLSPを経由してトラフィックを占めています。
(2) At an intermediate LSR, accounting of traffic through LSPs for each pair of ingress to egress.
（2）中間LSRで、出口に入口の各ペアのためのLSPを介してトラフィックを占めています。
(3) At egress LSR, accounting of traffic through LSPs for each ingress.
（3）出口LSRでは、各イングレスのためのLSPを通過するトラフィックを占めています。
(4) All LSRs containing LSPs that are being measured need to have a common identifier to distinguish each LSP. The identifier MUST be unique to each LSP, and its mapping to LSP SHOULD be provided whether from manual or automatic configuration.
（4）測定されているLSPを含むすべてのLSRは、各LSPを区別するための共通の識別子を有する必要があります。識別子は、各LSPに対して一意である必要があり、そしてLSPへのマッピングは手動または自動設定からかどうかを提供されるべきです。
In the case of non-merged LSPs, this can be achieved by simply reading traffic counters for the label stack associated with the LSP at any LSR along its path. However, in order to measure merged LSPs, an LSR MUST have a means to distinguish the source of each flow so as to disambiguate the statistics.
非マージされたLSPの場合、これは単に、その経路に沿った任意のLSRにおいてLSPに関連付けられたラベルスタックのためのトラフィック・カウンタを読み取ることによって達成することができます。しかし、マージされたLSPを測定するために、LSRは、統計を明確にするように、各フローのソースを区別するための手段を持たなければなりません。
It is not realistic for LSRs to perform the described operations on all LSPs that exist in a network. At a minimum, per-LSP based accounting SHOULD be performed on the edges of the network -- at the edges of both LSPs and the MPLS domain.
LSRは、ネットワーク内に存在するすべてのLSPに記載された動作を実行することは現実的ではありません。最低でも、毎LSPベースの会計は、ネットワークのエッジ上で実行されるべきである - のLSPとMPLSドメインの両方のエッジで。
Provisions to any of the network mechanisms designed to satisfy the requirements described herein are required to prevent their unauthorized use. Likewise, these network mechanisms MUST provide a means by which an operator can prevent denial of service attacks if those network mechanisms are used in such an attack.
本明細書に記載の要件を満たすように設計されたネットワークメカニズムの任意の規定は、その不正使用を防止するために必要とされます。同様に、これらのネットワークのメカニズムは、それらのネットワークの仕組みは、このような攻撃に使用されている場合、オペレータは、サービス拒否（DoS）攻撃を防ぐことができる手段を提供しなければなりません。
LSP mis-merging has security implications beyond that of simply being a network defect. LSP mis-merging can happen due to a number of potential sources of failure, some of which (due to MPLS label stacking) are new to MPLS.
LSP誤合併は、単にネットワーク欠陥であることのそれを超えセキュリティへの影響を持っています。 LSP誤合併が障害の潜在的なソースの数に起こることができ、そのうちのいくつか（原因MPLSラベルスタックには）MPLSに新しいです。
The performance of diagnostic functions and path characterization involve extracting a significant amount of information about network construction that the network operator MAY consider private.
診断機能とパス特性の性能は、ネットワークオペレータがプライベート検討することができるネットワークの構築に関する大量の情報を抽出伴います。
[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月。
[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）データプレーン障害をスイッチ"。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812]スリニバサン、C.、Viswanathanの、A.、およびT.ナドー、 "マルチプロトコルラベルスイッチング（MPLS）トラフィックエンジニアリング（TE）管理情報ベース（MIB）"、RFC 3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004.
[RFC3813]スリニバサン、C.、Viswanathanの、A.、およびT.ナドーは、 "マルチプロトコルラベルスイッチング（MPLS）ラベルスイッチングルータ（LSR）管理情報ベース（MIB）"、RFC 3813、2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan, "Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)", RFC 3814, June 2004.
[RFC3814]ナドー、T.、スリニヴァサン、C.、およびA. Viswanathanの、 "マルチプロトコルラベルスイッチング（MPLS）、転送等価クラスへのネクストホップラベル転送エントリ（FEC-TO-NHLFE）管理情報ベース（MIB）"、RFC 3814、2004年6月。
[Y1710] ITU-T Recommendation Y.1710, "Requirements for OAM Functionality In MPLS Networks"
[Y1710] ITU-T勧告Y.1710、 "MPLSネットワークにおけるOAM機能のための要件"
[I610] ITU-T Recommendation I.610, "B-ISDN operations and maintenance principles and functions", February 1999
[I610] ITU-T勧告I.610、 "B-ISDNの操作とメンテナンスの原則と機能"、1999年2月
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443] Agarwalさん、P.とB. Akyol、 "（MPLS）ネットワークのマルチプロトコルラベルスイッチングにおける生存時間（TTL）処理"、RFC 3443、2003年1月。
The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr. Kumaki, KDDI. Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa, Intec Netcore, and David Meyer.
著者は認識したいと、この文書に彼らの貴重なコメントについて以下の個人感謝：エイドリアン・スミス、ブリティッシュテレコムを。チョウランポン、SBC;氏池尻、NTTコミュニケーションズ。氏熊木、KDDI。ハリRakotoranto、宮河野、シスコシステムズ、 Luyuan牙、AT＆T;ダニー・マクファーソン、TCB;博士ケン・永見、郁夫中川、インテック・ネットコア、およびデビッド・マイヤー。
Authors' Addresses
著者のアドレス
Comments should be made directly to the MPLS mailing list at mpls@lists.ietf.org.
コメントはmpls@lists.ietf.orgでMPLSメーリングリストに直接なされるべきです。
Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
トーマスD.ナドー、シスコシステムズ、株式会社300ビーバーブルックロードBoxboro、MA 01719
Phone: +1-978-936-1470 EMail: tnadeau@cisco.com
電話：+ 1-978-936-1470 Eメール：tnadeau@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com, 2nd Floor CH-8301 Switzerland
モニークジャンヌ・モローシスコシステムズ、株式会社グラット-COM、2階のCH-8301スイス
Phone: (0)1 878-9412 EMail: mmorrow@cisco.com
電話番号：（0）1 878から9412 Eメール：mmorrow@cisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
ジョージツバメシスコシステムズ社300ビーバーブルックロードBoxboro、MA 01719
Phone: +1-978-936-1398 EMail: swallow@cisco.com
電話：+ 1-978-936-1398 Eメール：swallow@cisco.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
デビッド・アランノーテルネットワークス3500カーリングアベニュー。オタワ、オンタリオ、カナダ
Phone: 1-613-763-6362 EMail: dallan@nortel.com
電話：1-613-763-6362 Eメール：dallan@nortel.com
Satoru Matsushima Japan Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo, 105-7316 Japan
さとる まつしま じゃぱん てぇこｍ １ー９ー１、 ひがしーしんばし、 みなとーく ときょ、 １０５ー７３１６ じゃぱん
Phone: +81-3-6889-1092 EMail: satoru@ft.solteria.net
電話：+ 81-3-6889-1092 Eメール：satoru@ft.solteria.net
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）によって提供されます。