Internet Engineering Task Force (IETF) G. Swallow, Ed.
Request for Comments: 6427 Cisco Systems, Inc.
Category: Standards Track A. Fulignoli, Ed.
ISSN: 2070-1721 Ericsson
M. Vigoureux, Ed.
Alcatel-Lucent
S. Boutros
Cisco Systems, Inc.
D. Ward
Juniper Networks, Inc.
November 2011
MPLS Fault Management Operations, Administration, and Maintenance (OAM)
MPLS障害管理運用、管理、および保守（OAM）
Abstract
抽象
This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions.
この文書では、MPLSベースのトランスポートネットワークのラベルのためのサービス中断の条件パスを交換を示すために、運用、管理、および保守（OAM）メッセージを指定します。通知メカニズムは、メンテナンスエンティティグループエンドポイントに通知するサービス中断の条件のための一般的な方法を採用しています。この文書は、サービス中断条件の様々なタイプを通信するためのメッセージとともに、MPLS OAMチャネルを画定します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6427.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6427で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. MPLS Fault Management Messages ..................................5
2.1. MPLS Alarm Indication Signal ...............................5
2.1.1. MPLS Link Down Indication ...........................6
2.2. MPLS Lock Report ...........................................6
2.3. Propagation of MPLS Fault Messages .........................7
3. MPLS Fault Management Channel ...................................7
4. MPLS Fault Management Message Format ............................8
4.1. Fault Management Message TLVs ..............................9
4.1.1. Interface Identifier TLV ...........................10
4.1.2. Global Identifier ..................................10
5. Sending and Receiving Fault Management Messages ................10
5.1. Sending a Fault Management Message ........................10
5.2. Clearing a Fault Management Indication ....................11
5.3. Receiving a Fault Management Indication ...................11
6. Minimum Implementation Requirements ............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. Pseudowire Associated Channel Type ........................13
8.2. MPLS Fault OAM Message Type Registry ......................13
8.3. MPLS Fault OAM Flag Registry ..............................14
8.4. MPLS Fault OAM TLV Registry ...............................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
10. Contributing Authors ..........................................16
Proper operation of a transport network depends on the ability to quickly identify faults and focus attention on the root cause of the disruption. This document defines MPLS Fault Management Operations, Administration, and Maintenance (OAM) messages. When a fault occurs in a server (sub-)layer, Fault Management OAM messages are sent to clients of that server so that alarms, which otherwise would be generated by the subsequent disruption of the clients, may be suppressed. This prevents a storm of alarms and allows operations to focus on the actual faulty elements of the network.
トランスポートネットワークの適切な操作はすぐに障害を識別し、混乱の根本的な原因に注意を集中する能力に依存します。この文書では、MPLS障害管理運用、管理、および保守（OAM）メッセージを定義します。障害がサーバ（サブ）レイヤで発生したときに、さもなければクライアントのその後の崩壊によって生成されるアラームは、抑制することができるように、障害管理OAMメッセージは、そのサーバのクライアントに送信されます。これは、アラームのストームを防止し、操作はネットワークの実際の故障要素に焦点を当てることを可能にします。
In traditional transport networks, circuits such as T1 lines are typically provisioned on multiple switches. When an event that causes disruption occurs on any link or node along the path of such a transport circuit, OAM indications are generated. When received, these indications may be used to suppress alarms and/or activate a backup circuit. The MPLS-based transport network provides mechanisms equivalent to traditional transport circuits. Therefore, a Fault Management (FM) capability must be defined for MPLS. This document defines FM capabilities to meet the MPLS-TP requirements as described in RFC 5654 [1], and the MPLS-TP Operations, Administration, and Maintenance requirements as described in RFC 5860 [2]. These mechanisms are intended to be applicable to other aspects of MPLS as well. However, applicability to other types of LSPs is beyond the scope of this document.
伝統的なトランスポート・ネットワークでは、そのようなT1回線のような回路は、典型的には、複数のスイッチにプロビジョニングされています。破壊の原因となるイベントは、トランスポート回路の経路に沿った任意のリンクまたはノードで発生した場合、OAM指示が生成されます。受信された場合、これらの指示はアラームを抑制および/またはバックアップ回路を活性化するために使用されてもよいです。 MPLSベースのトランスポートネットワークは、伝統的なトランスポート回路と同等の機構を提供します。そのため、障害管理（FM）機能は、MPLS用に定義する必要があります。 RFC 5860に記載されているように、この文書では、[2] [1] RFC 5654に記載されているように、MPLS-TPの要件を満たすために、FM機能を定義し、MPLS-TP運用、管理、及び保守要件。これらのメカニズムは、同様にMPLSの他の態様に適用することを意図しています。しかし、LSPの他のタイプへの適用は、このドキュメントの範囲を超えています。
Two broad classes of service disruptive conditions are identified.
サービス中断の条件の二つの広いクラスが識別されます。
1. Fault: The inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions.
1.障害：必要なアクションを実行する機能のことができません。これは、予防保守、外部リソースの不足、または計画されたアクションにできないことが含まれていません。
2. Lock: an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the LSP) can be sent on an LSP.
2.ロック：もしあれば、それは、その唯一のテストトラフィックが予想されている管理ステータス、およびOAM（LSPに捧げ）がLSPに送信することができます。
Within this document, a further term is defined: server-failure. A server-failure occurs when a fault condition or conditions have persisted long enough to consider the required service function of the server (sub-)layer to have terminated. In the case of a protected server, this would mean that the working facilities and any protection facilities have all suffered faults of the required duration.
この文書の中で、更なる用語が定義されます。サーバー障害。障害状態または条件は、サーバ（サブ）の必要なサービス機能を検討終了したために層に十分な長持続していたときに、サーバー障害が発生しました。保護されたサーバーの場合、これは作業施設や任意の保護施設は、すべての必要な期間の障害を被っていることを意味します。
This document specifies an MPLS OAM channel called an "MPLS-OAM Fault Management (FM)" channel. A single message format and a set of procedures are defined to communicate service disruptive conditions from the location where they occur to the end points of LSPs that are affected by those conditions. Multiple message types and flags are used to indicate and qualify the particular condition.
この文書では、MPLS OAMチャンネルは、「MPLS-OAM障害管理（FM）」チャンネルと呼ばれる指定します。単一のメッセージ・フォーマットと手順のセットは、それらがそれらの条件によって影響されるLSPの端点に発生場所からサービス中断条件を通信するために定義されています。複数のメッセージタイプとフラグを示し、特定の条件を修飾するために使用されています。
Corresponding to the two classes of service disruptive conditions listed above, two messages are defined to communicate the type of condition. These are known as:
上記サービス中断条件の二つのクラスに対応する、2件のメッセージが条件のタイプを通信するために定義されています。これらはとして知られています。
Alarm Indication Signal (AIS)
アラーム表示信号（AIS）
Lock Report (LKR)
ロックレポート（LKR）
ACH: Associated Channel Header
ACH：関連するチャネルヘッダー
ACh: Associated Channel
アセチルコリン：関連したチャンネル
CC: Continuity Check
CC：連続性チェック
FM: Fault Management
FM：障害管理
GAL: Generic Associated Channel Label
GAL：ジェネリック関連するチャネル・ラベル
LOC: Loss of Continuity
LOC：連続性を失います
LSP: Label Switched Path
LSP：ラベルスイッチパス
MEP: Maintenance Entity Group End Point
MEP：メンテナンスエンティティグループエンドポイント
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
MPLS-TP: MPLS Transport Profile
MPLS-TP：MPLSトランスポートプロファイル
MS-PW: Multi-Segment Pseudowire
MS-PW：マルチセグメント擬似回線
OAM: Operations, Administration, and Maintenance
OAM：オペレーション、管理、およびメンテナンス
PHP: Penultimate Hop Pop
PHP：最後から二番目のホップポップ
PW: Pseudowire
PO：Psefdoviri
TLV: Type, Length, Value
TLV：タイプ、長さ、値
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 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。
This document defines two messages to indicate service disruptive conditions, Alarm Indication Signal and Lock Report. The semantics of the individual messages are described in subsections below. Fault OAM messages are applicable to LSPs used in the MPLS Transport Profile. Such LSPs are bound to specific server layers based upon static configuration or signaling in a client/server relationship.
この文書では、サービス中断の条件、アラーム表示信号とロックレポートを示すために、2つのメッセージを定義します。個々のメッセージの意味は以下のサブセクションで説明されています。 OAMメッセージを障害MPLSトランスポートプロファイルで使用されるのLSPに適用されます。そのようなLSPは、クライアント/サーバ関係の静的構成またはシグナリングに基づいて、特定のサーバの層に結合されています。
Fault Management messages are carried in-band of the client LSP or MS-PW by using the Associated Channel Header (ACH). For LSPs other than PWs, the ACH is identified by the Generic Associated Channel Label (GAL) as defined in RFC 5586 [4]. To facilitate recognition and delivery of Fault Management messages, the Fault Management Channel is identified by a unique Associated Channel (ACh) code point.
障害管理メッセージは、関連するチャンネルヘッダー（ACH）を使用することにより、帯域内のクライアントLSPまたはMS-PWの搭載されています。 RFC 5586で定義されているのPW以外のLSPのために、ACHは、[4]一般的な関連するチャネル・ラベル（GAL）によって識別されます。認識と障害管理メッセージの配信を容易にするために、障害管理チャンネルは独自の関連するチャネル（ACH）コード・ポイントで識別されます。
Fault OAM messages are generated by intermediate nodes where a client LSP is switched. When a server (sub-)layer, e.g., a link or bidirectional LSP, used by the client LSP fails, the intermediate node sends Fault Management messages downstream towards the end point of the LSP. The messages are sent to the client MEPs by inserting them into the affected client LSPs in the direction downstream of the fault location. These messages are sent periodically until the condition is cleared.
障害OAMメッセージは、クライアントLSPが切り替えられる中間ノードによって生成されます。サーバ（サブ）レイヤは、例えば、クライアントLSPによって使用されるリンクまたは双方向LSPは、失敗した場合、中間ノードは、LSPの終点に向けて下流障害管理メッセージを送信します。メッセージは、故障箇所の下流方向に影響を受けるクライアントのLSPにそれらを挿入することによって、クライアントのMEPに送信されます。条件がクリアされるまで、これらのメッセージは定期的に送信されます。
The MPLS Alarm Indication Signal (AIS) message is generated in response to detecting faults in the server (sub-)layer. The AIS message SHOULD be sent as soon as the condition is detected, but MAY be delayed owing to processing in an implementation, and MAY be suppressed if protection is achieved very rapidly. For example, an AIS message may be sent during a protection switching event and would cease being sent (or cease being forwarded by the protection switch selector) if the protection switch was successful in restoring the link. However, an implementation may instead wait to see if the protection switch is successful prior to sending any AIS messages.
MPLSアラーム表示信号（AIS）メッセージがサーバ（副）層の欠陥を検出することに応答して生成されます。 AISメッセージは、条件が検出されるが、実装の処理のために遅延させることができる、と保護は非常に迅速に達成される場合を抑制することができるとすぐに送信されるべきです。保護スイッチがリンクを回復に成功した場合、例えば、AISメッセージが（又は中止保護スイッチセレクタによって転送される）保護スイッチングイベントの間に送信されてもよいし、送られて停止になります。しかし、実装は代わりに保護スイッチを前に任意のAISメッセージを送ることに成功しているかどうかを確認するために待つことがあります。
The primary purpose of the AIS message is to suppress alarms in the layer network above the level at which the fault occurs. When the Link Down Indication is set, the AIS message can be used to trigger recovery mechanisms.
AISメッセージの主な目的は、障害が発生するレベルより上の層のネットワークでアラームを抑制することです。リンクダウンの指示が設定されている場合は、AISメッセージは、回復メカニズムをトリガするために使用することができます。
The Link Down Indication (LDI) is communicated by setting the L-Flag to 1. A node sets the L-Flag in the AIS message in response to detecting a failure in the server layer. A node MUST NOT set the L-Flag until the fault has been determined to be a server-failure. A node MUST set the L-Flag if the fault has been determined to be a server-failure. For example, during a server layer protection switching event, a node MUST NOT set the L-Flag. However, if the protection switch was unsuccessful in restoring the link within the expected repair time, the node MUST set the L-Flag.
リンクダウン指示（LDI）は、ノードは、サーバレイヤの障害の検出に応答してAISメッセージにL-フラグをセット1にL-フラグを設定することによって通信されます。障害がサーバの障害であることが決定されるまで、ノードはL-フラグを設定してはいけません。障害がサーバの障害であると判断された場合、ノードは、L-フラグを設定する必要があります。例えば、サーバ層保護スイッチングイベントの間、ノードはL-フラグを設定してはいけません。保護スイッチが予想修理時間以内にリンクを回復させるのに失敗した場合は、ノードは、L-フラグを設定する必要があります。
The setting of the L-Flag can be predetermined based on the protection state. For example, if a server layer is protected and both the working and protection paths are available, the node should send AIS with the L-Flag clear upon detecting a fault condition. If the server layer is unprotected, or the server layer is protected but only the active path is available, the node should send AIS with the L-Flag set upon detecting a loss of continuity (LOC) condition. Note again that the L-Flag is not set until a server-failure has been declared. Thus, if there is any hold-off timer associated with the LOC, then the L-Flag is not set until that timer has expired.
L-フラグの設定が保護状態に基づいて予め決定することができます。例えば、サーバ層が保護され、現用と予備パスの両方は、ノードが障害状態を検出したときクリアL-フラグでAISを送信する必要があり、利用可能です。サーバ層が保護されていない、またはサーバ層が保護されるだけアクティブパスが利用可能である場合、ノードは、連続（LOC）状態の喪失を検出すると設定L-フラグでAISを送信します。サーバの障害が宣言されるまでL-フラグが設定されていないことを再度注意してください。 LOCに関連付けられた任意のホールドオフタイマーがある場合、そのタイマーが満了するまでこのように、その後、L-フラグが設定されていません。
The receipt of an AIS message with the L-Flag set MAY be treated as the equivalent of LOC at the client layer. The choice of treatment is related to the rate at which the Continuity Check (CC) function is running. In a normal transport environment, CC is run at a high rate in order to detect a failure within tens of milliseconds. In such an environment, the L-Flag MAY be ignored and the AIS message is used solely for alarm suppression.
L-フラグが設定されたAISメッセージの受信は、クライアント層でLOCの等価として扱うことができます。治療の選択は、導通チェック（CC）機能が動作している速度に関連しています。通常の輸送環境では、CCは数十ミリ秒以内の故障を検出するために高いレートで実行されます。このような環境では、L-フラグは無視されるかもしれませんし、AISメッセージがアラーム抑制のためだけに使用されています。
In more general MPLS environments, the CC function may be running at a much slower rate. In this environment, the Link Down Indication enables faster switch-over upon a failure occurring along the client LSP.
より一般的なMPLS環境では、CC機能は、はるかに遅い速度で走行することができます。この環境では、リンクダウンの指示は、クライアントのLSPに沿って発生した障害時に高速切り替えができます。
The MPLS Lock Report (LKR) message is generated when a server (sub-)layer entity has been administratively locked. Its purpose is to communicate the locked condition to the client-layer entities. When a server layer is administratively locked, it is not available to carry client traffic. The purpose of the LKR message is to suppress alarms in the layer network above the level at which the administrative lock occurs and to allow the clients to differentiate the lock condition from a fault condition. While the primary purpose of the LKR message is to suppress alarms, similar to AIS with the LDI (L-Flag set), the receipt of an LKR message can be treated as the equivalent of loss of continuity at the client layer.
サーバー（サブ）レイヤエンティティが管理ロックされているとき、MPLSロック報告書（LKR）メッセージが生成されます。その目的は、クライアントレイヤエンティティにロックされた状態を伝えることです。サーバー層が管理上ロックされている場合は、クライアントのトラフィックを伝送することはできません。 LKRメッセージの目的は、管理ロックが発生するレベルより上の層のネットワークでアラームを抑制するために、クライアントは、故障状態からロック状態を区別できるようにすることです。 LKRメッセージの主な目的は、LDI（L-フラグセット）を有するAISと同様のアラームを抑制することであるが、LKRメッセージの受信は、クライアント層での連続の損失の等価として扱うことができます。
MPLS-TP allows for a hierarchy of LSPs. When the client MEP of an LSP (that is also acting as a server layer) receives FM indications, the following rules apply. If the CC function is disabled for the server LSP, a node SHOULD generate AIS messages toward any clients when either the AIS or LKR indication is raised. Note that the L-Flag is not automatically propagated. The rules of Section 2.1.1 apply. In particular, the L-Flag is not set until a server-failure has been declared.
MPLS-TPは、LSPの階層が可能になります。 LSP（それはまた、サーバー層として機能している）のクライアントMEPは、FMの兆候を受信した場合、次の規則が適用されます。 CC機能は、サーバーLSPのために無効になっている場合、ノードは、いずれかのAISまたはLKR表示が提起されている任意のクライアントに向かってAISメッセージを生成する必要があります。 L-フラグが自動的に反映されていないことに注意してください。 2.1.1項の規則が適用されます。サーバの障害が宣言されるまで具体的には、L-フラグが設定されていません。
The MPLS Fault Management channel is identified by the ACH as defined in RFC 5586 [4] with the Associated Channel Type set to the MPLS Fault Management (FM) code point = 0x0058. The FM Channel does not use ACh TLVs and MUST NOT include the ACh TLV header. The ACH with the FM ACh code point is shown below.
RFC 5586で定義されているMPLS障害管理チャネルは、ACHによって識別される[4]に関連するチャネルタイプには、MPLS障害管理（FM）コードポイント= 0x0058に設定します。 FMチャンネルのACh TLVを使用していないとのACh TLVヘッダを含んではいけません。 FMのAChのコードポイントとACHを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x0058 FM Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS Fault Management Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of the MPLS Fault Management Channel
図1：MPLS障害管理チャンネルのACHの表示
The first three fields are defined in RFC 5586 [4].
最初の3つのフィールドは、RFC 5586で定義されている[4]。
The Fault Management Channel is 0x0058.
障害管理チャンネルは0x0058です。
The format of the Fault Management message is shown below.
障害管理メッセージのフォーマットを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Resvd | Msg Type | Flags | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS Fault OAM Message Format
図2：MPLS OAM障害メッセージの形式
Version
版
The Version Number is currently 1.
バージョン番号は現在1です。
Reserved
予約済み
This field MUST be set to zero on transmission and ignored on receipt.
このフィールドは、送信時にゼロに設定して、領収書の上で無視しなければなりません。
Message Type
メッセージの種類
The Message Type indicates the type of condition as listed in the table below.
以下の表に示すメッセージ・タイプは、条件のタイプを示します。
Msg Type Description
-------- -----------------------------
0 Reserved
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
Flags
国旗
Two flags are defined. The reserved flags in this field MUST be set to zero on transmission and ignored on receipt.
二つのフラグが定義されています。このフィールドの予約済みフラグは、送信にゼロに設定され、領収書の上で無視しなければなりません。
+-+-+-+-+-+-+-+-+
| Reserved |L|R|
+-+-+-+-+-+-+-+-+
Figure 3: Flags
図3：フラグ
L-Flag
L-旗
Link Down Indication. The L-Flag only has significance in the AIS message. For the LKR message, the L-Flag MUST be set to zero and ignored on receipt. See Section 2.1.1 for details on setting this bit.
指示をダウンリンクします。 L-フラグのみAISメッセージで意味を持ちます。 LKRメッセージを、L-フラグをゼロに設定しなければならなくて、領収書の上で無視します。このビットの設定の詳細については、セクション2.1.1を参照してください。
R-Flag
R-旗
The R-Flag is clear to indicate the presence of an FM condition and is set to one to indicate the removal of a previously sent FM condition.
R-フラグFM状態の存在を示すことが明らかであると以前に送信されたFM条件の除去を示すために1に設定されています。
Refresh Timer
リフレッシュタイマ
The maximum time between successive FM messages specified in seconds. The range is 1 to 20. The value 0 is not permitted.
秒単位で指定された連続したFMメッセージ間の最大時間。範囲は1〜20の値0が許可されていません。
Total TLV Length
総TLVの長さ
The total length in bytes of all included TLVs.
全てのバイト単位の全長はTLVを含んでいました。
TLVs are used in Fault Management messages to carry information that may not pertain to all messages as well as to allow for extensibility. The TLVs currently defined are the IF_ID and the Global_ID.
TLVがすべてのメッセージに関係ないかもしれないだけでなく、拡張性を可能にするための情報を運ぶために障害管理メッセージで使用されています。現在定義されているのTLVはIF_IDとGlobal_IDです。
TLVs have the following format:
TLVの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| .
. Value .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Fault TLV Format
図4：障害TLVフォーマット
Type
タイプ
Encodes how the Value field is to be interpreted.
Valueフィールドがどのように解釈されるかエンコードします。
Length
長さ
Specifies the length of the Value field in octets.
オクテットで値フィールドの長さを指定します。
Value
値
Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
Typeフィールドによって指定されるように解釈されるべき情報を符号化長さオクテットのオクテットストリング。
The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in RFC 6370 [5]. The Type is 1. The length is 0x8.
RFC 6370で定義されるようにインタフェース識別子（IF_ID）TLV [5] IF_IDを運びます。タイプは、長さが0x8の1です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Interface Identifier TLV Format
図5：インタフェース識別子TLVのフォーマット
The Global Identifier (Global_ID) TLV carries the Global_ID as defined in RFC 6370 [5]. The Type is 2. The length is 0x4.
RFC 6370で定義されているグローバル識別子（Global_ID）TLV [5] Global_IDを運びます。タイプは、長さが0x4にある2です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Global Identifier TLV Format
図6：グローバル識別子TLVのフォーマット
Service disruptive conditions are indicated by sending FM messages. The message type is set to the value corresponding to the condition. The Refresh Timer is set to the maximum time between successive FM messages. This value MUST NOT be changed on successive FM messages reporting the same incident. If the optional clearing procedures are not used, then the default value is one second. Otherwise, the default value is 20 seconds.
サービスの破壊的な条件は、FMメッセージを送ることによって示されています。メッセージタイプは、条件に対応する値に設定されています。リフレッシュタイマは、連続したFMメッセージ間の最大時間に設定されています。この値は、同じ事件を報告し、連続FMメッセージに変更してはいけません。オプションのクリア手順が使用されていない場合、デフォルト値は1秒です。そうでない場合は、デフォルト値は20秒です。
A Global_ID MAY be included. If the R-Flag clearing procedures are to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV MAY be included.
Global_IDが含まれるかもしれません。 R-フラグクリア手順が使用される場合、IF_ID TLVを含まなければなりません。それ以外の場合は、IF_ID TLVが含まれるかもしれません。
The message is then sent. Assuming the condition persists, the message MUST be retransmitted two more times at an interval of one second. Further retransmissions are made according to the value of the Refresh Timer. Retransmissions continue until the condition is cleared.
メッセージが送信されます。状態が続くと仮定すると、メッセージは、1秒間隔でさらに2回再送信されなければなりません。さらに、再送信は、リフレッシュタイマの値に基づいて作られています。条件がクリアされるまで再送を続けます。
When a fault is cleared, a node MUST cease sending the associated FM messages. Ceasing to send FM messages will clear the indication after 3.5 times the Refresh Timer. To clear an indication more quickly, the following procedure is used. The R-Flag of the FM message is set to one. Other fields of the FM message SHOULD NOT be modified. The message is sent immediately and then retransmitted two more times at an interval of one second. Note, however, if another fault occurs, the node MUST cease these retransmissions and generate new FM messages for the new fault.
障害がクリアされると、ノードは、関連するFMメッセージの送信を中止しなければなりません。 FMメッセージを送信するために中止して3.5倍のリフレッシュタイマ後に表示をクリアします。より迅速に表示をクリアするには、以下の手順が使用されています。 FMメッセージのR-フラグは1に設定されています。 FMメッセージの他のフィールドは変更しないでください。メッセージは直ちに送信され、次いで、1秒間隔でさらに2回再送信されます。ただし、別の障害が発生した場合、ノードは、新たな障害のための新しいFMメッセージをこれらの再送信を中止し、生成しなければなりません。
When an FM message is received, a MEP examines it to ensure that it is well formed. If the message type is reserved or unknown, the message is ignored. If the version number is unknown, the message is ignored.
FMメッセージを受信した場合、MEPは、それが十分に形成されることを保証するためにそれを調べ。メッセージタイプが予約または未知されている場合は、メッセージは無視されます。バージョン番号が不明な場合は、メッセージは無視されます。
If the R-Flag is set to zero, the MEP checks to see if a condition matching the message type exists. If it does not, the condition specific to the message type is entered. An Expiration timer is set to 3.5 times the Refresh Timer. If the message type matches an existing condition, the message is considered a refresh and the Expiration timer is reset. In both cases, if an IF_ID TLV is present, it is recorded.
Rフラグがゼロに設定されている場合、MEPは、メッセージタイプと一致する条件が存在するかどうかをチェックします。そうでない場合は、メッセージタイプに固有の条件が入力されます。有効期限タイマーは3.5倍のリフレッシュタイマに設定されています。メッセージタイプは、既存の条件と一致した場合、メッセージは、リフレッシュとみなされ、有効期限タイマーがリセットされます。 IF_ID TLVが存在する場合の両方の場合において、それは記録されています。
If the R-Flag is set to one, the MEP checks to see if a condition matching the message type and IF_ID exists. If it does, that condition is cleared. Otherwise, the message is ignored.
R-フラグが1に設定されている場合、MEPは、条件は、メッセージタイプと一致するとIF_IDが存在するかどうかをチェックします。それがない場合は、その条件がクリアされます。そうしないと、メッセージは無視されます。
If the Expiration timer expires, the condition is cleared.
有効期限タイマーが満了した場合、条件がクリアされます。
At a minimum, an implementation MUST support the following:
最低でも、実装は次のことをサポートしなければなりません：
3. Receiving AIS and LKR messages with any allowed Refresh Timer value.
3.任意の許可リフレッシュタイマ値とAISとLKRメッセージを受信します。
The following items are OPTIONAL to implement.
以下の項目は、実装するオプションです。
1. Sending AIS and LKR messages with values of the Refresh Timer other than one second.
1.一つの第二以外のリフレッシュタイマの値とAISとLKRメッセージを送信します。
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of the security model of MPLS. MPLS networks make the assumption that it is very hard to inject traffic into a network, and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see RFC 5920 [8].
MPLS-TPは、MPLSのサブセットであるので、MPLSのセキュリティモデルの特徴の多くの上に構築されています。 MPLSネットワークは、ネットワークの外に向けられるべきトラフィックを引き起こすためにネットワークにトラフィックを注入するのは非常に難しい、と同じようにハードであるという仮定を作ります。制御プレーンプロトコルは、ホップバイホップセキュリティを利用すると、エンドツーエンドのコントロールプレーンのセキュリティが使用されないように、「チェーン・オブ・トラスト」モデルを想定します。 MPLSセキュリティの一般的な側面についての詳細は、RFC 5920 [8]を参照してください。
This document describes a protocol carried in the G-ACh (RFC 5586 [4]) and so is dependent on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in RFC 4385 [6]. Thus, this document relies heavily on the security mechanisms provided for the Associated Channel as described in those two documents.
この文書では、G-ACHで運ばれるプロトコルについて説明（RFC 5586 [4]）ので、G-ACH自体のセキュリティに依存しています。 G-ACHは、RFC 4385で定義された関連するチャネルの一般化である[6]。したがって、このドキュメントはこれら二つの文書で説明したように、関連するチャネルのために提供されているセキュリティ・メカニズムに大きく依存しています。
A specific concern for the G-ACh is that is can be used to provide a covert channel. This problem is wider than the scope of this document and does not need to be addressed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD
G-ACHに特異的な関心事であるが、隠れチャネルを提供するために使用することができることです。この問題は、このドキュメントの範囲よりも広く、かつ、ここで対処する必要はありませんが、チャネルは、エンドツーエンドの接続性を提供しなければならないことに注意すべき
NOT be policed by transit nodes. Thus, there is no simple way of preventing any traffic being carried in the G-ACh between consenting nodes.
トランジットノードによってポリシングがありません。したがって、同意ノード間G-ACHで搬送されるすべてのトラフィックを防止する簡単な方法は存在しません。
A good discussion of the data-plane security of an Associated Channel may be found in RFC 5085 [9]. That document also describes some mitigation techniques.
関連するチャネルのデータプレーンのセキュリティの良好な議論は、RFC 5085に見出すことができる[9]。その文書はまた、いくつかの緩和技術について説明します。
It should be noted that the G-ACh is essentially connection-oriented, so injection or modification of control messages specified in this document requires the subversion of a transit node. Such subversion is generally considered hard to protect against in MPLS networks, and impossible to protect against at the protocol level. Management-level techniques are more appropriate.
G-ACHは、本質的にコネクション指向であるため、この文書で指定された制御メッセージの注射または修飾がトランジットノードの転覆を必要とすることに留意すべきです。そのような転覆は、一般的に、プロトコルレベルで保護するためにMPLSネットワークにおけるに対して保護するのは難しい、そして不可能であると考えられます。管理レベルの技術は、より適切です。
Spurious fault OAM messages form a vector for a denial-of-service attack. However, since these messages are carried in a control channel, except for one case discussed below, one would have to gain access to a node providing the service in order to effect such an attack. Since transport networks are usually operated as a walled garden, such threats are less likely.
スプリアス障害OAMメッセージは、サービス拒否攻撃のベクトルを形成します。これらのメッセージは、制御チャネルで搬送されているので、以下に説明する一つの場合を除いて、一つはそのような攻撃を行うためにサービスを提供するノードにアクセスしなければなりません。トランスポート・ネットワークは通常、壁に囲まれた庭園として運用されているので、このような脅威は少ない可能性があります。
If external MPLS traffic is mapped to an LSP via a PHP forwarding operation, it is possible to insert a GAL followed by a fault OAM message. In such a situation, an operator SHOULD protect against this attack by filtering any fault OAM messages with the GAL at the top of the label stack.
外部MPLSトラフィックはPHP転送操作を介してLSPにマッピングされる場合、障害OAMメッセージ続いGALを挿入することが可能です。このような状況では、オペレータは、ラベルスタックの最上位にGALにすべての障害OAMメッセージをフィルタリングすることにより、この攻撃から保護する必要があります。
Fault OAM requires a unique Associated Channel Type that has been assigned by IANA from the Pseudowire Associated Channel Types registry.
障害OAMは、擬似回線関連するチャネルタイプレジストリからIANAによって割り当てられたユニークな関連するチャネルタイプが必要です。
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0058 Fault OAM No (This Document)
This section details the "MPLS Fault OAM Message Type Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values (as defined in RFC 5226 [7]): "Standards Action" and "Experimental Use".
このセクションでは、「MPLS OAM障害メッセージタイプレジストリ」、「マルチプロトコルラベルスイッチング（MPLS）運用、管理、および管理（OAM）パラメータ」レジストリの新しいサブレジストリを詳述します。タイプ空間が割り当て範囲に分割されます。 （RFC 5226で定義されている[7]）以下の用語は、IANAに値を割り当てるれる手順を説明するのに使用される：「標準アクション」および「実験用」。
MPLS Fault OAM Message Types take values in the range 0-255. Assignments in the range 0-251 are via Standards Action; values in the range 252-255 are for Experimental Use and MUST NOT be allocated.
MPLS OAM障害メッセージタイプは0〜255の範囲の値をとります。範囲0から251での割り当ては標準アクションを経由しています。範囲252から255の値は実験用であり、割り当てられてはなりません。
Message Types defined in this document are:
この文書で定義されたメッセージタイプは以下のとおりです。
Msg Type Description
-------- -----------------------------
0 Reserved (not available for allocation)
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
This section details the "MPLS Fault OAM Flag Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Flag space ranges from 0-7. All flags are allocated by "Standards Action" (as defined in RFC 5226 [7]).
このセクションでは、「MPLS OAM障害旗レジストリ」、「マルチプロトコルラベルスイッチング（MPLS）運用、管理、および管理（OAM）パラメータ」レジストリの新しいサブレジストリを詳述します。旗空間は0-7の範囲です。全てのフラグを「標準アクション」（RFC 5226で定義されている[7]）によって割り当てられます。
Flags defined in this document are:
この文書で定義されたフラグは次のとおりです。
Bit Hex Value Description
--- --------- -----------
0-5 Unassigned
6 0x2 L-Flag
7 0x1 R-Flag
This sections details the "MPLS Fault OAM TLV Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values (as defined in RFC 5226 [7]): "Standards Action", "Specification Required", and "Experimental Use".
このセクションでは、「MPLS OAM障害TLVレジストリ」、「マルチプロトコルラベルスイッチング（MPLS）運用、管理、および管理（OAM）パラメータ」レジストリの新しいサブレジストリを詳述します。タイプ空間が割り当て範囲に分割されます。 （RFC 5226で定義されている[7]）以下の用語は、IANAに値を割り当てるれる手順を説明するのに使用される：「標準アクション」、「仕様が必要」、および「実験用」。
MPLS Fault OAM TLVs take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-247 are made via "Specification Required"; values in the range 248-255 are for Experimental Use and MUST NOT be allocated.
MPLS OAM障害のTLVは、0〜255の範囲内の値をとります。範囲0から191での割り当ては標準アクションを経由しています。範囲192から247での割り当ては、「仕様が必要」を経由して作られています。範囲248-255の値は実験用であり、割り当てられてはなりません。
TLVs defined in this document are:
この文書で定義されたTLVは以下のとおりです。
Value TLV Name
----- -------
0 Reserved (not available for allocation)
1 Interface Identifier TLV
2 Global Identifier
[1] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[1]ニーヴン-ジェンキンス、B.、編。、Brungard、D.、編、ベッツ、M.編、Sprecher、N.、およびS.上野、 "MPLSトランスポートプロファイルの要件"、RFC 5654 2009年9月。
[2] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[2] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "運用、管理、およびMPLS交通ネットワークのメンテナンス（OAM）のための要件"、RFC 5860、2010年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[4]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、RFC 5586、2009年6月。
[5] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[5]ボッチ、M.、ツバメ、G.、およびE.グレー、 "MPLSトランスポートプロファイル（MPLS-TP）識別子"、RFC 6370、2011年9月。
[6] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[6]ブライアント、S.、ツバメ、G.、マルティーニ、L.、及びD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジ・ツー・エッジ（PWE3）コントロールワード"、RFC 4385、2006年2月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[7] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[8] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[8]牙、L.、エド。、RFC 5920、2010年7月 "MPLSとGMPLSネットワークのセキュリティフレームワーク"。
[9] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[9]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK
スチュワートブライアントシスコシステムズ社250、Longwaterグリーンパーク、読書RG2 6ギガバイト英国
EMail: stbryant@cisco.com
メールアドレス：stbryant@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
シヴァシババランシスコシステムズ株式会社2000年イノベーションドライブカナタ、オンタリオK2K 3E8カナダ
EMail: msiva@cisco.com
メールアドレス：msiva@cisco.com
Authors' Addresses
著者のアドレス
George Swallow (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States
ジョージスワロー（エディタ）は、Cisco Systems、Inc.の300ビーバーブルック・ロードボックスボロー、マサチューセッツ01719米国
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy
Annamaria Fulignoli（エディタ）エリクソン経由Moruzzi 56100ピサイタリア
EMail: annamaria.fulignoli@ericsson.com
メールアドレス：annamaria.fulignoli@ericsson.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
マーティン・ヘイル（編集者）アルカテル・ルーセントルートNozay 91620ヴィルジュフランス
EMail: martin.vigoureux@alcatel-lucent.com
メールアドレス：martin.vigoureux@alcatel-lucent.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
サミBoutrosシスコシステムズ株式会社3750シスコウェイサンノゼ、カリフォルニア95134 USA
EMail: sboutros@cisco.com
メールアドレス：sboutros@cisco.com
David Ward Juniper Networks, Inc.
デビッド・ウォードジュニパーネットワークス株式会社
EMail: dward@juniper.net
メールアドレス：dward@juniper.net