[要約] RFC 4377は、MPLSネットワークの運用管理（OAM）要件に関するものであり、MPLSネットワークのOAM機能の設計と実装に関するガイドラインを提供します。このRFCの目的は、MPLSネットワークの信頼性とパフォーマンスを向上させるためのOAM要件を明確にすることです。
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
マルチプロトコルラベルスイッチ（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
概要
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のOAM要件とMPLSのアプリケーションを指定します。
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.
欠陥：ラベルが正しく機能するのを防ぐことを防ぐエラー条件。たとえば、インテリアゲートウェイプロトコル（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で欠陥を検出する機能は、そのLSPのトラフィックを切り替えるために使用される各LSRの手動ホップバイホップのトラブルシューティングを必要としないはずです。たとえば、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がテストされる場合には、パスの活気の自動化が望まれます。たとえば、一部のLSPでは、LSRテスト機能を出力するための自動化されたIngress LSRが望まれます。目標は、顧客が行う前に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内で送信されたICMPメッセージがパスに沿ったある時点で「LSPから落ちる」ことが可能です。これらの場合、ICMPパケットはルーティング可能であるため、誤って肯定的な応答が返される場合があります。他のケースでは、特定のLSPのデータプレーンをテストする必要がある場合、ICMP Pingヘッダーに基づくトラフィックが解析され、データトラフィックと同じ等しいコストマルチパス（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.
リターンパスを介してステータスを受信することに依存する検出メカニズムは、それらの1つが元の欠陥によって影響を受けることがないと期待して、複数のリターンオプションを提供する必要があります。偽陰性が発生する可能性のあるケースの例は、機能的なMPLSリターンパスを必要とするメカニズムです。MPLS LSPは単方向であるため、検査中のLSPであるフォワードLSPが機能している可能性がありますが、宛先LSRからの応答が失われる可能性があるため、ソースLSRにフォワードLSPに欠陥があるという誤った印象を与えます。。ただし、たとえば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パケットは、顧客データが使用するパスの活気を反映するために、顧客データパスに正確に従う必要があります。関心のある特定のケースは、オペレーターのネットワーク内のECMPシナリオなど、転送メカニズムであり、それにより、流れは並列パス（つまり、IGPコスト等しいコスト）に負荷が共有されます。顧客のトラフィックが複数のパスに広がる可能性がある場合、パス順列のいずれかで障害を検出する機能が必要です。拡散メカニズムがペイロード固有である場合、ペイロードには、テスト中のトラフィックに共通する転送が必要です。これらの要件を満たすことで、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.
- Pushes、Pops、TTL伝播など、LSRが実行するスタック操作は、最後から2番目のホップLSRSでの伝播です。
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パケットの数を測定するには、少なくとも1つのメカニズムが必要です。さらに、特定の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.
1つの観察結果は、MPLの広範な展開、監視ツールの一般的な実装、および欠陥およびサービスレベルの仕様処理のキャリア間同期の必要性が、一般的に合意された値に合意された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の要件と併せて表示される場合、これには通常、LSPを使用してアプリケーションがパス連続テストを実装した場合、特定の時間制約がある場合があるLSPエグレスへの障害通知が必要です（たとえば、ATMI.610連続性チェック（CC））[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 ALAMアラーム表示信号（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.
1つの目標は、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.
プロバイダーとその顧客は、ネットワークを継続的に最適化するか、保証された帯域幅サービスを提供するために、高レベルのサービスレベルの仕様を検証する必要がある場合があります。したがって、MPLSアプリケーションを監視するためのトラフィック会計が必要です。
(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:
これらの3つの動機は、次のことを満たす必要があります。
- 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.
- （1）および（2）では、LSPごとに情報の収集は、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を使用してLSPのペアを識別する必要があります。
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) Ingress 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) Egress 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.
本明細書に記載されている要件を満たすように設計されたネットワークメカニズムのいずれかの規定は、許可されていない使用を防ぐために必要です。同様に、これらのネットワークメカニズムは、そのような攻撃でそれらのネットワークメカニズムが使用されている場合、オペレーターがサービス拒否攻撃を防ぐことができる手段を提供する必要があります。
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 Mis-Mergingには、単にネットワークの欠陥であることを超えたセキュリティへの影響があります。LSPの誤ったマルジングは、多くの潜在的な障害源のために発生する可能性があります。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Swallow、「Multi-Protocol Label Switched（MPLS）データプレーン障害の検出」、RFC 4379、2006年2月。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004.
[RFC3812] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Srinivasan、C.、Viswanathan、A。、およびT. Nadeau、「マルチプロトコルラベルスイッチング（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] Nadeau、T.、Srinivasan、C。、およびA. Viswanathan、「マルチプロトコルラベルスイッチング（MPLS）転送等価クラスへの次のホップラベル転送エントリ（FEC-to-NHLFE）管理情報ベース（MIB）」、RFC3814、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] Postel、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.
著者は、この文書に対する貴重なコメントについて、次の個人に認め、感謝したいと考えています。エイドリアン・スミス、イギリスの通信。Chou Lan Pok、SBC;Ikejiri氏、NTTコミュニケーションズ。クマキ氏、Kddi。ハリ・ラコトラント、ミヤ・コノ、シスコシステム。luyuan fang、at＆t;ダニー・マクファーソン、TCB;Ken Nagami博士、Ikuo Nakagawa、Intec Netcore、David Meyer。
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
Thomas D. Nadeau Cisco Systems、Inc。300 Beaver Brook Road Boxboro、MA 01719
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com, 2nd Floor CH-8301 Switzerland
Monique Jeanne Morrow Cisco Systems、Inc。Glatt-Com、2階CH-8301スイス
Phone: (0)1 878-9412 EMail: mmorrow@cisco.com
電話：（0）1 878-9412メール：mmorrow@cisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
George Swallow Cisco Systems、Inc。300 Beaver Brook Road Boxboro、MA 01719
Phone: +1-978-936-1398 EMail: swallow@cisco.com David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
電話：1-978-936-1398メール：swallow@cisco.com David Allan Nortel Networks 3500 Carling Ave. Ottawa、オンタリオ州カナダ
Phone: 1-613-763-6362 EMail: dallan@nortel.com
電話：1-613-763-6362メール：dallan@nortel.com
Satoru Matsushima Japan Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo, 105-7316 Japan
松島の日本のテレコム1-9-1、西海島、東京港、105-7316日本
Phone: +81-3-6889-1092
EMail: satoru@ft.solteria.net
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）によって提供されます。