Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 8001 Huawei
Category: Standards Track O. Gonzalez de Dios, Ed.
ISSN: 2070-1721 Telefonica Global CTO
C. Margaria
Juniper
M. Hartley
Z. Ali
Cisco
January 2017
Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 8001 Huawei
Category: Standards Track O. Gonzalez de Dios, Ed.
ISSN: 2070-1721 Telefonica Global CTO
C. Margaria
Juniper
M. Hartley
Z. Ali
Cisco
January 2017
RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information
用于收集共享风险链接组（SRLG）信息的RSVP-TE扩展
Abstract
摘要
This document provides extensions for Resource Reservation Protocol - Traffic Engineering (RSVP-TE), including GMPLS, to support automatic collection of Shared Risk Link Group (SRLG) information for the TE link formed by a Label Switched Path (LSP).
本文档提供了资源预留协议-流量工程（RSVP-TE）的扩展，包括GMPLS，以支持自动收集标签交换路径（LSP）形成的TE链路的共享风险链路组（SRLG）信息。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8001.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8001.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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. Applicability Example: Dual-Homing . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 6
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . . 6
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG Subobject . . . . . . . . . . . . . . . . . . . 7
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
8.3. Policy Control Failure Error Subcodes . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability Example: Dual-Homing . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . . 5
3.1. SRLG Collection Indication . . . . . . . . . . . . . . . . 5
3.2. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 6
3.3. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. SRLG ID Definition . . . . . . . . . . . . . . . . . . . . 6
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SRLG Collection Flag . . . . . . . . . . . . . . . . . . . 6
4.2. RRO SRLG Subobject . . . . . . . . . . . . . . . . . . . 7
5. Signaling Procedures . . . . . . . . . . . . . . . . . . . . . 8
5.1. SRLG Collection . . . . . . . . . . . . . . . . . . . . . 8
5.2. SRLG Update . . . . . . . . . . . . . . . . . . . . . . . 10
5.3 Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
5.4. Compatibility . . . . . . . . . . . . . . . . . . . . . . 11
6. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6.1. Policy Configuration . . . . . . . . . . . . . . . . . . . 11
6.2. Coherent SRLG IDs . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12
8.2. ROUTE_RECORD Object . . . . . . . . . . . . . . . . . . . 12
8.3. Policy Control Failure Error Subcodes . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
It is important to understand which Traffic Engineering (TE) links in a given network might be at risk from the same failures. In this sense, a set of links can constitute a Shared Risk Link Group (SRLG) if they share a resource whose failure can affect all links in the set [RFC4202].
了解给定网络中的哪些流量工程（TE）链路可能面临相同故障的风险非常重要。从这个意义上讲，如果一组链路共享一个资源，而该资源的故障可能会影响该组中的所有链路，则它们可以构成共享风险链路组（SRLG）[RFC4202]。
On the other hand, as described in [RFC4206] and [RFC6107], a Hierarchical LSP (H-LSP) or stitched LSP (S-LSP) can be used for carrying one or more other LSPs. Both the H-LSP and S-LSP can be formed as a TE link. In such cases, it is important to know the SRLG information of the LSPs that will be used to carry further LSPs.
另一方面，如[RFC4206]和[RFC6107]中所述，分层LSP（H-LSP）或缝合LSP（S-LSP）可用于承载一个或多个其他LSP。H-LSP和S-LSP都可以形成TE链路。在这种情况下，了解将用于承载更多LSP的LSP的SRLG信息非常重要。
This document provides a signaling mechanism that collects the SRLGs that are used by an LSP and can then be advertised as properties of the TE link formed by that LSP.
本文档提供了一种信令机制，该机制收集LSP使用的SRLGs，然后可以作为该LSP形成的TE链路的属性进行广告。
An interesting use case for the SRLG collection procedures defined in this document is achieving LSP diversity in a dual-homing scenario. The use case is illustrated in Figure 1, when the overlay model is applied as defined in [RFC4208]. In this example, the exchange of routing information over the User-Network Interface (UNI) is prohibited by operator policy.
本文档中定义的SRLG收集过程的一个有趣用例是在双归宿场景中实现LSP多样性。当按照[RFC4208]中的定义应用覆盖模型时，用例如图1所示。在此示例中，操作员策略禁止通过用户网络接口（UNI）交换路由信息。
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+
+---+ | PE1 | | PE3 | +---+
|CE1|----| | | |----|CE2|
+---+\ +-----+ +-----+ /+---+
\ | | /
\ +-----+ +-----+ /
\| PE2 | | PE4 |/
| | | |
+-----+ +-----+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+
+---+ | PE1 | | PE3 | +---+
|CE1|----| | | |----|CE2|
+---+\ +-----+ +-----+ /+---+
\ | | /
\ +-----+ +-----+ /
\| PE2 | | PE4 |/
| | | |
+-----+ +-----+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
Figure 1: Dual-Homing Configuration
图1：双归宿配置
Single-homed customer edge (CE) devices are connected to a single provider edge (PE) device via a single UNI link (which could be a bundle of parallel links, typically using the same fiber cable). This single UNI link can constitute a single point of failure. Such a single point of failure can be avoided if the CE device is connected to two PE devices via two UNI interfaces for CE1 and CE2, respectively, as depicted in Figure 1.
单宿客户边缘（CE）设备通过单个UNI链路（可能是一组并行链路，通常使用相同的光缆）连接到单个提供商边缘（PE）设备。该单单链路可构成单点故障。如图1所示，如果CE设备通过CE1和CE2的两个UNI接口分别连接到两个PE设备，则可以避免这种单点故障。
For the dual-homing case, it is possible to establish two connections (LSPs) from the source CE device to the same destination CE device where one connection is using one UNI link to PE1, for example, and the other connection is using the UNI link to PE2. In order to avoid single points of failure within the provider network, it is necessary to also ensure path (LSP) diversity within the provider network to achieve end-to-end diversity for the two LSPs between the two CE devices CE1 and CE2. This use case describes how it is possible to achieve path diversity within the provider network based on collected SRLG information. As the two connections (LSPs) enter the provider network at different PE devices, the PE device that receives the connection request for the second connection needs to know the additional path computation constraints such that the path of the second LSP is disjoint with respect to the already established first connection.
对于双归巢情况，可以建立从源CE设备到相同目的地CE设备的两个连接（lsp），其中一个连接使用到PE1的一个UNI链路，而另一个连接使用到PE2的UNI链路。为了避免提供商网络内的单点故障，还必须确保提供商网络内的路径（LSP）多样性，以实现两个CE设备CE1和CE2之间的两个LSP的端到端多样性。本用例描述了如何根据收集的SRLG信息在提供商网络内实现路径多样性。当两个连接（LSP）在不同PE设备处进入提供商网络时，接收第二连接的连接请求的PE设备需要知道附加路径计算约束，使得第二LSP的路径相对于已经建立的第一连接是不相交的。
As SRLG information is normally not shared between the provider network and the client network, i.e., between PE and CE devices, the challenge is how to solve the diversity problem when a CE is dual-homed. The RSVP extensions for collecting SRLG information defined in this document make it possible to retrieve SRLG information for an LSP and hence solve the dual-homing LSP diversity problem. For example, CE1 in Figure 1 may have requested an LSP1 to CE2 via PE1 that is routed via PE3 to CE2. CE1 can then subsequently request an LSP2 to CE2 via PE2 with the constraint that it needs to be maximally SRLG disjoint with respect to LSP1. PE2, however, does not have any SRLG information associated with LSP1, and this is needed as input for its constraint-based path computation function. If CE1 is capable of retrieving the SRLG information associated with LSP1 from PE1, it can pass this discovered information to PE2 as part of the LSP2 setup request (RSVP PATH message) in an EXCLUDE_ROUTE Object (XRO) or Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874], and PE2 can now calculate a path for LSP2 that is SRLG disjoint with respect to LSP1. The SRLG information associated with LSP1 can be retrieved when LSP1 is established or at any time before LSP2 is set up.
由于SRLG信息通常不会在提供商网络和客户端网络之间共享，即在PE和CE设备之间共享，因此面临的挑战是如何解决CE双宿时的分集问题。本文档中定义的用于收集SRLG信息的RSVP扩展使检索LSP的SRLG信息成为可能，从而解决了双归宿LSP分集问题。例如，图1中的CE1可能已通过PE1请求LSP1到CE2，该LSP1通过PE3到CE2路由。CE1随后可以通过PE2向CE2请求LSP2，其约束条件是它需要相对于LSP1最大SRLG不相交。然而，PE2没有任何与LSP1相关联的SRLG信息，需要将其作为基于约束的路径计算功能的输入。如果CE1能够从PE1检索与LSP1相关联的SRLG信息，它可以将发现的信息作为排除路由对象（XRO）或显式排除路由子对象（EXRS）中LSP2设置请求（RSVP路径消息）的一部分传递给PE2，如[RFC4874]中所述，PE2现在可以计算相对于LSP1 SRLG不相交的LSP2路径。可以在建立LSP1时或在建立LSP2之前的任何时候检索与LSP1相关联的SRLG信息。
When CE1 sends the setup request for LSP2 to PE2, it can also request the collection of SRLG information for LSP2 and send that information to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's
当CE1向PE2发送LSP2的设置请求时，它还可以请求收集LSP2的SRLG信息，并通过基于LSP2的SRLG排除重新向LSP1发送信号将该信息发送给PE1
discovered SRLGs. This will ensure that the two paths for the two LSPs remain mutually diverse; this is important when the provider network is capable of restoring connections that failed due to a network failure (fiber cut) in the provider network.
发现了SRLGs。这将确保两个LSP的两条路径保持相互不同；当提供商网络能够恢复由于提供商网络中的网络故障（光纤切断）而失败的连接时，这一点非常重要。
Note that the knowledge of SRLG information even for multiple LSPs does not allow a CE device to derive the provider network topology based on the collected SRLG information. It would, however, be possible for an entity controlling multiple CE devices to derive some information related to the topology. This document therefore allows PE devices to control the communication of SRLGs outside the provider network if desired.
注意，即使对于多个lsp，SRLG信息的知识也不允许CE设备基于收集的SRLG信息导出提供商网络拓扑。然而，控制多个CE设备的实体可能会导出与拓扑相关的一些信息。因此，如果需要，本文件允许PE设备在提供商网络之外控制SRLGs的通信。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The SRLG collection process takes place in three stages:
SRLG收集过程分为三个阶段：
o The LSP's ingress node requests that SRLG collection take place;
o LSP的入口节点请求进行SRLG收集；
o SRLG data is added to the Path and Resv ROUTE_RECORD Objects (RROs) by all nodes during signaling;
o 在信令期间，所有节点将SRLG数据添加到路径和Resv ROUTE_记录对象（RRO）；
o Changes to previously signaled SRLG data are made by sending updated Path and Resv messages as required.
o 根据需要，通过发送更新的Path和Resv消息来更改先前发出信号的SRLG数据。
The ingress node of the LSP needs be capable of indicating whether the SRLG information of the LSP is to be collected during the signaling procedure of setting up an LSP. There is no need for SRLG information to be collected without an explicit request by the ingress node.
LSP的入口节点需要能够指示在建立LSP的信令过程期间是否要收集LSP的SRLG信息。没有入口节点的明确请求，不需要收集SRLG信息。
It may be preferable for the SRLG collection request to be understood by all nodes along the LSP's path, or it may be more important for the LSP to be established successfully even if it traverses nodes that cannot supply SRLG information or have not implemented the procedures specified in this document. It is desirable for the ingress node to make the SRLG collection request in a manner that best suits its own policy.
沿LSP路径的所有节点都能理解SRLG收集请求可能更为可取，或者LSP成功建立可能更为重要，即使它穿越了无法提供SRLG信息或未实施本文档中规定的过程的节点。入口节点希望以最适合其自身策略的方式发出SRLG收集请求。
If requested, the SRLG information is collected during the setup of an LSP. SRLG information is added by each hop to the Path RRO during Path message processing. The same information is also added to the Resv RRO during Resv processing at each hop.
如果需要，将在设置LSP期间收集SRLG信息。在路径消息处理过程中，每个跃点都会将SRLG信息添加到路径RRO中。在每个跃点的Resv处理过程中，也会将相同的信息添加到Resv RRO中。
When the SRLG information of an existing LSP for which SRLG information was collected during signaling changes, the relevant nodes of the LSP need to be capable of updating the SRLG information of the LSP. This means that the signaling procedure needs to be capable of updating the new SRLG information.
当在信令期间为其收集SRLG信息的现有LSP的SRLG信息改变时，LSP的相关节点需要能够更新LSP的SRLG信息。这意味着信令过程需要能够更新新的SRLG信息。
The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity in [RFC4202]. This definition is used in this document.
SRLG的标识符（SRLG ID）在[RFC4202]中定义为32位量。本文件中使用了此定义。
In order to indicate to nodes that SRLG collection is desired, this document defines a new flag in the Attribute Flags TLV (see [RFC5420]). This document defines a new SRLG Collection Flag in the Attribute Flags TLV. A node that wishes to indicate that SRLG collection is desired MUST set this flag in an Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES object (if collection is to be mandatory) or an LSP_ATTRIBUTES object (if collection is desired but not mandatory).
为了向节点指示需要SRLG集合，本文档在属性标志TLV中定义了一个新标志（请参见[RFC5420]）。本文档在属性标志TLV中定义了一个新的SRLG集合标志。希望指示需要SRLG集合的节点必须在LSP_REQUIRED_ATTRIBUTES对象（如果集合是必需的）或LSP_ATTRIBUTES对象（如果集合是必需的但不是必需的）的属性标志TLV中设置此标志。
o Bit Number (specified in Section 8.1): SRLG Collection Flag
o 位号（第8.1节中规定）：SRLG收集标志
The SRLG Collection Flag is meaningful on a Path message. If the SRLG Collection Flag is set to 1, it means that the SRLG information SHOULD be reported to the ingress and egress node along the setup of the LSP.
SRLG集合标志在路径消息上有意义。如果SRLG收集标志设置为1，则意味着应在LSP设置过程中将SRLG信息报告给入口和出口节点。
The rules for the processing of the Attribute Flags TLV are not changed.
处理属性标志TLV的规则未更改。
This document defines a new RRO subobject (ROUTE_RECORD subobject) to record the SRLG information of the LSP. Its format is modeled on the RRO subobjects defined in [RFC3209].
本文档定义了一个新的RRO子对象（ROUTE_RECORD子对象），用于记录LSP的SRLG信息。其格式以[RFC3209]中定义的RRO子对象为模型。
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 |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID 1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ...... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG ID n (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type (8 bits)
类型（8位）
The type of the subobject. The value is specified in Section 8.2.
子对象的类型。该值在第8.2节中规定。
Length (8 bits)
长度（8位）
The Length field contains the total length of the subobject in octets, including the Type and Length fields. The Length depends on the number of SRLG IDs.
长度字段包含子对象的总长度（以八位字节为单位），包括类型字段和长度字段。长度取决于SRLG ID的数量。
Direction bit (D-bit) (1 bit)
Direction bit (D-bit) (1 bit)translate error, please retry
If not set, the SRLGs contained in this subobject apply to the downstream direction. If set, they apply to the upstream direction.
如果未设置，则此子对象中包含的SRLGs将应用于下游方向。如果设置，它们将应用于上游方向。
Reserved (15 bits)
保留（15位）
This 15-bit field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.
此15位字段为保留字段。传输时应将其设置为零，接收时必须忽略。
SRLG ID (4 octets)
SRLG ID（4个八位字节）
This field contains one SRLG ID. There is one SRLG ID field per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG subobject.
此字段包含一个SRLG ID。收集的每个SRLG都有一个SRLG ID字段。SRLG子对象中可能有多个SRLG ID字段。
A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without also pushing either an IPv4 subobject, an IPv6 subobject, an Unnumbered Interface ID subobject, or a Path Key Subobject (PKS).
在未同时推送IPv4子对象、IPv6子对象、未编号的接口ID子对象或路径键子对象（PKS）的情况下，节点不得推送ROUTE_记录中的SRLG子对象。
As described in [RFC3209], the ROUTE_RECORD object is managed as a stack. The SRLG subobject MUST be pushed by the node before the node IP address or link identifier. The SRLG subobject SHOULD be pushed after the Attribute subobject, if present, and after the LABEL subobject, if requested. It MUST be pushed within the hop to which it applies.
如[RFC3209]所述，ROUTE_记录对象作为堆栈进行管理。节点必须在节点IP地址或链接标识符之前推送SRLG子对象。SRLG子对象应推送到属性子对象（如果存在）之后，以及标签子对象（如果请求）之后。它必须在其应用的跃点内推送。
[RFC5553] describes mechanisms to carry a PKS in the RRO so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. RFC 5553 allows the path segment that needs to be hidden (that is, a Confidential Path Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS contains SRLG subobjects, these MAY be retained in the RRO by adding them again after the PKS in the RRO. The CPS is defined in [RFC5520].
[RFC5553]描述了在RRO中携带PKS的机制，以促进域间TE LSP信令的机密性。RFC 5553允许在RRO中用PKS替换需要隐藏的路径段（即机密路径段（CPS））。如果CP包含SRLG子对象，则可以通过在RRO中的PKS之后再次添加这些子对象来将其保留在RRO中。CPS在[RFC5520]中定义。
The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTES, and ROUTE_RECORD objects are not changed.
LSP_REQUIRED_属性、LSP_属性和ROUTE_记录对象的处理规则不变。
The ingress node of the LSP MUST be capable of indicating whether the SRLG information of the LSP is to be collected during the signaling procedure of setting up an LSP.
LSP的入口节点必须能够指示在设置LSP的信令过程期间是否要收集LSP的SRLG信息。
Per [RFC3209], an ingress node initiates the recording of the route information of an LSP by adding an RRO to a Path message. If an ingress node also desires SRLG recording, it MUST set the SRLG Collection Flag in the Attribute Flags TLV, which MAY be carried in either an LSP_REQUIRED_ATTRIBUTES object (when the collection is mandatory) or an LSP_ATTRIBUTES object (when the collection is desired, but not mandatory).
根据[RFC3209]，入口节点通过向路径消息添加RRO来启动LSP路由信息的记录。如果入口节点也需要SRLG记录，则它必须在属性标志TLV中设置SRLG收集标志，该标志可以包含在LSP_REQUIRED_ATTRIBUTES对象（当收集是必需的）或LSP_ATTRIBUTES对象（当收集是必需的，但不是必需的）中。
A node MUST NOT add SRLG information without an explicit request by the ingress node in the Path message.
没有入口节点在路径消息中的明确请求，节点不得添加SRLG信息。
When a node receives a Path message that carries an LSP_REQUIRED_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, it MUST return a PathErr message with
当节点接收到带有设置了SRLG集合标志的LSP_REQUIRED_ATTRIBUTES对象的路径消息时，如果本地策略确定不向端点提供SRLG信息，则它必须返回带有
o Error Code 2 (policy) and
o 错误代码2（策略）和
o Error subcode "SRLG Recording Rejected" (see Section 8.3 for value)
o 错误子代码“SRLG记录被拒绝”（数值见第8.3节）
to reject the Path message.
拒绝路径消息。
When a node receives a Path message that carries an LSP_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, the Path message MUST NOT be rejected due to the SRLG recording restriction, and the Path message MUST be forwarded without any SRLG subobject(s) added to the RRO of the corresponding outgoing Path message.
当节点接收到带有设置了SRLG收集标志的LSP_ATTRIBUTES对象的路径消息时，如果本地策略确定不向端点提供SRLG信息，则不得由于SRLG记录限制而拒绝该路径消息，并且必须在没有任何SRLG子对象的情况下转发该路径消息添加到相应传出路径消息的RRO。
If local policy permits the recording of the SRLG information, the processing node SHOULD add local SRLG information, as defined below, to the RRO of the corresponding outgoing Path message. The processing node MAY add multiple SRLG subobjects to the RRO if necessary. It then forwards the Path message to the next node in the downstream direction. The processing node MUST retain a record of the SRLG recording request for reference during Resv processing described below.
如果本地策略允许记录SRLG信息，则处理节点应将本地SRLG信息（如下所述）添加到相应传出路径消息的RRO中。如有必要，处理节点可向RRO添加多个SRLG子对象。然后，它将路径消息转发到下游方向的下一个节点。处理节点必须保留SRLG记录请求的记录，以供下文所述的Resv处理期间参考。
If the addition of SRLG information to the RRO would result in the RRO exceeding its maximum possible size or becoming too large for the Path message to contain it, the requested SRLGs MUST NOT be added. If the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES object, the processing node MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. If the SRLG collection request was contained in an LSP_ATTRIBUTES object, the processing node MAY omit some or all of the requested SRLGs from the RRO; otherwise, it MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. Subsequent processing of the LSP proceeds as further specified in [RFC3209].
如果向RRO中添加SRLG信息会导致RRO超过其最大可能大小或变得太大，以致路径消息无法包含它，则不得添加请求的SRLG。如果SRLG收集请求包含在LSP_REQUIRED_ATTRIBUTES对象中，则处理节点的行为必须符合[RFC3209]的规定，并从路径消息中完全删除RRO。如果SRLG收集请求包含在LSP_ATTRIBUTES对象中，则处理节点可以从RRO中省略部分或全部请求的SRLG；否则，它必须按照[RFC3209]的规定运行，并从Path消息中完全删除RRO。LSP的后续处理按照[RFC3209]中的进一步规定进行。
Following the steps described above, the intermediate nodes of the LSP can collect the SRLG information in the RRO during the processing of the Path message hop by hop. When the Path message arrives at the egress node, the egress node receives SRLG information in the RRO.
按照上述步骤，LSP的中间节点可以在逐跳处理路径消息期间收集RRO中的SRLG信息。当路径消息到达出口节点时，出口节点接收RRO中的SRLG信息。
Per [RFC3209], when issuing a Resv message for a Path message that contains an RRO, an egress node initiates the RRO process by adding an RRO to the outgoing Resv message. The processing for RROs contained in Resv messages then mirrors that of the Path messages.
根据[RFC3209]，当为包含RRO的Path消息发出Resv消息时，出口节点通过向传出的Resv消息添加RRO来启动RRO进程。然后，对Resv消息中包含的RRO的处理将镜像Path消息的处理。
When a node receives a Resv message for an LSP for which SRLG Collection was specified in the corresponding Path message, then when local policy allows recording SRLG information, the node MUST add SRLG information to the RRO of the corresponding outgoing Resv message as specified below. When the Resv message arrives at the ingress node, the ingress node can extract the SRLG information from the RRO in the same way as the egress node.
当节点接收到LSP的Resv消息（对应路径消息中为其指定了SRLG集合）时，当本地策略允许记录SRLG信息时，节点必须将SRLG信息添加到对应传出Resv消息的RRO中，如下所述。当Resv消息到达入口节点时，入口节点可以与出口节点相同的方式从RRO提取SRLG信息。
Note that a link's SRLG information for the upstream direction cannot be assumed to be the same as that for the downstream direction.
请注意，不能假设上游方向链路的SRLG信息与下游方向链路的SRLG信息相同。
o For Path and Resv messages for a unidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for the downstream data link only.
o 对于单向LSP的Path和Resv消息，节点应仅在下游数据链路的RRO中包含SRLG子对象。
o For Path and Resv messages for a bidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for both the upstream data link and the downstream data link from the local node. In this case, the node MUST include the information in the same order for both Path messages and Resv messages. That is, the SRLG subobject for the upstream link is added to the RRO before the SRLG subobject for the downstream link.
o 对于双向LSP的Path和Resv消息，节点应在来自本地节点的上游数据链路和下游数据链路的RRO中包括SRLG子对象。在这种情况下，对于Path消息和Resv消息，节点必须以相同的顺序包含信息。也就是说，上游链路的SRLG子对象在下游链路的SRLG子对象之前添加到RRO中。
If SRLG data is added for both the upstream and downstream links, the two sets of SRLG data MUST be added in separate SRLG subobjects. A single SRLG subobject MUST NOT contain a mixture of upstream and downstream SRLGs. When adding a SRLG subobject to an RRO, the D-bit MUST be set appropriately to indicate the direction of the SRLGs. If an SRLG ID applies in both directions, it SHOULD be added to both the upstream and downstream SRLG subobjects.
如果为上游和下游链路添加SRLG数据，则必须在单独的SRLG子对象中添加两组SRLG数据。单个SRLG子对象不得包含上游和下游SRLG的混合。将SRLG子对象添加到RRO时，必须适当设置D位以指示SRLG的方向。如果SRLG ID在两个方向上都适用，则应将其添加到上游和下游SRLG子对象。
Based on the above procedure, the endpoints can get the SRLG information automatically. Then, for instance, the endpoints can advertise it as a TE link to the routing instance based on the procedure described in [RFC6107] and configure the SRLG information of the Forwarding Adjacency (FA) automatically.
基于上述过程，端点可以自动获取SRLG信息。然后，例如，端点可以基于[RFC6107]中描述的过程将其作为到路由实例的TE链路进行公告，并自动配置转发邻接（FA）的SRLG信息。
When the SRLG information of a link is changed, the endpoints of LSPs using that link need to be made aware of the changes. When a change to the set of SRLGs associated with a link occurs, the procedures defined in Section 4.4.3 of [RFC3209] MUST be used to refresh the SRLG information for each affected LSP if the local node's policy dictates that the SRLG change be communicated to other nodes.
当链路的SRLG信息发生更改时，需要让使用该链路的LSP端点知道这些更改。当与链路相关的SRLG集合发生变更时，如果本地节点的策略规定SRLG变更应传达给其他节点，则必须使用[RFC3209]第4.4.3节中定义的程序刷新每个受影响LSP的SRLG信息。
If mandated by local policy as specified by the network operator, a node MAY remove SRLG information from any RRO in a Path or Resv message being processed. It MAY add a summary of the removed SRLGs or map them to other SRLG values. However, this SHOULD NOT be done unless explicitly mandated by local policy.
如果由网络运营商指定的本地策略强制，则节点可以从正在处理的路径或Resv消息中的任何RRO中删除SRLG信息。它可以添加已删除SRLG的摘要或将其映射到其他SRLG值。但是，除非当地政策明确规定，否则不应这样做。
A node that does not recognize the SRLG Collection Flag in the Attribute Flags TLV is expected to proceed as specified in [RFC5420]. It is expected to pass the TLV on unaltered if it appears in an LSP_ATTRIBUTES object or to reject the Path message with the appropriate Error Code and Value if it appears in a LSP_REQUIRED_ATTRIBUTES object.
不识别属性标志TLV中SRLG集合标志的节点应按照[RFC5420]中的规定进行操作。如果TLV出现在LSP_ATTRIBUTES对象中，则应将其原封不动地传递；如果路径消息出现在LSP_REQUIRED_ATTRIBUTES对象中，则应拒绝包含相应错误代码和值的路径消息。
A node that does not recognize the SRLG RRO subobject is expected to behave as specified in [RFC3209]: unrecognized subobjects are to be ignored and passed on unchanged.
无法识别SRLG RRO子对象的节点的行为应符合[RFC3209]中的规定：无法识别的子对象将被忽略并以不变的方式传递。
In a border node of an inter-domain or inter-layer network, the following SRLG processing policy MUST be capable of being configured:
在域间或层间网络的边界节点中，必须能够配置以下SRLG处理策略：
o Whether the node is allowed to participate in SRLG collection and notify changes to collected SRLG information to endpoint nodes as described in Section 5.2.
o 是否允许节点参与SRLG收集，并按照第5.2节所述将收集的SRLG信息的更改通知端点节点。
o Whether the SRLG IDs of the domain or specific layer network can be exposed to the nodes outside the domain or layer network, or whether they SHOULD be summarized, mapped to values that are comprehensible to nodes outside the domain or layer network, or removed entirely as described in Section 5.3.
o 域或特定层网络的SRLG ID是否可向域或层网络外部的节点公开，或者是否应将其汇总、映射到域或层网络外部的节点可以理解的值，或者按照第5.3节所述完全删除。
A node using [RFC5553] and PKS MAY apply the same policy.
使用[RFC5553]和PKS的节点可以应用相同的策略。
In a multi-layer, multi-domain scenario, SRLG IDs can be configured by different management entities in each layer or domain. In such scenarios, maintaining a coherent set of SRLG IDs is a key requirement in order to be able to use the SRLG information properly. Thus, SRLG IDs SHOULD be unique. Note that current procedures are targeted towards a scenario where the different layers and domains belong to the same operator or to several coordinated administrative groups. Ensuring the aforementioned coherence of SRLG IDs is beyond the scope of this document.
在多层、多域场景中，SRLG ID可以由每个层或域中的不同管理实体进行配置。在这种情况下，为了能够正确使用SRLG信息，维护一组一致的SRLG ID是一项关键要求。因此，SRLG ID应该是唯一的。请注意，当前程序针对的是不同层和域属于同一运营商或多个协调管理组的场景。确保上述SRLG ID的一致性超出了本文件的范围。
Further scenarios, where coherence in the SRLG IDs cannot be guaranteed, are out of the scope of the present document and are left for further study.
无法保证SRLG ID一致性的其他场景不在本文件范围内，有待进一步研究。
This document builds on the mechanisms defined in [RFC3473], which also discusses related security measures. In addition, [RFC5920] provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane. The procedures defined in this document permit the transfer of SRLG data between layers or domains during the signaling of LSPs, subject to policy at the layer or domain boundary. As described in Sections 5.3 and 6.1, local policy as specified by the network operator will explicitly mandate the processing of information at domain or layer boundaries.
本文件以[RFC3473]中定义的机制为基础，其中还讨论了相关的安全措施。此外，[RFC5920]概述了GMPLS控制平面的安全漏洞和保护机制。根据层或域边界的政策，本文件中定义的程序允许在LSP信令期间在层或域之间传输SRLG数据。如第5.3节和第6.1节所述，网络运营商规定的本地政策将明确要求在域或层边界处理信息。
IANA has created a registry and manages the space of the Attribute bit flags of the Attribute Flags TLV, as described in Section 11.3 of [RFC5420], in the "Attribute Flags" subregistry of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located at <http://www.iana.org/assignments/rsvp-te-parameters>.
IANA已在位于的“资源预留协议流量工程（RSVP-TE）参数”注册表的“属性标志”子区中创建了一个注册表并管理属性标志TLV的属性位标志空间，如[RFC5420]第11.3节所述<http://www.iana.org/assignments/rsvp-te-parameters>.
This document introduces a new Attribute bit flag:
本文档介绍了一个新的属性位标志：
Bit No Name Attribute Attribute RRO ERO Reference
Flags Path Flags Resv
--------- ---------- ---------- ----------- --- --- ---------
12 SRLG Yes No Yes No RFC 8001,
Collection [RFC7570]
Flag
Bit No Name Attribute Attribute RRO ERO Reference
Flags Path Flags Resv
--------- ---------- ---------- ----------- --- --- ---------
12 SRLG Yes No Yes No RFC 8001,
Collection [RFC7570]
Flag
IANA manages the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/rsvp-parameters>. This document introduces a new RRO subobject under the "Sub-object type - 21 ROUTE_RECORD - Type 1 Route Record" subregistry:
IANA管理位于的“资源预留协议（RSVP）参数”注册表<http://www.iana.org/assignments/rsvp-parameters>. 本文档在“子对象类型-21 ROUTE_RECORD-type 1 ROUTE RECORD”子区域下介绍了一个新的RRO子对象：
Value Description Reference
----- ------------------- ---------
34 SRLG subobject RFC 8001
Value Description Reference
----- ------------------- ---------
34 SRLG subobject RFC 8001
IANA manages the assignments in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at <http://www.iana.org/assignments/rsvp-parameters>.
IANA在“资源预留协议（RSVP）参数”注册表的“错误代码和全局定义的错误值子代码”部分管理分配，该注册表位于<http://www.iana.org/assignments/rsvp-parameters>.
This document introduces a new value under "Sub-Codes - 2 Policy Control Failure":
本文档在“子代码-2策略控制失败”下引入了一个新值：
Value Description Reference
----- ----------------------- ---------
21 SRLG Recording Rejected RFC 8001
Value Description Reference
----- ----------------------- ---------
21 SRLG Recording Rejected RFC 8001
[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>.
[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>.
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>.
[RFC4202]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的路由扩展”，RFC 4202，DOI 10.17487/RFC4202，2005年10月<http://www.rfc-editor.org/info/rfc4202>.
[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>.
[RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009, <http://www.rfc-editor.org/info/rfc5520>.
[RFC5520]Bradford，R.，Ed.，Vasseur，JP.，和A.Farrel，“使用基于路径密钥的机制在域间路径计算中保持拓扑机密性”，RFC 5520，DOI 10.17487/RFC5520，2009年4月<http://www.rfc-editor.org/info/rfc5520>.
[RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource Reservation Protocol (RSVP) Extensions for Path Key Support", RFC 5553, DOI 10.17487/RFC5553, May 2009, <http://www.rfc-editor.org/info/rfc5553>.
[RFC5553]Farrel，A.，Ed.，Bradford，R.，和JP。Vasseur，“路径密钥支持的资源预留协议（RSVP）扩展”，RFC 5553，DOI 10.17487/RFC5553，2009年5月<http://www.rfc-editor.org/info/rfc5553>.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, October 2005, <http://www.rfc-editor.org/info/rfc4206>.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，DOI 10.17487/RFC4206，2005年10月<http://www.rfc-editor.org/info/rfc4206>.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, DOI 10.17487/RFC4208, October 2005, <http://www.rfc-editor.org/info/rfc4208>.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，DOI 10.17487/RFC4208，2005年10月<http://www.rfc-editor.org/info/rfc4208>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[RFC4874]Lee，CY.，Farrel，A.和S.De Cnodder，“排除路由-资源预留协议流量工程（RSVP-TE）的扩展”，RFC 4874，DOI 10.17487/RFC4874，2007年4月<http://www.rfc-editor.org/info/rfc4874>.
[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>.
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, DOI 10.17487/RFC6107, February 2011, <http://www.rfc-editor.org/info/rfc6107>.
[RFC6107]Shiomoto，K.，Ed.，和A.Farrel，Ed.“动态信号分层标签交换路径的程序”，RFC 6107，DOI 10.17487/RFC6107，2011年2月<http://www.rfc-editor.org/info/rfc6107>.
[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>.
Acknowledgements
致谢
The authors would like to thank Dieter Beller, Vishnu Pavan Beeram, Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah, and Xian Zhang for their useful comments and improvements to this document.
作者要感谢迪特尔·贝勒、毗瑟奴·帕凡·比拉姆、卢·伯杰、黛博拉·布伦加德、伊戈尔·布莱斯金、拉蒙·卡塞拉斯、尼古拉斯·康斯特德、艾伦·戴维、艾尔温·戴维斯、杜鲁夫·杜迪、希曼苏·沙阿和冼张对本文件的有益评论和改进。
Contributors
贡献者
Dan Li Huawei F3-5-B RD Center Bantian, Longgang District, Shenzhen 518129 China
中国深圳市龙岗区坂田区丹丽华为F3-5-B路中心邮编：518129
Email: danli@huawei.com
Email: danli@huawei.com
Authors' Addresses
作者地址
Fatai Zhang (editor) Huawei F3-5-B RD Center Bantian, Longgang District, Shenzhen 518129 China
张法泰（编辑）中国深圳市龙岗区坂田华为F3-5-B路中心518129
Email: zhangfatai@huawei.com
Email: zhangfatai@huawei.com
Oscar Gonzalez de Dios (editor) Telefonica Global CTO Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045 Madrid 28050 Spain Phone: +34 913129647
Oscar Gonzalez de Dios（编辑）Telefonica全球首席技术官Distrito Telefonica，Ronda de la Comunicion sur大厦28045马德里28050西班牙电话：+34 913129647
Email: oscar.gonzalezdedios@telefonica.com
Email: oscar.gonzalezdedios@telefonica.com
Cyril Margaria Juniper 200 Somerset Corporate Blvd., Suite 4001 Bridgewater, NJ 08807 United States of America
Cyril Margaria Juniper美国新泽西州布里奇沃特市萨默塞特公司大道200号4001室，邮编：08807
Email: cmargaria@juniper.net
Email: cmargaria@juniper.net
Matt Hartley Cisco
马特·哈特利·思科
Email: mhartley@cisco.com
Email: mhartley@cisco.com
Zafar Ali Cisco
扎法尔·阿里·思科
Email: zali@cisco.com
Email: zali@cisco.com