Internet Engineering Task Force (IETF) J. Dong
Request for Comments: 7571 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Z. Li
China Mobile
D. Ceccarelli
Ericsson
July 2015
Internet Engineering Task Force (IETF) J. Dong
Request for Comments: 7571 M. Chen
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 Z. Li
China Mobile
D. Ceccarelli
Ericsson
July 2015
GMPLS RSVP-TE Extensions for Lock Instruct and Loopback
用于锁指令和环回的GMPLS RSVP-TE扩展
Abstract
摘要
This document specifies extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) to support Lock Instruct (LI) and Loopback (LB) mechanisms for Label Switched Paths (LSPs). These mechanisms are applicable to technologies that use Generalized MPLS (GMPLS) for the control plane.
本文档指定了对资源预留协议-流量工程（RSVP-TE）的扩展，以支持标签交换路径（LSP）的锁指令（LI）和环回（LB）机制。这些机制适用于将通用MPLS（GMPLS）用于控制平面的技术。
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/rfc7571.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7571.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-Codes . . . . . . . . . . . . . . . 6
4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Flag Definitions for LI and LB . . . . . . . . . . . . . . . 3
2.1. Lock Instruct Indication . . . . . . . . . . . . . . . . 3
2.2. Extensions for Loopback . . . . . . . . . . . . . . . . . 3
3. Operational Procedures . . . . . . . . . . . . . . . . . . . 3
3.1. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Loopback . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. Attribute Flags . . . . . . . . . . . . . . . . . . . . . 6
4.2. RSVP Error Value Sub-Codes . . . . . . . . . . . . . . . 6
4.3. Allocation Rule for ERO Subobjects . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
The requirements for Lock Instruct (LI) and Loopback (LB) in the Multiprotocol Label Switching Transport Profile (MPLS-TP) are specified in [RFC5860], and the framework of LI and LB is specified in [RFC6371]. A Label Switched Path (LSP) that is locked, using LI, is prevented from carrying user data traffic. The LB function can only be applied to an LSP that has been previously locked.
[RFC5860]规定了多协议标签交换传输配置文件（MPLS-TP）中锁指令（LI）和环回（LB）的要求，并且[RFC6371]规定了LI和LB的框架。使用LI锁定的标签交换路径（LSP）被阻止承载用户数据流量。LB功能只能应用于先前已锁定的LSP。
In general, the LI and LB are useful Operations, Administration, and Maintenance (OAM) functions for technologies that use Generalized MPLS (GMPLS) for the control plane, e.g., time-division multiplexing, wavelength-division multiplexing, and packet switching. It is natural to use and extend the GMPLS control-plane protocol to provide a unified approach for LI and LB provisioning in all these technologies.
通常，LI和LB是用于控制平面的通用MPLS（GMPLS）技术的有用操作、管理和维护（OAM）功能，例如，时分复用、波分复用和分组交换。在所有这些技术中，使用和扩展GMPLS控制平面协议以提供统一的LI和LB资源调配方法是很自然的。
[RFC7487] specifies the RSVP-TE extensions for the configuration of proactive MPLS-TP OAM functions, such as Continuity Check (CC), Connectivity Verification (CV), Delay Measurement (DM), and Loss Measurement (LM). The provisioning of on-demand OAM functions such as LI and LB are not covered in that document.
[RFC7487]指定用于配置主动MPLS-TP OAM功能的RSVP-TE扩展，如连续性检查（CC）、连接验证（CV）、延迟测量（DM）和损耗测量（LM）。该文档不包括按需OAM功能（如LI和LB）的配置。
This document specifies extensions to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) to support lock instruct and loopback mechanisms for LSPs. The mechanisms are applicable to technologies
本文档指定了对资源预留协议流量工程（RSVP-TE）的扩展，以支持LSP的锁指令和环回机制。这些机制适用于各种技术
that use GMPLS for the control plane. For a network supporting MPLS-TP, the mechanisms defined in this document are complementary to [RFC6435].
将GMPLS用于控制平面。对于支持MPLS-TP的网络，本文档中定义的机制是对[RFC6435]的补充。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
In order to indicate the lock/unlock status of the LSP, the A (Administratively down) bit in the Administrative Status (ADMIN_STATUS) Object [RFC3471] [RFC3473] is used.
为了指示LSP的锁定/解锁状态，使用管理状态（管理状态）对象[RFC3471][RFC3473]中的A（管理向下）位。
In order to indicate the loopback mode of LSP, a new bit flag is defined in the Attribute Flags TLV [RFC5420].
为了指示LSP的环回模式，在属性标志TLV[RFC5420]中定义了一个新的位标志。
Loopback flag:
环回标志：
This flag indicates a particular node on the LSP is required to enter loopback mode. This can also be used for specifying the loopback state of the node.
此标志表示LSP上的特定节点需要进入环回模式。这也可用于指定节点的环回状态。
- Bit number: 13
- 位号：13
- Attribute flag carried in Path message: Yes
- 路径消息中携带的属性标志：是
- Attribute flag carried in Resv message: No
- Resv消息中携带的属性标志：否
- Attribute flag carried in the Record Route Object (RRO) Attributes subobject: Yes
- 记录路由对象（RRO）属性子对象中携带的属性标志：是
When an ingress node intends to put an LSP into lock mode, it MUST send a Path message with the Administratively down (A) bit used as specified above and the Reflect (R) bit in the ADMIN_STATUS Object set.
当入口节点打算将LSP置于锁定模式时，它必须发送一条路径消息，其中包含如上所述使用的管理下行（a）位和管理状态对象集中的反射（R）位。
On receipt of this Path message, the egress node SHOULD try to take the LSP out of service. If the egress node locks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object set. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Lock Failure", and the following Resv messages MUST be sent with the A bit cleared.
收到此路径消息后，出口节点应尝试使LSP停止服务。若出口节点成功锁定LSP，它必须发送一条Resv消息，其中包含ADMIN_STATUS对象集中的一个位。否则，它必须发送带有错误代码“OAM问题”[RFC7260]和新错误值“Lock Failure”的PathErr消息，并且必须在清除位的情况下发送以下Resv消息。
When an LSP is put in lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object set.
当LSP处于锁定模式时，后续的Path和Resv消息必须在ADMIN_STATUS对象集中保持A位。
When the ingress node intends to take the LSP out of the lock mode, it MUST send a Path message with the A bit in the ADMIN_STATUS Object cleared.
当入口节点打算使LSP退出锁定模式时，它必须发送一条Path消息，并清除ADMIN_状态对象中的一位。
On receipt of this Path message, the egress node SHOULD try to bring the LSP back to service. If the egress node unlocks the LSP successfully, it MUST send a Resv message with the A bit in the ADMIN_STATUS Object cleared. Otherwise, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Unlock Failure", and the following Resv messages MUST be sent with the A bit set.
收到此路径消息后，出口节点应尝试使LSP恢复服务。若出口节点成功解锁LSP，它必须发送一条Resv消息，并清除ADMIN_STATUS对象中的一位。否则，它必须发送带有错误代码“OAM问题”[RFC7260]和新错误值“Unlock Failure”的PathErr消息，并且必须发送以下Resv消息并设置位。
When an LSP is taken out of lock mode, the subsequent Path and Resv messages MUST keep the A bit in the ADMIN_STATUS Object cleared.
当LSP退出锁定模式时，后续的Path和Resv消息必须将ADMIN_STATUS对象中的A位保持为清除状态。
The loopback request can be sent either to the egress node or to a particular intermediate node. The mechanism defined in [RFC7570] is used for addressing the loopback request to a particular node on the LSP. The ingress node MUST ensure that the LSP is in lock mode before it requests setting a particular node on the LSP into loopback mode.
环回请求可以发送到出口节点或特定中间节点。[RFC7570]中定义的机制用于将环回请求寻址到LSP上的特定节点。入口节点在请求将LSP上的特定节点设置为环回模式之前，必须确保LSP处于锁定模式。
When an ingress node intends to put a particular node on the LSP into loopback mode, it MUST send a Path message with the Loopback Attribute Flag defined above in the Attribute Flags TLV set. The mechanism defined in [RFC7570] is used to address the loopback request to the particular node. The ingress node MUST ensure that the entity at which loopback is intended to occur is explicitly identified by the immediately preceding subobject of the Explicit Route Object (ERO) Hop Attributes subobject. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate that the LSP is still in lock mode.
当入口节点打算将LSP上的特定节点置于环回模式时，它必须发送一条Path消息，其中包含上述属性标志TLV集合中定义的环回属性标志。[RFC7570]中定义的机制用于解决特定节点的环回请求。入口节点必须确保要发生环回的实体由显式路由对象（ERO）跃点属性子对象的前一个子对象显式标识。ADMIN_STATUS对象中的管理向下（A）位必须保持设置，以指示LSP仍处于锁定模式。
On receipt of this Path message, the target node of the loopback request MUST check if the LSP is in lock mode by verifying that the Administratively down (A) bit is set in the ADMIN_STATUS Object. If the bit is not set, the loopback request MUST be ignored. If the bit is set, the node MUST check that the desired loopback entity is explicitly identified by the ERO subobject prior to the ERO Hop Attributes subobject. Currently, the type value MUST be verified to be less than 32 (i.e., able to identify a specific entity where a loopback can occur; see Section 4.3), and for type values 1 (IPv4 prefix) and 2 (IPv6 prefix), the prefix length MUST be 32 and 128, respectively. If the desired loopback entity is not explicitly identified, the request MUST be ignored and a "Bad EXPLICIT_ROUTE object" error SHOULD be generated. Otherwise, the node SHOULD try to put the LSP into loopback mode. The loopback SHOULD be enabled on the entity identified by the ERO subobject immediately prior to the ERO Hop Attributes subobject. If the immediately preceding subobject is a label subobject [RFC3473], the loopback SHOULD be enabled for the direction indicated by the U bit of the label subobject.
收到此Path消息后，环回请求的目标节点必须通过验证ADMIN_STATUS对象中是否设置了管理性关闭（A）位来检查LSP是否处于锁定模式。如果未设置位，则必须忽略环回请求。如果设置了位，则节点必须检查ERO子对象是否在ERO Hop Attributes子对象之前明确标识了所需的环回实体。目前，必须验证类型值是否小于32（即，能够识别可能发生环回的特定实体；请参见第4.3节），对于类型值1（IPv4前缀）和2（IPv6前缀），前缀长度必须分别为32和128。如果未明确标识所需的环回实体，则必须忽略该请求，并应生成“错误的显式路由对象”错误。否则，节点应尝试将LSP置于环回模式。应在ERO Hop Attributes子对象之前的ERO子对象标识的实体上启用环回。如果前一个子对象是标签子对象[RFC3473]，则应针对标签子对象的U位指示的方向启用环回。
If the node puts the LSP into loopback mode successfully, it MUST set the Loopback Attribute Flag if it adds, per [RFC7570], an RRO Hop Attributes subobject to the RRO of a Path or Resv message. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set in the message. If the node cannot put the LSP into loopback mode, it MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Loopback Failure".
如果节点成功地将LSP置于环回模式，则如果节点根据[RFC7570]向路径或Resv消息的RRO添加了一个RRO Hop Attributes子对象，则必须设置环回属性标志。必须在消息中设置ADMIN_STATUS对象中的管理下降（A）位。如果节点无法将LSP置于环回模式，则必须发送一条PathErr消息，其中包含错误代码“OAM问题”[RFC7260]和新的错误值“环回失败”。
When the ingress node intends to take the particular node out of loopback mode, it MUST send a Path message with the Loopback Attribute Flag in the Attribute Flags TLV cleared. The mechanism defined in [RFC7570] is used to indicate that the particular node SHOULD exit loopback mode for this LSP. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set to indicate the LSP is still in lock mode.
当入口节点打算将特定节点移出环回模式时，它必须发送一条Path消息，并清除属性标志TLV中的环回属性标志。[RFC7570]中定义的机制用于指示特定节点应退出此LSP的环回模式。ADMIN_STATUS对象中的管理向下（A）位必须保持设置，以指示LSP仍处于锁定模式。
On receipt of this Path message, the target node SHOULD try to take the LSP out of loopback mode. If the node takes the LSP out of loopback mode successfully, it MUST clear the Loopback Attribute Flag in the RRO Hop Attributes subobject and push this subobject onto the RRO object in the corresponding Path or Resv message. The Administratively down (A) bit in the ADMIN_STATUS Object MUST be kept set in the message. Otherwise, the node MUST send a PathErr message with the Error Code "OAM Problem" [RFC7260] and the new Error Value "Exit Loopback Failure".
在收到此Path消息后，目标节点应尝试使LSP退出环回模式。如果节点成功使LSP退出环回模式，则必须清除RRO Hop Attributes子对象中的环回属性标志，并将此子对象推送到相应路径或Resv消息中的RRO对象上。必须在消息中设置ADMIN_STATUS对象中的管理下降（A）位。否则，节点必须发送带有错误代码“OAM问题”[RFC7260]和新错误值“退出环回失败”的PathErr消息。
After the loopback mode is cleared successfully, the ingress node MAY remove the Lock Instruct using the mechanism defined in Section 3.1. The ingress node MUST NOT request to exit lock mode if the LSP is
成功清除环回模式后，入口节点可使用第3.1节中定义的机制移除锁定指令。如果LSP处于锁定状态，则入口节点不得请求退出锁定模式
still in loopback mode. The egress node MUST ignore such a request when the LSP is still in loopback mode.
仍处于环回模式。当LSP仍处于环回模式时，出口节点必须忽略此类请求。
IANA has assigned new values defined in this document and summarized in this section.
IANA分配了本文件中定义的新值，并在本节中进行了总结。
IANA maintains a registry called "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" with a sub-registry called "Attribute Flags".
IANA维护一个名为“资源预留协议流量工程（RSVP-TE）参数”的注册表和一个名为“属性标志”的子注册表。
IANA has assigned a new bit flag as follows:
IANA分配了一个新的位标志，如下所示：
Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+-------------
13 | Loopback | Yes | No | Yes | Yes |this document
Bit | | Attribute | Attribute | | |
No. | Name | Flags Path | Flags Resv | RRO | ERO | Reference
-----+-----------+------------+------------+-----+-----+-------------
13 | Loopback | Yes | No | Yes | Yes |this document
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Error Codes and Globally-Defined Error Value Sub-Codes".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，其中包含一个名为“错误代码和全局定义的错误值子代码”的子注册表。
IANA has assigned four new Error Value sub-codes for the "OAM Problem" Error Code:
IANA为“OAM问题”错误代码分配了四个新的错误值子代码：
Value | Description | Reference
-----------+-----------------------------+--------------
26 | Lock Failure | this document
27 | Unlock Failure | this document
28 | Loopback Failure | this document
29 | Exit Loopback Failure | this document
Value | Description | Reference
-----------+-----------------------------+--------------
26 | Lock Failure | this document
27 | Unlock Failure | this document
28 | Loopback Failure | this document
29 | Exit Loopback Failure | this document
IANA maintains a registry called "Resource Reservation Protocol (RSVP) Parameters" with a sub-registry called "Class Names, Class Numbers, and Class Types".
IANA维护一个名为“资源保留协议（RSVP）参数”的注册表，以及一个名为“类名、类号和类类型”的子注册表。
For Explicit Route Object, the allocation rule for subobject types in the range 5-31 (0x05 - 0x1F) has been updated as:
对于显式路由对象，范围为5-31（0x05-0x1F）的子对象类型的分配规则已更新为：
5-31 Unassigned (For explicit resource identification)
5-31未分配（用于明确的资源标识）
This document does not introduce any new security issues beyond those identified in [RFC3209], [RFC3473], and [RFC7570]. For a more comprehensive discussion of GMPLS security and attack mitigation techniques, please see "Security Framework for MPLS and GMPLS Networks" [RFC5920].
除[RFC3209]、[RFC3473]和[RFC7570]中确定的安全问题外，本文件不会引入任何新的安全问题。有关GMPLS安全和攻击缓解技术的更全面讨论，请参阅“MPLS和GMPLS网络的安全框架”[RFC5920]。
In addition, the reporting of the loopback status using the RRO may reveal details about the node that the operator wishes to remain confidential. The privacy considerations as described in paragraph 3 of Section 5 of [RFC7570] also apply to this document.
此外，使用RRO报告环回状态可能会透露操作员希望保密的节点的详细信息。[RFC7570]第5节第3段所述的隐私注意事项也适用于本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，DOI 10.17487/RFC3209，2001年12月<http://www.rfc-editor.org/info/rfc3209>.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, DOI 10.17487/RFC3471, January 2003, <http://www.rfc-editor.org/info/rfc3471>.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，DOI 10.17487/RFC3471，2003年1月<http://www.rfc-editor.org/info/rfc3471>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <http://www.rfc-editor.org/info/rfc3473>.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，DOI 10.17487/RFC3473，2003年1月<http://www.rfc-editor.org/info/rfc3473>.
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, DOI 10.17487/RFC5420, February 2009, <http://www.rfc-editor.org/info/rfc5420>.
[RFC5420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，JP.，和A.Ayangarps，“使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码”，RFC 5420，DOI 10.17487/RFC5420，2009年2月<http://www.rfc-editor.org/info/rfc5420>.
[RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, <http://www.rfc-editor.org/info/rfc5860>.
[RFC5860]Vigoureux，M.，Ed.，Ward，D.，Ed.，和M.Betts，Ed.“MPLS传输网络中的操作、管理和维护（OAM）要求”，RFC 5860，DOI 10.17487/RFC5860，2010年5月<http://www.rfc-editor.org/info/rfc5860>.
[RFC7260] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE Extensions for Operations, Administration, and Maintenance (OAM) Configuration", RFC 7260, DOI 10.17487/RFC7260, June 2014, <http://www.rfc-editor.org/info/rfc7260>.
[RFC7260]Takacs，A.，Fedyk，D.，和J.He，“用于运行、管理和维护（OAM）配置的GMPLS RSVP-TE扩展”，RFC 7260，DOI 10.17487/RFC7260，2014年6月<http://www.rfc-editor.org/info/rfc7260>.
[RFC7570] Margaria, C., Ed., Martinelli, G., Balls, S., and B. Wright, "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, DOI 10.17487/RFC7570, July 2015, <http://www.rfc-editor.org/info/rfc7570>.
[RFC7570]Margaria，C.，Ed.，Martinelli，G.，Balls，S.，和B.Wright，“显式路由对象（ERO）中的标签交换路径（LSP）属性”，RFC 7570，DOI 10.17487/RFC7570，2015年7月<http://www.rfc-editor.org/info/rfc7570>.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, <http://www.rfc-editor.org/info/rfc5920>.
[RFC5920]方，L.，编辑，“MPLS和GMPLS网络的安全框架”，RFC 5920，DOI 10.17487/RFC5920，2010年7月<http://www.rfc-editor.org/info/rfc5920>.
[RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, <http://www.rfc-editor.org/info/rfc6371>.
[RFC6371]Busi，I.，Ed.和D.Allan，Ed.，“基于MPLS的传输网络的运营、管理和维护框架”，RFC 6371，DOI 10.17487/RFC63711911年9月<http://www.rfc-editor.org/info/rfc6371>.
[RFC6435] Boutros, S., Ed., Sivabalan, S., Ed., Aggarwal, R., Ed., Vigoureux, M., Ed., and X. Dai, Ed., "MPLS Transport Profile Lock Instruct and Loopback Functions", RFC 6435, DOI 10.17487/RFC6435, November 2011, <http://www.rfc-editor.org/info/rfc6435>.
[RFC6435]Boutros，S.，Ed.，Sivabalan，S.，Ed.，Aggarwal，R.，Ed.，Vigoureux，M.，Ed.，和X.Dai，Ed.，“MPLS传输配置文件锁定指令和环回功能”，RFC 6435，DOI 10.17487/RFC6435，2011年11月<http://www.rfc-editor.org/info/rfc6435>.
[RFC7487] Bellagamba, E., Takacs, A., Mirsky, G., Andersson, L., Skoldstrom, P., and D. Ward, "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using RSVP-TE", RFC 7487, DOI 10.17487/RFC7487, March 2015, <http://www.rfc-editor.org/info/rfc7487>.
[RFC7487]Bellagamba，E.，Takacs，A.，Mirsky，G.，Andersson，L.，Skoldstrom，P.，和D.Ward，“使用RSVP-TE为基于MPLS的传输网络配置主动操作、管理和维护（OAM）功能”，RFC 7487，DOI 10.17487/RFC7487，2015年3月<http://www.rfc-editor.org/info/rfc7487>.
Acknowledgments
致谢
The authors would like to thank Greg Mirsky, Lou Berger, and Francesco Fondelli for their comments and suggestions.
作者要感谢Greg Mirsky、Lou Berger和Francesco Fondelli的评论和建议。
Authors' Addresses
作者地址
Jie Dong Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China
中国北京市北青路156号华为校园华为技术有限公司，邮编：100095
Email: jie.dong@huawei.com
Email: jie.dong@huawei.com
Mach(Guoyi) Chen Huawei Technologies Huawei Campus, No.156 Beiqing Rd. Beijing 100095 China
中国北京市北青路156号华为校园Mach（国一）陈华为技术有限公司100095
Email: mach.chen@huawei.com
Email: mach.chen@huawei.com
Zhenqiang Li China Mobile Unit2, Dacheng Plaza, No. 28 Xuanwumenxi Ave. Beijing 100053 China
中国北京宣武门西路28号大成广场2号振强里中国移动100053
Email: lizhenqiang@chinamobile.com
Email: lizhenqiang@chinamobile.com
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy
Daniele Ceccarelli Ericsson通过A.Negrone 1/A Genova-意大利塞斯特里·波南特
Email: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com