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
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.
本文件规定了双向转发检测（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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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).
在传统的传输网络中，电路是在两个或多个交换机上配置的。服务提供商需要操作、管理和维护（OAM）工具来检测传输电路的误连接和连续性损失。模拟传统传输电路的伪线（PWs）和MPLS-TP标签交换路径（LSP）[12]都需要提供RFC 5860[3]所要求的相同的连续性检查（CC）、主动连续性验证（CV）和远程缺陷指示（RDI）能力。本文档描述了在两个维护实体组端点（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函数用于检测两个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.
本文件规定了BFD扩展和行为，以满足共路由和相关双向LSP的CC、主动CV监控和RDI功能要求。支持的封装包括通用关联通道标签（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[9]中定义的MPLS-TP系统标识符。ITU-T正在为ITU载波代码（ICC）定义一个全球唯一的语义，未来的工作可能会扩展本文档，将ICC用作MPLS-TP系统的标识符。
The mechanisms specified in this document are restricted to BFD asynchronous mode.
本文档中指定的机制仅限于BFD异步模式。
ACH: Associated Channel Header
ACH：关联通道头
BFD: Bidirectional Forwarding Detection
双向转发检测
CC: Continuity Check
连续性检查
CV: Connectivity Verification
连接验证
GAL: Generic Associated Channel Label
GAL：通用关联通道标签
G-ACh: Generic Associated Channel
G-ACh：通用关联信道
LDI: Link Down Indication
本地设计院（LDI）：连接下降指示
LKI: Lock Instruct
锁指令
LKR: Lock Report
锁定报告
LSP: Label Switched Path
标签交换路径
LSR: Label Switching Router
标签交换路由器
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-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
网络管理系统
OAM: Operations, Administration, and Maintenance [14]
OAM：运营、管理和维护[14]
PW: Pseudowire
伪线
PDU: Protocol Data Unit
协议数据单元
P/F: Poll/Final
P/F: Poll/Final
RDI: Remote Defect Indication
远程缺陷指示
SPME: Sub-Path Maintenance Entity
子路径维护实体
TTL: Time To Live
TTL：生命的时刻
TLV: Type Length Value
TLV：类型长度值
VCCV: Virtual Circuit Connectivity Verification
虚拟电路连通性验证
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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模式可通过RFC 5885[7]中描述的协议和程序与ACH信道7一起提供。这些程序可应用于双向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.
除了本备忘录中记录的程序外，还可以通过对LSP实施RFC 5884[8]和对PWs实施RFC 5085[10]与传统设备进行互操作。根据RFC 5586[2]，当BFD控制包封装在IP报头中时，IP报头中的字段按照RFC 5884[8]中的定义进行设置。当使用IP封装时，可以通过基于源IP地址和我的鉴别器字段的组合推断全局唯一的源来执行CV mis连接缺陷检测。
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-ID TLV，以允许汇MEP执行误连接检测。
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格式是CC还是CV，通过对封装BFD的通用相关信道（G-ACh）使用不同的封装和代码点来实现PDU的交错：
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主动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]，当自上次接收BFD控制数据包以来的时间超过检测时间时，接收器MEP应编码“1-控制检测时间已过期”的诊断代码，该时间等于远程系统的发送间隔乘以远程系统的检测乘数（在本文件中设置为3）。由于接收器MEP接收本地设计院（LDI），接收器MEP应编码“5路向下”的诊断代码。当CV PDU处理指示错误连接缺陷时，接收器MEP必须编码“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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Figure 1: ACH Indication of MPLS-TP CC/CV/RDI
The first nibble (0001b) indicates the G-ACh as per RFC 5586 [2].
根据RFC 5586[2]，第一个半字节（0001b）表示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 PDU适用于所有相关MPLS-TP结构，包括PWs、MPLS LSP（包括SPME）和区段。
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交织的CC BFD协议数据单元（PDU）（用源MEP-ID扩充，并被不同ACh信道类型识别为需要额外处理）。CV PDU的插入间隔为每秒一次。当自上次接收BFD控制数据包以来的时间超过检测时间（等于会话周期乘以远程系统的检测乘数（CC码点设置为3））时，就会检测到连续性丢失缺陷。最多在一秒钟内检测到错误连接缺陷。
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 ~ |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]中定义的BFD控制包组成，由G-ACh预挂。
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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个八位组字段，后跟2个八位组长度字段，后跟可变长度值字段。BFD会话将只使用源ID TLV的一种编码。
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区段的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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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全局_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全局_ID、32位节点标识符，后跟16位隧道_Num（在节点标识符的上下文中必须是唯一的）和16位LSP_Num（在隧道_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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全局_ID、节点标识符、隧道编号和LSP编号符合[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.) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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”。长度是以下数据的长度：全局_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实例。在配置的维护实体（ME）上启用CC和主动CV功能时，将启用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.
在ME上禁用CC和主动CV功能时，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数据包完成。必须忽略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在异步模式下运行，利用第3节中为给定MEG中的所有会话定义的封装。对于LSP、SPME和章节，这是GAL/G-ACh封装BFD，使用第3.3节中规定的代码点。对于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有两种操作模式：一种是协调LSP两个方向的会话状态，另一种是通过BFD会话构建的，两个方向独立操作，但仍然是同一MEG的一部分。单个双向BFD会话用于协调操作。两个独立的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]的两个方面。独立操作的特点是由通常是会话发起人（称为源MEP）的MEP将bfd.MinRxInterval设置为零，并且在双向LSP的任一端都将有会话发起人。每个源MEP将有一个相应的接收器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传输速率设置为零的情况下，MEP的行为。一种解释是，双向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的MEP）将忽略从零间隔对等方接收到的关闭状态。这意味着零间隔对等机将继续发送包含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.
Session initiation occurs starting from MinRx = 1 second, MinTx >= 1 second, and the detect multiplier = 3.translate error, please retry
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.
一旦处于上升状态，轮询/最终规程用于将控制消息交换的周期从其默认速率修改为所需速率，并将检测乘数设置为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会话。
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操作的mis连接缺陷状态（同样，不是以任何特定顺序）：
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.
2. 收到意外的全局唯一源MEP标识符（mis连接缺陷）。请注意，由于源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数据库中“您的鉴别器”字段中不存在的会话鉴别器（mis连接缺陷）。
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[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还将通过使用mis连接缺陷诊断代码（9）将缺陷指示发送回源MEP。
For a coordinated session, exit from a loss of connectivity defect is as described in Figure 7, which updates RFC 5880 [4].
对于协调会话，从连接丢失缺陷中退出如图7所述，图7更新了RFC 5880[4]。
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作为状态机的输入。对于处于向上状态的会话，收到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 | |<---+
+------+ +------+
+--+
| | 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).
对于独立模式，有两个状态机：一个用于源MEP（请求bfd.MinRxInterval=0），另一个用于接收器MEP（同意bfd.MinRxInterval=0）。
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状态进入状态机转换，而是进入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
+------+ +------+
+--+
| | 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) 会话初始化后，允许从下向上直接转换。除了通过ADMIN DOWN状态，源MEP永远不会从UP状态转换；因此，在正常的单向故障情况下，它永远不会转换到初始状态。
+--+
| | 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 | |<---+
+------+ +------+
+--+
| | 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:Sink 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.
“我的鉴别器”字段必须设置为非零值（可以是固定值）。传输的您的鉴别器值必须反映回“我的鉴别器”字段的接收值，或者如果该值未知，则必须设置为零。
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会话的“我的鉴别器”字段的值。
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
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任一端的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]中的“伪线关联通道类型”注册表中分配了两种通道类型。
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-mis连接缺陷
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.
Base 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的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通用关联信道”，RFC 55862009年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.，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 58802010年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）”，RFC 64272011年11月。
[6] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[6] Martini，L.，“伪线边到边仿真（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.，“用于伪线虚拟电路连接验证（VCCV）的双向转发检测（BFD）”，RFC 58852010年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 58842010年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传输配置文件（MPLS-TP）标识符”，RFC 63702011年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.，“伪线虚拟电路连接验证（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] Bocci，M.，Ed.，Bryant，S.，Ed.，Frost，D.，Ed.，Levrau，L.，和L.Berger，“传输网络中MPLS的框架”，RFC 59212010年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 62912011年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，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，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
安娜玛丽亚·富利格诺利·爱立信电子邮件：安娜玛丽亚。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-朗讯网
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
罗伯特·雷尼森ECI电信电子邮件：罗伯特。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
George Swallow Cisco Systems，Inc.电子邮件：swallow@cisco.com
John Drake Juniper EMail: jdrake@juniper.net
John Drake Juniper电子邮件：jdrake@juniper.net