Internet Engineering Task Force (IETF) D. Allan, Ed.
Request for Comments: 6428 Ericsson
Category: Standards Track G. Swallow, Ed.
ISSN: 2070-1721 Cisco Systems, Inc.
J. Drake, Ed.
Juniper
November 2011
Proactive Connectivity Verification, Continuity Check, and
Remote Defect Indication for the MPLS Transport Profile
Abstract
抽象
Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM).
連続性チェック、プロアクティブ接続検証、およびリモート障害表示の機能は、MPLSトランスポートプロファイル（MPLS-TP）の操作、管理、および保守（OAM）のために必要とされます。
Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section.
導通チェックは継続欠陥の損失のためのラベルスイッチパスを監視します。接続性検証は、所望のソースを所望のシンクに接続されていることの確認を提供するために、導通チェックを増強します。リモート障害表示を報告するために、エンドポイントを有効にし、それに関連するエンドポイントに、それは、疑似回線上で検出した障害または欠陥状態は、ラベルはパス、またはセクションを交換しました。
This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo.
この文書では、双方向フォワーディング検出（BFD）と積極的な連続性チェック、継続性の検証、およびMPLS-TPの疑似回線用リモート障害表示するための方法に関する特定の拡張子を指定し、ラベルはこのメモで延長としてBFDを使用してパス、およびセクションを交換しました。
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/rfc6428.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6428で取得することができます。
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
2. Conventions Used in This Document ...............................3
2.1. Terminology ................................................3
2.2. Requirements Language ......................................5
3. MPLS-TP CC, Proactive CV, and RDI Mechanism Using BFD ...........5
3.1. Existing Capabilities ......................................5
3.2. CC, CV, and RDI Overview ...................................5
3.3. ACH Code Points for CC and Proactive CV ....................6
3.4. MPLS-TP BFD CC Message Format ..............................7
3.5. MPLS-TP BFD Proactive CV Message Format ....................8
3.5.1. Section MEP-ID ......................................9
3.5.2. LSP MEP-ID ..........................................9
3.5.3. PW End Point MEP-ID ................................10
3.6. BFD Session in MPLS-TP Terminology ........................10
3.7. BFD Profile for MPLS-TP ...................................11
3.7.1. Session Initiation and Modification ................12
3.7.2. Defect Entry Criteria ..............................13
3.7.3. Defect Entry Consequent Action .....................14
3.7.4. Defect Exit Criteria ...............................14
3.7.5. State Machines .....................................15
3.7.6. Configuration of MPLS-TP BFD Sessions ..............17
3.7.7. Discriminator Values ...............................17
4. Configuration Considerations ...................................18
5. IANA Considerations ............................................18
6. Security Considerations ........................................19
7. References .....................................................19
7.1. Normative References ......................................19
7.2. Informative References ....................................20
8. Acknowledgments ................................................20
9. Contributing Authors ...........................................21
In traditional transport networks, circuits are provisioned on two or more switches. Service providers need Operations, Administration, and Maintenance (OAM) tools to detect mis-connectivity and loss of continuity of transport circuits. Both pseudowires (PWs) and MPLS-TP Label Switched Paths (LSPs) [12] emulating traditional transport circuits need to provide the same Continuity Check (CC), proactive Continuity Verification (CV), and Remote Defect Indication (RDI) capabilities as required in RFC 5860 [3]. This document describes the use of Bidirectional Forwarding Detection (BFD) [4] for CC, proactive CV, and RDI of a PW, LSP, or Sub-Path Maintenance Entity (SPME) between two Maintenance Entity Group End Points (MEPs).
伝統的なトランスポート・ネットワークでは、回路は、2つの以上のスイッチにプロビジョニングされています。サービスプロバイダは、輸送回路の継続の誤接続と損失を検出するための操作、管理、および保守（OAM）ツールが必要です。どちらの擬似回線（PWの）およびMPLS-TPラベルは、スイッチパス（LSP）[12]は、伝統的な輸送回路は同じ導通チェック（CC）、積極的な継続性の検証（CV）、およびリモート障害表示（RDI）機能を提供する必要がエミュレートし、必要に応じRFC 5860 [3]。この文書では、2つのメンテナンスエンティティグループのエンドポイント（MEPの）間の双方向フォワーディング検出（BFD）[4] CCのため、積極的なCV、およびPW、LSP、またはサブパスメンテナンスエンティティ（SPME）のRDIの使用を記載しています。
As described in RFC 6371 [13], CC and CV functions are used to detect loss of continuity (LOC) and unintended connectivity between two MEPs (e.g., mis-merging or mis-connectivity or unexpected MEP).
RFC 6371に記載されているように[13]、CCおよびCV機能は連続の喪失（LOC）と2つのMEP（例えば、誤併合または誤接続や予期しないMEP）との間の意図しない接続を検出するために使用されます。
RDI is an indicator that is transmitted by a MEP to communicate to its peer MEP that a signal fail condition exists. RDI is only used for bidirectional LSPs and is associated with proactive CC and CV BFD control packet generation.
RDIは、信号状態が存在失敗ピアMEPと通信するMEPにより送信される指標です。 RDIは、双方向のLSPのために使用され、積極的なCCおよびCV BFD制御パケットの生成に関連しています。
This document specifies the BFD extension and behavior to satisfy the CC, proactive CV monitoring, and the RDI functional requirements for both co-routed and associated bidirectional LSPs. Supported encapsulations include Generic Associated Channel Label (GAL) / Generic Associated Channel (G-ACh), Virtual Circuit Connectivity Verification (VCCV), and UDP/IP. Procedures for unidirectional point-to-point (P2P) and point-to-multipoint (P2MP) LSPs are for further study.
この文書では、CC、積極的なCVの監視、および共同ルーティングおよび関連する双方向のLSPの両方のためのRDI機能要件を満たすためにBFD拡張と動作を指定します。サポートされているカプセル化は、一般的な関連するチャネル・ラベル（GAL）/ジェネリック関連するチャネル（G-ACH）、仮想回線接続性検証（VCCV）、およびUDP / IPが含まれます。単方向ポイントツーポイント（P2P）の手順とポイントツーマルチポイント（P2MP）LSPは今後の検討課題です。
This document utilizes identifiers for MPLS-TP systems as defined in RFC 6370 [9]. Work is ongoing in the ITU-T to define a globally-unique semantic for ITU Carrier Codes (ICCs), and future work may extend this document to utilize ICCs as identifiers for MPLS-TP systems.
この文書は、RFC 6370で定義されているMPLS-TPシステムの識別子を利用する[9]。作業はITUキャリアコード（ICCを）のためのグローバルにユニークなセマンティックを定義するために、そして未来の仕事はMPLS-TPシステムのための識別子としてのICCを利用するために、この文書を延長することができるITU-Tで進行中です。
The mechanisms specified in this document are restricted to BFD asynchronous mode.
この文書で指定されたメカニズムは、非同期モードをBFDに制限されています。
ACH: Associated Channel Header
ACH：関連するチャネルヘッダー
BFD: Bidirectional Forwarding Detection
BFD：双方向フォワーディング検出
CC: Continuity Check
CC：連続性チェック
CV: Connectivity Verification
CV：接続検証
GAL: Generic Associated Channel Label
GAL：ジェネリック関連するチャネル・ラベル
G-ACh: Generic Associated Channel
G-ACH：ジェネリック関連したチャンネル
LDI: Link Down Indication
LDI：リンクダウンの表示
LKI: Lock Instruct
LKI：ロック指示し
LKR: Lock Report
LKR：ロックレポート
LSP: Label Switched Path
LSP：ラベルスイッチパス
LSR: Label Switching Router
LSR：ラベルスイッチングルータ
ME: Maintenance Entity
ME：メンテナンスエンティティ
MEG: Maintenance Entity Group
MEG：メンテナンスエンティティグループ
MEP: Maintenance Entity Group End Point
MEP：メンテナンスエンティティグループエンドポイント
MIP: Maintenance Entity Group Intermediate Point
MIP：メンテナンスエンティティグループの中間点
MPLS: Multiprotocol Label Switching
MPLS：マルチプロトコルラベルスイッチング
MPLS-OAM: MPLS Operations, Administration and Maintenance
MPLS-OAM：MPLS運用、管理および保守
MPLS-TP: MPLS Transport Profile
MPLS-TP：MPLSトランスポートプロファイル
MPLS-TP LSP: Unidirectional or bidirectional Label Switched Path representing a circuit
MPLS-TP LSP：回路を表す単方向または双方向ラベルスイッチパス
MS-PW: Multi-Segment Pseudowire
MS-PW：マルチセグメント擬似回線
NMS: Network Management System
NMS：ネットワーク管理システム
OAM: Operations, Administration, and Maintenance [14]
OAM：オペレーション、管理、およびメンテナンス[14]
PW: Pseudowire
PO：Psefdoviri
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
P/F: Poll/Final
P / F：ポール/決勝
RDI: Remote Defect Indication
RDI：リモート障害表示
SPME: Sub-Path Maintenance Entity
SPME：サブパスメンテナンスエンティティ
TTL: Time To Live
TTL：生存時間
TLV: Type Length Value
TLV：タイプ長さ値
VCCV: Virtual Circuit Connectivity Verification
VCCV：仮想回線接続性検証
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
This document describes procedures for achieve combined CC, CV, and RDI functionality within a single MPLS-TP MEG using BFD. This augments the capabilities that can be provided for MPLS-TP LSPs using existing specified tools and procedures.
この文書では、BFDを使用して、単一のMPLS-TP MEG内で結合CC、CV、およびRDIの機能を実現するための手順を説明します。これは、指定された既存のツールや手順を使用してMPLS-TPのLSPのために提供することが可能な機能を強化します。
A CC-only mode may be provided via protocols and procedures described in RFC 5885 [7] with ACH channel 7. These procedures may be applied to bidirectional LSPs (via the use of the GAL) as well as PWs.
CCのみのモードではこれらの手順7. ACHチャネルと[7] RFC 5885に記載されたプロトコルおよび手順を介して提供することができる双方向のLSP（GALの使用を介して）と同様のPWにも適用することができます。
Implementations may also interoperate with legacy equipment by implementing RFC 5884 [8] for LSPs and RFC 5085 [10] for PWs, in addition to the procedures documented in this memo. In accordance with RFC 5586 [2], when BFD control packets are encapsulated in an IP header, the fields in the IP header are set as defined in RFC 5884 [8]. When IP encapsulation is used, CV mis-connectivity defect detection can be performed by inferring a globally unique source on the basis of the combination of the source IP address and My Discriminator fields.
実装は、このメモに記載された手順に加えて、PWsのためのLSPのためのRFC [8] 5884及びRFC 5085 [10]を実装することによって、レガシー機器と相互運用することができます。 BFD制御パケットがIPヘッダでカプセル化されたときにRFC 5586に従って、[2]、IPヘッダ内のフィールドは、RFC 5884で定義されるように設定されている[8]。 IPカプセル化を使用する場合は、CVの誤接続の欠陥検出は、送信元IPアドレスと私の弁別フィールドの組み合わせに基づいてグローバルに一意のソースを推測することにより行うことができます。
The combined CC, CV, and RDI functionality for MPLS-TP is achieved by multiplexing CC and CV PDUs within a single BFD session. The CV PDUs are augmented with a Source MEP-ID TLV to permit mis-connectivity detection to be performed by sink MEPs.
MPLS-TP用の合成CC、CV、およびRDI機能は、単一のBFDセッション内で多重CCおよびCVのPDUによって達成されます。 CV PDUは、シンクのMEPによって実行されるように誤接続の検出を可能にするために、ソースMEP-ID TLVで補強されています。
The interleaving of PDUs is achieved via the use of distinct encapsulations and code points for generic associated channel (G-ACh) encapsulated BFD depending on whether the PDU format is CC or CV: o CC format: defines a new code point in the Associated Channel Header (ACH) described in RFC 5586 [2]. This format supports Continuity Check and RDI functionalities.
CCフォーマット：O：関連するチャネルにおける新たなコードポイントを定義PDUのインターリービングは、PDUフォーマットがCCまたはCVであるかに応じてBFDをカプセル化ジェネリック関連チャネル（G-ACH）のための別個のカプセル化とコードポイントの使用を介して達成されます。ヘッダ（ACH）は、RFC 5586に記載された[2]。この形式は、連続性チェックとRDIの機能をサポートしています。
o CV format: defines a new code point in the Associated Channel Header (ACH) described in RFC 5586 [2]. The ACH with "MPLS-TP Proactive CV" code point indicates that the message is an MPLS-TP BFD proactive CV message, and information for CV processing is appended in the form of the Source MEP-ID TLV.
O CVフォーマットは：RFC 5586に記載関連するチャネルヘッダ（ACH）に新しいコード・ポイントを定義する[2]。 「MPLS-TPプロアクティブCV」コードポイントとACHメッセージがMPLS-TP BFDプロアクティブCVメッセージであり、CV処理のための情報は、ソースMEP-ID TLVの形で添付されていることを示します。
RDI is communicated via the BFD diagnostic field in BFD CC messages, and the diagnostic code field in CV messages MUST be ignored. It is not a distinct PDU. As per [4], a sink MEP SHOULD encode a diagnostic code of "1 - Control Detection Time Expired" when the time since the last received BFD control packet exceeds the detection time, which is equal to the remote system's Transmit Interval multiplied by the remote system's Detect Multiplier (which is set to 3 in this document). A sink MEP SHOULD encode a diagnostic code of "5 - Path Down" as a consequence of the sink MEP receiving LDI. A sink MEP MUST encode a diagnostic code of "9 - mis-connectivity defect" when CV PDU processing indicates a mis-connectivity defect. A sink MEP that has started sending diagnostic code 5 SHOULD NOT change it to 1 when the detection timer expires.
RDIは、BFD CCメッセージでBFD診断分野を介して伝達され、CVメッセージで診断コードフィールドは無視しなければなりません。それは明確なPDUではありません。最後に受信BFD制御パケットからの時間は、リモートシステムの送信間隔と等しいが乗算された検出時間を超えた場合 - 「コントロール検出時間期限切れ1」に従ってと、[4]、シンクMEPは、診断コードをエンコードする必要があり（このドキュメントでは3に設定されている）リモートシステムの検出乗数。 LDIを受信シンクMEPの結果として - 「パス・ダウン5」シンクMEPは、診断コードを符号化すべきです。 CV PDU処理は誤接続の欠陥を示す場合 - 「誤接続の欠陥9」シンクMEPは、診断コードを符号化しなければなりません。検出タイマが満了したときに診断コードを送信し始めているシンクMEPは、5これを1に変更しないでください。
Figure 1 illustrates the G-ACh encoding for BFD CC-CV-RDI functionality.
図1は、BFD CC-CV-RDI機能のG-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| Flags | BFD CC/CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of MPLS-TP CC/CV/RDI
図1：MPLS-TPのCC / CV / RDIのACHの表示
The first nibble (0001b) indicates the G-ACh as per RFC 5586 [2].
最初のニブル（0001B）は、RFC 5586に従ってG-ACHを示す[2]。
The version and the flags are set to 0 as specified in [2].
[2]で指定されたバージョンとフラグが0に設定されています。
The code point is either
コードポイントのいずれかであります
- BFD CC code point = 0x0022, or
- BFD CCコードポイント= 0x0022、または
- BFD proactive CV code point = 0x0023.
- BFD積極的なCVコードポイント= 0x0023。
CC and CV PDUs apply to all pertinent MPLS-TP structures, including PWs, MPLS LSPs (including SPMEs), and Sections.
CCとCV PDUはPWを、（SPMEs含む）MPLS LSPを、そしてセクションを含むすべての関連するMPLS-TPの構造に適用されます。
CC and CV operations are simultaneously employed on a maintenance entity (ME) within a single BFD session. The expected usage is that normal operation is to send CC BFD protocol data units (PDUs) interleaved with a CV BFD PDU (augmented with a Source MEP-ID and identified as requiring additional processing by the different ACh channel types). The insertion interval for CV PDUs is one per second. Detection of a loss of continuity defect occurs when the time since the last received BFD control packet exceeds the detection time, which is equal to the session periodicity times the remote system's Detect Multiplier (which is set to 3 for the CC code point). Mis-connectivity defects are detected in a maximum of one second.
CCおよびCV動作が同時に単一BFDセッション内で保守エンティティ（ME）上で使用されています。予想される使用は、通常の動作がCV BFD PDU（ソースMEP-IDで拡張と異なるのAChチャネルタイプによる追加処理を必要とすると同定された）と交互CCのBFDプロトコルデータユニット（PDU）を送信することであるということです。 CV PDUに対する挿入間隔は、毎秒1です。最後に受信BFD制御パケットからの時間がセッション周期時間（CCコードポイントの3に設定されている）リモートシステムの検出乗数に等しい検出時間を超えたときに導通不良の損失の検出が起こります。誤接続の欠陥は1秒、最大で検出されます。
The format of an MPLS-TP CC message is shown below.
MPLS-TPのCCメッセージのフォーマットを以下に示します。
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| Flags | BFD CC Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ~ BFD Control Packet ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS-TP CC Message
図2：MPLS-TPのCCメッセージ
As shown in Figure 2, the MPLS-TP CC message consists of the BFD control packet as defined in [4] pre-pended by the G-ACh.
図2に示すように、MPLS-TPのCCメッセージは、[4] G-ACHによって予め保留に定義されているBFD制御パケットから成ります。
The format of an MPLS-TP CV Message is shown below.
MPLS-TP CVメッセージの書式は以下に示されています。
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| Flags | BFD CV Code Point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ BFD Control Packet ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Source MEP-ID TLV ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: MPLS-TP CV Message
図3：MPLS-TP CVメッセージ
As shown in Figure 3, the MPLS-TP CV message consists of the BFD control packet as defined in [4], pre-pended by the ACH and appended by a Source MEP-ID TLV.
図3に示すように、MPLS-TP CVメッセージは、ソースMEP-ID TLVによって[4]、ACHによって予め保留中で定義され、添付としてBFD制御パケットから成ります。
A Source MEP-ID TLV is encoded as a 2-octet field that specifies a Type, followed by a 2-octet Length field, followed by a variable-length Value field. A BFD session will only use one encoding of the Source ID TLV.
ソースMEP-ID TLVは可変長Valueフィールドに続く2オクテットの長さフィールドに続くタイプを指定する2オクテットフィールドとして符号化されます。 BFDセッションが唯一のソースID TLVの1つのエンコーディングを使用します。
The length in the BFD control packet is as per [4]; the length of the Source MEP-ID TLV is not included. There are three possible Source MEP TLVs (corresponding to the MEP-IDs defined in [9]). The type fields are:
BFD制御パケットの長さは、[4]の通りです。ソースMEP-ID TLVの長さが含まれていません。三つの可能なソースMEPのTLVは、（[9]で定義されたMEP-IDに対応する）があります。タイプフィールドは、以下のとおりです。
0 - Section MEP-ID
0 - セクションMEP-ID
1 - LSP MEP-ID
1 - LSP MEP-ID
2 - PW MEP-ID
2 - PW MEP-ID
When the GAL is used, the TTL field of the GAL MUST be set to at least 1, and the GAL MUST be the end of stack label (S=1) as per [2].
GALを使用する場合、GALのTTLフィールドは、少なくとも1に設定しなければなりません、そしてGAL [2]に従ってスタックラベル（S = 1）の終わりでなければなりません。
A node MUST NOT change the value in the Source MEP-ID TLV.
ノードは、ソースMEP-ID TLVの値を変更してはなりません。
When digest-based authentication is used, the Source ID TLV MUST NOT be included in the digest.
ダイジェストベースの認証を使用する場合は、ソースID TLVはダイジェストに含めることはできません。
The IP-compatible MEP-ID for MPLS-TP Sections is the interface ID. The format of the Section MEP-ID TLV is:
MPLS-TPセクションのMEP-ID IP互換のインターフェイスIDです。第MEP-ID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Section MEP-ID TLV Format
図4：セクションMEP-ID TLVフォーマット
Where the Type is of value '0'. The Length is the length of the value fields. The MPLS-TP Global_ID, Node Identifier, and Interface Numbers are as per [9].
タイプは価値がある場合は「0」。長さは、値フィールドの長さです。 MPLS-TP Global_ID、ノード識別子、およびインターフェイス番号[9]の通りです。
The fields for the LSP MEP-ID are as defined in [9]. This is applicable to both LSPs and SPMEs. This consists of the 32-bit MPLS-TP Global_ID, the 32-bit Node Identifier, followed by the 16-bit Tunnel_Num (that MUST be unique within the context of the Node Identifier), and the 16-bit LSP_NUM (that MUST be unique within the context of the Tunnel_Num). The format of the TLV is:
[9]で定義されるようにLSP MEP-IDのフィールドです。これは、LSPをとSPMEsの両方に適用可能です。これは32ビットのMPLS-TP Global_ID、16ビットTunnel_Num続く32ビットのノード識別子（すなわち、ノード識別子のコンテキスト内で一意でなければならない）、及び16ビットLSP_NUM（からなることでなければなりません）Tunnel_Numのコンテキスト内でユニーク。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel_Num | LSP_Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: LSP MEP-ID TLV Format
図5：LSP MEP-ID TLVフォーマット
Where the type is of value '1'. The length is the length of the value fields. The MPLS-TP Global_ID, Node Identifier, Tunnel_Num, and LSP_Num are as per [9].
タイプは価値がある場合は「1」。長さは、値フィールドの長さです。 MPLS-TP Global_ID、ノード識別子、Tunnel_Num、及びLSP_Num [9]の通りです。
The fields for the MPLS-TP PW End Point MEP-ID are as defined in [9]. The format of the TLV is:
[9]で定義されるようにMPLS-TP PWエンドポイントMEP-IDのフィールドです。 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | AGI Length | AGI Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ AGI Value (contd.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: PW End Point MEP-ID TLV Format
図6：PWエンドポイントMEP-ID TLVフォーマット
Where the type is value '2'. The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. The Attachment Group Identifier (AGI) Type is as per [6], and the AGI Length is the length of the AGI value field.
どこタイプは、値「2」です。長さは、次のデータの長さ：Global_ID、ノード識別子、および接続回線ID（AC_ID）は、[9]の通りです。添付グループ識別子（AGI）のタイプは、[6]の通りであり、AGIの長さは、AGI値フィールドの長さです。
A BFD session corresponds to a CC and proactive CV OAM instance in MPLS-TP terminology. A BFD session is enabled when the CC and proactive CV functionality are enabled on a configured Maintenance Entity (ME).
BFDセッションは、MPLS-TPの用語ではCCと積極的なCVのOAMインスタンスに対応しています。 CCと積極的なCV機能が設定さメンテナンスエンティティ（ME）で有効になっているとき、BFDセッションが有効になっています。
When the CC and proactive CV functionality are disabled on an ME, the BFD session transitions to the ADMIN DOWN state, and the BFD session ends.
CCと積極的なCV機能は、ME、ADMIN DOWN状態にBFDセッションの移行、およびBFDセッションの終了に無効になっているとき。
A new BFD session is initiated when the operator enables or re-enables the CC and CV functionality.
オペレータが有効またはCCおよびCV機能を再度有効にするときに新しいBFDセッションが開始されます。
All BFD state changes and P/F exchanges MUST be done using CC packets. P/F and session state information in CV packets MUST be ignored.
すべてのBFDの状態が変化し、P / Fの交換は、CCパケットを使用して行われなければなりません。 P / FとCVパケットにおけるセッション状態情報無視しなければなりません。
BFD operates in asynchronous mode utilizing the encapsulation defined in Section 3 for all sessions in a given MEG. For LSPs, SPMEs, and Sections, this is GAL/G-ACh-encapsulated BFD using the code points specified in Section 3.3. For PWs, this is G-ACh or GAL/G-ACh-encapsulated BFD using the code points specified in Section 3.3. In this mode, the BFD control packets are periodically sent at a configurable time rate. This rate is a fixed value common for both directions of MEG for the lifetime of the MEG.
BFDは、与えられたMEG内のすべてのセッションについては、セクション3で定義されたカプセル化を利用した非同期モードで動作します。 LSPを、SPMEs、およびセクションの場合、これはセクション3.3で指定されたコードポイントを使用してGAL / G-ACH封入BFDです。 PWの場合、これはセクション3.3で指定されたコードポイントを使用してG-ACHまたはGAL / G-ACH封入BFDです。このモードでは、BFD制御パケットを定期的に設定可能な時間のレートで送信されます。この速度は、MEGの寿命のためのMEGの両方向のための共通の固定値です。
This document specifies bidirectional BFD for P2P transport LSPs; hence, all BFD packets MUST be sent with the M bit clear.
この文書では、P2P輸送のLSPのための双方向のBFDを指定します。したがって、すべてのBFDパケットがMビットクリアで送信されなければなりません。
There are two modes of operation for bidirectional LSPs: one in which the session state of both directions of the LSP is coordinated, and one constructed from BFD sessions in such a way that the two directions operate independently but are still part of the same MEG. A single bidirectional BFD session is used for coordinated operation. Two independent BFD sessions are used for independent operation. It should be noted that independent operation treats session state and defect state as independent entities. For example, an independent session can be in the UP state while receiving RDI. For a coordinated session, the session state will track the defect state.
双方向のLSPのための2つの動作モードがあります。LSPの両方向のセッション状態が調整されたもので、2つの方向に独立して動作するが、それでも同じMEGの一部であるようにBFDセッションから構築1。単一の双方向BFDセッションが協調動作のために使用されています。二つの独立したBFDセッションは、独立した動作のために使用されています。独立した動作が独立したエンティティとしてセッション状態や欠陥状態を扱うことに留意すべきです。 RDIを受信しながら、例えば、独立したセッションがUP状態にすることができます。協調セッションの場合、セッション状態は、欠陥状態を追跡します。
In coordinated mode, an implementation SHOULD NOT reset bfd.RemoteDiscr until it is exiting the DOWN state.
それがDOWN状態を終了するまで、協調モードでは、実装はbfd.RemoteDiscrをリセットされることはありません。
In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr upon transitioning to the DOWN state.
独立モードでは、実装はDOWN状態に遷移する際にbfd.RemoteDiscrをリセットしてはいけません。
Overall operation is as specified in RFC 5880 [4] and augmented for MPLS in RFC 5884 [8]. Coordinated operation is as described in [4]. Independent operation requires clarification of two aspects of [4]. Independent operation is characterized by the setting of bfd.MinRxInterval to zero by the MEP that is typically the session originator (referred to as the source MEP), and there will be a session originator at either end of the bidirectional LSP. Each source MEP will have a corresponding sink MEP that has been configured to a transmission interval of zero.
RFC 5880で指定されるように全体的な動作は、[8] [4]及びRFC 5884にMPLSのための拡張です。 [4]で説明されるように協調動作です。独立した動作は、[4]の二つの側面の明確化を必要とします。独立した操作は、典型的には、（ソースMEPと呼ぶ）セッション発信元であるMEPによってゼロにbfd.MinRxIntervalを設定することを特徴とする、双方向LSPの両端にセッション発信者が存在することになります。各ソースMEPは、ゼロの送信間隔に設定されている対応するシンクMEPを有するであろう。
This memo specifies a preferred interpretation of the base specification on how a MEP behaves with a BFD transmit rate set to zero. One interpretation is that no periodic messages on the reverse component of the bidirectional LSP originate with that MEP; it will only originate messages on a state change.
このメモは、MEPはゼロに設定BFD送信レートで動作方法に基本仕様の好ましい解釈を指定します。一つの解釈は、双方向LSPの逆成分には定期的なメッセージがそのMEPと属していないことです。それが唯一の状態変化にメッセージを発信します。
The first clarification is that, when a state change occurs, a MEP set to a transmit rate of zero sends BFD control messages with a one-second period on the reverse component until such time that the state change is confirmed by the session peer. At this point, the MEP set to a transmit rate of zero can resume quiescent behavior. This adds robustness to all state transitions in the RxInterval=0 case.
最初の清澄化は、状態変化が発生した場合、ゼロの送信レートに設定MEPは、状態変化がセッションピアによって確認されるような時間まで逆成分に1秒周期でBFD制御メッセージを送信する、ということです。この時点で、MEPは、静止動作を再開することができ、ゼロの伝送レートに設定しました。これはRxInterval = 0の場合におけるすべての状態遷移に堅牢性を追加します。
The second clarification is that the originating MEP (the one with a non-zero bfd.TxInterval) will ignore a DOWN state received from a zero-interval peer. This means that the zero-interval peer will continue to send DOWN state messages that include the RDI diagnostic code as the state change is never confirmed. This adds robustness to the exchange of RDI on a unidirectional failure (for both session types DOWN with a diagnostic of either control detection period expired or neighbor signaled session down offering RDI functionality).
第二の清澄は、発信MEP（非ゼロbfd.TxInterval有するもの）がDOWN状態がゼロ間隔ピアから受信無視することです。これは、ゼロ間隔ピアが状態変化が確認されることはありませんようRDI診断コードが含まれる状態メッセージをDOWN送信し続けることを意味します。これは、（DOWNのいずれかの制御検出期間の診断の両方のセッション・タイプ期限切れまたは隣人がRDI機能を提供し、セッションをダウン合図するための）単一故障でRDIの交換にロバスト性を追加します。
A further extension to the base specification is that there are additional OAM protocol exchanges that act as inputs to the BFD state machine. These are the Link Down Indication [5] and the Lock Instruct/Lock Report transactions, the Lock Report interaction being optional.
基本仕様のさらなる拡張は、BFD状態マシンへの入力として働く追加のOAMプロトコル交換があることです。これらは、リンクダウンの表示[5]とロックに指示/ロックレポートトランザクション、ロックレポートの相互作用は、オプションされています。
Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 second, and the detect multiplier = 3.
セッション開始はMinRx = 1秒、MinTx> = 1秒から開始生じ、= 3の乗算器を検出します。
Once in the UP state, Poll/Final discipline is used to modify the periodicity of control message exchange from their default rates to the desired rates and to set the detect multiplier to 3.
一度UP状態で、ポーリング/最終規律を所望の速度にデフォルトレートからの制御メッセージ交換の周期を変更すると3に検出乗数を設定するために使用されています。
Note that in the Poll/Final process a receiver of a new timer value with a poll flag can reject the timer value by tearing the session, or it can return its preferred timer value with the final flag. Note also that the receiver of a new timer value with a final flag can reject the timer value by tearing the session, or it can return its preferred timer value with the poll flag.
ポーリング/最終工程でポーリングフラグを新しいタイマ値の受信機がセッションを引き裂くことにより、タイマ値を拒否することができ、またはそれは、最終的なフラグでその好ましいタイマ値を返すことができることに留意されたいです。最終フラグを新しいタイマ値の受信機がセッションを引き裂くことにより、タイマ値を拒否することができ、またはそれはポーリングフラグとその好ましいタイマ値を返すことができることにも留意されたいです。
Once the desired rate has been reached using the Poll/Final mechanism, implementations SHOULD NOT attempt further rate modification.
所望の速度はポーリング/最終メカニズムを使用して到達した後、実装はさらに、レート変更を試みるべきではありません。
In the rare circumstance where an operator has a reason to further change session parameters, beyond the initial migration from default values, Poll/Final discipline can be used with the caveat that a peer implementation may consider a session change unacceptable and/or bring the BFD session down via the use of the ADMIN DOWN state.
オペレータはさらに、セッションパラメータを変更する理由があるまれな状況では、デフォルト値から最初の移行を越えて、ポーリング/最終規律は、ピア実装は、セッションの変更が受け入れられない検討及び/又はBFDをもたらすことができることを警告で使用することができADMIN DOWN状態の使用を介したセッションダウン。
There are further defect criteria beyond those that are defined in [4] to consider given the possibility of mis-connectivity defects. The result is the criteria for an LSP direction to transition from the defect-free state to a defect state is a superset of that in the BFD base specification [4].
誤接続不良の可能性が与えられる[4]の検討に定義されているものを超えて、さらに、欠陥の基準があります。結果は、欠陥状態に無欠陥状態から遷移するLSP方向の基準である[4] BFDベース仕様のもののスーパーセットです。
The following conditions cause a MEP to enter the defect state for CC PDUs (in no particular order):
以下の条件は、（順不同）CCのPDUに対する欠陥状態に入るようにMEPを引き起こします。
The following will cause the MEP to enter the mis-connectivity defect state for CV operation (again, not in any particular order):
以下は、MEPは（再び、ない特定の順序で）CV動作に誤接続不良状態に入るようになります：
1. BFD control packets are received with an unexpected encapsulation (mis-connectivity defect), these include:
1. BFD制御パケットが予期しないカプセル化（誤接続不良）で受信され、これらは、次のとおり
- receiving an IP encoded CC or CV BFD control packet on an LSP configured to use GAL/G-ACh, or - vice versa (Note there are other possibilities that can also alias as an OAM packet.)
- GAL / G-ACH、または使用するように構成されたLSP上のIP符号化されたCC又はCV BFD制御パケット受信 - 逆にする（OAMパケットとすることができ、また別名他の可能性があります）。
2. Receipt of an unexpected globally unique Source MEP identifier (mis-connectivity defect). Note that as each encoding of the Source MEP-ID TLV contains unique information (there is no mechanical translation possible between MEP-ID formats), receipt of an unexpected Source MEP-ID type is the same as receiving an unexpected value.
予期しないグローバルに一意のソースMEP識別子（誤接続の欠陥）の2。領収書。ソースMEP-IDの各符号化TLVは（MEP-IDのフォーマットとの間の可能な機械的な翻訳が存在しない）固有の情報が含まれているように、予期しないソースMEP-IDタイプの受信が予期しない値を受け取ると同じであることに留意されたいです。
3. Receipt of a session discriminator that is not in the local BFD database in the Your Discriminator field (mis-connectivity defect).
あなたの弁別フィールド（誤接続不良）でのローカルBFDデータベースにないセッション弁別3.領収書。
4. Receipt of a session discriminator that is in the local database but does not have the expected label (mis-connectivity defect).
ローカルデータベース内にあるが、期待ラベル（誤接続の欠陥を）持っていないセッション弁別器の4.領収書。
5. If BFD authentication is used, receipt of a message with incorrect authentication information (password, MD5 digest, or SHA1 hash).
5. BFD認証が使用されている場合、不正な認証情報（パスワード、MD5ダイジェスト、またはSHA1ハッシュ）とのメッセージの受信。
The effective defect hierarchy (order of checking) is:
効果的な欠陥階層（チェックの順序）は、次のとおりです。
2. Receiving Link Down Indication, e.g., a local link failure, an MPLS-TP LDI, or Lock Report.
2.リンクダウンの指示、例えば、ローカルリンク障害、MPLS-TP LDI、またはロック報告を受けました。
3. Receiving from an incorrect source (determined by whatever means).
3.（どんな手段で決定）間違ったソースから受け取ります。
4. Receiving from a correct source (as near as can be determined), but with incorrect session information.
4.（決定することができるように近くに）正しいソースからの受信が、間違ったセッション情報を有します。
Upon defect entry, a sink MEP will assert signal fail into any client (sub-)layers. It will also communicate session DOWN to its session peer using CC messages.
欠陥エントリ時に、シンクMEPは、任意のクライアント（サブ）レイヤに失敗信号をアサートします。また、CCメッセージを使用して、そのセッションのピアにDOWNのセッションを通信します。
The blocking of traffic as a consequent action MUST be driven only by a defect's consequent action as specified in Section 5.1.1.2 of RFC 6371 [13].
RFC 6371 [13]のセクション5.1.1.2で指定されるように結果としてのアクションとしてトラフィックのブロックは、欠陥の結果として作用によって駆動されなければなりません。
When the defect is mis-connectivity, the Section, LSP, or PW termination will silently discard all non-OAM traffic received. The sink MEP will also send a defect indication back to the source MEP via the use of a diagnostic code of mis-connectivity defect (9).
欠陥が誤接続された場合、セクション、LSP、またはPWの終了は静かにすべての非OAMトラフィックが受信破棄します。シンクMEPはまた、誤接続の欠陥（9）の診断コードの使用を介してバックソースMEPに欠陥表示を送信します。
For a coordinated session, exit from a loss of connectivity defect is as described in Figure 7, which updates RFC 5880 [4].
RFC 5880 [4]を更新する、図7で説明したように、協調セッションのために、接続不良の損失からの出口です。
For an independent session, exit from a loss of connectivity defect occurs upon receipt of a well-formed BFD control packet from the peer MEP as described in Figures 8 and 9.
図8および図9で説明したように独立したセッションのために、接続不良の損失からの出口は、ピアMEPから整形BFD制御パケットの受信時に起こります。
Exit from a mis-connectivity defect state occurs when no CV messages with mis-connectivity defects have been received for a period of 3.5 seconds.
誤接続の欠陥状態からの出口は、誤接続の欠陥とはCVメッセージは3.5秒の期間に受信されていない場合に発生します。
The following state machines update RFC 5880 [4]. They have been modified to include LDI and LKR as specified in [5] as inputs to the state machine and to clarify the behavior for independent mode. LKR is an optional input.
次のステートマシン更新RFC 5880 [4]。彼らは、状態マシンへの入力として[5]で指定されるようにLDIとLKRを含むように変更され、独立モードの動作を明確にします。 LKRはオプションの入力です。
The coordinated session state machine has been augmented to indicate LDI and optionally LKR as inputs to the state machine. For a session that is in the UP state, receipt of LDI or optionally LKR will transition the session into the DOWN state.
協調セッションステートマシンはステートマシンへの入力としてLDI及び任意LKRを示すために拡張されています。 UP状態にあるセッションのために、LDIまたは任意にLKRの受信はDOWN状態にセッションを移行します。
+--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| |
| |ADMIN DOWN, DOWN,| |
| |TIMER TIMER,| |
V |LDI,LKR LDI,LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 7: MPLS CC State Machine for Coordinated Session Operation
図7：協調セッションの操作のためのMPLS CCステートマシン
For independent mode, there are two state machines: one for the source MEP (which requested bfd.MinRxInterval=0) and one for the sink MEP (which agreed to bfd.MinRxInterval=0).
（bfd.MinRxInterval = 0を要求された）ソースMEP用と（= 0 bfd.MinRxIntervalに同意）シンクMEPのための1つ：独立モードのために、2台のステートマシンがあります。
The source MEP will not transition out of the UP state once initialized except in the case of a forced ADMIN DOWN. Hence, LDI and optionally LKR do not enter into the state machine transition from the UP state, but do enter into the INIT and DOWN states.
ソースは、MEPは、かつて強制ADMINのDOWNの場合を除いて、初期化UP状態から遷移しません。したがって、LDIおよび任意LKRはUP状態から状態マシン遷移に入らないが、INITおよびDOWN状態に入るん。
+--+
| | UP, ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | | |
| |ADMIN DOWN ADMIN DOWN | |
| |TIMER, | |
| |LDI, | |
V |LKR | V
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | | INIT, UP, DOWN,
+--->| | INIT, UP | |<---+ LDI, LKR
+------+ +------+
Figure 8: MPLS CC State Machine for Source MEP for
Independent Session Operation
The sink MEP state machine (for which the transmit interval has been set to zero) is modified to:
（送信間隔はゼロに設定されている）シンクMEP状態機械をに変更されます。
1) Permit direct transition from DOWN to UP once the session has been initialized. With the exception of via the ADMIN DOWN state, the source MEP will never transition from the UP state; hence, in normal unidirectional fault scenarios, it will never transition to the INIT state.
セッションが初期化された後DOWNからUPに1）許可直接遷移。 ADMIN DOWN状態を経ての例外を除いて、ソースMEPがUP状態から移行することはありません。したがって、通常の一方向性の障害のシナリオでは、INIT状態に遷移することはありません。
+--+
| | ADMIN DOWN, TIMER, LDI, LKR
| V
DOWN +------+ INIT, UP
+------------| |------------+
| | DOWN | |
| +-------->| |<--------+ |
| | +------+ | |
| | MIS-CONNECTIVITY,| |
| | ADMIN DOWN,| |
| |ADMIN DOWN, TIMER, | |
| |TIMER, DOWN, | |
| |LDI, LDI, | V
V |LKR LKR | |
+------+ +------+
+----| | | |----+
DOWN| | INIT |--------------------->| UP | |INIT, UP
+--->| | INIT, UP | |<---+
+------+ +------+
Figure 9: MPLS CC State Machine for the Sink MEP
for Independent Session Operation
The configuration of MPLS-TP BFD session parameters and the coordination of the same between the source and sink MEPs are out of scope of this memo.
MPLS-TP BFDセッションパラメータとソースとのMEPは、このメモの範囲の外にあるシンクとの間の同一の調整の構成。
In the BFD control packet, the discriminator values either are local to the sink MEP or have no significance (when not known).
BFD制御パケットに、ディスクリミネータ値のいずれかがシンクMEPに対してローカルであるか、または（知られていない場合）は意味を持ちません。
The My Discriminator field MUST be set to a non-zero value (which can be a fixed value). The transmitted Your Discriminator value MUST reflect back the received value of the My Discriminator field or be set to zero if that value is not known.
マイディスクリミネータ・フィールドは、（固定値であってもよい）非ゼロ値に設定しなければなりません。送信あなたの弁別値は私の弁別フィールドの受信値をバックに反映しなければならないか、その値が知られていない場合は、ゼロに設定されます。
Per Section 7 of RFC 5884 [8], a node MUST NOT change the value of the My Discriminator field for an established BFD session.
RFC 5884のセクション7パー[8]、ノードが確立BFDセッションのための私の弁別フィールドの値を変更しないでください。
The following is an example set of configuration parameters for a BFD session:
以下は、BFDセッションの設定パラメータの設定例を示します。
Mode and Encapsulation
----------------------
RFC 5884 - BFD CC in UDP/IP/LSP
RFC 5885 - BFD CC in G-ACh
RFC 5085 - UDP/IP in G-ACh
MPLS-TP - CC/CV in GAL/G-ACh or G-ACh
For MPLS-TP, the following additional parameters need to be configured:
MPLS-TPの場合は、以下の追加パラメータを設定する必要があります。
1) Session mode, coordinated or independent 2) CC periodicity 3) The MEP-ID for the MEPs at either end of the LSP 4) Whether authentication is enabled (and if so, the associated parameters)
1）セッションモード、協調または独立した2）CC周期3）MEP-ID認証が有効かどうかLSP 4の端部）のいずれかでのMEPのための（およびそうであれば、関連するパラメータ）
The discriminators used by each MEP, both bfd.LocalDiscr and bfd.RemoteDiscr, can optionally be configured or locally assigned. Finally, a detect multiplier of 3 is directly inferred from the code points.
各MEPによって使用される識別器、bfd.LocalDiscrとbfd.RemoteDiscr両方は、必要に応じて構成またはローカルに割り当てることができます。最後に、3の検出乗数は直接コードポイントから推測されます。
IANA has allocated two channel types from the "Pseudowire Associated Channel Types" registry in RFC 4385 [15].
IANAはRFC 4385 [15]に「擬似回線関連するチャネルタイプ」レジストリから2つのチャンネルタイプを割り当てています。
0x0022 MPLS-TP CC message 0x0023 MPLS-TP CV message
0x0022 MPLS-TP CCメッセージ0x0023 MPLS-TPのCVメッセージ
IANA has created a "CC/CV MEP-ID TLV" registry. The parent registry is the "Pseudowire Associated Channel Types" registry of RFC 4385 [15]. All code points within this registry shall be allocated according to the "Standards Action" procedures as specified in [11]. The items tracked in the registry will be the type, associated name, and reference.
IANAは、 "CC / CV MEP-ID TLV" のレジストリを作成しました。親レジストリは、RFC 4385の「擬似回線関連するチャネルタイプ」レジストリ[15]です。 [11]で指定されるように、このレジストリ内のすべてのコードポイントは、「標準アクション」手順に従って割り当てられなければなりません。レジストリで追跡されたアイテムは、タイプ、関連付けられた名前、および参照あろう。
The initial values are:
初期値は次のとおりです。
0 - Section MEP-ID 1 - LSP MEP-ID 2 - PW MEP-ID
0 - セクションMEP-ID 1 - LSP MEP-ID 2 - PW MEP-ID
IANA has assigned the following code point from the "Bidirectional Forwarding Detection (BFD) Parameters" registry, "BFD Diagnostic Codes" subregistry [4]:
IANAは、「双方向フォワーディング検出（BFD）パラメータ」レジストリ、「BFD診断コード」副登録から次のコードポイントが割り当てられている[4]。
9 - mis-connectivity defect
9 - 誤接続不良
The use of CV improves network integrity by ensuring traffic is not "leaking" between LSPs.
CVの使用はLSPの間で「漏れて」されていないトラフィックを確保することによって、ネットワークの整合性を向上させます。
Base BFD foresees an optional authentication section (see Section 6.7 of [4]) that can be applied to this application. Although the Source MEP-ID TLV is not included in the BFD authentication digest, there is a chain of trust such that the discriminator associated with the digest is also associated with the expected MEP-ID; this will prevent impersonation of CV messages in this application.
ベースBFDは、このアプリケーションに適用することができる（[4]のセクション6.7を参照されたい）任意認証部を予見します。ソースMEP-ID TLVがBFD認証ダイジェストに含まれていないが、ダイジェストに関連付けられた識別器も期待MEP-IDに関連付けられていることをそのような信頼の鎖があります。これは、このアプリケーションではCVメッセージのなりすましを防ぐことができます。
This memo specifies the use of globally unique identifiers for MEP-IDs. This provides absolutely authoritative detection of persistent leaking of traffic between LSPs. Non-uniqueness can result in undetected leaking in the scenario where two LSPs with common MEP-IDs are misconnected. This would be considered undesirable but rare; it would also be difficult to exploit for malicious purposes as, at a minimum, both a network end point and a node that was a transit point for the target MEG would need to be compromised.
このメモは、MEP-IDのグローバル一意識別子の使用を指定します。これはLSPの間のトラフィックの持続的な漏れの絶対的に信頼できる検出を提供します。非一意性は、一般的なMEP-IDを持つ2つのLSPが誤って接続されているシナリオでは検出されない漏れにつながることができます。これは望ましくないが、稀であると考えられます。また、最低でも、として悪意のある目的のためにネットワークエンドポイントとMEGは妥協する必要があるターゲットの中継点であったノードの両方を利用することは困難です。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[2]ボッチ、M.、エド。、Vigoureux、M.、エド。、およびS.ブライアント、エド。、 "MPLSジェネリック関連チャンネル"、RFC 5586、2009年6月。
[3] 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.
[3] Vigoureux、M.、エド。、ウォード、D.、エド。、およびM.ベッツ、エド。、 "運用、管理、およびMPLS交通ネットワークのメンテナンス（OAM）のための要件"、RFC 5860、2010年5月。
[4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[4]カッツ、D.およびD.区、 "双方向フォワーディング検出（BFD）"、RFC 5880、2010年6月。
[5] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., Boutros, S., and D. Ward, "MPLS Fault Management Operations, Administration, and Maintenance (OAM)", RFC 6427, November 2011.
[5]ツバメ、G.編、Fulignoli、A.編、Vigoureux、M.編、Boutros、S.、およびD.区、「MPLS障害管理運用、管理、および保守（OAM） 」、RFC 6427、2011年11月。
[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[6]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[7] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010.
[7]ナドー、T.、エド。、およびC. Pignataro、エド。、 "双方向フォワーディング検出（BFD）疑似仮想回線接続検証（VCCV）のための"、RFC 5885、2010年6月。
[8] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010.
[8]アガルワルは、R.、Kompella、K.、ナドー、T.、およびG.ツバメは、RFC 5884、2010年6月 "MPLSラベルの双方向フォワーディング検出（BFD）はパス（LSPを）交換しました"。
[9] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[9]ボッチ、M.、ツバメ、G.、およびE.グレー、 "MPLSトランスポートプロファイル（MPLS-TP）識別子"、RFC 6370、2011年9月。
[10] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[10]ナドー、T.、エド、およびC. Pignataro、エド、 "Pseudowireの仮想回線接続性検証（VCCV）：スードワイヤ用制御チャネル"。。、RFC 5085、2007年12月。
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[11] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[12] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
[12]ボッチ、M.編、ブライアント、S.、エド。、霜、D.、編、Levrau、L.、およびL.バーガー、 "トランスポートネットワークにおけるMPLSのための枠組み"、RFC 5921、 2010年7月。
[13] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
[13]ビジネスサービス、I.、エド。、およびD.アラン編、 "運用、管理、およびMPLSベースのトランスポートネットワークのメンテナンス枠組み"、RFC 6371、2011年9月。
[14] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, June 2011.
[14]アンダーソン、L.、バンHelvoort、H.、Bonica、R.、Romascanu、D.、およびS.マンスフィールド、OAM "IETFにおける頭字語 "" の使用のためのガイドライン"、BCP 161、RFC 6291 、2011年6月。
[15] 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.
[15]ブライアント、S.、ツバメ、G.、マルティーニ、L.、及びD.マクファーソン、 "MPLS PSNの上の使用のための擬似回線エミュレーションエッジ・ツー・エッジ（PWE3）コントロールワード"、RFC 4385、2006年2月。
Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher, and Yaacov Weingarten also contributed to this document.
ニティン・バハドゥール、ラウール・アガーウォール、トム・ナドー、Nurit Sprecher、およびYaacovヴェンガルテンも、この文書に貢献しました。
Annamaria Fulignoli Ericsson EMail: annamaria.fulignoli@ericsson.com
Annamaria FulignoliエリクソンEメール：annamaria.fulignoli@ericsson.com
Sami Boutros Cisco Systems, Inc. EMail: sboutros@cisco.com
サミBoutrosシスコシステムズ、株式会社Eメール：sboutros@cisco.com
Martin Vigoureux Alcatel-Lucent EMail: martin.vigoureux@alcatel-lucent.com
マーティン・ヘイルアルカテル・ルーセントEメール：martin.vigoureux@alcatel-lucent.com
Siva Sivabalan Cisco Systems, Inc. EMail: msiva@cisco.com
シヴァシババランシスコシステムズ株式会社Eメール：ಮಸಿವ@ಸಿಸ್ಕೋ.ಕಂ
David Ward Juniper EMail: dward@juniper.net
デビッド・ウォードジュニパーEメール：dward@juniper.net
Robert Rennison ECI Telecom EMail: robert.rennison@ecitele.com
ロバートRennison ECIテレコムEメール：robert.rennison@ecitele.com
Editors' Addresses
エディタのアドレス
Dave Allan Ericsson EMail: david.i.allan@ericsson.com
デイブ・アラン・エリクソンメール：david.i.allan@ericsson.com
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
ジョージツバメシスコシステムズ、株式会社Eメール：swallow@cisco.com
John Drake Juniper EMail: jdrake@juniper.net
ジョン・ドレイクジュニパーEメール：jdrake@juniper.net