Network Working Group A. Farrel, Ed.
Request for Comments: 5420 Old Dog Consulting
Obsoletes: 4420 D. Papadimitriou
Updates: 3209, 3473 Alcatel
Category: Standards Track JP. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2009
Network Working Group A. Farrel, Ed.
Request for Comments: 5420 Old Dog Consulting
Obsoletes: 4420 D. Papadimitriou
Updates: 3209, 3473 Alcatel
Category: Standards Track JP. Vasseur
Cisco Systems, Inc.
A. Ayyangar
Juniper Networks
February 2009
Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
使用资源预留协议流量工程（RSVP-TE）对MPLS LSP建立的属性进行编码
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) may be established using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions. This protocol includes an object (the SESSION_ATTRIBUTE object) that carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, allowing for eight options to be set. Recent proposals in many documents that extend RSVP-TE have suggested uses for each of the previously unused bits.
可以使用资源预留协议流量工程（RSVP-TE）扩展建立多协议标签交换（MPLS）标签交换路径（LSP）。此协议包括一个对象（会话_属性对象），该对象带有一个标志字段，用于指示LSP的选项和属性。该标志字段有八位，允许设置八个选项。在许多扩展RSVP-TE的文件中，最近的提案建议使用每个以前未使用的位。
This document defines a new object for RSVP-TE messages that allows the signaling of further attribute bits and also the carriage of arbitrary attribute parameters to make RSVP-TE easily extensible to support new requirements. Additionally, this document defines a way to record the attributes applied to the LSP on a hop-by-hop basis.
本文档为RSVP-TE消息定义了一个新的对象，该对象允许发送更多属性位的信号，也允许携带任意属性参数，以使RSVP-TE易于扩展以支持新的需求。此外，本文档定义了一种在逐跳基础上记录应用于LSP的属性的方法。
The object mechanisms defined in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs.
本文档中定义的目标机制同样适用于通用MPLS（GMPLS）支持分组交换（PSC）的LSP和GMPLS非PSC LSP。
This document replaces and obsoletes the previous version of this work, published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures.
本文件取代并废弃了本工作的前一版本，即RFC 4420。唯一的变化是类型长度变量（TLV）数据结构的编码。
Table of Contents
目录
1. Introduction and Problem Statement ..............................4
1.1. Applicability to Generalized MPLS ..........................5
1.2. A Rejected Alternate Solution ..............................5
2. Terminology .....................................................6
3. Attributes TLVs .................................................6
3.1. Attribute Flags TLV ........................................7
4. LSP_ATTRIBUTES Object ...........................................8
4.1. Format .....................................................9
4.2. Generic Processing Rules for Path Messages .................9
4.3. Generic Processing Rules for Resv Messages .................9
5. LSP_REQUIRED_ATTRIBUTES Object .................................10
5.1. Format ....................................................11
5.2. Generic Processing Rules ..................................11
6. Inheritance Rules ..............................................11
7. Recording Attributes Per LSP ...................................12
7.1. Requirements ..............................................12
7.2. RRO Attributes Subobject ..................................12
7.3. Procedures ................................................13
7.3.1. Subobject Presence Rules ...........................13
7.3.2. Reporting Compliance with LSP Attributes ...........14
7.3.3. Reporting Per-Hop Attributes .......................14
7.3.4. Default Behavior ...................................14
8. Summary of Attribute Bit Allocation ............................14
9. Message Formats ................................................15
10. Guidance for Key Application Scenarios ........................16
10.1. Communicating to Egress LSRs .............................16
10.2. Communicating to Key Transit LSRs ........................17
10.3. Communicating to All LSRs ................................17
11. IANA Considerations ...........................................17
11.1. New RSVP C-Nums and C-Types ..............................17
11.2. New TLV Space ............................................18
11.3. Attribute Flags ..........................................19
11.4. New Error Codes ..........................................19
11.5. New Record Route Subobject Identifier ....................19
12. Security Considerations .......................................20
13. Acknowledgements ..............................................20
14. Changes from RFC 4420 to RFC 5420 .............................20
15. Normative References ..........................................21
16. Informative References ........................................21
1. Introduction and Problem Statement ..............................4
1.1. Applicability to Generalized MPLS ..........................5
1.2. A Rejected Alternate Solution ..............................5
2. Terminology .....................................................6
3. Attributes TLVs .................................................6
3.1. Attribute Flags TLV ........................................7
4. LSP_ATTRIBUTES Object ...........................................8
4.1. Format .....................................................9
4.2. Generic Processing Rules for Path Messages .................9
4.3. Generic Processing Rules for Resv Messages .................9
5. LSP_REQUIRED_ATTRIBUTES Object .................................10
5.1. Format ....................................................11
5.2. Generic Processing Rules ..................................11
6. Inheritance Rules ..............................................11
7. Recording Attributes Per LSP ...................................12
7.1. Requirements ..............................................12
7.2. RRO Attributes Subobject ..................................12
7.3. Procedures ................................................13
7.3.1. Subobject Presence Rules ...........................13
7.3.2. Reporting Compliance with LSP Attributes ...........14
7.3.3. Reporting Per-Hop Attributes .......................14
7.3.4. Default Behavior ...................................14
8. Summary of Attribute Bit Allocation ............................14
9. Message Formats ................................................15
10. Guidance for Key Application Scenarios ........................16
10.1. Communicating to Egress LSRs .............................16
10.2. Communicating to Key Transit LSRs ........................17
10.3. Communicating to All LSRs ................................17
11. IANA Considerations ...........................................17
11.1. New RSVP C-Nums and C-Types ..............................17
11.2. New TLV Space ............................................18
11.3. Attribute Flags ..........................................19
11.4. New Error Codes ..........................................19
11.5. New Record Route Subobject Identifier ....................19
12. Security Considerations .......................................20
13. Acknowledgements ..............................................20
14. Changes from RFC 4420 to RFC 5420 .............................20
15. Normative References ..........................................21
16. Informative References ........................................21
This document replaces and obsoletes the previous version of this work, published as RFC 4420 [RFC4420]. The only change is in the encoding of the Type-Length-Variable (TLV) data structures presented in Section 3. See Section 14 for a summary of changes.
本文件取代并废弃了本工作的前一版本，即RFC 4420[RFC4420]。唯一的变化是第3节中介绍的类型长度变量（TLV）数据结构的编码。有关变更的摘要，请参见第14节。
Traffic-Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) [RFC3031] may be set up using the Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message includes the SESSION_ATTRIBUTE object, which carries a Flags field used to indicate desired options and attributes of the LSP.
流量工程多协议标签交换（MPLS）标签交换路径（LSP）[RFC3031]可以使用RSVP-TE信令协议[RFC3209]的路径消息建立。Path消息包括SESSION_ATTRIBUTE对象，它携带一个Flags字段，用于指示所需的选项和LSP属性。
The Flags field in the SESSION_ATTRIBUTE object has eight bits. Just three of those bits are assigned in [RFC3209]. A further two bits are assigned in [RFC4090] for fast re-reroute functionality, leaving only three bits available. Several recent proposals and Internet Drafts have demonstrated that there is a high demand for the use of the other three bits. Some, if not all, of those proposals are likely to go forward as RFCs, resulting in depletion or near depletion of the Flags field and a consequent difficulty in signaling new options and attributes that may be developed in the future.
会话_属性对象中的标志字段有八位。[RFC3209]中只分配了其中的三个位。[RFC4090]中还分配了另外两位，用于快速重路由功能，只剩下三位可用。最近的几项提案和互联网草案表明，使用其他三个比特的需求量很大。这些提案中的一些（如果不是全部的话）可能会作为RFC进行，从而导致Flags油田枯竭或接近枯竭，并因此难以发出未来可能开发的新选项和属性的信号。
This document defines a new object for RSVP-TE messages that allows the signaling of further attributes bits. The new object is constructed from TLVs, and a new TLV is defined to carry a variable number of attributes bits.
本文档为RSVP-TE消息定义了一个新对象，该对象允许发送更多属性位的信号。新对象由TLV构造，新TLV定义为携带可变数量的属性位。
The new RSVP-TE message object is quite flexible, due to the use of the TLV format and allows:
由于使用TLV格式，新的RSVP-TE消息对象非常灵活，并允许：
- future specification of bit flags - additional options and attribute parameters carried in TLV format
- 位标志的未来规范-TLV格式中携带的附加选项和属性参数
Note that the LSP Attributes defined in this document are specifically scoped to an LSP. They may be set differently on separate LSPs with the same Tunnel ID between the same source and destination (that is, within the same session).
请注意，本文档中定义的LSP属性专门适用于LSP。它们可以在同一源和目标（即，在同一会话中）之间具有相同隧道ID的单独LSP上进行不同的设置。
It is noted that some options and attributes do not need to be acted on by all Label Switched Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Special transit LSRs, such as Area or Autonomous System Border Routers (ABRs or ASBRs), may also fall into this category. This means that the new options and attributes should be signaled transparently, and only examined at those points that need to act on them.
注意，一些选项和属性不需要由沿着LSP路径的所有标签交换路由器（lsr）操作。具体地，这些选项和属性可以仅应用于路径上的密钥LSR，例如入口LSR和出口LSR。特殊运输LSR，如区域或自治系统边界路由器（ABR或ASBR），也可能属于这一类。这意味着新的选项和属性应该以透明的方式发出信号，并且只在需要对它们采取行动的地方进行检查。
On the other hand, other options and attributes may require action at all transit LSRs along the path of the LSP. Inability to support the required attributes by one of those transit LSRs may require the LSR to refuse the establishment of the LSP.
另一方面，其他选项和属性可能需要在沿LSP路径的所有过境LSR处采取行动。无法通过其中一个公交LSR支持所需属性可能要求LSR拒绝建立LSP。
These considerations are particularly important in the context of backward compatibility. In general, it should be possible to provide new MPLS services across a legacy network without upgrading those LSRs that do not need to participate actively in the new services. Moreover, some features just require action on specific intermediate hops, not on every visited LSR.
在向后兼容性的环境中，这些注意事项尤其重要。一般来说，应该能够跨遗留网络提供新的MPLS服务，而无需升级那些不需要积极参与新服务的lsr。此外，有些功能只需要对特定的中间跳进行操作，而不是对每个访问的LSR进行操作。
Note that options already specified for the SESSION_ATTRIBUTE object in preexisting RFCs are not migrated to the new mechanisms described in this document.
请注意，先前存在的RFC中已为会话_属性对象指定的选项不会迁移到本文档中描述的新机制。
RSVP includes a way for unrecognized objects to be transparently forwarded by transit nodes without them refusing the incoming protocol messages and without the objects being stripped from the outgoing protocol message (see [RFC2205], Section 3.10). This capability extends to RSVP-TE and provides a good way to ensure that only those LSRs that understand a particular object examine it.
RSVP包括一种方法，用于传输节点透明地转发未识别的对象，而不会拒绝传入协议消息，也不会从传出协议消息中剥离对象（参见[RFC2205]，第3.10节）。此功能扩展到RSVP-TE，并提供了一种很好的方法来确保只有那些理解特定对象的LSR才能检查它。
This document distinguishes between options and attributes that are only required at key LSRs along the path of the LSP, and those that must be acted on by every LSR along the LSP. Two LSP Attributes objects are defined in this document; using the C-Num definition rules inherited from [RFC2205], the first is passed transparently by LSRs that do not recognize it, and the second causes LSP setup failure with the generation of a PathErr message with an appropriate Error Code if an LSR does not recognize it.
本文档区分了仅在LSP路径上的关键LSR处需要的选项和属性，以及LSP上的每个LSR必须执行的选项和属性。本文档中定义了两个LSP属性对象；使用从[RFC2205]继承的C-Num定义规则，第一个规则由不识别它的LSR透明地传递，第二个规则导致LSP设置失败，如果LSR不识别，则生成带有适当错误代码的PathErr消息。
The RSVP-TE signaling protocol also forms the basis of a signaling protocol for Generalized MPLS (GMPLS) as described in [RFC3471] and [RFC3473]. The extensions described in this document are equally applicable to MPLS and GMPLS.
RSVP-TE信令协议还构成[RFC3471]和[RFC3473]中所述的通用MPLS（GMPLS）信令协议的基础。本文件中描述的扩展同样适用于MPLS和GMPLS。
A rejected alternate solution was to define a new C-Type for the existing SESSION_ATTRIBUTE object. This new C-Type could allow a larger Flags field and address the immediate problem.
被拒绝的替代解决方案是为现有会话_属性对象定义新的C类型。这种新的C类型可以允许更大的标志字段，并解决眼前的问题。
This solution was rejected because:
此解决方案被拒绝，因为：
- A new C-Type is not backward compatible with deployed implementations that expect to see a C-Type of 1 or 7. It is important that any solution be capable of carrying new attributes transparently across legacy LSRs if those LSRs are not required to act on the attributes.
- 新的C-Type与预期C-Type为1或7的已部署实现不向后兼容。重要的是，如果不要求传统LSR对属性进行操作，则任何解决方案都能够跨这些LSR透明地承载新属性。
- Support for arbitrary attributes parameters through TLVs would have meant a significant change of substance to the existing object.
- 通过TLV支持任意属性参数将意味着现有对象的实质发生重大变化。
This document uses terminology from the MPLS architecture document [RFC3031] and from the RSVP-TE protocol specification [RFC3209], which inherits from the RSVP specification [RFC2205]. It also makes use of the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and [RFC3473].
本文件使用MPLS体系结构文件[RFC3031]和RSVP-TE协议规范[RFC3209]中的术语，RSVP-TE协议规范继承自RSVP规范[RFC2205]。它还利用了[RFC3471]和[RFC3473]中介绍的通用MPLS RSVP-TE术语。
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]中所述进行解释。
Attributes carried by the new objects defined in this document are encoded within TLVs. One or more TLVs may be present in each object. There are no ordering rules for TLVs, and no interpretation should be placed on the order in which TLVs are received.
本文档中定义的新对象携带的属性在TLV中进行编码。每个对象中可能存在一个或多个TLV。没有TLV的订购规则，也不应对TLV的接收顺序进行解释。
Each TLV is encoded as follows.
每个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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
The identifier of the TLV.
TLV的标识符。
Length
长
Indicates the total length of the TLV in octets. That is, the combined length of the Type, Length, and Value fields, i.e., four plus the length of the Value field in octets.
表示TLV的总长度（以八位字节为单位）。也就是说，类型、长度和值字段的组合长度，即四加上值字段的长度（以八位字节为单位）。
The entire TLV MUST be padded with between zero and three trailing zeros to make it four-octet aligned. The Length field does not count any padding.
整个TLV必须填充0到3个尾随零之间，以使其与4个八位组对齐。长度字段不计算任何填充。
Value
价值
The data carried in the TLV.
TLV中携带的数据。
This document defines only one TLV type value. Type 1 indicates the Attribute Flags TLV. Other TLV types may be defined in the future with type values assigned by IANA (see Section 11.2).
本文档仅定义一个TLV类型值。类型1表示属性标志TLV。其他TLV类型可能在将来使用IANA指定的类型值进行定义（见第11.2节）。
The Attribute Flags TLV may be present in an LSP_ATTRIBUTES object and/or an LSP_REQUIRED_ATTRIBUTES object, defined in Sections 4 and 5. The bits in the TLV represent the same attributes regardless of which object carries the TLV. Documents that define individual bits MUST specify whether the bit may be set in one object, the other, or both. It is not expected that a bit will be set in both objects on a single Path message at the same time, but this is not ruled out by this document.
属性标志TLV可能存在于第4节和第5节中定义的LSP_属性对象和/或LSP_REQUIRED_属性对象中。TLV中的位表示相同的属性，而不管哪个对象携带TLV。定义单个位的文档必须指定是在一个对象中设置位，还是在另一个对象中设置位，或者同时在两个对象中设置位。预计不会同时在单路径消息的两个对象中设置位，但本文档不排除这一点。
The Attribute Flags TLV Value field is an array of units of 32 flags numbered from the most significant bit as bit zero. The Length field for this TLV is therefore always a multiple of four bytes, regardless of the number of bits carried, and no padding is required.
属性标志TLV值字段是一个由32个标志组成的单元数组，从最高有效位开始编号为零位。因此，该TLV的长度字段始终是四个字节的倍数，与所携带的位数无关，并且不需要填充。
Unassigned bits are considered as reserved and MUST be set to zero on transmission by the originator of the object. Bits not contained in the TLV MUST be assumed to be set to zero. If the TLV is absent either because it is not contained in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object, or because those objects are themselves absent, all processing MUST be performed as though the bits were present and set to zero. That is to say, assigned bits that are not present either because the TLV is deliberately foreshortened or because the TLV is not included MUST be treated as though they are present and are set to zero.
未分配的位被视为保留位，并且在对象的发起人传输时必须设置为零。必须假定TLV中未包含的位设置为零。如果由于TLV不包含在LSP_属性或LSP_REQUIRED_属性对象中，或者由于这些对象本身不存在，因此TLV不存在，则必须执行所有处理，就像位存在并设置为零一样。也就是说，由于TLV被故意缩短或由于TLV未被包括而不存在的分配比特必须被视为它们存在并且被设置为零。
No bits are defined in this document. The assignment of bits is managed by IANA (see Section 11.3).
本文档中未定义位。位的分配由IANA管理（见第11.3节）。
The LSP_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information is not required to be acted on by all transit LSRs. Specifically, if an LSR does not support the object, it forwards it unexamined and unchanged. This facilitates the exchange of attributes across legacy networks that do not support this new object.
LSP_ATTRIBUTES对象用于表示支持LSP所需的属性，或指示LSP的性质或使用，其中不要求所有公交LSR对该信息采取行动。具体来说，如果LSR不支持该对象，它将未经检查且未更改地转发该对象。这有助于在不支持此新对象的传统网络之间交换属性。
This object effectively extends the Flags field in the SESSION_ATTRIBUTE object and allows for the future inclusion of more complex objects through TLVs.
该对象有效地扩展了SESSION_属性对象中的Flags字段，并允许将来通过TLV包含更复杂的对象。
Note that some function may require an LSR to inspect both the SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object.
请注意，某些函数可能需要LSR来检查SESSION_属性对象和LSP_属性或LSP_REQUIRED_属性对象。
The LSP_ATTRIBUTES object may also be used to report LSP operational state on a Resv message even when no LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object was carried on the corresponding Path message. The object is added or updated by LSRs that support the object. LSRs that do not understand the object or have nothing to report do not add the object and forward it unchanged on Resv messages that they generate.
LSP_ATTRIBUTES对象也可用于在Resv消息上报告LSP操作状态，即使在相应的Path消息上没有携带LSP_属性或LSP_REQUIRED_ATTRIBUTES对象。该对象由支持该对象的LSR添加或更新。不理解该对象或无需报告的LSR不会添加该对象，并在生成的Resv消息上原封不动地转发该对象。
The LSP_ATTRIBUTES object class is 197 of the form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) ensures that LSRs that do not recognize the object pass it on transparently.
LSP_属性对象类是11bbbb形式的197。该C-Num值（参见[RFC2205]，第3.10节）确保不识别对象的LSR透明地传递对象。
One C-Type is defined, C-Type = 1 for LSP Attributes.
定义了一个C-Type，对于LSP属性，C-Type=1。
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP, and on Resv messages to report operational state.
此对象是可选的，可以放置在路径消息上以传递有关LSP所需属性的附加信息，也可以放置在Resv消息上以报告操作状态。
LSP_ATTRIBUTES class = 197, C-Type = 1
LSP_属性类别=197，C类型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
属性TLV按照第3节所述进行编码。
An LSR that does not support this object is required to pass it on unaltered, as indicated by the C-Num and the rules defined in [RFC2205].
不支持此对象的LSR需要原封不动地传递它，如C-Num和[RFC2205]中定义的规则所示。
An LSR that does support this object but does not recognize a TLV type code carried in this object MUST pass the TLV on unaltered in the LSP_ATTRIBUTES object that it places in the Path message that it sends downstream.
不支持此对象但不识别此对象中携带的TLV类型代码的LSR必须在LSP_ATTRIBUTES对象中未经更改地传递TLV，该对象放置在其发送到下游的路径消息中。
An LSR that does support this object and recognizes a TLV but does not support the attribute defined by the TLV MUST act as specified in the document that defines the TLV.
确实支持此对象并识别TLV但不支持TLV定义的属性的LSR必须按照定义TLV的文档中的指定操作。
An LSR that supports the Attribute Flags TLV but does not recognize a bit set in the Attribute Flags TLV MUST forward the TLV unchanged.
支持属性标志TLV但不识别属性标志TLV中设置的位的LSR必须转发TLV，而不进行更改。
An LSR that supports the Attribute Flags TLV and recognizes a bit that is set but does not support the indicated attribute MUST act as specified in the document that defines the bit.
支持属性标志TLV并识别已设置但不支持指定属性的位的LSR必须按照定义该位的文档中的指定操作。
An LSR that wishes to report operational status of an LSP may include this object in a Resv message, or update the object that is already carried in a Resv message.
希望报告LSP操作状态的LSR可以在Resv消息中包括该对象，或者更新Resv消息中已经携带的对象。
Note that this usage reports the state of the entire LSP and not the state of the LSP at an individual LSR. This latter function is achieved using the LSP Attributes subobject of the Record Route object (RRO) as described in Section 7.
请注意，此用法报告整个LSP的状态，而不是单个LSR上LSP的状态。后一个功能是使用记录路由对象（RRO）的LSP Attributes子对象实现的，如第7节所述。
The bits in the Attributes TLV may be used to report operational status for the whole LSP. For example, an egress LSR may report a particular status by setting a bit. LSRs within the network that determine that this status has not been achieved may clear the bit as they forward the Resv message.
属性TLV中的位可用于报告整个LSP的操作状态。例如，出口LSR可以通过设置位来报告特定状态。网络内确定尚未达到该状态的LSR可在转发Resv消息时清除位。
Observe that LSRs that do not support the object or do not support the function characterized by a particular bit in the Attributes TLV will not clear the bit when forwarding the Resv. Thus, care must be taken in defining the usage of this object on a Resv. The usage of an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object on a Resv must be fully defined in the document that defines the bit.
请注意，不支持对象或不支持属性TLV中特定位所描述的功能的LSR在转发Resv时不会清除该位。因此，在Resv上定义此对象的用法时必须小心。Resv上LSP_Attributes对象的属性TLV中单个位的使用必须在定义该位的文档中完全定义。
Additional TLVs may also be defined to be carried in this object on a Resv.
还可以将附加TLV定义为在Resv上的该对象中携带。
An LSR that does not support this object will pass it on unaltered because of the C-Num.
由于C-Num，不支持此对象的LSR将原封不动地传递它。
The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information MUST be inspected at each transit LSR. Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object without acting on its contents.
LSP_REQUIRED_ATTRIBUTES对象用于表示支持LSP所需的属性，或指示LSP的性质或使用，其中必须在每个运输LSR检查该信息。具体而言，每个运输LSR必须检查LSP_REQUIRED_attributes对象中的属性，并且在未对其内容进行操作的情况下不得转发该对象。
This object effectively extends the Flags field in the SESSION_ATTRIBUTE object and allows for the future inclusion of more complex objects through TLVs. It complements the LSP_ATTRIBUTES object.
该对象有效地扩展了SESSION_属性对象中的Flags字段，并允许将来通过TLV包含更复杂的对象。它补充了LSP_属性对象。
The LSP_REQUIRED_ATTRIBUTES object class is 67 of the form 0bbbbbbb. This C-Num value ensures that LSRs that do not recognize the object reject the LSP setup, effectively saying that they do not support the attributes requested. This means that this object SHOULD only be used for attributes that require support at some transit LSRs and so require examination at all transit LSRs. See Section 4 for how end-to-end and selective attributes are signaled.
LSP_REQUIRED_ATTRIBUTES对象类是67，形式为0bbb。此C-Num值确保不识别对象的LSR拒绝LSP设置，实际上表示它们不支持请求的属性。这意味着该对象只应用于某些公交LSR需要支持的属性，因此需要在所有公交LSR进行检查。有关端到端和选择性属性的信号传递方式，请参见第4节。
One C-Type is defined, C-Type = 1 for LSP Required Attributes.
定义了一个C-Type，对于LSP必需属性，C-Type=1。
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP.
此对象是可选的，可以放置在路径消息上，以传递有关LSP所需属性的附加信息。
LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1
LSP_必需_属性类=67，C类型=1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Attributes TLVs are encoded as described in Section 3.
属性TLV按照第3节所述进行编码。
An LSR that does not support this object will use a PathErr to reject the Path message based on the C-Num using the Error Code "Unknown Object Class".
不支持此对象的LSR将使用PathErr拒绝基于C-Num的路径消息，错误代码为“Unknown object Class”。
An LSR that does not recognize a TLV type code carried in this object MUST reject the Path message using a PathErr with Error Code "Unknown Attributes TLV" and Error Value set to the value of the unknown TLV type code.
无法识别此对象中携带的TLV类型代码的LSR必须使用错误代码为“Unknown Attributes TLV”且错误值设置为未知TLV类型代码值的PathErr拒绝路径消息。
An LSR that does not recognize a bit set in the Attribute Flags TLV MUST reject the Path message using a PathErr with Error Code "Unknown Attributes Bit" and Error Value set to the bit number of the unknown bit in the Attribute Flags.
无法识别属性标志TLV中设置的位的LSR必须使用错误代码为“Unknown Attributes bit”且错误值设置为属性标志中未知位的位号的PathErr拒绝路径消息。
An LSR that recognizes an attribute (however encoded) but does not support that attribute MUST act according to the behavior specified in the document that defines that specific attribute.
识别属性（无论如何编码）但不支持该属性的LSR必须根据定义该特定属性的文档中指定的行为进行操作。
Note that this object is not used on a Resv. In order to report the status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the Attributes subobject in the Record Route object (see Section 7) must be used.
请注意，此对象不用于Resv。为了报告LSP的状态，必须使用Resv上的LSP_ATTRIBUTES对象或记录路由对象中的ATTRIBUTES子对象（参见第7节）。
In certain circumstances, when reaching an LSP region boundary, a forwarding adjacency LSP (FA-LSP; see [RFC4206]) is initially set up to allow the establishment of the LSP carrying the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects. In this case, when the
在某些情况下，当到达LSP区域边界时，首先设置转发邻接LSP（FA-LSP；请参见[RFC4206]），以允许建立承载LSP_属性和/或LSP_所需属性对象的LSP。在这种情况下，当
boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY, upon local policy, inherit a subset of the Attributes TLVs, in particular when the FA-LSP belongs to the same switching capability class as the triggering LSP.
边界LSR支持LSP_属性和LSP_所需的_属性处理，FA-LSP可以根据本地策略继承属性TLV的子集，特别是当FA-LSP属于与触发LSP相同的交换能力类别时。
When these conditions are met, the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects are simply copied with the inherited Attributes TLVs in the Path message used to establish the FA-LSP. By default (and in order to simplify deployment), none of the incoming LSP Attributes TLVs are considered as inheritable. Note that when the FA-LSP establishment itself requires one or more Attributes TLVs, an 'OR' operation is performed with the inherited set of values.
当满足这些条件时，LSP_属性和/或LSP_必需_属性对象将与用于建立FA-LSP的路径消息中的继承属性TLV一起简单复制。默认情况下（为了简化部署），传入的LSP属性TLV都不被认为是可继承的。请注意，当FA-LSP建立本身需要一个或多个属性TLV时，将使用继承的值集执行“或”操作。
Documents that define individual bits for the LSP Attribute Flags TLV MUST specify whether or not these bits MAY be inherited (including the condition to be met in order for this inheritance to occur). The same applies for any other TLV that will be defined following the rules specified in Section 3.
为LSP属性标志TLV定义单个位的文档必须指定是否可以继承这些位（包括发生此继承所需满足的条件）。这同样适用于根据第3节规定的规则定义的任何其他TLV。
In some circumstances, it is useful to determine which of the requested LSP attributes have been applied at which LSRs along the path of the LSP. For example, an attribute may be requested in the LSP_ATTRIBUTES object such that LSRs that do not support the object are not required to support the attribute or provide the requested function. In this case, it may be useful to the ingress LSR to know which LSRs acted on the request and which ignored it.
在某些情况下，确定哪些请求的LSP属性已应用于LSP路径上的哪些lsr是有用的。例如，可以在LSP_ATTRIBUTES对象中请求属性，使得不支持该对象的lsr不需要支持该属性或提供所请求的功能。在这种情况下，入口LSR可能需要知道哪些LSR对请求进行了操作，哪些忽略了请求。
Additionally, there may be other qualities that need to be reported on a hop-by-hop basis. These are currently indicated in the Flags field of RRO subobjects. Since there are only eight bits available in this field, and since some are already assigned and there is also likely to be an increase in allocations in new documents, there is a need for some other method to report per-hop attributes.
此外，可能还有其他需要逐跳报告的质量。这些当前在RRO子对象的标志字段中指示。由于该字段中只有8位可用，而且一些位已经分配，而且新文档中的分配也可能增加，因此需要使用其他方法来报告每跳属性。
The RRO Attributes subobject may be carried in the RECORD_ROUTE object if it is present. The subobject uses the standard format of an RRO subobject.
如果存在RRO属性子对象，则该子对象可能会包含在记录路由对象中。子对象使用RRO子对象的标准格式。
The length is variable, as for the Attribute Flags TLV. The content is the same as the Attribute Flags TLV -- that is, it is a series of bit flags.
与属性标志TLV一样，长度是可变的。内容与属性标志TLV相同——也就是说，它是一系列位标志。
There is a one-to-one correspondence between bits in the Attribute Flags TLV and the RRO Attributes subobject. If a bit is only required in one of the two places, it is reserved in the other place. See the procedures sections, below, for more information.
属性标志TLV和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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
0x05
0x05
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. This length must be a multiple of four and must be at least eight.
长度包含子对象的总长度（字节），包括类型和长度字段。该长度必须是四的倍数，并且至少必须是八。
Attribute Flags
属性标志
The attribute flags recorded for the specific hop.
为特定跃点记录的属性标志。
As will be clear from [RFC3209], the RECORD_ROUTE object is managed as a "stack", with each LSR adding subobjects to the start of the object. The Attributes subobject is pushed onto the RECORD_ROUTE object immediately prior to pushing the node's IP address or link identifier. Thus, if label recording is being used, the Attributes subobject SHOULD be pushed onto the RECORD_ROUTE object after the Record Label subobject(s).
从[RFC3209]中可以清楚地看到，RECORD_ROUTE对象作为一个“堆栈”进行管理，每个LSR将子对象添加到对象的开头。属性子对象在推送节点的IP地址或链接标识符之前立即推送到记录路由对象上。因此，如果正在使用标签记录，则应将属性子对象推送到记录标签子对象之后的记录路由对象上。
A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE object without also pushing an IPv4, IPv6, or Unnumbered Interface ID subobject.
如果不同时推送IPv4、IPv6或未编号的接口ID子对象，则节点不得将Attributes子对象推送到RECORD_ROUTE对象上。
This means that an Attributes subobject is bound to the LSR identified by the subobject found in the RRO immediately before the Attributes subobject.
这意味着属性子对象绑定到由在属性子对象之前的RRO中找到的子对象标识的LSR。
If the new subobject causes the RRO to be too big to fit in a Path (or Resv) message, the processing MUST be as described in Section 4.4.3 of [RFC3209].
如果新的子对象导致RRO太大，无法放入Path（或Resv）消息中，则处理必须如[RFC3209]第4.4.3节所述。
If more than one Attributes subobject is found between a pair of subobjects that identify LSRs, only the first one found (that is, the nearest to the top of the stack) SHALL have any meaning within the context of this document. All such subobjects MUST be forwarded unmodified by transit LSRs.
如果在标识LSR的一对子对象之间发现多个Attributes子对象，则只有找到的第一个子对象（即最接近堆栈顶部的子对象）在本文档上下文中具有任何意义。所有此类子对象必须在未经传输LSR修改的情况下转发。
To report compliance with an attribute requested in the Attribute Flags TLV, an LSR MAY set the corresponding bit (see Section 8) in the Attributes subobject. To report non-compliance, an LSR MAY clear the corresponding bit in the Attributes subobject.
为了报告与属性标志TLV中请求的属性的符合性，LSR可以在属性子对象中设置相应的位（参见第8节）。要报告不合规性，LSR可以清除属性子对象中的相应位。
The requirement to report compliance MUST be specified in the document that defines the usage of any bit. This will reduce to a statement of whether hop-by-hop acknowledgement is required.
报告合规性的要求必须在定义任何bit使用的文件中规定。这将简化为是否需要逐跳确认的声明。
To report a per-hop attribute, an LSR sets the appropriate bit in the Attributes subobject.
要报告每跳属性，LSR将在属性子对象中设置适当的位。
The requirement to report a per-hop attribute MUST be specified in the document that defines the usage of the bit.
必须在定义位用法的文档中指定报告每跳属性的要求。
By default, all bits in an Attributes subobject SHOULD be set to zero.
默认情况下，属性子对象中的所有位都应设置为零。
If a received Attributes subobject is not long enough to include a specific numbered bit, that bit MUST be treated as though present and as if set to zero.
如果接收的属性子对象的长度不足以包含特定的编号位，则必须将该位视为存在并设置为零。
If the RRO subobject is not present for a hop in the LSP, all bits MUST be assumed to be set to zero.
如果LSP中的跳不存在RRO子对象，则必须假定所有位都设置为零。
This document defines two uses of per-LSP attribute flag bit fields. The bit numbering in the Attribute Flags TLV and the RRO Attributes subobject is identical. That is, the same attribute is indicated by the same bit in both places. This means that only a single registry of bits is maintained.
本文档定义了每LSP属性标志位字段的两种用法。属性标志TLV和RRO属性子对象中的位编号相同。也就是说，相同的属性由两个位置的相同位表示。这意味着只维护一个位注册表。
The consequence is a degree of clarity in implementation and registration.
其结果是在实施和登记方面有一定程度的明确性。
Note, however, that it is not always the case that a bit will be used in both the Attribute Flags TLV and the RRO Attributes subobject. For example, an attribute may be requested using the Attribute Flags TLV, but there is no requirement to report the handling of the attribute on a hop-by-hop basis. Conversely, there may be a requirement to report the attributes of an LSP on a hop-by-hop basis, but there is no corresponding request attribute.
但是，请注意，并非总是在属性标志TLV和RRO属性子对象中都使用位。例如，可以使用属性标志TLV请求属性，但不需要逐跳报告属性的处理情况。相反，可能需要逐跳报告LSP的属性，但没有相应的请求属性。
In these cases, a single bit number is still assigned for both the Attribute Flags TLV and the RRO Attributes subobject, even though the bit may be irrelevant in either the Attribute Flags or the RRO Attributes subobject. The document that defines the usage of the new bit MUST state in which places it is used and MUST handle a default setting of zero.
在这些情况下，仍然为属性标志TLV和RRO属性子对象分配一个位号，即使该位在属性标志或RRO属性子对象中可能不相关。定义新位用法的文档必须说明使用新位的位置，并且必须处理默认设置零。
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY be carried in a Path message. The LSP_ATTRIBUTES object MAY be carried in a Resv message.
LSP_ATTRIBUTES对象和LSP_REQUIRED_ATTRIBUTES对象可以在路径消息中携带。LSP_属性对象可以在Resv消息中携带。
The order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order.
建议使用RSVP-TE消息中对象的顺序，但实现必须能够以任何有意义的顺序接收对象。
On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed immediately after the SESSION_ATTRIBUTE object if it is present, or otherwise immediately after the LABEL_REQUEST object.
在路径消息上，建议将LSP_ATTRIBUTES对象和LSP_REQUIRED_ATTRIBUTES对象立即放置在会话_属性对象（如果存在）之后，或者立即放置在LABEL_请求对象之后。
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED to be placed first.
如果LSP_ATTRIBUTES对象和LSP_REQUIRED_ATTRIBUTES对象都存在，则建议首先放置LSP_REQUIRED_ATTRIBUTES对象。
LSRs MUST be prepared to receive these objects in any order in any position within a Path message. Subsequent instances of these objects within a Path message SHOULD be ignored and MUST be forwarded unchanged.
LSR必须准备好在路径消息中的任何位置以任何顺序接收这些对象。路径消息中这些对象的后续实例应被忽略，并且必须原封不动地转发。
On a Resv message, the LSP_ATTRIBUTES object is placed in the flow descriptor and is associated with the FILTER_SPEC object that precedes it. It is RECOMMENDED that the LSP_ATTRIBUTES object be placed immediately after the LABEL object.
在Resv消息上，LSP_ATTRIBUTES对象被放置在流描述符中，并与它前面的FILTER_SPEC对象相关联。建议将LSP_属性对象放置在标签对象之后。
LSRs MUST be prepared to receive this object in any order in any position within a Resv message, subject to the previous note. Only one instance of the LSP_ATTRIBUTES object is meaningful within the context of a FILTER_SPEC object. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged.
LSR必须准备好在Resv消息中的任何位置以任何顺序接收此对象，但需遵守前面的说明。在FILTER_SPEC对象的上下文中，只有一个LSP_ATTRIBUTES对象的实例有意义。该对象的后续实例应被忽略，并且必须原封不动地转发。
As described in the Introduction section of this document, it may be that requested LSP attributes need to be acted on by only the egress LSR of the LSP, by certain key transit points (such as ABRs and ASBRs), or by all LSRs along the LSP. This section briefly describes how each of these scenarios is met. This section is informational and does not define any new procedures.
如本文件引言部分所述，可能需要仅由LSP的出口LSR、某些关键中转点（如ABR和ASBR）或LSP沿线的所有LSR对请求的LSP属性进行操作。本节简要介绍如何满足这些场景。本节仅供参考，不定义任何新程序。
When communicating LSP attributes that must be acted on only by the LSP egress LSR, the attributes should be communicated in the LSP_ATTRIBUTES object. Because of its C-Num, this object may be ignored (passed onwards, untouched) by transit LSRs that do not understand it. This means that the Path message will not be rejected by LSRs that do not understand the object. In this way, the requested LSP attributes are guaranteed to reach the egress LSR.
当传递必须仅由LSP出口LSR作用的LSP属性时，应在LSP_attributes对象中传递这些属性。由于其C-Num，不理解该对象的transit LSR可能会忽略该对象（向前传递，未触及）。这意味着不理解对象的LSR不会拒绝Path消息。这样，保证请求的LSP属性到达出口LSR。
Attributes are set within the LSP_ATTRIBUTES object according to which LSP attributes are required. Each attribute is defined in some RFC and is accompanied by a statement of what the expected behavior is. This behavior will include whether the attribute must be acted on by any LSR that recognizes it, or specifically by the egress LSR. Thus, any attribute that must be acted on only by an egress LSR will be defined in this way -- any transit LSR seeing this attribute either will understand the semantics of the attribute and ignore it (forwarding it, unchanged) or will not understand the attribute and ignore it (forwarding it, unchanged) according to the rules of the LSP_ATTRIBUTES object.
属性在LSP_Attributes对象中设置，根据需要哪些LSP属性。每个属性都是在一些RFC中定义的，并伴随着一条关于预期行为的语句。此行为将包括该属性是否必须由识别它的任何LSR操作，或者特别是由出口LSR操作。因此，任何必须由出口LSR操作的属性都将以这种方式定义——任何看到该属性的运输LSR要么理解该属性的语义并忽略它（转发，不变），要么不理解该属性并忽略它（转发，不变）根据LSP_属性对象的规则。
The remaining issue is how the ingress LSR can know whether the egress LSR has acted correctly on the required LSP attribute. Another part of the definition of the attribute (in the defining RFC) is whether reporting is required. If reporting is required, the egress LSR is required to use the RRO Attributes subobject to report whether it has acted on the received attribute.
剩下的问题是入口LSR如何知道出口LSR是否正确地处理了所需的LSP属性。属性定义的另一部分（在定义RFC中）是是否需要报告。如果需要报告，则出口LSR需要使用RRO Attributes子对象来报告它是否对接收到的属性进行了操作。
If an egress LSR understands a received attribute as mandatory for an egress LSR but does not wish to satisfy the request, it will reject the Path message. If an egress LSR understands the attribute but believes it to be optional and does not wish to satisfy the request,
如果出口LSR将接收到的属性理解为出口LSR的必需属性，但不希望满足请求，则它将拒绝Path消息。如果出口LSR了解该属性，但认为该属性是可选的，并且不希望满足该请求，
it will report its non-compliance in the RRO Attributes subobject. If the egress LSR does not understand the received attribute, it may report non-compliance in the RRO Attributes subobject explicitly, or it may omit the RRO Attributes subobject, implying that it has not satisfied the request.
它将在“RRO属性”子对象中报告其不符合项。如果出口LSR不理解接收到的属性，它可能会在RRO Attributes子对象中显式报告不合规性，或者可能会忽略RRO Attributes子对象，这意味着它没有满足请求。
Processing for key transit LSRs (such as ABRs and ASBRs) follows exactly as for egress LSR. The only difference is that the definition of the LSP attribute in the defining RFC will state that the attribute must be acted on by these transit LSRs.
关键传输LSR（如ABR和ASBR）的处理与出口LSR的处理完全相同。唯一的区别是，定义RFC中的LSP属性定义将声明这些运输LSR必须对该属性进行操作。
In order to force all LSRs to examine the LSP attributes, the LSP_REQUIRED_ATTRIBUTES object is used. The C-Num of this object is such that any LSR that does not recognize the object must reject a received Path message containing the object.
为了强制所有LSR检查LSP属性，将使用LSP_REQUIRED_attributes对象。此对象的C-Num使得任何不识别该对象的LSR都必须拒绝包含该对象的接收路径消息。
An LSR that recognizes the LSP_REQUIRED_ATTRIBUTES object but does not recognize an attribute will reject the Path message.
识别LSP_REQUIRED_ATTRIBUTES对象但不识别属性的LSR将拒绝路径消息。
An LSR that recognizes an attribute but does not wish to support the attribute reacts according to the definition of the attribute in the defining RFC. This may allow the LSR to ignore the attribute and forward it unchanged, or may require it to fail the LSP setup. The LSR may additionally be required to report whether it supports the attribute using the RRO Attributes subobject.
识别属性但不希望支持该属性的LSR根据定义RFC中的属性定义进行反应。这可能允许LSR忽略该属性并将其不变地转发，或者可能需要它使LSP设置失败。此外，还可能需要LSR使用“RRO属性”子对象报告其是否支持该属性。
The IANA allocations made for RFC 4420 [RFC4420] now apply to this document and are listed here for completeness.
为RFC 4420[RFC4420]进行的IANA分配现在适用于本文件，为完整起见，在此列出。
IANA has updated the registry entries created for RFC 4420 to reference this document, which is now the normative reference for those entries. This document makes no further requests for IANA action.
IANA已更新了为RFC 4420创建的注册表条目，以引用本文件，该文件现在是这些条目的规范性参考。本文件不再要求IANA采取行动。
Two new RSVP C-Nums are defined in this document and have been assigned by IANA.
本文件中定义了两个新的RSVP C-NUM，并由IANA分配。
o LSP_ATTRIBUTES object
o LSP_属性对象
The C-Num (value 197) is of the form 11bbbbbb so that LSRs that do not recognize the object will ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message.
C-Num（值197）的形式为11bbbbbb，因此不识别该对象的LSR将忽略该对象，但在由该消息产生的所有消息中未经检查和修改地转发该对象。
One C-Type is defined for this object and has been assigned by IANA.
为该对象定义了一个C类型，并由IANA分配。
o LSP Attributes TLVs
o LSP属性TLV
C-Type value 1.
C型值1。
o LSP_REQUIRED_ATTRIBUTES object
o LSP_必需_属性对象
The C-Num (value 67) is of the form 0bbbbbbb so that LSRs that do not recognize the object will reject the message that carries it with an "Unknown Object Class" error.
C-Num（值67）的形式为0bbb，因此不识别该对象的LSR将拒绝带有“未知对象类”错误的消息。
One C-Type is defined for this object and has been assigned by IANA.
为该对象定义了一个C类型，并由IANA分配。
o LSP Required Attributes TLVs
o LSP必需属性TLV
C-Type value 1.
C型值1。
The two new objects referenced above are constructed from TLVs. Each TLV includes a 16-bit type identifier (the T-field). The same T-field values are applicable to both objects.
上面提到的两个新对象是从TLV构建的。每个TLV包括一个16位类型标识符（T字段）。相同的T字段值适用于两个对象。
The IANA has created a new registry and will manage TLV type identifiers as follows:
IANA已创建了一个新的注册表，并将按如下方式管理TLV类型标识符：
- TLV Type (T-field value) - TLV Name - Whether allowed on LSP_ATTRIBUTES object - Whether allowed on LSP_REQUIRED_ATTRIBUTES object
- TLV类型（T字段值）-TLV名称-是否允许在LSP_属性对象上-是否允许在LSP_必需属性对象上
This document defines one TLV type as follows:
本文件定义了一种TLV类型，如下所示：
- TLV Type = 1 - TLV Name = Attribute Flags TLV - allowed on LSP_ATTRIBUTES object - allowed on LSP_REQUIRED_ATTRIBUTES object
- TLV类型=1-TLV名称=属性标志TLV-允许在LSP_属性对象上使用-允许在LSP_必需的_属性对象上使用
New TLV type values may be allocated only by an IETF Consensus action.
新的TLV类型值只能由IETF一致行动分配。
This document provides new attributes bit flags for use in other documents that specify new RSVP-TE attributes. These flags are present in the Attribute Flags TLV referenced in the previous section.
本文档提供了新的属性位标志，可在指定新RSVP-TE属性的其他文档中使用。这些标志出现在上一节中引用的属性标志TLV中。
The IANA has created a new registry and will manage the space of attributes bit flags, numbering them in the usual IETF notation: starting at zero and continuing at least through 31.
IANA已经创建了一个新的注册表，并将管理属性位标志的空间，以通常的IETF符号对它们进行编号：从零开始，至少持续到31。
New bit numbers may be allocated only by an IETF Consensus action.
新的位号只能由IETF一致行动分配。
Each bit should be tracked with the following qualities:
应按照以下质量跟踪每个位：
- Bit number - Defining RFC - Name of bit - Whether there is meaning in the Attribute Flags TLV on a Path - Whether there is meaning in the Attribute Flags TLV on a Resv - Whether there is meaning in the RRO Attributes subobject
- 位号-定义RFC-位名称-路径上的属性标志TLV是否有意义-Resv上的属性标志TLV是否有意义-RRO属性子对象是否有意义
Note that this means that all bits in the Attribute Flags TLV and the RRO Attributes subobject use the same bit number, regardless of whether they are used in one or both places. Thus, only one list of bits is required to be maintained. (It would be meaningless in the context of this document for a bit to have no meaning in either the Attribute Flags TLV or the RRO Attributes subobject.)
请注意，这意味着属性标志TLV和RRO属性子对象中的所有位使用相同的位号，无论它们是在一个位置使用还是在两个位置使用。因此，只需要维护一个位列表。（在本文档的上下文中，bit在属性标志TLV或RRO属性子对象中没有任何意义是没有意义的。）
This document defines the following new Error Codes and Error Values. Numeric values have been assigned by IANA.
本文档定义了以下新的错误代码和错误值。IANA已指定数值。
Error Code Error Value 29 "Unknown Attributes TLV" Identifies the unknown TLV type code. 30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit.
错误代码错误值29“未知属性TLV”标识未知TLV类型代码。30“未知属性位”标识未知属性位。
A new subobject is defined for inclusion in the RECORD_ROUTE object.
定义了一个新的子对象以包含在记录路由对象中。
The RRO Attributes subobject is identified by a Type value of 5.
RRO属性子对象由类型值5标识。
This document adds two new objects to the RSVP Path message as used in MPLS and GMPLS signaling, and a new subobject to the RECORD_ROUTE object carried on many RSVP messages. It does not introduce any new direct security issues, and the reader is referred to the security considerations expressed in [RFC2205], [RFC3209], and [RFC3473].
本文档向在MPLS和GMPLS信令中使用的RSVP Path消息添加了两个新对象，并向许多RSVP消息中携带的RECORD_ROUTE对象添加了一个新的子对象。它没有引入任何新的直接安全问题，读者可以参考[RFC2205]、[RFC3209]和[RFC3473]中表达的安全注意事项。
It is of passing note that any signaling request that indicates the functional preferences or attributes of an MPLS LSP may provide anyone with unauthorized access to the contents of the message with information about the LSP that an administrator may wish to keep secret. Although this document adds new objects for signaling desired LSP attributes, it does not contribute to this issue, which can only be satisfactorily handled by encrypting the content of the signaling message.
值得注意的是，指示MPLS LSP的功能偏好或属性的任何信令请求可以向任何未经授权访问消息内容的人提供管理员可能希望保密的关于LSP的信息。尽管本文档添加了新的对象来发送所需的LSP属性，但它不会导致此问题，只能通过加密信令消息的内容来令人满意地处理此问题。
Similarly, the addition of attribute-recording information to the RRO may reveal information about the status of the LSP and the capabilities of individual LSRs that operators wish to keep secret. The same strategy that applies to other RRO subobjects also applies here. Note, however, that there is a tension between notifying the head end of the LSP status at transit LSRs, and hiding the existence or identity of the transit LSRs.
类似地，向RRO添加属性记录信息可以揭示关于LSP的状态以及操作员希望保密的各个lsr的能力的信息。适用于其他RRO子对象的相同策略也适用于此处。然而，请注意，在通知传输lsr处的LSP状态的前端和隐藏传输lsr的存在或身份之间存在紧张关系。
Credit to the OSPF Working Group for inspiration from their solution to a similar problem. Thanks to Rahul Aggarwal for his careful review and support of this work. Thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for their input. As so often, thanks to John Drake for useful offline discussions. Thanks to Mike Shand for providing the Routing Directorate review and to Joel Halpern for the General Area review -- both picked up on some unclarities.
OSPF工作组从他们对类似问题的解决方案中获得了灵感，这要归功于他们。感谢Rahul Aggarwal对这项工作的仔细审查和支持。还要感谢张雷蒙德、科佩拉、菲利普·马修斯、吉姆吉布森和艾伦·库尔伯格的投入。和往常一样，感谢约翰·德雷克提供的有用的离线讨论。感谢迈克·尚德（Mike Shand）提供了路由董事会审查，感谢乔尔·哈尔佩恩（Joel Halpern）提供了一般区域审查——两人都发现了一些不一致之处。
Thanks to the OIF for noticing the discrepancy in RFC 4420 that is fixed in this document. Alfred Hoenes noted several typographical errors.
感谢OIF注意到RFC 4420中的差异，该差异已在本文件中修复。阿尔弗雷德·霍恩斯指出了几个印刷错误。
This document obsoletes RFC 4420 [RFC4420]. The only change is in Section 3. Section 3 describes the semantic of the Length field of the Attributes TLV.
本文件淘汰了RFC 4420[RFC4420]。唯一的变化是第3节。第3节描述了属性TLV的长度字段的语义。
Prior to the change, the Length field indicated the length of the Value field only. After the change, as described in Section 3, the Length field indicates the length of the whole TLV. This change means that this document is consistent with the subobject format defined in [RFC3209] and the TLV format defined in [RFC3471].
更改之前，长度字段仅指示值字段的长度。变更后，如第3节所述，长度字段表示整个TLV的长度。此变更意味着本文件与[RFC3209]中定义的子对象格式和[RFC3471]中定义的TLV格式一致。
In addition, the RFC Editor made many editorial changes to improve the text and readability. These changes can be observed by comparing the text of this document with that of [RFC4420].
此外，RFC编辑器进行了许多编辑更改，以改进文本和可读性。通过将本文件的文本与[RFC4420]的文本进行比较，可以观察到这些变化。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella，K.和Y.Rekhter，“具有通用多协议标签交换（GMPLS）流量工程（TE）的标签交换路径（LSP）层次结构”，RFC 4206，2005年10月。
[RFC4420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. Ayyangar, "Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006.
[RFC4420]Farrel，A.，Ed.，Papadimitriou，D.，Vasseur，J.-P.，和A.Ayyangar，“使用资源预留协议流量工程（RSVP-TE）建立多协议标签交换（MPLS）标签交换路径（LSP）的属性编码”，RFC 4420，2006年2月。
Authors' Addresses
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Fr.Wellesplein 1，B-2018比利时安特卫普
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA - 01719 USA
Jean-Philippe Vasseur Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号-01719
EMail: jpv@cisco.com
EMail: jpv@cisco.com
Arthi Ayyangar Juniper Networks, Inc. 1194 N.Mathilda Ave Sunnyvale, CA 94089 USA
Arthi Ayyangar Juniper Networks，Inc.美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号，邮编94089
EMail: arthi@juniper.net
EMail: arthi@juniper.net