[要約] RFC 6428は、MPLSトランスポートプロファイルにおけるプロアクティブな接続性の検証、連続性チェック、およびリモートディフェクト指示に関する標準仕様です。このRFCの目的は、ネットワークの信頼性とパフォーマンスを向上させるために、MPLSネットワークでの接続性の検証と障害の検出をサポートすることです。
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
MPLS輸送プロファイルのプロアクティブな接続の検証、連続性チェック、およびリモート欠陥の表示
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.
このドキュメントは、MPLS-TP擬似ワイヤ、ラベルスイッチパス、およびこのメモによって拡張されたBFDを使用したセクションのプロアクティブな連続性チェック、連続性検証、およびリモート欠陥の表示のための双方向転送検出（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
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
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）ツールを必要とします。擬似動物（PWS）およびMPLS-TPラベルスイッチ付きパス（LSP）[12]は、従来の輸送回路をエミュレートする必要があります。RFC 5860 [3]。このドキュメントでは、2つのメンテナンスエンティティグループエンドポイント（MEP）間のPW、LSP、またはサブパスメンテナンスエンティティ（SPME）のCC、プロアクティブCV、およびRDIの双方向転送検出（BFD）[4]の使用について説明します。
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関数は、2つのMEP間の連続性の喪失（LOC）と意図しない接続性（例：誤った接続または誤接続または予期しない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-CHACH）、仮想回路接続検証（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 [9]で定義されているように、MPLS-TPシステムの識別子を使用しています。ITU-Tで作業が進行中であり、ITUキャリアコード（ICC）のグローバルなセマンティックを定義しており、将来の作業により、このドキュメントがMPLS-TPシステムの識別子としてICCを使用するように拡張する可能性があります。
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
私：メンテナンスエンティティ
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
PW：Pseudowire
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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のみのモードは、ACHチャネル7を使用してRFC 5885 [7]で説明されているプロトコルと手順を介して提供される場合があります。これらの手順は、PWSとPWSと同様に、双方向LSP（GALの使用を介して）に適用できます。
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.
このメモに文書化された手順に加えて、LSPSにはRFC 5884 [8]およびPWS用のRFC 5085 [10]を実装することにより、実装はレガシー機器と相互運用する場合があります。RFC 5586 [2]に従って、BFD制御パケットがIPヘッダーにカプセル化されると、IPヘッダーのフィールドはRFC 5884 [8]で定義されていると設定されています。IPカプセル化を使用すると、ソースIPアドレスと私の識別子フィールドの組み合わせに基づいてグローバルに一意のソースを推測することにより、CV誤接続性欠陥検出を実行できます。
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は、Sink MEPSによって誤接続性検出を実行できるように、ソース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:
PDUのインターリービングは、PDU形式がCCまたはCVであるかどうかに応じて、一般的な関連チャネル（G-CACH）カプセル化されたBFDの明確なカプセルとコードポイントを使用することで達成されます。
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.
o CC形式：RFC 5586 [2]に記載されている関連チャネルヘッダー（ACH）の新しいコードポイントを定義します。この形式は、連続性チェックと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 [2]に記載されている関連チャネルヘッダー（ACH）の新しいコードポイントを定義します。「MPLS-TP Proactive 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ではありません。[4]によると、シンクMEPは、最後に受信したBFD制御パケットが検出時間を超えているときに「1-制御検出時間が失効した」の診断コードをエンコードする必要があります。これは、リモートシステムの送信間隔に等しくなり、リモートシステムの検出乗数（このドキュメントでは3に設定されています）。シンクMEPは、シンクMEPがLDIを受信した結果として、「5パスダウン」の診断コードをエンコードする必要があります。シンクMEPは、CV PDU処理がミス接続性欠陥を示す場合、「9-誤接続性欠陥」の診断コードをエンコードする必要があります。診断コード5の送信を開始したシンクMEPは、検出タイマーが期限切れになったときに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 [2]に従ってG-achを示します。
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 PDUSは、PWS、MPLS LSP（SPMEを含む）、およびセクションを含むすべての関連する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チャネルタイプによる追加処理が必要であると識別されるCV BFDプロトコルデータユニット（PDU）をインターリーブすることです。CV PDUの挿入間隔は1秒あたり1つです。連続性欠陥の損失の検出は、最後に受信したBFDコントロールパケット以降の時間が検出時間を超えると発生します。ミス接続性の欠陥は、最大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メッセージは、g-achによって事前に施行された[4]で定義されている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メッセージは、[4]で定義されたBFDコントロールパケットで構成され、ACHによって事前にペートされ、ソースMEP-ID TLVによって追加されます。
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は、タイプを指定する2-OCTETフィールドとしてエンコードされ、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の長さは含まれていません。3つの可能なソース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セクションのIP互換MEP-IDは、インターフェイス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:
LSP MEP-IDのフィールドは[9]で定義されています。これは、LSPとSPMEの両方に適用できます。これは、32ビットMPLS-TP Global_ID、32ビットノード識別子で構成され、16ビットtunnel_Num（ノード識別子のコンテキスト内で一意でなければなりません）と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:
MPLS-TP PWエンドポイントMEP-IDのフィールドは、[9]で定義されています。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で無効になっている場合、BFDセッションはAdmin Down Stateに移行し、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パケットを使用して行う必要があります。CVパケットのP/Fおよびセッション状態情報は無視する必要があります。
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、SPME、およびセクションの場合、これはセクション3.3で指定されたコードポイントを使用して、GAL/G-CACHがカプセル化したBFDです。PWSの場合、これはセクション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つの動作モードがあります。1つはLSPの両方向のセッション状態が調整され、1つは2つの方向が独立して動作しますが、まだ同じMegの一部であるようにBFDセッションから構築されます。調整された操作には、単一の双方向BFDセッションが使用されます。2つの独立したBFDセッションが独立した操作に使用されます。独立した操作は、セッションの状態と欠陥状態を独立したエンティティとして扱うことに注意する必要があります。たとえば、RDIを受け取っている間、独立したセッションがUP状態にある可能性があります。調整されたセッションの場合、セッション状態は欠陥状態を追跡します。
In coordinated mode, an implementation SHOULD NOT reset bfd.RemoteDiscr until it is exiting the DOWN state.
コーディネートモードでは、実装はBFD.REMOTEDISCRをリセットしてはならない。
In independent mode, an implementation MUST NOT reset bfd.RemoteDiscr upon transitioning to the DOWN state.
独立モードでは、実装はダウン状態に移行する際に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 [4]で指定されており、RFC 5884 [8]のMPLSで増強されています。調整された手術は、[4]に記載されているとおりです。独立した操作には、[4]の2つの側面を明確にする必要があります。独立した操作は、通常、セッションオリジター（ソース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.
このメモは、BFD送信速度がゼロに設定されたBFD送信レートを使用してMEPの動作に関するベース仕様の優先解釈を指定します。1つの解釈は、双方向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).
2番目の明確化は、起源のMEP（ゼロ以外のBFD.TXINTERVALを持つもの）が、ゼロインターバルピアから受け取ったダウン状態を無視することです。これは、ゼロインターバルピアが、状態の変更が確認されないため、RDI診断コードを含む状態メッセージを引き続き送信することを意味します。これにより、単方向の障害に対する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.
投票/最終プロセスでは、ポーリングフラグを備えた新しいタイマー値の受信者は、セッションを引き裂くことでタイマーの値を拒否するか、最終フラグで優先タイマーの値を返すことができることに注意してください。また、最終フラグを備えた新しいタイマー値の受信者は、セッションを引き裂くことでタイマーの値を拒否するか、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 Stateの使用によるセッション。
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方向の基準は、BFDベース仕様のスーパーセットです[4]。
The following conditions cause a MEP to enter the defect state for CC PDUs (in no particular order):
次の条件により、MEPはCC PDUの欠陥状態に入ります（順番に）：
1. BFD session times out (loss of continuity defect).
1. BFDセッションタイムズアウト（連続性欠陥の喪失）。
2. Receipt of a Link Down Indication or Lock Report.
2. リンクダウン表示またはロックレポートの受信。
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.)
- IPエンコードされたCCまたはCV BFDコントロールパケットを受信して、GAL/G -CHACHまたはその逆を使用するように構成されたLSPで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.
2. 予期しないグローバルに一意のソースMEP識別子（誤接続性欠陥）の受信。ソース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).
3. 差別装置フィールドのローカルBFDデータベースにないセッション差別者の受領（誤接続性欠陥）。
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:
効果的な欠陥階層（チェックの順序）は次のとおりです。
1. Receiving nothing.
1. 何も受け取っていません。
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. 正しいソースから（決定できるように近く）が、セッション情報が誤っています。
5. Receiving BFD control packets in all discernable ways correct.
5. すべての識別可能な方法でBFD制御パケットを受信します。
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メッセージを使用してセッションピアまでセッションを通知します。
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のセクション5.1.1.2で指定されているように、欠陥の結果的なアクションによってのみ駆動されなければなりません[13]。
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は、誤接続性欠陥の診断コードを使用して、ソースMEPに欠陥の表示を送り返します（9）。
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.
ミス接続性欠陥状態からの終了は、3.5秒間、誤接続性欠陥のあるCVメッセージが受信されていない場合に発生します。
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の受領は、セッションをダウン状態に移行します。
+--+
| | 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).
独立モードの場合、2つの状態マシンがあります。1つはソースMEP（BFD.MINRXINTERVAL = 0を要求しました）とシンクMEP（BFD.MINRXINTERVAL = 0に同意しました）に1つあります。
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は、強制管理者の場合を除き、初期化された場合、UP状態から遷移しません。したがって、LDIおよびオプションでLKRは、UP状態から州のマシンの移行に入ることはありませんが、初期状態とダウン状態に入ります。
+--+
| | 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
図8：独立セッション操作のためのソースMEPのMPLS CC状態マシン
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.
1) セッションが初期化されたら、直接的な移行を下からアップに許可します。Via Admin Down Stateを除いて、ソース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
図9：独立セッション操作のためのシンクMEP用のMPLS CCステートマシン
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.
私の識別子フィールドは、ゼロ以外の値（固定値になる可能性がある）に設定する必要があります。送信された差別装置の値は、My Virceの受信価値を反映するか、その値が不明な場合はゼロに設定する必要があります。
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 [8]のセクション7ごとに、ノードは、確立されたBFDセッションのMY差別化器フィールドの値を変更してはなりません。
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）LSP 4の両端でのMEPのMEP-ID 4）認証が有効になっているかどうか（そして、もしそうなら、関連するパラメーター）
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]の「Pseudowire関連チャネルタイプ」レジストリから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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[2] Bocci、M.、ed。、vigoureux、M.、ed。、およびS. Bryant、ed。、「Mpls Generic Associated Channel」、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.、Ed。、ed。、Ward、D.、ed。、およびM. Betts、ed。、「MPLS輸送ネットワークの運用、管理、およびメンテナンスの要件（OAM）」、RFC 5860、2010年5月。
[4] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[4] Katz、D。およびD. Ward、「双方向転送検出（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] Swallow、G.、Ed。、Fulignoli、A.、Ed。、Vigoureux、M.、Ed。、Boutros、S.、およびD. Ward、「MPLS障害管理操作、管理、およびメンテナンス（OAM）」、RFC6427、2011年11月。
[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[6] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire仮想回路接続検証（VCCV）の双方向転送検出（BFD）」、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] Aggarwal、R.、Kompella、K.、Nadeau、T。、およびG. Swallow、「MPLSラベルスイッチドパス（LSP）の双方向転送検出（BFD）」、RFC 5884、2010年6月。
[9] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[9] Bocci、M.、Swallow、G。、およびE. Gray、「MPLS Transport Profile（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] Nadeau、T.、ed。、およびC. Pignataro、ed。、「Pseudowire Virtual Circuit Connectivity Verification（VCCV）：Pseudowiresの制御チャネル」、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] Bocci、M.、Ed。、Bryant、S.、Ed。、Frost、D.、Ed。、Levrau、L.、およびL. Berger、「輸送ネットワークにおけるMPLのフレームワーク」、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] Busi、I.、ed。、およびD. Allan、ed。、「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] Andersson、L.、Van Helvoort、H.、Bonica、R.、Romascanu、D。、およびS. Mansfield、「IETFでの「OAM」頭字語の使用に関するガイドライン」、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] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを介した使用のための単語」、RFC 4385、2006年2月。
Nitin Bahadur, Rahul Aggarwal, Tom Nadeau, Nurit Sprecher, and Yaacov Weingarten also contributed to this document.
Nitin Bahadur、Rahul Aggarwal、Tom Nadeau、Nurit Sprecher、Yaacov Weingartenもこの文書に貢献しました。
Annamaria Fulignoli Ericsson EMail: annamaria.fulignoli@ericsson.com
Annamaria Fulignoli Ericssonメール：Annamaria.fulignoli@ericsson.com
Sami Boutros Cisco Systems, Inc. EMail: sboutros@cisco.com
Sami Boutros Cisco Systems、Inc。電子メール：sboutros@cisco.com
Martin Vigoureux Alcatel-Lucent EMail: martin.vigoureux@alcatel-lucent.com
Martin Vigoureux Alcatel-Lucentメール：martin.vigoureux@alcatel-lucent.com
Siva Sivabalan Cisco Systems, Inc. EMail: msiva@cisco.com
Siva Sivabalan Cisco Systems、Inc。電子メール：msiva@cisco.com
David Ward Juniper EMail: dward@juniper.net
David Ward Juniperメール：dward@juniper.net
Robert Rennison ECI Telecom EMail: robert.rennison@ecitele.com
Robert Rennison ECI Telecom Email：robert.rennison@ecitele.com
Editors' Addresses
編集者のアドレス
Dave Allan Ericsson EMail: david.i.allan@ericsson.com
Dave Allan Ericssonメール：David.i.allan@ericsson.com
George Swallow Cisco Systems, Inc. EMail: swallow@cisco.com
George Swallow Cisco Systems、Inc。メール：swallow@cisco.com
John Drake Juniper EMail: jdrake@juniper.net
John Drake Juniperメール：jdrake@juniper.net