[要約] RFC 6427は、MPLSネットワークの障害管理、運用、および保守（OAM）に関する標準を提供します。このRFCの目的は、MPLSネットワークの信頼性とパフォーマンスを向上させるために、OAM機能を定義することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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ベースの輸送ネットワークは、従来の輸送回路に相当するメカニズムを提供します。したがって、MPLSに対して障害管理（FM）機能を定義する必要があります。このドキュメントでは、RFC 5654 [1]で説明されているMPLS-TP要件を満たすFM機能と、RFC 5860 [2]に記載されているMPLS-TP操作、管理、およびメンテナンス要件を定義しています。これらのメカニズムは、MPLSの他の側面にも適用できることを目的としています。ただし、他のタイプのLSPへの適用性は、このドキュメントの範囲を超えています。
Two broad classes of service disruptive conditions are identified.
2つの広範なサービス破壊的条件が特定されています。
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. ロック：Test Traffic（もしあればTest Trafficと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
このドキュメントは、「MPLS-OAM障害管理（FM）」チャネルと呼ばれるMPLS OAMチャネルを指定します。サービスの破壊的条件を通信するために、単一のメッセージ形式と一連の手順が定義されています
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.
それらが発生する場所から、それらの条件の影響を受ける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つのクラスのサービス破壊的条件に対応して、2つのメッセージが定義され、条件のタイプを通信します。これらは次のように知られています：
Alarm Indication Signal (AIS)
アラーム表示信号（AIS）
Lock Report (LKR)
ロックレポート（LKR）
ACH: Associated Channel Header
ACH：関連するチャネルヘッダー
ACh: Associated Channel
ACH：関連チャネル
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：最後から2番目のホップポップ
PW: Pseudowire
PW：Pseudowire
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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の帯域内に搭載されます。PWS以外のLSPの場合、ACHは、RFC 5586 [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）は、L-FLAGを1に設定することにより通信されます。ノードは、サーバーレイヤーの障害の検出に応じてAISメッセージにL-FLAGを設定します。ノードは、障害がサーバーフェイルであると判断されるまでL-Flagを設定してはなりません。障害がサーバーフェイルであると判断された場合、ノードはL-FLAGを設定する必要があります。たとえば、サーバーレイヤー保護スイッチングイベント中に、ノードはL-Flagを設定してはなりません。ただし、予想される修復時間内にリンクの復元に保護スイッチが失敗した場合、ノードはL-Flagを設定する必要があります。
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-flagの設定は、保護状態に基づいて事前に決定できます。たとえば、サーバーレイヤーが保護されており、作業パスと保護パスの両方が利用可能な場合、ノードは障害状態を検出するとL-FLAGがクリアされてAIを送信する必要があります。サーバーレイヤーが保護されていない場合、またはサーバーレイヤーが保護されているがアクティブパスのみが利用可能な場合、ノードは連続性（LOC）条件の損失を検出するとL-FLAGを設定してAISを送信する必要があります。サーバーフェイルが宣言されるまで、L-Flagは設定されないことに再度注意してください。したがって、LOCに関連付けられたホールドオフタイマーがある場合、そのタイマーが期限切れになるまでL-FLAGは設定されません。
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-FLAGセットを使用したAISメッセージの受信は、クライアントレイヤーのLOCに相当するものとして扱うことができます。治療の選択は、連続性チェック（CC）関数が実行されている速度に関連しています。通常の輸送環境では、CCは数十ミリ秒以内の障害を検出するために高速で実行されます。このような環境では、L-FLAGは無視され、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
MPLSロックレポート（LKR）メッセージは、サーバー（サブ）レイヤーエンティティが管理上ロックされているときに生成されます。その目的は、ロックされた状態をクライアント層エンティティに伝えることです。サーバーレイヤーが管理上ロックされている場合、クライアントトラフィックを運ぶことはできません。LKRメッセージの目的は次のとおりです
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.
管理ロックが発生するレベルより上のレイヤーネットワークのアラームを抑制し、クライアントがロック条件を障害条件と区別できるようにします。LKRメッセージの主な目的は、LDI（L-Flagセット）の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表示を受け取ると、次のルールが適用されます。サーバーLSPに対してCC関数が無効になっている場合、AISまたはLKRの表示が発生した場合、ノードは任意のクライアントに対してAISメッセージを生成する必要があります。L-FLAGは自動的に伝播されないことに注意してください。セクション2.1.1の規則が適用されます。特に、サーバーフェイルが宣言されるまでL-Flagは設定されません。
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.
MPLS障害管理チャネルは、RFC 5586 [4]で定義されているACHによって識別され、関連するチャネルタイプが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.
2つのフラグが定義されています。このフィールドの予約されたフラグは、送信時にゼロに設定し、受領時に無視する必要があります。
+-+-+-+-+-+-+-+-+
| Reserved |L|R|
+-+-+-+-+-+-+-+-+
Figure 3: Flags
図3：フラグ
L-Flag
l-flag
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-flagは、AISメッセージでのみ重要です。LKRメッセージの場合、l-flagはゼロに設定し、受領時に無視する必要があります。このビットの設定の詳細については、セクション2.1.1を参照してください。
R-Flag
r-flag
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-Flagは、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.
値フィールドの解釈方法をエンコードします。
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.
型フィールドで指定されていると解釈される情報をエンコードする長さのオクテットのオクテット文字列。
The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in RFC 6370 [5]. The Type is 1. The length is 0x8.
インターフェイス識別子（IF_ID）TLVは、RFC 6370 [5]で定義されているIF_IDを運びます。タイプは1です。長さは0x8です。
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.
Global Identifier（Global_Id）TLVは、RFC 6370 [5]で定義されているGlobal_IDを運びます。タイプは2です。長さは0x4です。
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-FLAGクリアリング手順を使用する場合、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-flagは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-flagがゼロに設定されている場合、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-flagが1に設定されている場合、MEPはメッセージタイプとif_idが存在する条件が存在するかどうかを確認します。もしそうなら、その状態はクリアされます。それ以外の場合、メッセージは無視されます。
If the Expiration timer expires, the condition is cleared.
有効期限タイマーが期限切れになった場合、状態はクリアされます。
At a minimum, an implementation MUST support the following:
少なくとも、実装は以下をサポートする必要があります。
1. Sending AIS and LKR messages at a rate of one per second.
1. AISおよびLKRメッセージを1秒あたり1倍の割合で送信します。
2. Support of setting the L-Flag to indicate a server-failure.
2. L-FLAGを設定して、サーバーフェイルを示すことをサポートします。
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. 1秒以外の更新タイマーの値でAISおよびLKRメッセージを送信します。
2. Support of receiving the L-Flag.
2. l-flagの受信のサポート。
3. Support of setting the R-Flag to a value other than zero.
3. r-flagをゼロ以外の値に設定するサポート。
4. Support of receiving the R-Flag.
4. R-Flagの受信のサポート。
5. All TLVs.
5. すべてのTLV。
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]。したがって、このドキュメントは、これら2つのドキュメントで説明されているように、関連するチャネルに提供されるセキュリティメカニズムに大きく依存しています。
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メッセージは、サービス拒否攻撃のためのベクトルを形成します。ただし、これらのメッセージはコントロールチャネルで運ばれているため、以下で説明する1つのケースを除き、そのような攻撃を行うためにサービスを提供するノードにアクセスする必要があります。輸送ネットワークは通常、壁に囲まれた庭として運営されているため、そのような脅威の可能性は低くなります。
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にマッピングされた場合、GALを挿入すると、フォールトOAMメッセージが続くことができます。このような状況では、オペレーターは、ラベルスタックの上部にあるGALで障害OAMメッセージをフィルタリングすることにより、この攻撃から保護する必要があります。
Fault OAM requires a unique Associated Channel Type that has been assigned by IANA from the Pseudowire Associated Channel Types registry.
Fault OAMには、Pseudowire関連チャネルタイプレジストリから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
このセクションでは、「マルチプロトコルラベルスイッチング（MPLS）操作、管理、および管理（OAM）パラメーター」レジストリの新しいサブレジストリである「MPLS障害OAMメッセージタイプレジストリ」について詳しく説明しています。タイプスペースは割り当て範囲に分割されます。
following terms are used in describing the procedures by which IANA allocates values (as defined in RFC 5226 [7]): "Standards Action" and "Experimental Use".
次の用語は、IANAが値を割り当てる手順（RFC 5226 [7]で定義されているように）の説明に使用されます：「標準アクション」および「実験的使用」。
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 Fault OAM Flag Registry」について詳しく説明しています。フラグスペースの範囲は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）パラメーター」レジストリの新しいサブレジストリである「MPLS障害OAM TLVレジストリ」について詳しく説明しています。タイプスペースは割り当て範囲に分割されます。以下の用語は、IANAが値を割り当てる手順（RFC 5226 [7]で定義されている）の説明に使用されます：「標準アクション」、「必要な仕様」、および「実験的使用」。
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] Niven-Jenkins、B.、Ed。、Brungard、D.、Ed。、Betts、M.、Ed。、Sprecher、N.、およびS. Ueno、「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.、Ed。、ed。、Ward、D.、ed。、およびM. Betts、ed。、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[4] Bocci、M.、ed。、vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、RFC 5586、2009年6月。
[5] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[5] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介した使用のための単語」、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] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、RFC 5920、2010年7月。
[9] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[9] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、RFC 5085、2007年12月。
Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK
Stewart Bryant Cisco Systems、Inc。250、Longwater Green Park、RG2 6GB UKを読む
EMail: stbryant@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan Cisco Systems、Inc。2000イノベーションドライブカナタ、オンタリオK2K 3E8カナダ
EMail: msiva@cisco.com
Authors' Addresses
著者のアドレス
George Swallow (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States
George Swallow（編集者）Cisco Systems、Inc。300 Beaver Brook Road Boxborough、マサチューセッツ01719米国
EMail: swallow@cisco.com
Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy
アナマリア・フリニョーリ（編集者）モルッツィ・ピサ56100イタリア経由のエリクソン
EMail: annamaria.fulignoli@ericsson.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Martin Vigoureux（編集者）Alcatel-Lucent Route de Villejust Nozay 91620フランス
EMail: martin.vigoureux@alcatel-lucent.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
Sami Boutros Cisco Systems、Inc。3750 Cisco Way San Jose、California 95134 USA
EMail: sboutros@cisco.com
David Ward Juniper Networks, Inc.
David Ward Juniper Networks、Inc。
EMail: dward@juniper.net