Network Working Group D. Allan, Ed.
Request for Comments: 4378 Nortel Networks
Category: Informational T. Nadeau, Ed.
Cisco Systems, Inc.
February 2006
A Framework for Multi-Protocol Label Switching (MPLS)
Operations and Management (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).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document is a framework for how data plane protocols can be applied to operations and maintenance procedures for Multi-Protocol Label Switching (MPLS). The document is structured to outline how Operations and Management (OAM) functionality can be used to assist in fault, configuration, accounting, performance, and security management, commonly known by the acronym FCAPS.
このドキュメントでは、データプレーンプロトコルは、マルチプロトコルラベルスイッチング（MPLS）のための操作と保守手順に適用することができますどのようにするためのフレームワークです。文書がどのように運用と管理（OAM）機能は、一般的頭字語FCAPSで知られ、障害、設定、アカウンティング、パフォーマンス、およびセキュリティ管理を支援するために使用することができますの概要を説明するために構成されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Fault Management ................................................2
3.1. Fault Detection ............................................2
3.2. Diagnosis ..................................................6
3.3. Availability ...............................................7
4. Configuration Management ........................................7
5. Accounting ......................................................7
6. Performance Management ..........................................7
7. Security Management .............................................8
8. Security Considerations .........................................9
9. Acknowledgements ................................................9
10. Normative References ...........................................9
This memo outlines in broader terms how data plane protocols can assist in meeting the Operations and Management (OAM) requirements outlined in [RFC4377] and [Y1710] and can apply to the management functions of fault, configuration, accounting, performance, and security (commonly known as FCAPS) for MPLS networks, as defined in [RFC3031]. The approach of the document is to outline functionality, the potential mechanisms to provide the function, and the required applicability of data plane OAM functions. Included in the discussion are security issues specific to use of tools within a provider domain and use for inter-provider Label Switched Paths (LSPs).
このメモは、データプレーンプロトコルは運用と管理（OAM）要件[RFC4377]に概説さとを満たすのに役立つことができますどのように広範な用語で概説[Y1710]と（障害、構成、アカウンティング、パフォーマンス、およびセキュリティの管理機能にも適用することができます[RFC3031]で定義されるように、一般的に、MPLSネットワークのため）FCAPSとして知られています。文書のアプローチは、機能、及びデータプレーンのOAM機能の必要な適用可能性を提供する機能、潜在的なメカニズムを概説することです。プロバイダドメイン内のツールの使用およびインタープロバイダのラベルに使用する特定のセキュリティ上の問題が議論に含まれるのは、スイッチパス（LSP）。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
OAM Operations and Management
OAM運用と管理
FCAPS Fault management, Configuration management, Administration management, Performance management, and Security management
FCAPS障害管理、構成管理、アドミニストレーション管理、パフォーマンス管理、およびセキュリティ管理
FEC Forwarding Equivalence Class
FEC転送等価クラス
ILM Incoming Label Map
ILM着信ラベルマップ
NHLFE Next Hop Label Forwarding Entry
NHLFEネクストホップラベル転送エントリ
MIB Management Information Base
MIB管理情報ベース
LSR Label Switching Router
LSRラベルスイッチングルータ
RTT Round Trip Time
RTTラウンドトリップタイム
Fault detection encompasses the identification of all data plane failures between the ingress and egress of an LSP. This section will enumerate common failure scenarios and explain how one might (or might not) detect the situation.
障害検出はLSPの入口と出口との間のすべてのデータプレーン障害の同定を包含する。このセクションでは、一般的な障害シナリオを列挙し、どのように1つの威力を説明する（またはしない場合があります）の状況を検出します。
Lower-layer faults:
下層障害：
Lower-layer faults are those in the physical or virtual link that impact the transport of MPLS labeled packets between adjacent LSRs at the specific level of interest. Some physical links (such as SONET/SDH) may have link-layer OAM functionality and detect and notify the LSR of link-layer faults directly. Some physical links (such as Ethernet) may not have this capability and require MPLS or IP layer heartbeats to detect failures. However, once detected, reaction to these fault notifications is often the same as those described in the first case.
下層障害はMPLSの輸送に影響を与える物理的または仮想リンクにおけるそれら関心のある特定のレベルで隣接するLSRの間でパケットをラベル付けされています。 （例えば、SONET / SDHのような）いくつかの物理リンクは、リンク層のOAM機能を有し、直接リンク層障害のLSRを検出して通知してもよいです。 （イーサネットなど）いくつかの物理リンクは、この能力を持っており、障害を検出するために、MPLSまたはIP層のハートビートを必要としなくてもよいです。しかし、一度検出され、これらの障害通知に対する反応は、多くの場合、最初のケースで説明したものと同じです。
Node failures:
ノード障害：
Node failures are those that impact the forwarding capability of a node component, including its entire set of links. This can be due to component failure, power outage, or reset of the control processor in an LSR employing a distributed architecture, etc.
ノードの障害は、リンクの全体セットを含む、ノードのコンポーネントの転送能力に影響を与えるものです。これは、コンポーネントの障害、停電、またはLSR内の制御プロセッサのリセット分散型アーキテクチャを採用し、等に起因することができ
MPLS LSP mis-forwarding:
MPLS LSPの誤転送：
Mis-forwarding occurs when there is a loss of synchronization between the data and the control planes in one or more nodes. This can occur due to hardware failure, software failure, or configuration problems.
1つ以上のノードにデータと制御プレーンとの間の同期の損失がある場合に誤転送が発生します。これは、ハードウェア障害、ソフトウェア障害、または構成上の問題に発生する可能性があります。
It will manifest itself in one of two forms:
これは、2つのいずれかの形式で現れます：
- packets belonging to a particular LSP are cross-connected into an NHLFE for which there is no corresponding ILM at the next downstream LSR. This can occur in cases where the NHLFE entry is corrupted. Therefore, the packet arrives at the next LSR with a top label value for which the LSR has no corresponding forwarding information, and is typically dropped. This is a No Incoming Label Map (No ILM) condition and can be detected directly by the downstream LSR that receives the incorrectly labeled packet.
- 特定のLSPに属するパケットは、次の下流LSRには対応するILMがないいるNHLFEに相互接続されています。これはNHLFEエントリが破損している場合に発生する可能性があります。したがって、パケットはLSRが該当する転送情報を持っていない、と一般的にドロップされた上部ラベル値と次のLSRに到達します。これは、着信ラベルマップ（ノーILM）の条件であると間違ってラベル付きパケットを受信した下流のLSRによって直接検出することができます。
- packets belonging to a particular LSP are cross-connected into an incorrect NHLFE entry for which there is a corresponding ILM at the next downstream LSR, but is associated with a different LSP. This may be detected by the following:
- 特定のLSPに属するパケットは、クロス接続された次のダウンストリームLSRに対応するILMが存在するため、誤ったNHLFEエントリにあるが、異なるLSPに関連しています。これは、以下によって検出されることがあります。
o some or all of the misdirected traffic is not routable at the egress node, or
O一部またはすべての見当違いのトラフィックが出口ノードにルーティングできない、または
o OAM probing is able to detect the fault by detecting the inconsistency between the data path and the control plane state.
O OAMプロービングは、データパスおよび制御プレーンの状態の間で矛盾を検出することにより故障を検出することが可能です。
Discontinuities in the MPLS Encapsulation
MPLSカプセル化の不連続
The forwarding path of the FEC carried by an LSP may transit nodes or links for which MPLS is not configured. This may result in a number of behaviors that are undesirable and not easily detected.
MPLSが設定されていないLSPよいトランジットノードやリンクによって運ばれるFECの転送パス。これは望ましくないと容易に検出されない行動の数をもたらすことができます。
- if exposed, payload is not routable at the LSR, resulting in silent discard, OR
- 露光された場合、ペイロードはサイレント破棄をもたらす、LSRでルーティングできない、OR
- the exposed MPLS label was not offered by the LSR, which may result in either silent discard or mis-forwarding.
- 露出MPLSラベルは、サイレント破棄または誤転送のいずれかをもたらし得るLSR、によって提供されませんでした。
Alternately, the payload may be routable and packets successfully delivered but may bypass associated MPLS instrumentation and tools.
あるいは、ペイロードはルーティング可能であってもよく、パケットが正常に配信が、関連付けられたMPLS計装およびツールをバイパスすることができます。
MTU problems
MTUの問題
MTU problems occur when client traffic cannot be fragmented by intermediate LSRs and is dropped somewhere along the path of the LSP. MTU problems should appear as a discrepancy in the traffic count between the set of ingress LSRs and the egress LSRs for an FEC and will appear in the corresponding MPLS MIB performance tables in the transit LSRs as discarded packets.
MTUの問題は、クライアントのトラフィックが中間のLSRによって断片化することができないとLSPのパスに沿ってどこかにドロップされたときに発生します。 MTUの問題は、FECのためのイングレスのLSRのセットと出口のLSR間のトラフィック数の不一致として表示されますと、廃棄されたパケットなどのトランジットのLSRに対応するMPLS MIBのパフォーマンス表に表示されます。
TTL Mishandling
TTL取扱いを誤ります
The implementation of TTL handling is inconsistent at penultimate hop LSRs. Tools that rely on consistent TTL processing may produce inconsistent results in any given network.
TTL処理の実装は、最後から二番目のホップのLSRで矛盾しています。一貫したTTL処理に依存しているツールは、任意のネットワークで一貫性のない結果を生成することができます。
Congestion
混雑
Congestion occurs when the offered load on any interface exceeds the link capacity for sufficient time that the interface buffering is exhausted. Congestion problems will appear as a discrepancy in the traffic count between the set of ingress LSRs and the egress LSRs for an FEC and will appear in the MPLS MIB performance tables in the transit LSRs as discarded packets.
任意のインターフェイス上で提供された負荷がインターフェイスバッファリングが排出されるのに十分な時間、リンク容量を超えた場合に輻輳が発生します。輻輳の問題は、FECのためのイングレスのLSRのセットと出口のLSR間のトラフィック数の不一致として表示され、廃棄されたパケットなどのトランジットのLSRでのMPLS MIBのパフォーマンス表に表示されます。
Mis-ordering
誤発注
Mis-ordering of LSP traffic occurs when incorrect or inappropriate load sharing is implemented within an MPLS network. Load sharing typically takes place when multiple equal-cost paths exist between the ingress and egress of an LSP. In these cases, traffic is split among these equal-cost paths using a variety of algorithms. One such algorithm relies on splitting traffic between each path on a per-packet basis. When this is done, it is possible for some packets along the path to be delayed due to congestion or slower links, which may result in packets being received out of order at the egress. Detection and remedy of this situation may be left up to client applications that use the LSPs. For instance, TCP is capable of re-ordering packets belonging to a specific flow (although this may result in re-transmission of some of the mis-ordered packets).
不正または不適切な負荷分散がMPLSネットワーク内に実装されたときにLSPトラフィックの誤発注が発生します。複数の等コスト・パスがLSPの入口と出口の間に存在するときに負荷分散は、一般的に行われます。これらのケースでは、トラフィックは、様々なアルゴリズムを使用して、これらの等コスト・パス間で分割されます。そのようなアルゴリズムは、パケット単位で各パス間で分割トラフィックに依存しています。これが行われるときに経路に沿っていくつかのパケットが輻輳又は出口に順序が狂って受信されるパケットをもたらす可能性が遅いリンクに起因する遅延することが可能です。このような状況の検出と改善策はLSPを使用するクライアントアプリケーションに任されます。 （これは、誤順序付きパケットの一部の再送信をもたらすかもしれないが）、例えば、TCPは、特定のフローに属する再順序付けパケットが可能です。
Detection of mis-ordering can also be determined by sending probe traffic along the path and verifying that all probe traffic is indeed received in the order it was transmitted. This will only detect truly pathological problems as mis-ordering typically is an insufficiently predictable and repeatable problem.
誤順序の検出はまた、経路に沿ってプローブトラフィックを送信し、すべてのプローブ交通が実際にそれが送信された順序で受信されたことを確認することによって決定することができます。誤発注は、一般的に不十分予測可能かつ反復可能な問題であるとして、これが唯一の真の病理学的な問題を検出します。
LSRs do not normally implement mechanisms to detect mis-ordering of flows.
LSRは、通常のフローの誤発注を検出するためのメカニズムを実装していません。
Payload Corruption
ペイロードの破損
Payload corruption may occur and may be undetected by LSRs. Such errors are typically detected by client payload integrity mechanisms.
ペイロードの破損が発生する可能性がありますとのLSRによって検出されないことがあります。このようなエラーは通常、クライアントのペイロードの整合性メカニズムによって検出されています。
The design of Service Level Agreements (SLAs) and management support systems requires that ample headroom be alloted in terms of their processing capabilities in order to process and handle all necessary fault conditions within the bounds stipulated in the SLA. This includes planning for event handling using a time budget that takes into account the over-all SLA and the time required to address any defects that arise. However, it is possible that some fault conditions may surpass this budget due to their catastrophic nature (e.g., fibre cut) or due to incorrect planning of the time processing budget.
サービスレベル契約（SLA）と管理支援システムの設計は、SLAに規定十分なヘッドルームが境界内のすべての必要な障害条件を処理し、処理するために、その処理能力の面でallotedされている必要があります。これは、アカウントにオーバーすべてのSLAと発生する欠陥に対処するために必要な時間がかかり、時間の予算を使ってイベント処理のために計画しています。しかし、いくつかの障害状態が原因彼らの壊滅的な性質（例えば、ファイバの切断）、または期限処理予算の間違った企画に、この予算を上回る可能性があります。
^ --------------
| | ^
| | |---- Time to notify NOC + process/correct
SLA | | v defect
Max - | -------------
Time | | ^
| | |----- Time to diagnose/isolate/correct
| | v
v -------------
Figure 1: Fault Correction Budget
図1：障害補正予算
In figure 1, we represent the overall fault correction time budget by the maximum time as specified in an SLA for the service in question. This time is then divided into two subsections, the first encompassing the total time required to detect a fault and notify an operator (or optionally automatically correct the defect). This section may have an explicit maximum time to detect defects arising from either the application or a need to do alarm management (i.e., suppression), and this will be reflected in the frequency of OAM execution. The second section indicates the time required to notify the operational systems used to diagnose, isolate, and correct the defect (if they cannot be corrected automatically).
図1では、我々は、当該サービスのSLAに指定されている最大時間によって、全体的な障害補正時間の予算を表します。この時間は、2つのサブセクション、故障を検出し、オペレータに通知する（または必要に応じて自動的に欠陥を修正する）ために必要な合計時間を包含する最初に分割されます。このセクションでは、アプリケーションやアラーム管理（すなわち、抑制）を行う必要性のいずれかに起因する欠陥を検出するための明示的な最大時間を有していてもよく、これはOAM実行の頻度に反映されます。第二部は、診断、分離、および（それらは自動的に補正することができない場合）欠陥を修正するために使用される運用システムに通知するために必要な時間を示しています。
Characterization is defined as determining the forwarding path of a packet (which may not be necessarily known). Characterization may be performed on a working path through the network. For example, this is done to determine equal-cost multi-paths (ECMP), the MTU of a path, or simply to know the path occupied by a specific FEC. Characterization will be able to leverage mechanisms used for isolation.
特徴付けは、（必ずしも知らなくてもよい）、パケットの転送経路を決定することと定義されます。特徴付けは、ネットワークを介して現用パス上で実行されてもよいです。例えば、これは特定のFECによって占有パスを知ることが単に経路のMTU、等コストマルチパス（ECMP）を決定するために行わ、またはれます。特徴付けは、単離のために使用されるメカニズムを活用することができるであろう。
Isolation of a fault can occur in two forms. In the first case, the local failure is detected, and the node where the failure occurred is capable of issuing an alarm for such an event. The node should attempt to withdraw the defective resources and/or rectify the situation prior to raising an alarm. Active data plane OAM mechanisms may also detect the failure conditions remotely and issue their own alarms if the situation is not rectified quickly enough.
障害の分離は、2つの形で発生する可能性があります。最初のケースでは、ローカル障害が検出され、障害が発生したノードは、イベントのための警報を発することが可能です。ノードは、欠陥のあるリソースを撤回しようとすると/または警報を発する前に状況を是正すべきです。アクティブなデータプレーンOAMメカニズムはまた、リモートで障害状態を検出し、状況が十分に迅速に修正されていない場合は、独自のアラームを発行することができます。
In the second case, the fault has not been detected locally. In this case, the local node cannot raise an alarm, nor can it be expected to rectify the situation. In this case, the failure may be detected remotely via data plane OAM. This mechanism should also be able to determine the location of the fault, perhaps on the basis of limited information such as a customer complaint. This mechanism may also be able to automatically remove the defective resources from the network and restore service, but should at least provide a network operator with enough information by which they can perform this operation. Given that detection of faults is desired to happen as quickly as possible, tools which possess the ability to incrementally test LSP health should be used to uncover faults.
第二のケースでは、障害は、局所的に検出されていません。この場合、ローカル・ノードは、警報を発することができない、また状況を是正することが期待されます。この場合、障害がデータプレーンOAMを介して遠隔的に検出することができます。この機構はまた、おそらく、顧客の苦情などの限られた情報に基づいて、障害の位置を決定することができなければなりません。また、このメカニズムは、自動的にネットワークからの不良リソースを削除し、サービスを復元することができるかもしれないが、少なくとも彼らは、この操作を行うことが可能な十分な情報とネットワークオペレータを提供する必要があります。故障の検出が可能な限り迅速に起こることが望まれていることを考えると、インクリメンタルLSPの健康をテストする能力を持っているツールは、障害を発見するために使用されるべきです。
Availability is the measure of the percentage of time that a service is operating within a specification, often specified by an SLA.
可用性は、多くの場合、SLAで指定されたサービスは仕様の範囲内で動作している時間の割合の尺度です。
MPLS has several forwarding modes (depending on the control plane used). As such, more than one model may be defined and more than one measurement technique may be required.
MPLSは、（使用される制御プレーンに応じて）いくつかの転送モードを有します。このように、複数のモデルが定義されてもよいし、複数の測定技術が必要とされ得ます。
Data plane OAM can assist in configuration management by providing the ability to verify the configuration of an LSP or of applications utilizing that LSP. This would be an ad-hoc data plane probe that should verify path integrity (a complete path exists) and that the path function is synchronized with the control plane. As part of the payload, the probe would carry relevant control plane information that the receiver would be able to compare with the local-control plane configuration.
データプレーンOAMは、LSPの又はそのLSPを利用するアプリケーションの設定を確認する能力を提供することにより、構成管理を助けることができます。これは、経路の完全性（完全なパスが存在する）とパス機能は、制御プレーンと同期していることを確認する必要があり、アドホックデータプレーンプローブであろう。ペイロードの一部として、プローブは、受信機が、ローカル制御プレーンのコンフィグレーションと比較することができるであろう関連する制御プレーンの情報を運びます。
The requirements for accounting in MPLS networks, as specified in [RFC4377], do not place any requirements on data plane OAM.
[RFC4377]で指定されるように、MPLSネットワークで会計の要件は、データプレーンのOAM上の任意の要件を置かないでください。
Performance management permits the information transfer characteristics of LSPs to be measured, perhaps in order to be compared against an SLA. This falls into two categories: latency (where jitter is considered a variation in latency) and information loss.
パフォーマンス管理は、SLAと比較するために、おそらく、測定されるLSPの情報伝達特性を可能にします。 （ジッターが待ち時間の変化であると考えられる）、待ち時間情報の損失：これは、2つのカテゴリに分類されます。
Latency can be measured in two ways: one is to have precisely synchronized clocks at the ingress and egress such that time-stamps in PDUs flowing from the ingress to the egress can be compared. The other is to use an exchange of PING type PDUs that gives a round trip time (RTT) measurement, and an estimate of the one-way latency that can be inferred with some loss of precision. Use of load spreading techniques, such as ECMP, mean that any individual RTT measurement is only representative of the typical RTT for an FEC.
レイテンシは、2つの方法で測定することができる：一つは出口に入口から流入したPDUのタイムスタンプを比較することができるように入口および出口に正確に同期したクロックを有することです。他のラウンドトリップ時間（RTT）測定、及び精度のいくつかの損失と推測することができる一方向待ち時間の推定値を与えるPING型PDUの交換を使用することです。例えばECMPとして負荷拡散技術の使用は、任意の個々のRTT測定値がFECのための典型的なRTTの単なる代表であることを意味します。
To measure information loss, a common practice is to periodically read ingress and egress counters (i.e., MIB module counters). This information may also be used for offline correlation. Another common practice is to send explicit probe traffic that traverses the data plane path in question. This probe traffic can also be used to measure jitter and delay.
情報の損失を測定するために、一般的な方法は、定期的に入力および出力カウンタ（すなわち、MIBモジュールカウンタ）を読み取ることです。この情報は、オフラインで相関のために使用することができます。もう一つの一般的な方法は、問題のデータプレーンパスを横断明示的なプローブ・トラフィックを送信することです。このプローブトラフィックも、ジッタや遅延を測定するために使用することができます。
Providing a secure OAM environment is required if MPLS specific network mechanisms are to be used successfully. To this end, operators have a number of options when deploying network mechanisms including simply filtering OAM messages at the edge of the MPLS network. Malicious users should not be able to use non-MPLS interfaces to insert MPLS-specific OAM transactions. Provider initiated OAM transactions should be able to be blocked from leaking outside the MPLS cloud.
MPLS特定のネットワークメカニズムが正常に使用される場合は、安全なOAM環境を提供することが必要です。単にMPLSネットワークのエッジでOAMメッセージをフィルタリングなどのネットワークメカニズムを展開する際にこの目的を達成するために、オペレータは多くのオプションを持っています。悪意のあるユーザは、MPLS-OAM特定のトランザクションを挿入するために、非MPLSインターフェイスを使用することがあってはなりません。プロバイダ開始OAM取引は、MPLSクラウド外に漏れるのを阻止することができるはずです。
Finally, if a provider does wish to allow OAM messages to flow into (or through) their networks, for example, in a multi-provider deployment, authentication and authorization are required to prevent malicious and/or unauthorized access. Also, given that MPLS networks often run IP simultaneously, similar requirements apply to any native IP OAM network mechanisms in use. Therefore, authentication and authorization for OAM technologies is something that MUST be considered when designing network mechanisms that satisfy the framework presented in this document.
プロバイダがOAMメッセージがマルチプロバイダの展開で、例えば、自社のネットワークに（または経由）流れることを可能にしたくない場合は最後に、認証および認可は、悪意のあるおよび/または不正なアクセスを防止するために必要とされます。また、MPLSネットワークは、多くの場合、同時にIPを実行することを考えると、同様の要件は、使用中の任意のネイティブIP OAMネットワークメカニズムに適用されます。したがって、OAM技術の認証および認可は、この文書で提示枠組みを満たすネットワークの仕組みを設計する際に考慮しなければならないものです。
OAM messaging can address some existing security concerns with the MPLS architecture. That is, through rigorous defect handling, operator's can offer their customers a greater degree of integrity protection that their traffic will not be incorrectly delivered (for example, by being able to detect leaking LSP traffic from a VPN).
OAMメッセージは、MPLSアーキテクチャといくつかの既存のセキュリティ懸念に対処することができます。これは、厳格な欠陥処理により、オペレータのは、（VPNからのLSPのトラフィックが漏れ検出することが可能であることにより、例えば）顧客のトラフィックが誤って配信されないことを完全性保護の大きい程度を提供することができています。
Support for inter-provider data plane OAM messaging introduces a number of security concerns as, by definition, portions of LSPs will not be within a single provider's network the provider has no control over who may inject traffic into the LSP, which can be exploited for denial of service attacks. OAM PDUs are not explicitly identified in the MPLS header and therefore are not typically inspected by transit LSRs. This creates opportunity for malicious or poorly behaved users to disrupt network operations.
、定義により、LSPの部分は、単一のプロバイダのネットワーク内ではありませんプロバイダがために利用することができるLSPへトラフィックを注入することができる人を制御できないようにインタープロバイダデータプレーンOAMメッセージのサポートは、セキュリティ上の懸念の数を紹介しますサービス拒否攻撃。 OAM PDUは、明示的にMPLSヘッダにおいて識別されておらず、従って、典型的にトランジットのLSRによって検査されていません。これは、ネットワークの運用を妨害する悪質なまたは不十分振る舞ったユーザーのための機会を作成します。
Attempts to introduce filtering on target LSP OAM flows may be problematic if flows are not visible to intermediate LSRs. However, it may be possible to interdict flows on the return path between providers (as faithfulness to the forwarding path is to a return path requirement) to mitigate aspects of this vulnerability.
フローは、中間のLSRに表示されていない場合、ターゲットLSPのOAMフローにフィルタを導入する試みは問題となり得ます。しかし、この脆弱性の側面を軽減する（転送パスに忠実リターンパス要件であるように）プロバイダとの間の復路の流れを禁じることも可能です。
OAM tools may permit unauthorized or malicious users to extract significant amounts of information about network configuration. This would be especially true of IP based tools as, in many network configurations, MPLS does not typically extend to untrusted hosts, but IP does. For example, TTL hiding at ingress and egress LSRs will prevent external users from using TTL-based mechanisms to probe an operator's network. This suggests that tools used for problem diagnosis or which, by design, are capable of extracting significant amounts of information will require authentication and authorization of the originator. This may impact the scalability of such tools when employed for monitoring instead of diagnosis.
OAMツールは、ネットワーク構成に関する大量の情報を抽出するために、不正または悪意のあるユーザーを許可することができます。多くのネットワーク構成では、MPLSは、一般的に信頼できないホストには適用されませんが、IPがない、これはIPベースのツールは特にそうでしょう。例えば、入口及び出口LSRsに隠れTTLは、オペレータのネットワークをプローブするTTLベースのメカニズムを使用して、外部からユーザーを防ぐことができます。これは、設計により、問題の診断やそのために使用するツールは、発信者の認証と承認が必要になります大量の情報を抽出することが可能であることを示唆しています。代わりに、診断のモニタリングのために用いられるとき、これはそのようなツールのスケーラビリティに影響を与えることができます。
This document describes a framework for MPLS Operations and Management. Although this document discusses and addresses some security concerns in Section 7, it does not introduce any new security concerns.
この文書では、MPLS運用と管理のためのフレームワークについて説明します。この文書は説明し、第7節では、いくつかのセキュリティ問題に対処しますが、それはどんな新しいセキュリティ上の懸念を導入していません。
The editors would like to thank Monique Morrow from Cisco Systems and Harmen van Der Linde from AT&T for their valuable review comments on this document.
編集者は、このドキュメントの彼らの貴重なレビューコメントのためにAT＆Tからシスコシステムズからモニークモローとハーメンファンデリンデに感謝したいと思います。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S. Matsushima, "Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks", RFC 4377, February 2006.
[RFC4377]ナドー、T.、モロー、M.、ツバメ、G.、アラン、D.、およびS.松島は、RFC 4377 "操作とマルチプロトコルラベルの管理（OAM）要件（MPLS）ネットワークのスイッチ" 、2006年2月。
[Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM Functionality for MPLS Networks".
[Y1710] ITU-T勧告Y.1710（2002）、 "MPLSネットワークのOAM機能の要件"。
Authors' Addresses
著者のアドレス
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
Thomas D. Nadeau Cisco Systems 300 Beaver Brook Drive Boxborough, MA 01824
トーマスD.ナドー、シスコシステムズ300ビーバーブルックドライブボックスボロー、MA 01824
Phone: +1-978-936-1470 EMail: tnadeau@cisco.com
電話：+ 1-978-936-1470 Eメール：tnadeau@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。