[要約] RFC 4378は、MPLSの運用と管理（OAM）のためのフレームワークを提供しています。このRFCの目的は、MPLSネットワークのパフォーマンス監視、障害検出、トラブルシューティングなどのOAM機能を定義することです。
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)
マルチプロトコルラベルスイッチング（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 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）機能を使用して、障害、構成、会計、パフォーマンス、およびセキュリティ管理を支援する方法を概説するために構成されています。
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).
このメモは、データプレーンプロトコルが[RFC4377]および[Y1710]で概説されている運用と管理（OAM）要件を満たすのに役立ち、障害、構成、会計、パフォーマンス、およびセキュリティの管理機能に適用できる方法をより広範に概説しています。[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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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の侵入と出口の間のすべてのデータプレーン障害の識別が含まれます。このセクションでは、一般的な障害シナリオを列挙し、状況をどのように検出するか（またはそうでないか）を説明します。
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.
低層断層は、特定のレベルの関心レベルで隣接する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があるが、異なるLSPに関連付けられている誤ったNHLFEエントリに相互接続されています。これは、次のことで検出できます。
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.
LSPによって運ばれるFECの転送パスは、MPLSが構成されていないリンクまたはリンクを通過できます。これにより、望ましくなく簡単に検出されない多くの動作が生じる可能性があります。
- if exposed, payload is not routable at the LSR, resulting in silent discard, OR
- 露出した場合、ペイロードはLSRでルーティングできないため、サイレント廃棄、または
- 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処理の実装は、最後から2番目のホップ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).
LSPトラフィックの誤った順序は、MPLSネットワーク内で誤ったまたは不適切な負荷共有が実装された場合に発生します。通常、LSPの侵入と出口の間に複数の等コストのパスが存在する場合、負荷共有が行われます。これらの場合、さまざまなアルゴリズムを使用してトラフィックがこれらの等しいコストパスに分割されます。そのようなアルゴリズムの1つは、パケットごとに各パス間でトラフィックを分割することに依存しています。これが行われると、混雑やリンクが遅いため、パスに沿った一部のパケットが遅延する可能性があり、その結果、パケットが出口で故障しないようになる可能性があります。この状況の検出と治療は、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.
ペイロードの破損が発生する可能性があり、LSRSによって検出されない場合があります。このようなエラーは、通常、クライアントのペイロード整合性メカニズムによって検出されます。
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で規定されている境界内のすべての必要な障害条件を処理および処理するために、十分なヘッドルームを処理能力の観点から割り当てる必要があります。これには、すべての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実行の頻度に反映されます。2番目のセクションでは、欠陥を診断、分離、および修正するために使用される運用システムを通知するのに必要な時間を示します（自動的に修正できない場合）。
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.
特性評価は、パケットの転送パスを決定するものとして定義されます（必ずしも知られていない場合があります）。特性評価は、ネットワークを通る作業経路で実行される場合があります。たとえば、これは、等しいコストのマルチパス（ECMP）、パスのMTU、または単に特定のFECで占められているパスを知るために行われます。特性評価は、分離に使用されるメカニズムを活用できます。
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.
2番目のケースでは、障害は局所的に検出されていません。この場合、ローカルノードはアラームを上げることも、状況を修正することも期待できません。この場合、障害はデータプレーン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つの方法で測定できます。1つは、入り口と出口で侵入のタイムスタンプが侵入から出口に流れるタイムスタンプを比較できるようにすることです。もう1つは、往復時間（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インターフェイスを使用してMPLS固有のOAMトランザクションを挿入できないはずです。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.
Provider Interprovider Data Plane OAMメッセージのサポートは、LSPの一部が単一のプロバイダーのネットワーク内にないため、多くのセキュリティ上の懸念を紹介します。サービス拒否攻撃。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.
ターゲットLSP OAMフローにフィルタリングを導入しようとする試みは、フローが中間LSRに表示されない場合に問題がある場合があります。ただし、この脆弱性の側面を緩和するために、プロバイダー間のリターンパスでのフローを阻止することが可能かもしれません（転送パスへの忠実さはリターンパス要件です）。
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ツールにより、不正なユーザーや悪意のあるユーザーが、ネットワーク構成に関するかなりの量の情報を抽出できる場合があります。これは、多くのネットワーク構成では、MPLが通常信頼されていないホストに拡張されないため、IPベースのツールに特に当てはまります。たとえば、IngressおよびEmurser 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.
編集者は、この文書に関する貴重なレビューコメントについて、Cisco SystemsのMonique MorrowとAT＆TのHarmen van der Lindeに感謝します。
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、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] Nadeau、T.、Morrow、M.、Swallow、G.、Allan、D。、およびS. Matsushima、「運用および管理（OAM）要件マルチプロトコルラベルスイッチ（MPLS）ネットワーク」、RFC 4377、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
David Allan Nortel Networks 3500 Carling Ave. Ottawa、オンタリオ州カナダ
Phone: +1-613-763-6362
EMail: dallan@nortel.com
Thomas D. Nadeau Cisco Systems 300 Beaver Brook Drive Boxborough, MA 01824
トーマスD.ナドーシスコシステム300ビーバーブルックドライブボックスボロー、マサチューセッツ州01824
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。