Internet Engineering Task Force (IETF) G. Swallow, Ed.
Request for Comments: 6427 Cisco Systems, Inc.
Category: Standards Track A. Fulignoli, Ed.
ISSN: 2070-1721 Ericsson
M. Vigoureux, Ed.
Alcatel-Lucent
S. Boutros
Cisco Systems, Inc.
D. Ward
Juniper Networks, Inc.
November 2011
Internet Engineering Task Force (IETF) G. Swallow, Ed.
Request for Comments: 6427 Cisco Systems, Inc.
Category: Standards Track A. Fulignoli, Ed.
ISSN: 2070-1721 Ericsson
M. Vigoureux, Ed.
Alcatel-Lucent
S. Boutros
Cisco Systems, Inc.
D. Ward
Juniper Networks, Inc.
November 2011
MPLS Fault Management Operations, Administration, and Maintenance (OAM)
MPLS故障管理操作、管理和维护（OAM）
Abstract
摘要
This document specifies Operations, Administration, and Maintenance (OAM) messages to indicate service disruptive conditions for MPLS-based transport network Label Switched Paths. The notification mechanism employs a generic method for a service disruptive condition to be communicated to a Maintenance Entity Group End Point. This document defines an MPLS OAM channel, along with messages to communicate various types of service disruptive conditions.
本文档指定了操作、管理和维护（OAM）消息，以指示基于MPLS的传输网络标签交换路径的服务中断条件。通知机制采用一种通用方法，将服务中断条件传送到维护实体组端点。本文档定义了MPLS OAM通道，以及用于通信各种类型的服务中断条件的消息。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6427.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6427.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. MPLS Fault Management Messages ..................................5
2.1. MPLS Alarm Indication Signal ...............................5
2.1.1. MPLS Link Down Indication ...........................6
2.2. MPLS Lock Report ...........................................6
2.3. Propagation of MPLS Fault Messages .........................7
3. MPLS Fault Management Channel ...................................7
4. MPLS Fault Management Message Format ............................8
4.1. Fault Management Message TLVs ..............................9
4.1.1. Interface Identifier TLV ...........................10
4.1.2. Global Identifier ..................................10
5. Sending and Receiving Fault Management Messages ................10
5.1. Sending a Fault Management Message ........................10
5.2. Clearing a Fault Management Indication ....................11
5.3. Receiving a Fault Management Indication ...................11
6. Minimum Implementation Requirements ............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. Pseudowire Associated Channel Type ........................13
8.2. MPLS Fault OAM Message Type Registry ......................13
8.3. MPLS Fault OAM Flag Registry ..............................14
8.4. MPLS Fault OAM TLV Registry ...............................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
10. Contributing Authors ..........................................16
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. MPLS Fault Management Messages ..................................5
2.1. MPLS Alarm Indication Signal ...............................5
2.1.1. MPLS Link Down Indication ...........................6
2.2. MPLS Lock Report ...........................................6
2.3. Propagation of MPLS Fault Messages .........................7
3. MPLS Fault Management Channel ...................................7
4. MPLS Fault Management Message Format ............................8
4.1. Fault Management Message TLVs ..............................9
4.1.1. Interface Identifier TLV ...........................10
4.1.2. Global Identifier ..................................10
5. Sending and Receiving Fault Management Messages ................10
5.1. Sending a Fault Management Message ........................10
5.2. Clearing a Fault Management Indication ....................11
5.3. Receiving a Fault Management Indication ...................11
6. Minimum Implementation Requirements ............................12
7. Security Considerations ........................................12
8. IANA Considerations ............................................13
8.1. Pseudowire Associated Channel Type ........................13
8.2. MPLS Fault OAM Message Type Registry ......................13
8.3. MPLS Fault OAM Flag Registry ..............................14
8.4. MPLS Fault OAM TLV Registry ...............................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
10. Contributing Authors ..........................................16
Proper operation of a transport network depends on the ability to quickly identify faults and focus attention on the root cause of the disruption. This document defines MPLS Fault Management Operations, Administration, and Maintenance (OAM) messages. When a fault occurs in a server (sub-)layer, Fault Management OAM messages are sent to clients of that server so that alarms, which otherwise would be generated by the subsequent disruption of the clients, may be suppressed. This prevents a storm of alarms and allows operations to focus on the actual faulty elements of the network.
运输网络的正常运行取决于快速识别故障并将注意力集中在中断的根本原因上的能力。本文档定义了MPLS故障管理操作、管理和维护（OAM）消息。当服务器（子）层中发生故障时，故障管理OAM消息将发送到该服务器的客户端，以便可以抑制报警，否则会由客户端的后续中断生成报警。这可以防止警报风暴，并允许操作集中于网络的实际故障元件。
In traditional transport networks, circuits such as T1 lines are typically provisioned on multiple switches. When an event that causes disruption occurs on any link or node along the path of such a transport circuit, OAM indications are generated. When received, these indications may be used to suppress alarms and/or activate a backup circuit. The MPLS-based transport network provides mechanisms equivalent to traditional transport circuits. Therefore, a Fault Management (FM) capability must be defined for MPLS. This document defines FM capabilities to meet the MPLS-TP requirements as described in RFC 5654 [1], and the MPLS-TP Operations, Administration, and Maintenance requirements as described in RFC 5860 [2]. These mechanisms are intended to be applicable to other aspects of MPLS as well. However, applicability to other types of LSPs is beyond the scope of this document.
在传统的传输网络中，诸如T1线路之类的电路通常配置在多个交换机上。当在沿着这种传输电路的路径的任何链路或节点上发生导致中断的事件时，生成OAM指示。收到这些指示后，可用于抑制报警和/或激活备用电路。基于MPLS的传输网络提供了与传统传输电路等效的机制。因此，必须为MPLS定义故障管理（FM）能力。本文件定义了FM能力，以满足RFC 5654[1]中所述的MPLS-TP要求，以及RFC 5860[2]中所述的MPLS-TP操作、管理和维护要求。这些机制旨在也适用于MPLS的其他方面。然而，对其他类型LSP的适用性超出了本文件的范围。
Two broad classes of service disruptive conditions are identified.
确定了两大类服务中断条件。
1. Fault: The inability of a function to perform a required action. This does not include an inability due to preventive maintenance, lack of external resources, or planned actions.
1. 故障：功能无法执行所需操作。这不包括由于预防性维护、缺乏外部资源或计划的行动而导致的无能力。
2. Lock: an administrative status in which it is expected that only test traffic, if any, and OAM (dedicated to the LSP) can be sent on an LSP.
2. 锁定：一种管理状态，在这种状态下，预期LSP上只能发送测试流量（如果有）和OAM（专用于LSP）。
Within this document, a further term is defined: server-failure. A server-failure occurs when a fault condition or conditions have persisted long enough to consider the required service function of the server (sub-)layer to have terminated. In the case of a protected server, this would mean that the working facilities and any protection facilities have all suffered faults of the required duration.
在本文档中，定义了另一个术语：服务器故障。当故障条件或条件持续足够长以考虑服务器（子）层终止的所需服务功能时，会发生服务器故障。在受保护服务器的情况下，这意味着工作设施和任何保护设施都发生了所需持续时间内的故障。
This document specifies an MPLS OAM channel called an "MPLS-OAM Fault Management (FM)" channel. A single message format and a set of procedures are defined to communicate service disruptive conditions
本文档指定了一个称为“MPLS-OAM故障管理（FM）”通道的MPLS OAM通道。定义了一种消息格式和一组过程，用于传达服务中断情况
from the location where they occur to the end points of LSPs that are affected by those conditions. Multiple message types and flags are used to indicate and qualify the particular condition.
从它们出现的位置到受这些条件影响的LSP端点。多个消息类型和标志用于指示和限定特定条件。
Corresponding to the two classes of service disruptive conditions listed above, two messages are defined to communicate the type of condition. These are known as:
与上面列出的两类服务中断条件相对应，定义了两条消息来传达条件类型。这些被称为：
Alarm Indication Signal (AIS)
报警指示信号（AIS）
Lock Report (LKR)
锁定报告（LKR）
ACH: Associated Channel Header
ACH：关联通道头
ACh: Associated Channel
相关信道
CC: Continuity Check
连续性检查
FM: Fault Management
FM：故障管理
GAL: Generic Associated Channel Label
GAL：通用关联通道标签
LOC: Loss of Continuity
LOC：连续性丧失
LSP: Label Switched Path
标签交换路径
MEP: Maintenance Entity Group End Point
MEP：维护实体组终点
MPLS: Multiprotocol Label Switching
多协议标签交换
MPLS-TP: MPLS Transport Profile
MPLS-TP:MPLS传输配置文件
MS-PW: Multi-Segment Pseudowire
MS-PW：多段伪导线
OAM: Operations, Administration, and Maintenance
OAM：运营、管理和维护
PHP: Penultimate Hop Pop
PHP：倒数第二跳流行音乐
PW: Pseudowire
伪线
TLV: Type, Length, Value
TLV：类型、长度、值
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[3]中所述进行解释。
This document defines two messages to indicate service disruptive conditions, Alarm Indication Signal and Lock Report. The semantics of the individual messages are described in subsections below. Fault OAM messages are applicable to LSPs used in the MPLS Transport Profile. Such LSPs are bound to specific server layers based upon static configuration or signaling in a client/server relationship.
本文件定义了两条指示服务中断条件的信息，即报警指示信号和锁定报告。下面的小节描述了各个消息的语义。故障OAM消息适用于MPLS传输配置文件中使用的LSP。此类LSP基于客户端/服务器关系中的静态配置或信令绑定到特定服务器层。
Fault Management messages are carried in-band of the client LSP or MS-PW by using the Associated Channel Header (ACH). For LSPs other than PWs, the ACH is identified by the Generic Associated Channel Label (GAL) as defined in RFC 5586 [4]. To facilitate recognition and delivery of Fault Management messages, the Fault Management Channel is identified by a unique Associated Channel (ACh) code point.
故障管理消息通过使用相关信道头（ACH）在客户端LSP或MS-PW的频带中传输。对于PWs以外的LSP，ACH由RFC 5586[4]中定义的通用关联信道标签（GAL）标识。为了便于识别和传递故障管理消息，故障管理通道由唯一的关联通道（ACh）代码点标识。
Fault OAM messages are generated by intermediate nodes where a client LSP is switched. When a server (sub-)layer, e.g., a link or bidirectional LSP, used by the client LSP fails, the intermediate node sends Fault Management messages downstream towards the end point of the LSP. The messages are sent to the client MEPs by inserting them into the affected client LSPs in the direction downstream of the fault location. These messages are sent periodically until the condition is cleared.
故障OAM消息由切换客户端LSP的中间节点生成。当客户端LSP使用的服务器（子）层（例如链路或双向LSP）失败时，中间节点向LSP的端点向下游发送故障管理消息。通过将消息插入故障位置下游方向的受影响客户端LSP，将消息发送至客户端MEP。这些消息会定期发送，直到条件清除为止。
The MPLS Alarm Indication Signal (AIS) message is generated in response to detecting faults in the server (sub-)layer. The AIS message SHOULD be sent as soon as the condition is detected, but MAY be delayed owing to processing in an implementation, and MAY be suppressed if protection is achieved very rapidly. For example, an AIS message may be sent during a protection switching event and would cease being sent (or cease being forwarded by the protection switch selector) if the protection switch was successful in restoring the link. However, an implementation may instead wait to see if the protection switch is successful prior to sending any AIS messages.
MPLS报警指示信号（AIS）消息是根据检测到服务器（子）层中的故障而生成的。AIS消息应在检测到情况后立即发送，但可能由于实现中的处理而延迟，并且如果很快实现保护，则可能被抑制。例如，可以在保护切换事件期间发送AIS消息，并且如果保护交换机成功恢复链路，则AIS消息将停止发送（或停止由保护交换机选择器转发）。然而，在发送任何AIS消息之前，实现可能会等待看保护切换是否成功。
The primary purpose of the AIS message is to suppress alarms in the layer network above the level at which the fault occurs. When the Link Down Indication is set, the AIS message can be used to trigger recovery mechanisms.
AIS消息的主要目的是抑制层网络中高于故障发生级别的报警。当设置链路断开指示时，AIS消息可用于触发恢复机制。
The Link Down Indication (LDI) is communicated by setting the L-Flag to 1. A node sets the L-Flag in the AIS message in response to detecting a failure in the server layer. A node MUST NOT set the L-Flag until the fault has been determined to be a server-failure. A node MUST set the L-Flag if the fault has been determined to be a server-failure. For example, during a server layer protection switching event, a node MUST NOT set the L-Flag. However, if the protection switch was unsuccessful in restoring the link within the expected repair time, the node MUST set the L-Flag.
链路下降指示（LDI）通过将L标志设置为1进行通信。节点在AIS消息中设置L标志，以响应检测到服务器层中的故障。在确定故障为服务器故障之前，节点不得设置L标志。如果故障被确定为服务器故障，则节点必须设置L标志。例如，在服务器层保护切换事件期间，节点不得设置L标志。但是，如果保护开关未能在预期修复时间内恢复链路，则节点必须设置L标志。
The setting of the L-Flag can be predetermined based on the protection state. For example, if a server layer is protected and both the working and protection paths are available, the node should send AIS with the L-Flag clear upon detecting a fault condition. If the server layer is unprotected, or the server layer is protected but only the active path is available, the node should send AIS with the L-Flag set upon detecting a loss of continuity (LOC) condition. Note again that the L-Flag is not set until a server-failure has been declared. Thus, if there is any hold-off timer associated with the LOC, then the L-Flag is not set until that timer has expired.
可以基于保护状态来预定L标志的设置。例如，如果服务器层受到保护，并且工作路径和保护路径都可用，则节点应在检测到故障条件时发送清除L标志的AIS。如果服务器层未受保护，或者服务器层受保护但只有活动路径可用，则节点应在检测到连续性丧失（LOC）情况时发送设置了L标志的AIS。再次注意，在声明服务器故障之前，不会设置L标志。因此，如果存在与LOC相关联的任何延迟计时器，则在该计时器过期之前不会设置L标志。
The receipt of an AIS message with the L-Flag set MAY be treated as the equivalent of LOC at the client layer. The choice of treatment is related to the rate at which the Continuity Check (CC) function is running. In a normal transport environment, CC is run at a high rate in order to detect a failure within tens of milliseconds. In such an environment, the L-Flag MAY be ignored and the AIS message is used solely for alarm suppression.
具有L标志集的AIS消息的接收可被视为等同于客户端层的LOC。治疗方法的选择与连续性检查（CC）功能的运行速度有关。在正常的传输环境中，CC以高速率运行，以便在数十毫秒内检测到故障。在这种环境中，L标志可能被忽略，AIS信息仅用于报警抑制。
In more general MPLS environments, the CC function may be running at a much slower rate. In this environment, the Link Down Indication enables faster switch-over upon a failure occurring along the client LSP.
在更一般的MPLS环境中，CC功能的运行速度可能要慢得多。在此环境中，链路断开指示可在客户端LSP发生故障时实现更快的切换。
The MPLS Lock Report (LKR) message is generated when a server (sub-)layer entity has been administratively locked. Its purpose is to communicate the locked condition to the client-layer entities. When a server layer is administratively locked, it is not available to carry client traffic. The purpose of the LKR message is to
当服务器（子）层实体已被管理锁定时，将生成MPLS锁定报告（LKR）消息。其目的是将锁定条件传达给客户端层实体。当服务器层被管理锁定时，它无法承载客户端流量。LKR消息的目的是
suppress alarms in the layer network above the level at which the administrative lock occurs and to allow the clients to differentiate the lock condition from a fault condition. While the primary purpose of the LKR message is to suppress alarms, similar to AIS with the LDI (L-Flag set), the receipt of an LKR message can be treated as the equivalent of loss of continuity at the client layer.
在管理锁定发生的级别上抑制层网络中的报警，并允许客户端区分锁定状态和故障状态。虽然LKR消息的主要目的是抑制报警，类似于带有LDI（L标志集）的AIS，但LKR消息的接收可被视为客户端层的连续性损失。
MPLS-TP allows for a hierarchy of LSPs. When the client MEP of an LSP (that is also acting as a server layer) receives FM indications, the following rules apply. If the CC function is disabled for the server LSP, a node SHOULD generate AIS messages toward any clients when either the AIS or LKR indication is raised. Note that the L-Flag is not automatically propagated. The rules of Section 2.1.1 apply. In particular, the L-Flag is not set until a server-failure has been declared.
MPLS-TP允许LSP的层次结构。当LSP（也充当服务器层）的客户端MEP接收到FM指示时，以下规则适用。如果服务器LSP禁用了CC功能，则当发出AIS或LKR指示时，节点应向任何客户端生成AIS消息。请注意，L标志不会自动传播。第2.1.1节的规则适用。特别是，在声明服务器故障之前，不会设置L标志。
The MPLS Fault Management channel is identified by the ACH as defined in RFC 5586 [4] with the Associated Channel Type set to the MPLS Fault Management (FM) code point = 0x0058. The FM Channel does not use ACh TLVs and MUST NOT include the ACh TLV header. The ACH with the FM ACh code point is shown below.
MPLS故障管理信道由ACH识别，如RFC 5586[4]中所定义，相关信道类型设置为MPLS故障管理（FM）码点=0x0058。FM频道不使用ACh TLV，且不得包含ACh TLV标头。带有FM ACH代码点的ACH如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x0058 FM Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS Fault Management Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | 0x0058 FM Channel |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~
~ MPLS Fault Management Message ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ACH Indication of the MPLS Fault Management Channel
图1:MPLS故障管理通道的ACH指示
The first three fields are defined in RFC 5586 [4].
前三个字段在RFC 5586[4]中定义。
The Fault Management Channel is 0x0058.
故障管理通道为0x0058。
The format of the Fault Management message is shown below.
故障管理消息的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Resvd | Msg Type | Flags | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vers | Resvd | Msg Type | Flags | Refresh Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total TLV Len | ~
+-+-+-+-+-+-+-+-+ TLVs ~
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: MPLS Fault OAM Message Format
图2:MPLS故障OAM消息格式
Version
版本
The Version Number is currently 1.
版本号当前为1。
Reserved
含蓄的
This field MUST be set to zero on transmission and ignored on receipt.
此字段在传输时必须设置为零，在接收时必须忽略。
Message Type
消息类型
The Message Type indicates the type of condition as listed in the table below.
消息类型表示下表中列出的条件类型。
Msg Type Description
-------- -----------------------------
0 Reserved
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
Msg Type Description
-------- -----------------------------
0 Reserved
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
Flags
旗帜
Two flags are defined. The reserved flags in this field MUST be set to zero on transmission and ignored on receipt.
定义了两个标志。此字段中的保留标志在传输时必须设置为零，在接收时必须忽略。
+-+-+-+-+-+-+-+-+
| Reserved |L|R|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
| Reserved |L|R|
+-+-+-+-+-+-+-+-+
Figure 3: Flags
图3：旗帜
L-Flag
L旗
Link Down Indication. The L-Flag only has significance in the AIS message. For the LKR message, the L-Flag MUST be set to zero and ignored on receipt. See Section 2.1.1 for details on setting this bit.
链接关闭指示。L标志仅在AIS信息中具有重要意义。对于LKR消息，L标志必须设置为零，并在收到时忽略。有关设置该位的详细信息，请参见第2.1.1节。
R-Flag
R旗
The R-Flag is clear to indicate the presence of an FM condition and is set to one to indicate the removal of a previously sent FM condition.
R标志清除以指示FM条件的存在，并设置为1以指示删除先前发送的FM条件。
Refresh Timer
刷新定时器
The maximum time between successive FM messages specified in seconds. The range is 1 to 20. The value 0 is not permitted.
以秒为单位指定的连续FM消息之间的最长时间。范围是1到20。不允许使用值0。
Total TLV Length
TLV总长度
The total length in bytes of all included TLVs.
所有包含的TLV的总长度（字节）。
TLVs are used in Fault Management messages to carry information that may not pertain to all messages as well as to allow for extensibility. The TLVs currently defined are the IF_ID and the Global_ID.
TLV用于故障管理消息中，以承载可能不属于所有消息的信息，并允许扩展性。当前定义的TLV是IF_ID和全局_ID。
TLVs have the following format:
TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| .
. Value .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
| .
. Value .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Fault TLV Format
图4：故障TLV格式
Type
类型
Encodes how the Value field is to be interpreted.
编码如何解释值字段。
Length
长
Specifies the length of the Value field in octets.
以八位字节为单位指定值字段的长度。
Value
价值
Octet string of Length octets that encodes information to be interpreted as specified by the Type field.
八位字节长度八位字节的字符串，该字符串对要按照类型字段指定的方式解释的信息进行编码。
The Interface Identifier (IF_ID) TLV carries the IF_ID as defined in RFC 6370 [5]. The Type is 1. The length is 0x8.
接口标识符（IF_ID）TLV携带RFC 6370[5]中定义的IF_ID。类型是1。长度为0x8。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Interface Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Interface Identifier TLV Format
图5：接口标识符TLV格式
The Global Identifier (Global_ID) TLV carries the Global_ID as defined in RFC 6370 [5]. The Type is 2. The length is 0x4.
全局标识符（Global_ID）TLV携带RFC 6370[5]中定义的全局_ID。类型是2。长度为0x4。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MPLS-TP Global Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Global Identifier TLV Format
图6：全局标识符TLV格式
Service disruptive conditions are indicated by sending FM messages. The message type is set to the value corresponding to the condition. The Refresh Timer is set to the maximum time between successive FM messages. This value MUST NOT be changed on successive FM messages reporting the same incident. If the optional clearing procedures are not used, then the default value is one second. Otherwise, the default value is 20 seconds.
通过发送FM消息来指示服务中断情况。消息类型设置为与条件对应的值。刷新计时器设置为连续FM消息之间的最长时间。不得在报告同一事件的连续FM消息上更改此值。如果未使用可选的清除程序，则默认值为1秒。否则，默认值为20秒。
A Global_ID MAY be included. If the R-Flag clearing procedures are to be used, the IF_ID TLV MUST be included. Otherwise, the IF_ID TLV MAY be included.
可以包括一个全局ID。如果要使用R标志清除程序，则必须包括If_ID TLV。否则，可以包括IF_ID TLV。
The message is then sent. Assuming the condition persists, the message MUST be retransmitted two more times at an interval of one second. Further retransmissions are made according to the value of the Refresh Timer. Retransmissions continue until the condition is cleared.
然后发送消息。假设该情况持续存在，则消息必须以1秒的间隔重新传输两次以上。根据刷新定时器的值进行进一步的重传。重新传输将继续，直到清除该条件。
When a fault is cleared, a node MUST cease sending the associated FM messages. Ceasing to send FM messages will clear the indication after 3.5 times the Refresh Timer. To clear an indication more quickly, the following procedure is used. The R-Flag of the FM message is set to one. Other fields of the FM message SHOULD NOT be modified. The message is sent immediately and then retransmitted two more times at an interval of one second. Note, however, if another fault occurs, the node MUST cease these retransmissions and generate new FM messages for the new fault.
当故障被清除时，节点必须停止发送相关的FM消息。停止发送FM消息将在刷新计时器3.5倍后清除指示。为了更快地清除指示，使用以下步骤。FM消息的R标志设置为1。不应修改FM消息的其他字段。消息立即发送，然后以1秒的间隔再传输两次。但是，请注意，如果发生另一个故障，节点必须停止这些重新传输，并为新故障生成新的FM消息。
When an FM message is received, a MEP examines it to ensure that it is well formed. If the message type is reserved or unknown, the message is ignored. If the version number is unknown, the message is ignored.
当接收到FM消息时，MEP将对其进行检查，以确保其格式正确。如果消息类型为保留或未知，则忽略该消息。如果版本号未知，则忽略该消息。
If the R-Flag is set to zero, the MEP checks to see if a condition matching the message type exists. If it does not, the condition specific to the message type is entered. An Expiration timer is set to 3.5 times the Refresh Timer. If the message type matches an existing condition, the message is considered a refresh and the Expiration timer is reset. In both cases, if an IF_ID TLV is present, it is recorded.
如果R标志设置为零，MEP将检查是否存在与消息类型匹配的条件。如果没有，则输入特定于消息类型的条件。过期计时器设置为刷新计时器的3.5倍。如果消息类型与现有条件匹配，则消息将被视为刷新，并重置过期计时器。在这两种情况下，如果存在if_ID TLV，则记录该TLV。
If the R-Flag is set to one, the MEP checks to see if a condition matching the message type and IF_ID exists. If it does, that condition is cleared. Otherwise, the message is ignored.
如果R标志设置为1，MEP将检查是否存在与消息类型匹配的条件以及是否存在_ID。如果是，则清除该条件。否则，该消息将被忽略。
If the Expiration timer expires, the condition is cleared.
如果过期计时器过期，则清除该条件。
At a minimum, an implementation MUST support the following:
实施至少必须支持以下内容：
1. Sending AIS and LKR messages at a rate of one per second.
1. 以每秒一条的速率发送AIS和LKR消息。
2. Support of setting the L-Flag to indicate a server-failure.
2. 支持设置L标志以指示服务器故障。
3. Receiving AIS and LKR messages with any allowed Refresh Timer value.
3. 接收具有任何允许刷新计时器值的AIS和LKR消息。
The following items are OPTIONAL to implement.
以下各项是可选的。
1. Sending AIS and LKR messages with values of the Refresh Timer other than one second.
1. 发送AIS和LKR消息时，刷新计时器的值不是1秒。
2. Support of receiving the L-Flag.
2. 支持接收L标志。
3. Support of setting the R-Flag to a value other than zero.
3. 支持将R标志设置为非零的值。
4. Support of receiving the R-Flag.
4. 支持接收R标志。
5. All TLVs.
5. 所有TLV。
MPLS-TP is a subset of MPLS and so builds upon many of the aspects of the security model of MPLS. MPLS networks make the assumption that it is very hard to inject traffic into a network, and equally hard to cause traffic to be directed outside the network. The control-plane protocols utilize hop-by-hop security and assume a "chain-of-trust" model such that end-to-end control-plane security is not used. For more information on the generic aspects of MPLS security, see RFC 5920 [8].
MPLS-TP是MPLS的一个子集，因此建立在MPLS安全模型的许多方面之上。MPLS网络假设很难将流量注入网络，也很难将流量定向到网络外部。控制平面协议利用逐跳安全性，并假设“信任链”模型，因此不使用端到端控制平面安全性。有关MPLS安全性的一般方面的更多信息，请参阅RFC 5920[8]。
This document describes a protocol carried in the G-ACh (RFC 5586 [4]) and so is dependent on the security of the G-ACh itself. The G-ACh is a generalization of the Associated Channel defined in RFC 4385 [6]. Thus, this document relies heavily on the security mechanisms provided for the Associated Channel as described in those two documents.
本文档描述了G-ACh（RFC 5586[4]）中的协议，因此依赖于G-ACh本身的安全性。G-ACh是RFC 4385[6]中定义的相关信道的推广。因此，本文档在很大程度上依赖于为这两个文档中描述的相关通道提供的安全机制。
A specific concern for the G-ACh is that is can be used to provide a covert channel. This problem is wider than the scope of this document and does not need to be addressed here, but it should be noted that the channel provides end-to-end connectivity and SHOULD
G-ACh的一个特别关注点是，它可以用来提供隐蔽通道。此问题超出了本文档的范围，此处不需要解决，但应注意，通道提供端到端连接，因此应
NOT be policed by transit nodes. Thus, there is no simple way of preventing any traffic being carried in the G-ACh between consenting nodes.
不受传输节点的监控。因此，没有简单的方法来防止在同意节点之间的G-ACh中承载任何业务。
A good discussion of the data-plane security of an Associated Channel may be found in RFC 5085 [9]. That document also describes some mitigation techniques.
RFC 5085[9]中对相关信道的数据平面安全性进行了详细讨论。该文件还描述了一些缓解技术。
It should be noted that the G-ACh is essentially connection-oriented, so injection or modification of control messages specified in this document requires the subversion of a transit node. Such subversion is generally considered hard to protect against in MPLS networks, and impossible to protect against at the protocol level. Management-level techniques are more appropriate.
应该注意的是，G-ACh本质上是面向连接的，因此本文档中指定的控制消息的注入或修改需要对传输节点进行颠覆。通常认为在MPLS网络中很难防止这种颠覆，在协议级别上也不可能防止这种颠覆。管理层技术更合适。
Spurious fault OAM messages form a vector for a denial-of-service attack. However, since these messages are carried in a control channel, except for one case discussed below, one would have to gain access to a node providing the service in order to effect such an attack. Since transport networks are usually operated as a walled garden, such threats are less likely.
虚假故障OAM消息构成拒绝服务攻击的载体。然而，由于这些消息是在控制信道中承载的，除了下面讨论的一种情况外，为了实施这种攻击，必须获得对提供服务的节点的访问权。由于交通网络通常作为一个有围墙的花园运行，因此此类威胁的可能性较小。
If external MPLS traffic is mapped to an LSP via a PHP forwarding operation, it is possible to insert a GAL followed by a fault OAM message. In such a situation, an operator SHOULD protect against this attack by filtering any fault OAM messages with the GAL at the top of the label stack.
如果通过PHP转发操作将外部MPLS流量映射到LSP，则可以在错误OAM消息之后插入GAL。在这种情况下，操作员应通过使用标签堆栈顶部的GAL过滤任何故障OAM消息来防范此攻击。
Fault OAM requires a unique Associated Channel Type that has been assigned by IANA from the Pseudowire Associated Channel Types registry.
故障OAM需要唯一的关联通道类型，该类型已由IANA从伪线关联通道类型注册表分配。
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0058 Fault OAM No (This Document)
Registry:
Value Description TLV Follows Reference
----------- ----------------------- ----------- ---------
0x0058 Fault OAM No (This Document)
This section details the "MPLS Fault OAM Message Type Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is divided into assignment ranges; the
本节详细介绍了“多协议标签交换（MPLS）操作、管理和管理（OAM）参数”注册表的新子注册表“MPLS故障OAM消息类型注册表”。将类型空间划分为赋值范围；这个
following terms are used in describing the procedures by which IANA allocates values (as defined in RFC 5226 [7]): "Standards Action" and "Experimental Use".
以下术语用于描述IANA分配值的程序（定义见RFC 5226[7]）：“标准行动”和“实验使用”。
MPLS Fault OAM Message Types take values in the range 0-255. Assignments in the range 0-251 are via Standards Action; values in the range 252-255 are for Experimental Use and MUST NOT be allocated.
MPLS故障OAM消息类型取值范围为0-255。0-251范围内的分配通过标准行动进行；252-255范围内的值仅供实验使用，不得分配。
Message Types defined in this document are:
本文档中定义的消息类型包括：
Msg Type Description
-------- -----------------------------
0 Reserved (not available for allocation)
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
Msg Type Description
-------- -----------------------------
0 Reserved (not available for allocation)
1 Alarm Indication Signal (AIS)
2 Lock Report (LKR)
This section details the "MPLS Fault OAM Flag Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Flag space ranges from 0-7. All flags are allocated by "Standards Action" (as defined in RFC 5226 [7]).
本节详细介绍了“多协议标签交换（MPLS）操作、管理和管理（OAM）参数”注册表的新子注册表“MPLS故障OAM标志注册表”。标志空间的范围为0-7。所有标志均由“标准行动”分配（如RFC 5226[7]中所定义）。
Flags defined in this document are:
本文件中定义的标志为：
Bit Hex Value Description
--- --------- -----------
0-5 Unassigned
6 0x2 L-Flag
7 0x1 R-Flag
Bit Hex Value Description
--- --------- -----------
0-5 Unassigned
6 0x2 L-Flag
7 0x1 R-Flag
This sections details the "MPLS Fault OAM TLV Registry", a new sub-registry of the "Multiprotocol Label Switching (MPLS) Operations, Administration, and Management (OAM) Parameters" registry. The Type space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA allocates values (as defined in RFC 5226 [7]): "Standards Action", "Specification Required", and "Experimental Use".
本节详细介绍了“多协议标签交换（MPLS）操作、管理和管理（OAM）参数”注册表的新子注册表“MPLS故障OAM TLV注册表”。将类型空间划分为赋值范围；以下术语用于描述IANA分配值的程序（如RFC 5226[7]中的定义）：“标准行动”、“要求规范”和“实验使用”。
MPLS Fault OAM TLVs take values in the range 0-255. Assignments in the range 0-191 are via Standards Action; assignments in the range 192-247 are made via "Specification Required"; values in the range 248-255 are for Experimental Use and MUST NOT be allocated.
MPLS故障OAM TLV的取值范围为0-255。0-191范围内的分配通过标准行动进行；192-247范围内的分配通过“所需规格”进行；248-255范围内的值仅供实验使用，不得分配。
TLVs defined in this document are:
本文件中定义的TLV为：
Value TLV Name
----- -------
0 Reserved (not available for allocation)
1 Interface Identifier TLV
2 Global Identifier
Value TLV Name
----- -------
0 Reserved (not available for allocation)
1 Interface Identifier TLV
2 Global Identifier
[1] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
[1] Niven Jenkins，B.，Ed.，Brungard，D.，Ed.，Betts，M.，Ed.，Sprecher，N.，和S.Ueno，“MPLS传输配置文件的要求”，RFC 56542009年9月。
[2] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[2] Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.，“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，2010年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
[4] Bocci，M.，Ed.，Vigoureux，M.，Ed.，和S.Bryant，Ed.，“MPLS通用关联信道”，RFC 55862009年6月。
[5] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[5] Bocci，M.，Swallow，G.和E.Gray，“MPLS传输配置文件（MPLS-TP）标识符”，RFC 63702011年9月。
[6] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[6] Bryant，S.，Swallow，G.，Martini，L.，和D.McPherson，“用于MPLS PSN的伪线仿真边到边（PWE3）控制字”，RFC 4385，2006年2月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[7] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[8] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010.
[8] Fang，L.，Ed.“MPLS和GMPLS网络的安全框架”，RFC 5920，2010年7月。
[9] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007.
[9] Nadeau，T.，Ed.，和C.Pignataro，Ed.，“伪线虚拟电路连接验证（VCCV）：伪线的控制通道”，RFC 5085，2007年12月。
Stewart Bryant Cisco Systems, Inc. 250, Longwater Green Park, Reading RG2 6GB UK
Stewart Bryant Cisco Systems，Inc.250，Longwater Green Park，Reading RG2 6GB英国
EMail: stbryant@cisco.com
EMail: stbryant@cisco.com
Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada
Siva Sivabalan思科系统公司，加拿大安大略省卡纳塔创新大道2000号K2K 3E8
EMail: msiva@cisco.com
EMail: msiva@cisco.com
Authors' Addresses
作者地址
George Swallow (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, Massachusetts 01719 United States
George Swallow（编辑）思科系统公司，美国马萨诸塞州Boxborough市比弗布鲁克路300号，邮编01719
EMail: swallow@cisco.com
EMail: swallow@cisco.com
Annamaria Fulignoli (editor) Ericsson Via Moruzzi Pisa 56100 Italy
安娜玛丽亚·富利诺利（编辑）爱立信Via Moruzzi Pisa 56100意大利
EMail: annamaria.fulignoli@ericsson.com
EMail: annamaria.fulignoli@ericsson.com
Martin Vigoureux (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France
Martin Vigoureux（编辑）阿尔卡特-朗讯维勒赫斯特-诺扎伊路线91620法国
EMail: martin.vigoureux@alcatel-lucent.com
EMail: martin.vigoureux@alcatel-lucent.com
Sami Boutros Cisco Systems, Inc. 3750 Cisco Way San Jose, California 95134 USA
Sami Boutros Cisco Systems，Inc.美国加利福尼亚州圣何塞市思科大道3750号，邮编95134
EMail: sboutros@cisco.com
EMail: sboutros@cisco.com
David Ward Juniper Networks, Inc.
David Ward Juniper网络公司。
EMail: dward@juniper.net
EMail: dward@juniper.net