Network Working Group D. Awduche
Request for Comments: 3209 Movaz Networks, Inc.
Category: Standards Track L. Berger
D. Gan
Juniper Networks, Inc.
T. Li
Procket Networks, Inc.
V. Srinivasan
Cosine Communications, Inc.
G. Swallow
Cisco Systems, Inc.
December 2001
Network Working Group D. Awduche
Request for Comments: 3209 Movaz Networks, Inc.
Category: Standards Track L. Berger
D. Gan
Juniper Networks, Inc.
T. Li
Procket Networks, Inc.
V. Srinivasan
Cosine Communications, Inc.
G. Swallow
Cisco Systems, Inc.
December 2001
RSVP-TE: Extensions to RSVP for LSP Tunnels
RSVP-TE：LSP隧道RSVP的扩展
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) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching). Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702.
本文档描述了在MPLS（多协议标签交换）中使用RSVP（资源保留协议），包括所有必要的扩展，以建立标签交换路径（LSP）。由于沿着LSP的流完全由应用于路径的入口节点的标签识别，因此这些路径可以被视为隧道。LSP隧道的一个关键应用是RFC 2702中规定的MPLS流量工程。
We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label-switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks.
我们提出了几个扩展RSVP的附加对象，允许使用RSVP作为信令协议建立显式路由标签交换路径。结果是标签交换隧道的实例化，它可以自动路由到远离网络故障、拥塞和瓶颈的地方。
Contents
目录
1 Introduction .......................................... 3
1.1 Background ............................................. 4
1.2 Terminology ............................................ 6
2 Overview .............................................. 7
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7
2.2 Operation of LSP Tunnels ............................... 8
2.3 Service Classes ........................................ 10
2.4 Reservation Styles ..................................... 10
2.4.1 Fixed Filter (FF) Style ................................ 10
2.4.2 Wildcard Filter (WF) Style ............................. 11
2.4.3 Shared Explicit (SE) Style ............................. 11
2.5 Rerouting Traffic Engineered Tunnels ................... 12
2.6 Path MTU ............................................... 13
3 LSP Tunnel related Message Formats ..................... 15
3.1 Path Message ........................................... 15
3.2 Resv Message ........................................... 16
4 LSP Tunnel related Objects ............................. 17
4.1 Label Object ........................................... 17
4.1.1 Handling Label Objects in Resv messages ................ 17
4.1.2 Non-support of the Label Object ........................ 19
4.2 Label Request Object ................................... 19
4.2.1 Label Request without Label Range ...................... 19
4.2.2 Label Request with ATM Label Range ..................... 20
4.2.3 Label Request with Frame Relay Label Range ............. 21
4.2.4 Handling of LABEL_REQUEST .............................. 22
4.2.5 Non-support of the Label Request Object ................ 23
4.3 Explicit Route Object .................................. 23
4.3.1 Applicability .......................................... 24
4.3.2 Semantics of the Explicit Route Object ................. 24
4.3.3 Subobjects ............................................. 25
4.3.4 Processing of the Explicit Route Object ................ 28
4.3.5 Loops .................................................. 30
4.3.6 Forward Compatibility .................................. 30
4.3.7 Non-support of the Explicit Route Object ............... 31
4.4 Record Route Object .................................... 31
4.4.1 Subobjects ............................................. 31
4.4.2 Applicability .......................................... 34
4.4.3 Processing RRO ......................................... 35
4.4.4 Loop Detection ......................................... 36
4.4.5 Forward Compatibility .................................. 37
4.4.6 Non-support of RRO ..................................... 37
4.5 Error Codes for ERO and RRO ............................ 37
4.6 Session, Sender Template, and Filter Spec Objects ...... 38
4.6.1 Session Object ......................................... 39
4.6.2 Sender Template Object ................................. 40
4.6.3 Filter Specification Object ............................ 42
1 Introduction .......................................... 3
1.1 Background ............................................. 4
1.2 Terminology ............................................ 6
2 Overview .............................................. 7
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7
2.2 Operation of LSP Tunnels ............................... 8
2.3 Service Classes ........................................ 10
2.4 Reservation Styles ..................................... 10
2.4.1 Fixed Filter (FF) Style ................................ 10
2.4.2 Wildcard Filter (WF) Style ............................. 11
2.4.3 Shared Explicit (SE) Style ............................. 11
2.5 Rerouting Traffic Engineered Tunnels ................... 12
2.6 Path MTU ............................................... 13
3 LSP Tunnel related Message Formats ..................... 15
3.1 Path Message ........................................... 15
3.2 Resv Message ........................................... 16
4 LSP Tunnel related Objects ............................. 17
4.1 Label Object ........................................... 17
4.1.1 Handling Label Objects in Resv messages ................ 17
4.1.2 Non-support of the Label Object ........................ 19
4.2 Label Request Object ................................... 19
4.2.1 Label Request without Label Range ...................... 19
4.2.2 Label Request with ATM Label Range ..................... 20
4.2.3 Label Request with Frame Relay Label Range ............. 21
4.2.4 Handling of LABEL_REQUEST .............................. 22
4.2.5 Non-support of the Label Request Object ................ 23
4.3 Explicit Route Object .................................. 23
4.3.1 Applicability .......................................... 24
4.3.2 Semantics of the Explicit Route Object ................. 24
4.3.3 Subobjects ............................................. 25
4.3.4 Processing of the Explicit Route Object ................ 28
4.3.5 Loops .................................................. 30
4.3.6 Forward Compatibility .................................. 30
4.3.7 Non-support of the Explicit Route Object ............... 31
4.4 Record Route Object .................................... 31
4.4.1 Subobjects ............................................. 31
4.4.2 Applicability .......................................... 34
4.4.3 Processing RRO ......................................... 35
4.4.4 Loop Detection ......................................... 36
4.4.5 Forward Compatibility .................................. 37
4.4.6 Non-support of RRO ..................................... 37
4.5 Error Codes for ERO and RRO ............................ 37
4.6 Session, Sender Template, and Filter Spec Objects ...... 38
4.6.1 Session Object ......................................... 39
4.6.2 Sender Template Object ................................. 40
4.6.3 Filter Specification Object ............................ 42
4.6.4 Reroute and Bandwidth Increase Procedure ............... 42
4.7 Session Attribute Object ............................... 43
4.7.1 Format without resource affinities ..................... 43
4.7.2 Format with resource affinities ........................ 45
4.7.3 Procedures applying to both C-Types .................... 46
4.7.4 Resource Affinity Procedures .......................... 48
5 Hello Extension ........................................ 49
5.1 Hello Message Format ................................... 50
5.2 HELLO Object formats ................................... 51
5.2.1 HELLO REQUEST object ................................... 51
5.2.2 HELLO ACK object ....................................... 51
5.3 Hello Message Usage .................................... 52
5.4 Multi-Link Considerations .............................. 53
5.5 Compatibility .......................................... 54
6 Security Considerations ................................ 54
7 IANA Considerations .................................... 54
7.1 Message Types .......................................... 55
7.2 Class Numbers and C-Types .............................. 55
7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57
7.4 Subobject Definitions .................................. 57
8 Intellectual Property Considerations ................... 58
9 Acknowledgments ........................................ 58
10 References ............................................. 58
11 Authors' Addresses ..................................... 60
12 Full Copyright Statement ............................... 61
4.6.4 Reroute and Bandwidth Increase Procedure ............... 42
4.7 Session Attribute Object ............................... 43
4.7.1 Format without resource affinities ..................... 43
4.7.2 Format with resource affinities ........................ 45
4.7.3 Procedures applying to both C-Types .................... 46
4.7.4 Resource Affinity Procedures .......................... 48
5 Hello Extension ........................................ 49
5.1 Hello Message Format ................................... 50
5.2 HELLO Object formats ................................... 51
5.2.1 HELLO REQUEST object ................................... 51
5.2.2 HELLO ACK object ....................................... 51
5.3 Hello Message Usage .................................... 52
5.4 Multi-Link Considerations .............................. 53
5.5 Compatibility .......................................... 54
6 Security Considerations ................................ 54
7 IANA Considerations .................................... 54
7.1 Message Types .......................................... 55
7.2 Class Numbers and C-Types .............................. 55
7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57
7.4 Subobject Definitions .................................. 57
8 Intellectual Property Considerations ................... 58
9 Acknowledgments ........................................ 58
10 References ............................................. 58
11 Authors' Addresses ..................................... 60
12 Full Copyright Statement ............................... 61
Section 2.9 of the MPLS architecture [2] defines a label distribution protocol as a set of procedures by which one Label Switched Router (LSR) informs another of the meaning of labels used to forward traffic between and through them. The MPLS architecture does not assume a single label distribution protocol. This document is a specification of extensions to RSVP for establishing label switched paths (LSPs) in MPLS networks.
MPLS体系结构[2]的第2.9节将标签分发协议定义为一组过程，通过这些过程，一个标签交换路由器（LSR）通知另一个标签，标签用于转发它们之间和通过它们的流量。MPLS体系结构不采用单标签分发协议。本文档是用于在MPLS网络中建立标签交换路径（LSP）的RSVP扩展规范。
Several of the new features described in this document were motivated by the requirements for traffic engineering over MPLS (see [3]). In particular, the extended RSVP protocol supports the instantiation of explicitly routed LSPs, with or without resource reservations. It also supports smooth rerouting of LSPs, preemption, and loop detection.
本文档中描述的几个新特性是基于MPLS流量工程的需求（参见[3]）。特别是，扩展RSVP协议支持显式路由LSP的实例化，无论是否保留资源。它还支持LSP的平滑重路由、抢占和环路检测。
The LSPs created with RSVP can be used to carry the "Traffic Trunks" described in [3]. The LSP which carries a traffic trunk and a traffic trunk are distinct though closely related concepts. For example, two LSPs between the same source and destination could be load shared to carry a single traffic trunk. Conversely several
使用RSVP创建的LSP可用于承载[3]中所述的“交通干线”。承载交通干线和交通干线的LSP是不同但密切相关的概念。例如，同一源和目的地之间的两个LSP可以负载共享，以承载单个业务中继。反之数
traffic trunks could be carried in the same LSP if, for instance, the LSP were capable of carrying several service classes. The applicability of these extensions is discussed further in [10].
例如，如果LSP能够承载多个服务级别，则可以在同一LSP中承载交通干线。[10]中进一步讨论了这些扩展的适用性。
Since the traffic that flows along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels, tunneling below normal IP routing and filtering mechanisms. When an LSP is used in this way we refer to it as an LSP tunnel.
由于沿着标签交换路径的流量由应用于LSP的入口节点的标签定义，因此这些路径可以被视为隧道、低于正常IP路由的隧道和过滤机制。当以这种方式使用LSP时，我们将其称为LSP隧道。
LSP tunnels allow the implementation of a variety of policies related to network performance optimization. For example, LSP tunnels can be automatically or manually routed away from network failures, congestion, and bottlenecks. Furthermore, multiple parallel LSP tunnels can be established between two nodes, and traffic between the two nodes can be mapped onto the LSP tunnels according to local policy. Although traffic engineering (that is, performance optimization of operational networks) is expected to be an important application of this specification, the extended RSVP protocol can be used in a much wider context.
LSP隧道允许实施与网络性能优化相关的各种策略。例如，LSP隧道可以自动或手动路由，远离网络故障、拥塞和瓶颈。此外，可以在两个节点之间建立多个并行LSP隧道，并且可以根据本地策略将两个节点之间的业务映射到LSP隧道上。虽然流量工程（即操作网络的性能优化）预计将是本规范的一个重要应用，但扩展的RSVP协议可以在更广泛的环境中使用。
The purpose of this document is to describe the use of RSVP to establish LSP tunnels. The intent is to fully describe all the objects, packet formats, and procedures required to realize interoperable implementations. A few new objects are also defined that enhance management and diagnostics of LSP tunnels.
本文件的目的是描述使用RSVP建立LSP隧道。目的是全面描述实现可互操作实现所需的所有对象、数据包格式和过程。还定义了一些新对象，以增强LSP隧道的管理和诊断。
The document also describes a means of rapid node failure detection via a new HELLO message.
本文档还描述了通过新的HELLO消息快速检测节点故障的方法。
All objects and messages described in this specification are optional with respect to RSVP. This document discusses what happens when an object described here is not supported by a node.
本规范中描述的所有对象和消息对于RSVP都是可选的。本文档讨论当节点不支持此处描述的对象时会发生什么情况。
Throughout this document, the discussion will be restricted to unicast label switched paths. Multicast LSPs are left for further study.
在本文档中，讨论仅限于单播标签交换路径。多播LSP留待进一步研究。
Hosts and routers that support both RSVP [1] and Multi-Protocol Label Switching [2] can associate labels with RSVP flows. When MPLS and RSVP are combined, the definition of a flow can be made more flexible. Once a label switched path (LSP) is established, the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of label to traffic can be accomplished using a number of different criteria. The set of packets that are assigned the same label value by a specific node are
同时支持RSVP[1]和多协议标签交换[2]的主机和路由器可以将标签与RSVP流相关联。当MPLS和RSVP相结合时，流的定义可以变得更加灵活。一旦建立了标签交换路径（LSP），通过该路径的流量由应用于LSP的入口节点的标签定义。标签到流量的映射可以使用许多不同的标准来完成。由特定节点分配相同标签值的数据包集如下所示：
said to belong to the same forwarding equivalence class (FEC) (see [2]), and effectively define the "RSVP flow." When traffic is mapped onto a label-switched path in this way, we call the LSP an "LSP Tunnel". When labels are associated with traffic flows, it becomes possible for a router to identify the appropriate reservation state for a packet based on the packet's label value.
据说属于相同的转发等价类（FEC）（参见[2]），并有效地定义了“RSVP流”。当流量以这种方式映射到标签交换路径时，我们称LSP为“LSP隧道”。当标签与业务流相关联时，路由器可以基于分组的标签值识别分组的适当保留状态。
The signaling protocol model uses downstream-on-demand label distribution. A request to bind labels to a specific LSP tunnel is initiated by an ingress node through the RSVP Path message. For this purpose, the RSVP Path message is augmented with a LABEL_REQUEST object. Labels are allocated downstream and distributed (propagated upstream) by means of the RSVP Resv message. For this purpose, the RSVP Resv message is extended with a special LABEL object. The procedures for label allocation, distribution, binding, and stacking are described in subsequent sections of this document.
信令协议模型使用下游按需标签分发。入口节点通过RSVP Path消息发起将标签绑定到特定LSP隧道的请求。为此，RSVP Path消息增加了一个LABEL_请求对象。标签通过RSVP Resv消息分配到下游并分发（向上游传播）。为此，RSVP Resv消息使用一个特殊的标签对象进行扩展。本文件后续章节中描述了标签分配、分发、装订和堆叠的程序。
The signaling protocol model also supports explicit routing capability. This is accomplished by incorporating a simple EXPLICIT_ROUTE object into RSVP Path messages. The EXPLICIT_ROUTE object encapsulates a concatenation of hops which constitutes the explicitly routed path. Using this object, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, independent of conventional IP routing. The explicitly routed path can be administratively specified, or automatically computed by a suitable entity based on QoS and policy requirements, taking into consideration the prevailing network state. In general, path computation can be control-driven or data-driven. The mechanisms, processes, and algorithms used to compute explicitly routed paths are beyond the scope of this specification.
信令协议模型还支持显式路由能力。这是通过将一个简单的显式路由对象合并到RSVP路径消息中来实现的。EXPLICIT_ROUTE对象封装了构成显式路由路径的跃点串联。使用此对象，标签交换RSVP-MPLS流所采用的路径可以预先确定，与传统IP路由无关。显式路由路径可以通过管理方式指定，或者由适当的实体基于QoS和策略要求自动计算，同时考虑当前的网络状态。通常，路径计算可以是控制驱动的，也可以是数据驱动的。用于计算显式路由路径的机制、过程和算法超出了本规范的范围。
One useful application of explicit routing is traffic engineering. Using explicitly routed LSPs, a node at the ingress edge of an MPLS domain can control the path through which traffic traverses from itself, through the MPLS network, to an egress node. Explicit routing can be used to optimize the utilization of network resources and enhance traffic oriented performance characteristics.
显式路由的一个有用应用是流量工程。使用显式路由LSP，MPLS域入口边缘的节点可以控制流量从自身通过MPLS网络到出口节点的路径。显式路由可以用来优化网络资源的利用，增强面向流量的性能特性。
The concept of explicitly routed label switched paths can be generalized through the notion of abstract nodes. An abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node. Using this concept of abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes or a sequence of Autonomous Systems.
显式路由标签交换路径的概念可以通过抽象节点的概念进行推广。抽象节点是一组内部拓扑对LSP的入口节点不透明的节点。如果抽象节点仅包含一个物理节点，则称其为简单节点。使用这种抽象概念，可以将显式路由LSP指定为IP前缀序列或自治系统序列。
The signaling protocol model supports the specification of an explicit path as a sequence of strict and loose routes. The combination of abstract nodes, and strict and loose routes significantly enhances the flexibility of path definitions.
信令协议模型支持将显式路径指定为严格和松散路由序列。抽象节点、严格路由和松散路由的组合显著增强了路径定义的灵活性。
An advantage of using RSVP to establish LSP tunnels is that it enables the allocation of resources along the path. For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes [4].
使用RSVP建立LSP隧道的一个优点是，它可以沿路径分配资源。例如，可以使用标准RSVP预留和集成服务类将带宽分配给LSP隧道[4]。
While resource reservations are useful, they are not mandatory. Indeed, an LSP can be instantiated without any resource reservations whatsoever. Such LSPs without resource reservations can be used, for example, to carry best effort traffic. They can also be used in many other contexts, including implementation of fall-back and recovery policies under fault conditions, and so forth.
虽然资源保留很有用，但不是强制性的。实际上，LSP可以在没有任何资源保留的情况下实例化。例如，可以使用这种没有资源预留的lsp来承载尽力而为的业务。它们还可以用于许多其他环境，包括在故障条件下实施回退和恢复策略，等等。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC2119[6]中所述进行解释。
The reader is assumed to be familiar with the terminology in [1], [2] and [3].
假定读者熟悉[1]、[2]和[3]中的术语。
Abstract Node
抽象节点
A group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node.
其内部拓扑对LSP的入口节点不透明的一组节点。如果抽象节点仅包含一个物理节点，则称其为简单节点。
Explicitly Routed LSP
显式路由LSP
An LSP whose path is established by a means other than normal IP routing.
一种LSP，其路径是通过正常IP路由以外的方式建立的。
Label Switched Path
标记交换路径
The path created by the concatenation of one or more label switched hops, allowing a packet to be forwarded by swapping labels from an MPLS node to another MPLS node. For a more precise definition see [2].
通过连接一个或多个标签交换跃点而创建的路径，允许通过将标签从一个MPLS节点交换到另一个MPLS节点来转发数据包。有关更精确的定义，请参见[2]。
LSP
LSP
A Label Switched Path
标签交换路径
LSP Tunnel
LSP隧道
An LSP which is used to tunnel below normal IP routing and/or filtering mechanisms.
用于隧道低于正常IP路由和/或过滤机制的LSP。
Traffic Engineered Tunnel (TE Tunnel)
交通工程隧道（TE隧道）
A set of one or more LSP Tunnels which carries a traffic trunk.
一组承载交通干线的一条或多条LSP隧道。
Traffic Trunk
交通干线
A set of flows aggregated by their service class and then placed on an LSP or set of LSPs called a traffic engineered tunnel. For further discussion see [3].
由其服务类聚合的一组流，然后放置在一个LSP或一组LSP上，称为流量工程隧道。有关进一步讨论，请参见[3]。
According to [1], "RSVP defines a 'session' to be a data flow with a particular destination and transport-layer protocol." However, when RSVP and MPLS are combined, a flow or session can be defined with greater flexibility and generality. The ingress node of an LSP can use a variety of means to determine which packets are assigned a particular label. Once a label is assigned to a set of packets, the label effectively defines the "flow" through the LSP. We refer to such an LSP as an "LSP tunnel" because the traffic through it is opaque to intermediate nodes along the label switched path.
根据[1]，“RSVP将‘会话’定义为具有特定目的地和传输层协议的数据流。”然而，当RSVP和MPLS相结合时，流或会话的定义具有更大的灵活性和通用性。LSP的入口节点可以使用各种方法来确定哪些分组被分配了特定标签。一旦一个标签被分配给一组数据包，该标签就有效地定义了通过LSP的“流”。我们将这种LSP称为“LSP隧道”，因为通过它的流量对标签交换路径上的中间节点是不透明的。
New RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 have been defined to support the LSP tunnel feature. The semantics of these objects, from the perspective of a node along the label switched path, is that traffic belonging to the LSP tunnel is identified solely on the basis of packets arriving from the PHOP or "previous hop" (see [1]) with the particular label value(s) assigned by this node to upstream senders to the session. In fact, the IPv4(v6) that appears in the object name only denotes that the destination address is an IPv4(v6) address. When we refer to these objects generically, we use the qualifier LSP_TUNNEL.
新的RSVP会话、发送方模板和筛选器规范对象（称为LSP_TUNNEL_IPv4和LSP_TUNNEL_IPv6）已定义为支持LSP TUNNEL功能。从沿着标签交换路径的节点的角度来看，这些对象的语义是，属于LSP隧道的通信量仅基于从PHOP或“前一跳”（参见[1]）到达的分组来识别，该节点将特定标签值分配给会话的上游发送方。事实上，出现在对象名称中的IPv4（v6）仅表示目标地址是IPv4（v6）地址。当我们泛指这些对象时，我们使用限定符LSP_TUNNEL。
In some applications it is useful to associate sets of LSP tunnels. This can be useful during reroute operations or to spread a traffic trunk over multiple paths. In the traffic engineering application such sets are called traffic engineered tunnels (TE tunnels). To enable the identification and association of such LSP tunnels, two identifiers are carried. A tunnel ID is part of the SESSION object. The SESSION object uniquely defines a traffic engineered tunnel. The
在某些应用中，关联LSP隧道集非常有用。这在重新路由操作期间或在多条路径上分布流量主干时非常有用。在交通工程应用中，此类集合称为交通工程隧道（TE隧道）。为了能够识别和关联此类LSP隧道，携带了两个标识符。隧道ID是会话对象的一部分。会话对象唯一地定义了流量工程隧道。这个
SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID. The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel
SENDER_TEMPLATE和FILTER_SPEC对象带有LSP ID。SENDER_TEMPLATE（或FILTER_SPEC）对象与SESSION对象一起唯一标识LSP隧道
This section summarizes some of the features supported by RSVP as extended by this document related to the operation of LSP tunnels. These include: (1) the capability to establish LSP tunnels with or without QoS requirements, (2) the capability to dynamically reroute an established LSP tunnel, (3) the capability to observe the actual route traversed by an established LSP tunnel, (4) the capability to identify and diagnose LSP tunnels, (5) the capability to preempt an established LSP tunnel under administrative policy control, and (6) the capability to perform downstream-on-demand label allocation, distribution, and binding. In the following paragraphs, these features are briefly described. More detailed descriptions can be found in subsequent sections of this document.
本节总结了RSVP支持的与LSP隧道运营相关的一些功能，并在本文件中进行了扩展。这些包括：（1）建立有或没有QoS要求的LSP隧道的能力，（2）动态重新路由已建立的LSP隧道的能力，（3）观察已建立的LSP隧道穿越的实际路由的能力，（4）识别和诊断LSP隧道的能力，（5）在管理策略控制下抢占已建立LSP隧道的能力，以及（6）执行下游按需标签分配、分发和绑定的能力。在以下段落中，将简要介绍这些功能。更多详细说明见本文件后续章节。
To create an LSP tunnel, the first MPLS node on the path -- that is, the sender node with respect to the path -- creates an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path message. The LABEL_REQUEST object indicates that a label binding for this path is requested and also provides an indication of the network layer protocol that is to be carried over this path. The reason for this is that the network layer protocol sent down an LSP cannot be assumed to be IP and cannot be deduced from the L2 header, which simply identifies the higher layer protocol as MPLS.
要创建LSP隧道，路径上的第一个MPLS节点（即相对于路径的发送方节点）将创建会话类型为LSP_tunnel_IPv4或LSP_tunnel_IPv6的RSVP路径消息，并将LABEL_请求对象插入到路径消息中。LABEL_REQUEST对象表示已请求此路径的标签绑定，还提供将通过此路径承载的网络层协议的指示。这是因为不能将LSP下发送的网络层协议假定为IP，也不能从L2报头推断出来，L2报头只是将上层协议标识为MPLS。
If the sender node has knowledge of a route that has high likelihood of meeting the tunnel's QoS requirements, or that makes efficient use of network resources, or that satisfies some policy criteria, the node can decide to use the route for some or all of its sessions. To do this, the sender node adds an EXPLICIT_ROUTE object to the RSVP Path message. The EXPLICIT_ROUTE object specifies the route as a sequence of abstract nodes.
如果发送方节点知道一条路由，该路由极有可能满足隧道的QoS要求，或者有效利用网络资源，或者满足某些策略标准，则该节点可以决定将该路由用于其部分或全部会话。为此，发送方节点向RSVP Path消息添加一个显式的路由对象。EXPLICIT_ROUTE对象将路由指定为抽象节点序列。
If, after a session has been successfully established, the sender node discovers a better route, the sender can dynamically reroute the session by simply changing the EXPLICIT_ROUTE object. If problems are encountered with an EXPLICIT_ROUTE object, either because it causes a routing loop or because some intermediate routers do not support it, the sender node is notified.
如果在成功建立会话后，发送方节点发现更好的路由，则发送方可以通过简单地更改显式路由对象来动态地重新路由会话。如果显式路由对象遇到问题，或者因为它导致路由循环，或者因为某些中间路由器不支持它，则会通知发送方节点。
By adding a RECORD_ROUTE object to the Path message, the sender node can receive information about the actual route that the LSP tunnel traverses. The sender node can also use this object to request
通过向路径消息添加记录路由对象，发送方节点可以接收有关LSP隧道所穿越的实际路由的信息。发送方节点也可以使用此对象来请求
notification from the network concerning changes to the routing path. The RECORD_ROUTE object is analogous to a path vector, and hence can be used for loop detection.
来自网络的有关路由路径更改的通知。记录路由对象类似于路径向量，因此可用于环路检测。
Finally, a SESSION_ATTRIBUTE object can be added to Path messages to aid in session identification and diagnostics. Additional control information, such as setup and hold priorities, resource affinities (see [3]), and local-protection, are also included in this object.
最后，可以将会话_属性对象添加到路径消息中，以帮助会话识别和诊断。此对象中还包括其他控制信息，例如设置和保持优先级、资源亲缘关系（请参见[3]）和本地保护。
Routers along the path may use the setup and hold priorities along with SENDER_TSPEC and any POLICY_DATA objects contained in Path messages as input to policy control. For instance, in the traffic engineering application, it is very useful to use the Path message as a means of verifying that bandwidth exists at a particular priority along an entire path before preempting any lower priority reservations. If a Path message is allowed to progress when there are insufficient resources, then there is a danger that lower priority reservations downstream of this point will unnecessarily be preempted in a futile attempt to service this request.
路径上的路由器可以使用设置和保持优先级以及发送方_TSPEC和路径消息中包含的任何策略_数据对象作为策略控制的输入。例如，在流量工程应用程序中，在抢占任何较低优先级保留之前，使用路径消息作为验证带宽沿整个路径以特定优先级存在的手段是非常有用的。如果在资源不足的情况下允许Path消息继续进行，则存在这样一种危险，即该点下游的较低优先级保留将在为该请求提供服务的无效尝试中被不必要地抢占。
When the EXPLICIT_ROUTE object (ERO) is present, the Path message is forwarded towards its destination along a path specified by the ERO. Each node along the path records the ERO in its path state block. Nodes may also modify the ERO before forwarding the Path message. In this case the modified ERO SHOULD be stored in the path state block in addition to the received ERO.
当存在显式路由对象（ERO）时，路径消息将沿着ERO指定的路径转发到其目的地。路径上的每个节点在其路径状态块中记录ERO。节点还可以在转发路径消息之前修改ERO。在这种情况下，除了接收到的ERO外，修改后的ERO还应存储在路径状态块中。
The LABEL_REQUEST object requests intermediate routers and receiver nodes to provide a label binding for the session. If a node is incapable of providing a label binding, it sends a PathErr message with an "unknown object class" error. If the LABEL_REQUEST object is not supported end to end, the sender node will be notified by the first node which does not provide this support.
LABEL_请求对象请求中间路由器和接收器节点为会话提供标签绑定。如果节点无法提供标签绑定，则会发送带有“未知对象类”错误的PathErr消息。如果不支持端到端的LABEL_请求对象，则不提供此支持的第一个节点将通知发送方节点。
The destination node of a label-switched path responds to a LABEL_REQUEST by including a LABEL object in its response RSVP Resv message. The LABEL object is inserted in the filter spec list immediately following the filter spec to which it pertains.
标签交换路径的目标节点通过在其响应RSVP Resv消息中包含标签对象来响应标签请求。标签对象将插入过滤器等级库列表中，紧跟在其所属的过滤器等级库之后。
The Resv message is sent back upstream towards the sender, following the path state created by the Path message, in reverse order. Note that if the path state was created by use of an ERO, then the Resv message will follow the reverse path of the ERO.
Resv消息按照path消息创建的路径状态以相反的顺序向发送方发送回上游。请注意，如果路径状态是通过使用ERO创建的，则Resv消息将遵循ERO的反向路径。
Each node that receives a Resv message containing a LABEL object uses that label for outgoing traffic associated with this LSP tunnel. If the node is not the sender, it allocates a new label and places that label in the corresponding LABEL object of the Resv message which it
接收包含标签对象的Resv消息的每个节点将该标签用于与此LSP隧道关联的传出流量。如果节点不是发送方，它将分配一个新标签，并将该标签放置在它所发送的Resv消息的相应标签对象中
sends upstream to the PHOP. The label sent upstream in the LABEL object is the label which this node will use to identify incoming traffic associated with this LSP tunnel. This label also serves as shorthand for the Filter Spec. The node can now update its "Incoming Label Map" (ILM), which is used to map incoming labeled packets to a "Next Hop Label Forwarding Entry" (NHLFE), see [2].
向上游发送到PHOP。标签对象中向上游发送的标签是此节点将用于标识与此LSP隧道关联的传入流量的标签。该标签还可用作过滤器规范的简写。节点现在可以更新其“传入标签映射”（ILM），该映射用于将传入的标签数据包映射到“下一跳标签转发条目”（NHLFE），请参见[2]。
When the Resv message propagates upstream to the sender node, a label-switched path is effectively established.
当Resv消息向上游传播到发送方节点时，有效地建立了标签交换路径。
This document does not restrict the type of Integrated Service requests for reservations. However, an implementation SHOULD support the Controlled-Load service [4] and the Null Service [16].
本文档不限制综合服务预订请求的类型。但是，实现应该支持受控加载服务[4]和空服务[16]。
The receiver node can select from among a set of possible reservation styles for each session, and each RSVP session must have a particular style. Senders have no influence on the choice of reservation style. The receiver can choose different reservation styles for different LSPs.
接收方节点可以为每个会话从一组可能的保留样式中进行选择，并且每个RSVP会话必须具有特定的样式。发件人对预订风格的选择没有影响。接收器可以为不同的LSP选择不同的预订样式。
An RSVP session can result in one or more LSPs, depending on the reservation style chosen.
RSVP会话可以产生一个或多个LSP，具体取决于所选的保留样式。
Some reservation styles, such as FF, dedicate a particular reservation to an individual sender node. Other reservation styles, such as WF and SE, can share a reservation among several sender nodes. The following sections discuss the different reservation styles and their advantages and disadvantages. A more detailed discussion of reservation styles can be found in [1].
某些保留样式（如FF）将特定保留专用于单个发送方节点。其他保留样式（如WF和SE）可以在多个发送方节点之间共享保留。以下各节将讨论不同的预订方式及其优缺点。有关预订风格的更详细讨论，请参见[1]。
The Fixed Filter (FF) reservation style creates a distinct reservation for traffic from each sender that is not shared by other senders. This style is common for applications in which traffic from each sender is likely to be concurrent and independent. The total amount of reserved bandwidth on a link for sessions using FF is the sum of the reservations for the individual senders.
固定筛选器（FF）保留样式为每个发件人的流量创建一个不同的保留，其他发件人不共享该保留。这种风格在应用程序中很常见，其中来自每个发送方的流量可能是并发的和独立的。使用FF的会话在链路上保留的带宽总量是各个发送方的保留带宽之和。
Because each sender has its own reservation, a unique label is assigned to each sender. This can result in a point-to-point LSP between every sender/receiver pair.
因为每个发件人都有自己的保留，所以会为每个发件人分配一个唯一的标签。这可能导致每个发送方/接收方对之间出现点对点LSP。
With the Wildcard Filter (WF) reservation style, a single shared reservation is used for all senders to a session. The total reservation on a link remains the same regardless of the number of senders.
使用通配符筛选器（WF）保留样式，单个共享保留用于会话的所有发件人。无论发送者的数量如何，链接上的总保留都保持不变。
A single multipoint-to-point label-switched-path is created for all senders to the session. On links that senders to the session share, a single label value is allocated to the session. If there is only one sender, the LSP looks like a normal point-to-point connection. When multiple senders are present, a multipoint-to-point LSP (a reversed tree) is created.
将为会话的所有发送方创建一个多点到点标签交换路径。在发送到会话共享的链接上，将为会话分配一个标签值。如果只有一个发送方，则LSP看起来像正常的点对点连接。当存在多个发送方时，将创建多点对点LSP（反向树）。
This style is useful for applications in which not all senders send traffic at the same time. A phone conference, for example, is an application where not all speakers talk at the same time. If, however, all senders send simultaneously, then there is no means of getting the proper reservations made. Either the reserved bandwidth on links close to the destination will be less than what is required or then the reserved bandwidth on links close to some senders will be greater than what is required. This restricts the applicability of WF for traffic engineering purposes.
此样式对于并非所有发件人都同时发送流量的应用程序非常有用。例如，电话会议是一种并非所有发言者都同时讲话的应用程序。但是，如果所有发件人同时发送，则无法获得适当的预订。靠近目的地的链路上的保留带宽将小于所需带宽，或者靠近某些发送方的链路上的保留带宽将大于所需带宽。这限制了WF在交通工程中的适用性。
Furthermore, because of the merging rules of WF, EXPLICIT_ROUTE objects cannot be used with WF reservations. As a result of this issue and the lack of applicability to traffic engineering, use of WF is not considered in this document.
此外，由于WF的合并规则，显式路由对象不能与WF保留一起使用。由于该问题以及交通工程的不适用性，本文件不考虑WF的使用。
The Shared Explicit (SE) style allows a receiver to explicitly specify the senders to be included in a reservation. There is a single reservation on a link for all the senders listed. Because each sender is explicitly listed in the Resv message, different labels may be assigned to different senders, thereby creating separate LSPs.
共享显式（SE）样式允许接收者显式指定要包含在保留中的发送者。对于列出的所有发件人，链接上只有一个预订。由于每个发送者都在Resv消息中明确列出，因此可能会将不同的标签分配给不同的发送者，从而创建单独的LSP。
SE style reservations can be provided using multipoint-to-point label-switched-path or LSP per sender. Multipoint-to-point LSPs may be used when path messages do not carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects. In either of these cases a common label may be assigned.
可以使用多点到点标签交换路径或每个发送方的LSP来提供SE样式的预订。当路径消息不包含显式路由对象时，或者当路径消息具有相同的显式路由对象时，可以使用多点对点LSP。在这两种情况下，都可以指定一个通用标签。
Path messages from different senders can each carry their own ERO, and the paths taken by the senders can converge and diverge at any point in the network topology. When Path messages have differing EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object must be established.
来自不同发送方的路径消息可以各自携带自己的ERO，并且发送方所采用的路径可以在网络拓扑中的任何点上聚合和发散。当路径消息具有不同的显式路由对象时，必须为每个显式路由对象建立单独的LSP。
One of the requirements for Traffic Engineering is the capability to reroute an established TE tunnel under a number of conditions, based on administrative policy. For example, in some contexts, an administrative policy may dictate that a given TE tunnel is to be rerouted when a more "optimal" route becomes available. Another important context when TE tunnel reroute is usually required is upon failure of a resource along the TE tunnel's established path. Under some policies, it may also be necessary to return the TE tunnel to its original path when the failed resource becomes re-activated.
交通工程的要求之一是能够根据行政政策，在多种条件下改变已建TE隧道的路线。例如，在某些情况下，管理策略可能规定，当更“最优”的路由可用时，给定的TE隧道将被重新路由。通常需要TE隧道重新路由的另一个重要上下文是沿着TE隧道的已建立路径的资源发生故障时。在某些策略下，当发生故障的资源重新激活时，可能还需要将TE隧道返回到其原始路径。
In general, it is highly desirable not to disrupt traffic, or adversely impact network operations while TE tunnel rerouting is in progress. This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel. This concept is called "make-before-break." A problem can arise because the old and new LSP tunnels might compete with each other for resources on network segments which they have in common. Depending on availability of resources, this competition can cause Admission Control to prevent the new LSP tunnel from being established. An advantage of using RSVP to establish LSP tunnels is that it solves this problem very elegantly.
一般来说，在TE隧道重新路由过程中，最好不要中断通信或对网络运行造成不利影响。这种自适应和平滑的重新路由要求需要建立一个新的LSP隧道，并在拆除旧LSP隧道之前将流量从旧LSP隧道转移到该隧道上。这一概念被称为“先通后断”。可能会出现一个问题，因为新旧LSP隧道可能会在它们共同拥有的网段上相互竞争资源。根据资源的可用性，这种竞争可能导致准入控制，以阻止建立新的LSP隧道。使用RSVP建立LSP隧道的一个优点是它非常优雅地解决了这个问题。
To support make-before-break in a smooth fashion, it is necessary that on links that are common to the old and new LSPs, resources used by the old LSP tunnel should not be released before traffic is transitioned to the new LSP tunnel, and reservations should not be counted twice because this might cause Admission Control to reject the new LSP tunnel.
为了以平稳的方式支持先通后断，有必要在新旧LSP共用的链路上，在流量转换到新LSP隧道之前，不应释放旧LSP隧道使用的资源，保留不应计算两次，因为这可能会导致准入控制拒绝新的LSP隧道。
A similar situation can arise when one wants to increase the bandwidth of a TE tunnel. The new reservation will be for the full amount needed, but the actual allocation needed is only the delta between the new and old bandwidth. If policy is being applied to PATH messages by intermediate nodes, then a PATH message requesting too much bandwidth will be rejected. In this situation simply increasing the bandwidth request without changing the SENDER_TEMPLATE, could result in a tunnel being torn down, depending upon local policy.
当想要增加TE隧道的带宽时，也会出现类似的情况。新的预留将用于所需的全部数量，但实际需要的分配只是新带宽和旧带宽之间的增量。如果中间节点将策略应用于路径消息，则将拒绝请求过多带宽的路径消息。在这种情况下，仅增加带宽请求而不更改发送方\模板，可能会导致隧道被拆除，具体取决于本地策略。
The combination of the LSP_TUNNEL SESSION object and the SE reservation style naturally accommodates smooth transitions in bandwidth and routing. The idea is that the old and new LSP tunnels share resources along links which they have in common. The LSP_TUNNEL SESSION object is used to narrow the scope of the RSVP session to the particular TE tunnel in question. To uniquely identify a TE tunnel, we use the combination of the destination IP address (an address of the node which is the egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which is placed in the Extended Tunnel ID field.
LSP_隧道会话对象和SE保留样式的组合自然适应了带宽和路由的平滑过渡。其想法是，新旧LSP隧道沿着它们共同拥有的链路共享资源。LSP_TUNNEL SESSION对象用于将RSVP会话的范围缩小到所讨论的特定TE隧道。为了唯一地标识TE隧道，我们使用目标IP地址（作为隧道出口的节点的地址）、隧道ID和隧道入口节点的IP地址（位于扩展隧道ID字段中）的组合。
During the reroute or bandwidth-increase operation, the tunnel ingress needs to appear as two different senders to the RSVP session. This is achieved by the inclusion of the "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC objects. Since the semantics of these objects are changed, a new C-Types are assigned.
在重新路由或带宽增加操作期间，隧道入口需要显示为RSVP会话的两个不同发送方。这是通过包含“LSP ID”实现的，该ID包含在SENDER_模板和FILTER_SPEC对象中。由于这些对象的语义发生了变化，因此分配了一个新的C类型。
To effect a reroute, the ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE. The ingress node then creates a new ERO to define the new path. Thereafter the node sends a new Path Message using the original SESSION object and the new SENDER_TEMPLATE and ERO. It continues to use the old LSP and refresh the old Path message. On links that are not held in common, the new Path message is treated as a conventional new LSP tunnel setup. On links held in common, the shared SESSION object and SE style allow the LSP to be established sharing resources with the old LSP. Once the ingress node receives a Resv message for the new LSP, it can transition traffic to it and tear down the old LSP.
为了实现重新路由，入口节点选择一个新的LSP ID并形成一个新的发送方\ U模板。入口节点然后创建一个新的ERO来定义新路径。此后，节点使用原始会话对象和新的发送者\模板和ERO发送新的路径消息。它继续使用旧LSP并刷新旧路径消息。在不共用的链路上，新路径消息被视为传统的新LSP隧道设置。在公共链接上，共享会话对象和SE样式允许建立LSP，并与旧LSP共享资源。一旦入口节点接收到新LSP的Resv消息，它就可以将流量转移到新LSP并拆除旧LSP。
To effect a bandwidth-increase, a new Path Message with a new LSP_ID can be used to attempt a larger bandwidth reservation while the current LSP_ID continues to be refreshed to ensure that the reservation is not lost if the larger reservation fails.
为了实现带宽增加，可以使用具有新LSP_ID的新路径消息来尝试更大的带宽保留，同时继续刷新当前LSP_ID，以确保在更大的保留失败时保留不会丢失。
Standard RSVP [1] and Int-Serv [11] provide the RSVP sender with the minimum MTU available between the sender and the receiver. This path MTU identification capability is also provided for LSPs established via RSVP.
标准RSVP[1]和Int Serv[11]为RSVP发送方提供发送方和接收方之间可用的最小MTU。还为通过RSVP建立的LSP提供了该路径MTU识别能力。
Path MTU information is carried, depending on which is present, in the Integrated Services or Null Service objects. When using Integrated Services objects, path MTU is provided based on the procedures defined in [11]. Path MTU identification when using Null Service objects is defined in [16].
路径MTU信息在集成服务或空服务对象中携带，具体取决于存在的路径。使用集成服务对象时，将根据[11]中定义的过程提供路径MTU。[16]中定义了使用空服务对象时的路径MTU标识。
With standard RSVP, the path MTU information is used by the sender to check which IP packets exceed the path MTU. For packets that exceed the path MTU, the sender either fragments the packets or, when the IP datagram has the "Don't Fragment" bit set, issues an ICMP destination unreachable message. This path MTU related handling is also required for LSPs established via RSVP.
对于标准RSVP，发送方使用路径MTU信息检查哪些IP数据包超过路径MTU。对于超过路径MTU的数据包，发送方要么将数据包分段，要么在IP数据报设置了“不分段”位时，发出ICMP目的地不可到达消息。通过RSVP建立的LSP也需要此路径MTU相关处理。
The following algorithm applies to all unlabeled IP datagrams and to any labeled packets which the node knows to be IP datagrams, to which labels need to be added before forwarding. For labeled packets the bottom of stack is found, the IP header examined.
以下算法适用于所有未标记的IP数据报以及节点知道是IP数据报的任何标记数据包，在转发之前需要向其添加标签。对于标记的数据包，找到堆栈的底部，检查IP头。
Using the terminology defined in [5], an LSR MUST execute the following algorithm:
使用[5]中定义的术语，LSR必须执行以下算法：
1. Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node.
1. 设N为标签堆栈中的字节数（即标签堆栈项数的4倍），包括要由该节点添加的标签。
2. Let M be the smaller of the "Maximum Initially Labeled IP Datagram Size" or of (Path MTU - N).
2. 设M为“初始标记的最大IP数据报大小”或（路径MTU-N）中的较小者。
When the size of an IPv4 datagram (without labels) exceeds the value of M,
当IPv4数据报（无标签）的大小超过M值时，
If the DF bit is not set in the IPv4 header, then
如果IPv4标头中未设置DF位，则
(a) the datagram MUST be broken into fragments, each of whose size is no greater than M, and
(a) 数据报必须分为多个片段，每个片段的大小不超过M，并且
(b) each fragment MUST be labeled and then forwarded.
(b) 每个片段都必须标记，然后转发。
If the DF bit is set in the IPv4 header, then
如果在IPv4标头中设置了DF位，则
(a) the datagram MUST NOT be forwarded
(a) 不得转发数据报
(b) Create an ICMP Destination Unreachable Message:
(b) 创建无法访问的ICMP目标消息：
i. set its Code field [12] to "Fragmentation Required and DF Set", ii. set its Next-Hop MTU field [13] to M
我将其代码字段[12]设置为“所需碎片和DF设置”，ii。将其下一跳MTU字段[13]设置为M
(c) If possible, transmit the ICMP Destination Unreachable Message to the source of the of the discarded datagram.
(c) 如果可能，将ICMP目的地不可到达消息传输到丢弃数据报的源。
When the size of an IPv6 datagram (without labels) exceeds the value of M,
当IPv6数据报（无标签）的大小超过M值时，
(a) the datagram MUST NOT be forwarded
(a) 不得转发数据报
(b) Create an ICMP Packet too Big Message with the Next-Hop link MTU field [14] set to M
(b) 创建ICMP数据包太大的消息，并将下一跳链接MTU字段[14]设置为M
(c) If possible, transmit the ICMP Packet too Big Message to the source of the of the discarded datagram.
(c) 如果可能，将ICMP数据包过大消息传输到丢弃数据报的源。
Five new objects are defined in this section:
本节定义了五个新对象：
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path
New C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC, objects.
还为会话、发件人模板和筛选器规范对象分配了新的C类型。
Detailed descriptions of the new objects are given in later sections. All new objects are OPTIONAL with respect to RSVP. An implementation can choose to support a subset of objects. However, the LABEL_REQUEST and LABEL objects are mandatory with respect to this specification.
新对象的详细描述将在后面的部分中给出。对于RSVP，所有新对象都是可选的。实现可以选择支持对象的子集。但是，对于本规范而言，标签请求和标签对象是强制性的。
The LABEL and RECORD_ROUTE objects, are sender specific. In Resv messages they MUST appear after the associated FILTER_SPEC and prior to any subsequent FILTER_SPEC.
标签和记录路由对象是特定于发件人的。在Resv消息中，它们必须出现在相关筛选器规范之后和任何后续筛选器规范之前。
The relative placement of EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE objects is simply a recommendation. The ordering of these objects is not important, so an implementation MUST be prepared to accept objects in any order.
显式路由、标签请求和会话属性对象的相对位置只是一个建议。这些对象的顺序并不重要，因此实现必须准备好以任何顺序接受对象。
The format of the Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
The format of the Resv message is as follows:
Resv消息的格式如下：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
Note: LABEL and RECORD_ROUTE (if present), are bound to the preceding FILTER_SPEC. No more than one LABEL and/or RECORD_ROUTE may follow each FILTER_SPEC.
注意：标签和记录路由（如果存在）绑定到前面的过滤器规范。每个过滤器规范后面最多只能有一个标签和/或记录路由。
Labels MAY be carried in Resv messages. For the FF and SE styles, a label is associated with each sender. The label for a sender MUST immediately follow the FILTER_SPEC for that sender in the Resv message.
标签可以在Resv消息中携带。对于FF和SE样式，标签与每个发送者关联。发件人的标签必须立即遵循Resv邮件中该发件人的筛选器规范。
The LABEL object has the following format:
标签对象具有以下格式：
LABEL class = 16, C_Type = 1
标签类别=16，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The contents of a LABEL is a single label, encoded in 4 octets. Each generic MPLS label is an unsigned integer in the range 0 through 1048575. Generic MPLS labels and FR labels are encoded right aligned in 4 octets. ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
标签的内容是单个标签，编码为4个八位字节。每个通用MPLS标签都是0到1048575范围内的无符号整数。通用MPLS标签和FR标签以4个八位字节右对齐编码。ATM标签编码时，VPI右对齐位为0-15，VCI右对齐位为16-31。
In MPLS a node may support multiple label spaces, perhaps associating a unique space with each incoming interface. For the purposes of the following discussion, the term "same label" means the identical label value drawn from the identical label space. Further, the following applies only to unicast sessions.
在MPLS中，节点可以支持多个标签空间，可能将唯一空间与每个传入接口相关联。出于以下讨论的目的，术语“相同标签”指从相同标签空间绘制的相同标签值。此外，以下仅适用于单播会话。
Labels received in Resv messages on different interfaces are always considered to be different even if the label value is the same.
即使标签值相同，在不同接口上的Resv消息中接收的标签始终被视为不同。
The downstream node selects a label to represent the flow. If a label range has been specified in the label request, the label MUST be drawn from that range. If no label is available the node sends a PathErr message with an error code of "routing problem" and an error value of "label allocation failure".
下游节点选择一个标签来表示流。如果标签请求中指定了标签范围，则必须从该范围中绘制标签。如果没有可用的标签，节点将发送一条PathErr消息，错误代码为“路由问题”，错误值为“标签分配失败”。
If a node receives a Resv message that has assigned the same label value to multiple senders, then that node MAY also assign a single value to those same senders or to any subset of those senders. Note
如果节点接收到已将相同标签值分配给多个发送者的Resv消息，则该节点还可以将单个值分配给这些发送者或这些发送者的任何子集。笔记
that if a node intends to police individual senders to a session, it MUST assign unique labels to those senders.
如果节点打算监视会话的各个发送者，则必须为这些发送者分配唯一的标签。
In the case of ATM, one further condition applies. Some ATM nodes are not capable of merging streams. These nodes MAY indicate this by setting a bit in the label request to zero. The M-bit in the LABEL_REQUEST object of C-Type 2, label request with ATM label range, serves this purpose. The M-bit SHOULD be set by nodes which are merge capable. If for any senders the M-bit is not set, the downstream node MUST assign unique labels to those senders.
对于ATM，另一个条件适用。某些ATM节点无法合并流。这些节点可以通过将标签请求中的一位设置为零来指示这一点。C-Type 2的LABEL_请求对象中的M位“LABEL REQUEST with ATM LABEL range”用于此目的。M位应由具有合并功能的节点设置。如果没有为任何发送方设置M位，则下游节点必须为这些发送方分配唯一的标签。
Once a label is allocated, the node formats a new LABEL object. The node then sends the new LABEL object as part of the Resv message to the previous hop. The node SHOULD be prepared to forward packets carrying the assigned label prior to sending the Resv message. The LABEL object SHOULD be kept in the Reservation State Block. It is then used in the next Resv refresh event for formatting the Resv message.
分配标签后，节点将格式化新标签对象。然后，节点将新标签对象作为Resv消息的一部分发送到上一个跃点。在发送Resv消息之前，节点应准备转发带有指定标签的数据包。标签对象应保留在保留状态块中。然后在下一个Resv刷新事件中使用它来格式化Resv消息。
A node is expected to send a Resv message before its refresh timers expire if the contents of the LABEL object change.
如果标签对象的内容发生更改，则节点应在其刷新计时器过期之前发送Resv消息。
A node uses the label carried in the LABEL object as the outgoing label associated with the sender. The router allocates a new label and binds it to the incoming interface of this session/sender. This is the same interface that the router uses to forward Resv messages to the previous hops.
节点使用标签对象中携带的标签作为与发送方关联的传出标签。路由器分配新标签并将其绑定到此会话/发送方的传入接口。这与路由器用于将Resv消息转发到前一个跃点的接口相同。
Several circumstance can lead to an unacceptable label.
有几种情况会导致标签不可接受。
1. the node is a merge incapable ATM switch but the downstream node has assigned the same label to two senders
1. 该节点是不能合并的ATM交换机，但下游节点已将相同的标签分配给两个发送方
2. The implicit null label was assigned, but the node is not capable of doing a penultimate pop for the associated L3PID
2. 已分配隐式null标签，但节点无法为关联的L3PID执行倒数第二个pop
3. The assigned label is outside the requested label range
3. 指定的标签超出了请求的标签范围
In any of these events the node send a ResvErr message with an error code of "routing problem" and an error value of "unacceptable label value".
在这些事件中的任何一个事件中，节点发送一个ResvErr消息，其中错误代码为“路由问题”，错误值为“不可接受的标签值”。
Under normal circumstances, a node should never receive a LABEL object in a Resv message unless it had included a LABEL_REQUEST object in the corresponding Path message. However, an RSVP router that does not recognize the LABEL object sends a ResvErr with the error code "Unknown object class" toward the receiver. This causes the reservation to fail.
在正常情况下，节点不应在Resv消息中接收LABEL对象，除非它在相应的Path消息中包含LABEL_请求对象。但是，不识别标签对象的RSVP路由器向接收器发送带有错误代码“Unknown object class”的ResvErr。这会导致保留失败。
The Label Request Class is 19. Currently there are three possible C_Types. Type 1 is a Label Request without label range. Type 2 is a label request with an ATM label range. Type 3 is a label request with a Frame Relay label range. The LABEL_REQUEST object formats are shown below.
标签请求类是19。目前有三种可能的C_类型。类型1是没有标签范围的标签请求。类型2是具有ATM标签范围的标签请求。类型3是具有帧中继标签范围的标签请求。标签请求对象格式如下所示。
Class = 19, C_Type = 1
类别=19，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
L3PID
L3PID
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
使用此路径的第3层协议的标识符。使用标准Ethertype值。
Class = 19, C_Type = 2
类别=19，C_类型=2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (Res)
保留（Res）
This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
此字段是保留的。传输时必须将其设置为零，接收时必须忽略。
L3PID
L3PID
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
使用此路径的第3层协议的标识符。使用标准Ethertype值。
M
M
Setting this bit to one indicates that the node is capable of merging in the data plane
将该位设置为1表示节点能够在数据平面中合并
Minimum VPI (12 bits)
最小VPI（12位）
This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
此12位字段指定发起交换机上支持的虚拟路径标识符块的下限。如果VPI小于12位，则必须在此字段中右对齐，并且前面的位必须设置为零。
Minimum VCI (16 bits)
最小VCI（16位）
This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
此16位字段指定发起交换机上支持的虚拟连接标识符块的下限。如果VCI小于16位，则必须在此字段中右对齐，并且前面的位必须设置为零。
Maximum VPI (12 bits)
最大VPI（12位）
This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that is supported on the originating switch. If the VPI is less than 12-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
此12位字段指定发起交换机支持的虚拟路径标识符块的上限。如果VPI小于12位，则必须在此字段中右对齐，并且前面的位必须设置为零。
Maximum VCI (16 bits)
最大VCI（16位）
This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that is supported on the originating switch. If the VCI is less than 16-bits it MUST be right justified in this field and preceding bits MUST be set to zero.
此16位字段指定发起交换机支持的虚拟连接标识符块的上限。如果VCI小于16位，则必须在此字段中右对齐，并且前面的位必须设置为零。
Class = 19, C_Type = 3
等级=19，C_类型=3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |DLI| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |DLI| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
含蓄的
This field is reserved. It MUST be set to zero on transmission and ignored on receipt.
此字段是保留的。必须在传输时将其设置为零，在接收时将其忽略。
L3PID
L3PID
an identifier of the layer 3 protocol using this path. Standard Ethertype values are used.
使用此路径的第3层协议的标识符。使用标准Ethertype值。
DLI
DLI
DLCI Length Indicator. The number of bits in the DLCI. The following values are supported:
DLCI长度指示器。DLCI中的位数。支持以下值：
Len DLCI bits
Len-DLCI位
0 10 2 23
0 10 2 23
Minimum DLCI
最小DLCI
This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0.
此23位字段指定原始交换机上支持的数据链路连接标识符（DLCI）块的下限。DLCI在此字段中必须右对齐，未使用的位必须设置为0。
Maximum DLCI
最大DLCI
This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported on the originating switch. The DLCI MUST be right justified in this field and unused bits MUST be set to 0.
此23位字段指定原始交换机上支持的数据链路连接标识符（DLCI）块的上限。DLCI在此字段中必须右对齐，未使用的位必须设置为0。
To establish an LSP tunnel the sender creates a Path message with a LABEL_REQUEST object. The LABEL_REQUEST object indicates that a label binding for this path is requested and provides an indication of the network layer protocol that is to be carried over this path. This permits non-IP network layer protocols to be sent down an LSP. This information can also be useful in actual label allocation, because some reserved labels are protocol specific, see [5].
要建立LSP隧道，发送方将创建一个带有LABEL_请求对象的Path消息。LABEL_REQUEST对象表示已请求此路径的标签绑定，并提供将通过此路径承载的网络层协议的指示。这允许通过LSP发送非IP网络层协议。此信息在实际标签分配中也很有用，因为某些保留标签是特定于协议的，请参见[5]。
The LABEL_REQUEST SHOULD be stored in the Path State Block, so that Path refresh messages will also contain the LABEL_REQUEST object. When the Path message reaches the receiver, the presence of the LABEL_REQUEST object triggers the receiver to allocate a label and to place the label in the LABEL object for the corresponding Resv message. If a label range was specified, the label MUST be allocated from that range. A receiver that accepts a LABEL_REQUEST object MUST include a LABEL object in Resv messages pertaining to that Path message. If a LABEL_REQUEST object was not present in the Path message, a node MUST NOT include a LABEL object in a Resv message for that Path message's session and PHOP.
标签请求应存储在路径状态块中，以便路径刷新消息也将包含标签请求对象。当Path消息到达接收方时，LABEL_请求对象的存在会触发接收方分配标签，并将标签放置在标签对象中以用于相应的Resv消息。如果指定了标签范围，则必须从该范围分配标签。接受LABEL_请求对象的接收器必须在与该Path消息相关的Resv消息中包含LABEL对象。如果路径消息中不存在LABEL_请求对象，则节点不得在该路径消息的会话和PHOP的Resv消息中包含LABEL对象。
A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages.
发送LABEL_请求对象的节点必须准备好接受并正确处理相应Resv消息中的LABEL对象。
A node that recognizes a LABEL_REQUEST object, but that is unable to support it (possibly because of a failure to allocate labels) SHOULD send a PathErr with the error code "Routing problem" and the error value "MPLS label allocation failure." This includes the case where a label range has been specified and a label cannot be allocated from that range.
识别LABEL_请求对象但无法支持该对象（可能是因为分配标签失败）的节点应发送路径错误，错误代码为“Routing problem”，错误值为“MPLS LABEL allocation failure”这包括已指定标签范围且无法从该范围分配标签的情况。
A node which receives and forwards a Path message each with a LABEL_REQUEST object, MUST copy the L3PID from the received LABEL_REQUEST object to the forwarded LABEL_REQUEST object.
接收和转发路径消息（每个消息都带有一个LABEL_请求对象）的节点必须将L3PID从接收到的LABEL_请求对象复制到转发的LABEL_请求对象。
If the receiver cannot support the protocol L3PID, it SHOULD send a PathErr with the error code "Routing problem" and the error value "Unsupported L3PID." This causes the RSVP session to fail.
如果接收器不能支持协议L3PID，它应该发送一个带有错误代码“Routing problem”和错误值“Unsupported L3PID”的PathErr。这会导致RSVP会话失败。
An RSVP router that does not recognize the LABEL_REQUEST object sends a PathErr with the error code "Unknown object class" toward the sender. An RSVP router that recognizes the LABEL_REQUEST object but does not recognize the C_Type sends a PathErr with the error code "Unknown object C_Type" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the LABEL_REQUEST.
无法识别LABEL_请求对象的RSVP路由器向发送方发送错误代码为“Unknown object class”的PathErr。识别LABEL_请求对象但不识别C_类型的RSVP路由器向发送方发送错误代码为“Unknown object C_Type”的PathErr。这会导致路径设置失败。发送方应通知管理层无法建立LSP，并可能采取措施在没有LABEL_请求的情况下继续保留。
RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers. However, obviously, non-RSVP routers cannot convey labels via RSVP. This means that if a router has a neighbor that is known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when sending messages that pass through the non-RSVP routers. The router SHOULD send a PathErr back to the sender, with the error code "Routing problem" and the error value "MPLS being negotiated, but a non-RSVP capable router stands in the path." This same message SHOULD be sent, if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router. See [1] for a description of how a downstream router can determine the presence of non-RSVP routers.
RSVP设计用于优雅地处理发送方和接收方之间任何位置的非RSVP路由器。然而，显然，非RSVP路由器不能通过RSVP传送标签。这意味着，如果路由器有一个已知不支持RSVP的邻居，则在发送通过非RSVP路由器的消息时，路由器不得公布LABEL_请求对象。路由器应将PathErr发送回发送方，错误代码为“Routing problem”，错误值为“MPLS正在协商，但路径中存在不支持RSVP的路由器”。如果路由器从不支持RSVP的路由器接收到消息中的LABEL_请求对象，则应发送相同的消息。有关下游路由器如何确定非RSVP路由器存在的说明，请参见[1]。
Explicit routes are specified via the EXPLICIT_ROUTE object (ERO). The Explicit Route Class is 20. Currently one C_Type is defined, Type 1 Explicit Route. The EXPLICIT_ROUTE object has the following format:
显式路由通过显式路由对象（ERO）指定。显式路由类是20。目前定义了一种C_类型，类型1显式路由。显式路由对象具有以下格式：
Class = 20, C_Type = 1
类别=20，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
子对象
The contents of an EXPLICIT_ROUTE object are a series of variable-length data items called subobjects. The subobjects are defined in section 4.3.3 below.
显式路由对象的内容是一系列称为子对象的可变长度数据项。子对象定义见下文第4.3.3节。
If a Path message contains multiple EXPLICIT_ROUTE objects, only the first object is meaningful. Subsequent EXPLICIT_ROUTE objects MAY be ignored and SHOULD NOT be propagated.
如果路径消息包含多个显式路由对象，则只有第一个对象有意义。后续的显式路由对象可能会被忽略，不应传播。
The EXPLICIT_ROUTE object is intended to be used only for unicast situations. Applications of explicit routing to multicast are a topic for further research.
显式路由对象仅用于单播情况。显式路由在组播中的应用是一个有待进一步研究的课题。
The EXPLICIT_ROUTE object is to be used only when all routers along the explicit route support RSVP and the EXPLICIT_ROUTE object. The EXPLICIT_ROUTE object is assigned a class value of the form 0bbbbbbb. RSVP routers that do not support the object will therefore respond with an "Unknown Object Class" error.
仅当沿显式路由的所有路由器支持RSVP和显式路由对象时，才使用显式路由对象。显式路由对象被指定一个0bbb形式的类值。因此，不支持对象的RSVP路由器将响应“未知对象类”错误。
An explicit route is a particular path in the network topology. Typically, the explicit route is determined by a node, with the intent of directing traffic along that path.
显式路由是网络拓扑中的特定路径。通常，显式路由由节点确定，目的是沿着该路径引导流量。
An explicit route is described as a list of groups of nodes along the explicit route. In addition to the ability to identify specific nodes along the path, an explicit route can identify a group of nodes that must be traversed along the path. This capability allows the routing system a significant amount of local flexibility in fulfilling a request for an explicit route. This capability allows the generator of the explicit route to have imperfect information about the details of the path.
显式路由描述为沿显式路由的节点组列表。除了能够识别路径上的特定节点外，显式路由还可以识别必须沿路径遍历的一组节点。此功能允许路由系统在满足显式路由请求时具有很大的本地灵活性。此功能允许显式路由的生成器具有关于路径细节的不完全信息。
The explicit route is encoded as a series of subobjects contained in an EXPLICIT_ROUTE object. Each subobject identifies a group of nodes in the explicit route. An explicit route is thus a specification of groups of nodes to be traversed.
显式路由编码为显式路由对象中包含的一系列子对象。每个子对象标识显式路由中的一组节点。因此，显式路由是要遍历的节点组的规范。
To formalize the discussion, we call each group of nodes an abstract node. Thus, we say that an explicit route is a specification of a set of abstract nodes to be traversed. If an abstract node consists of only one node, we refer to it as a simple abstract node.
为了使讨论形式化，我们将每组节点称为抽象节点。因此，我们说显式路由是要遍历的一组抽象节点的规范。如果一个抽象节点只包含一个节点，我们将其称为简单抽象节点。
As an example of the concept of abstract nodes, consider an explicit route that consists solely of Autonomous System number subobjects. Each subobject corresponds to an Autonomous System in the global topology. In this case, each Autonomous System is an abstract node, and the explicit route is a path that includes each of the specified Autonomous Systems. There may be multiple hops within each Autonomous System, but these are opaque to the source node for the explicit route.
作为抽象节点概念的一个例子，考虑一个仅由自治系统编号子对象组成的显式路由。每个子对象对应于全局拓扑中的自治系统。在这种情况下，每个自治系统是一个抽象节点，显式路由是包含每个指定自治系统的路径。每个自治系统内可能有多个跃点，但对于显式路由，这些跃点对源节点是不透明的。
The contents of an EXPLICIT_ROUTE object are a series of variable-length data items called subobjects. Each subobject has the form:
显式路由对象的内容是一系列称为子对象的可变长度数据项。每个子对象具有以下形式：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
L
L
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
L位是子对象的属性。如果子对象表示显式路由中的松散跃点，则设置L位。如果未设置位，则子对象表示显式路由中的严格跃点。
Type
类型
The Type indicates the type of contents of the subobject. Currently defined values are:
类型指示子对象的内容类型。当前定义的值为：
1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number
1 IPv4前缀2 IPv6前缀32自治系统编号
Length
长
The Length contains the total length of the subobject in bytes, including the L, Type and Length fields. The Length MUST be at least 4, and MUST be a multiple of 4.
长度包含子对象的总长度（字节），包括L、类型和长度字段。长度必须至少为4，并且必须是4的倍数。
The L bit in the subobject is a one-bit attribute. If the L bit is set, then the value of the attribute is 'loose.' Otherwise, the value of the attribute is 'strict.' For brevity, we say that if the value of the subobject attribute is 'loose' then it is a 'loose subobject.' Otherwise, it's a 'strict subobject.' Further, we say that the abstract node of a strict or loose subobject is a strict or a loose node, respectively. Loose and strict nodes are always interpreted relative to their prior abstract nodes.
子对象中的L位是一位属性。如果设置了L位，则属性的值为“松散”。否则，属性的值为“严格”。为简洁起见，我们说如果子对象属性的值为“松散”，则它为“松散子对象”。否则，它为“严格子对象”。此外，我们说严格或松散子对象的抽象节点分别是严格或松散节点。松散节点和严格节点总是相对于其先前的抽象节点进行解释。
The path between a strict node and its preceding node MUST include only network nodes from the strict node and its preceding abstract node.
严格节点及其前一个节点之间的路径必须仅包括严格节点及其前一个抽象节点中的网络节点。
The path between a loose node and its preceding node MAY include other network nodes that are not part of the strict node or its preceding abstract node.
松散节点与其前一节点之间的路径可以包括不属于严格节点或其前一抽象节点的其他网络节点。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
L
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
L位是子对象的属性。如果子对象表示显式路由中的松散跃点，则设置L位。如果未设置位，则子对象表示显式路由中的严格跃点。
Type
类型
0x01 IPv4 address
0x01 IPv4地址
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为8。
IPv4 address
IPv4地址
An IPv4 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
IPv4地址。根据下面的前缀长度值，此地址被视为前缀。超过前缀的位在接收时被忽略，在传输时应设置为零。
Prefix length
前缀长度
Length in bits of the IPv4 prefix
IPv4前缀的位长度
Padding
衬料
Zero on transmission. Ignored on receipt.
传输为零。收到时忽略。
The contents of an IPv4 prefix subobject are a 4-octet IPv4 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 32 indicates a single IPv4 node.
IPv4前缀子对象的内容包括4个八位字节的IPv4地址、1个八位字节的前缀长度和1个八位字节的pad。此子对象表示的抽象节点是一组具有位于此前缀内的IP地址的节点。请注意，前缀长度32表示单个IPv4节点。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L
L
The L bit is an attribute of the subobject. The L bit is set if the subobject represents a loose hop in the explicit route. If the bit is not set, the subobject represents a strict hop in the explicit route.
L位是子对象的属性。如果子对象表示显式路由中的松散跃点，则设置L位。如果未设置位，则子对象表示显式路由中的严格跃点。
Type
类型
0x02 IPv6 address
0x02 IPv6地址
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为20。
IPv6 address
IPv6地址
An IPv6 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission.
IPv6地址。根据下面的前缀长度值，此地址被视为前缀。超过前缀的位在接收时被忽略，在传输时应设置为零。
Prefix Length
前缀长度
Length in bits of the IPv6 prefix.
IPv6前缀的长度（位）。
Padding
衬料
Zero on transmission. Ignored on receipt.
传输为零。收到时忽略。
The contents of an IPv6 prefix subobject are a 16-octet IPv6 address, a 1-octet prefix length, and a 1-octet pad. The abstract node represented by this subobject is the set of nodes that have an IP address which lies within this prefix. Note that a prefix length of 128 indicates a single IPv6 node.
IPv6前缀子对象的内容包括16个八位IPv6地址、1个八位前缀长度和1个八位焊盘。此子对象表示的抽象节点是一组具有位于此前缀内的IP地址的节点。请注意，前缀长度128表示单个IPv6节点。
The contents of an Autonomous System (AS) number subobject are a 2- octet AS number. The abstract node represented by this subobject is the set of nodes belonging to the autonomous system.
自治系统（AS）编号子对象的内容是2个八位组的AS编号。此子对象表示的抽象节点是属于自治系统的节点集。
The length of the AS number subobject is 4 octets.
AS编号子对象的长度为4个八位字节。
A node receiving a Path message containing an EXPLICIT_ROUTE object must determine the next hop for this path. This is necessary because the next abstract node along the explicit route might be an IP subnet or an Autonomous System. Therefore, selection of this next hop may involve a decision from a set of feasible alternatives. The criteria used to make a selection from feasible alternatives is implementation dependent and can also be impacted by local policy, and is beyond the
接收包含显式路由对象的路径消息的节点必须确定此路径的下一个跃点。这是必要的，因为显式路由上的下一个抽象节点可能是IP子网或自治系统。因此，选择该下一跳可能涉及从一组可行的备选方案中作出决定。用于从可行备选方案中进行选择的标准取决于实施情况，也可能受到当地政策的影响，并且超出了适用范围
scope of this specification. However, it is assumed that each node will make a best effort attempt to determine a loop-free path. Note that paths so determined can be overridden by local policy.
本规范的范围。但是，假设每个节点都会尽最大努力确定无循环路径。请注意，这样确定的路径可以被本地策略覆盖。
To determine the next hop for the path, a node performs the following steps:
要确定路径的下一个跃点，节点将执行以下步骤：
1) The node receiving the RSVP message MUST first evaluate the first subobject. If the node is not part of the abstract node described by the first subobject, it has received the message in error and SHOULD return a "Bad initial subobject" error. If there is no first subobject, the message is also in error and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error.
1) 接收RSVP消息的节点必须首先计算第一个子对象。如果该节点不是第一个子对象描述的抽象节点的一部分，则它已收到错误消息，并应返回“错误的初始子对象”错误。如果没有第一个子对象，则消息也会出错，系统应返回“错误的显式路由对象”错误。
2) If there is no second subobject, this indicates the end of the explicit route. The EXPLICIT_ROUTE object SHOULD be removed from the Path message. This node may or may not be the end of the path. Processing continues with section 4.3.4.2, where a new EXPLICIT_ROUTE object MAY be added to the Path message.
2) 如果没有第二个子对象，则表示显式布线的结束。应该从路径消息中删除显式路由对象。此节点可能是也可能不是路径的终点。处理继续进行第4.3.4.2节，其中可向路径消息添加新的显式路由对象。
3) Next, the node evaluates the second subobject. If the node is also a part of the abstract node described by the second subobject, then the node deletes the first subobject and continues processing with step 2, above. Note that this makes the second subobject into the first subobject of the next iteration and allows the node to identify the next abstract node on the path of the message after possible repeated application(s) of steps 2 and 3.
3) 接下来，节点计算第二个子对象。如果该节点也是由第二个子对象描述的抽象节点的一部分，则该节点将删除第一个子对象，并继续进行上述步骤2的处理。请注意，这将使第二个子对象成为下一次迭代的第一个子对象，并允许节点在可能重复应用步骤2和3后识别消息路径上的下一个抽象节点。
4) Abstract Node Border Case: The node determines whether it is topologically adjacent to the abstract node described by the second subobject. If so, the node selects a particular next hop which is a member of the abstract node. The node then deletes the first subobject and continues processing with section 4.3.4.2.
4) 抽象节点边界情况：节点确定它是否在拓扑上与第二个子对象描述的抽象节点相邻。如果是，则节点选择作为抽象节点成员的特定下一跳。然后，节点删除第一个子对象，并继续按照第4.3.4.2节进行处理。
5) Interior of the Abstract Node Case: Otherwise, the node selects a next hop within the abstract node of the first subobject (which the node belongs to) that is along the path to the abstract node of the second subobject (which is the next abstract node). If no such path exists then there are two cases:
5) 抽象节点案例的内部：否则，节点在第一个子对象（节点所属）的抽象节点内选择下一跳，该跳沿第二个子对象（下一个抽象节点）的抽象节点的路径。如果不存在此类路径，则有两种情况：
5a) If the second subobject is a strict subobject, there is an error and the node SHOULD return a "Bad strict node" error.
5a）如果第二个子对象是严格子对象，则存在错误，并且节点应返回“错误严格节点”错误。
5b) Otherwise, if the second subobject is a loose subobject, the node selects any next hop that is along the path to the next abstract node. If no path exists, there is an error, and the node SHOULD return a "Bad loose node" error.
5b）否则，如果第二个子对象是松散的子对象，则该节点选择沿到下一抽象节点的路径的任何下一跳。如果不存在路径，则存在错误，并且节点应返回“坏的松散节点”错误。
6) Finally, the node replaces the first subobject with any subobject that denotes an abstract node containing the next hop. This is necessary so that when the explicit route is received by the next hop, it will be accepted.
6) 最后，该节点将第一个子对象替换为表示包含下一跳的抽象节点的任何子对象。这是必要的，以便在下一跳接收到显式路由时，它将被接受。
After selecting a next hop, the node MAY alter the explicit route in the following ways.
在选择下一跳之后，节点可以通过以下方式改变显式路由。
If, as part of executing the algorithm in section 4.3.4.1, the
如果作为执行第4.3.4.1节中算法的一部分
EXPLICIT_ROUTE object is removed, the node MAY add a new EXPLICIT_ROUTE object.
移除显式路由对象后，节点可以添加新的显式路由对象。
Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject or MAY replace the first subobject. Each subobject in this series MUST denote an abstract node that is a subset of the current abstract node.
否则，如果节点是第一个子对象的抽象节点的成员，则可以在第一个子对象之前插入一系列子对象，或者替换第一个子对象。此系列中的每个子对象都必须表示作为当前抽象节点子集的抽象节点。
Alternately, if the first subobject is a loose subobject, an arbitrary series of subobjects MAY be inserted prior to the first subobject.
或者，如果第一个子对象是松散的子对象，则可以在第一个子对象之前插入任意系列的子对象。
While the EXPLICIT_ROUTE object is of finite length, the existence of loose nodes implies that it is possible to construct forwarding loops during transients in the underlying routing protocol. This can be detected by the originator of the explicit route through the use of another opaque route object called the RECORD_ROUTE object. The RECORD_ROUTE object is used to collect detailed path information and is useful for loop detection and for diagnostics.
虽然显式路由对象的长度是有限的，但松散节点的存在意味着在底层路由协议的瞬态期间可以构造转发循环。显式路由的发起人可以通过使用另一个不透明路由对象（称为RECORD_route object）来检测到这一点。RECORD_ROUTE对象用于收集详细的路径信息，对环路检测和诊断非常有用。
It is anticipated that new subobjects may be defined over time. A node which encounters an unrecognized subobject during its normal ERO processing sends a PathErr with the error code "Routing Error" and error value of "Bad Explicit Route Object" toward the sender. The EXPLICIT_ROUTE object is included, truncated (on the left) to the offending subobject. The presence of an unrecognized subobject which is not encountered in a node's ERO processing SHOULD be ignored. It is passed forward along with the rest of the remaining ERO stack.
预计随着时间的推移，可能会定义新的子对象。在正常ERO处理过程中遇到无法识别的子对象的节点会向发送方发送一个路径错误，错误代码为“Routing error”，错误值为“Bad Explicit Route Object”。包含显式路由对象，并将其截断（在左侧）到有问题的子对象。应忽略节点ERO处理中未遇到的未识别子对象的存在。它与剩余的ERO堆栈一起向前传递。
An RSVP router that does not recognize the EXPLICIT_ROUTE object sends a PathErr with the error code "Unknown object class" toward the sender. This causes the path setup to fail. The sender should notify management that a LSP cannot be established and possibly take action to continue the reservation without the EXPLICIT_ROUTE or via a different explicit route.
不识别显式路由对象的RSVP路由器向发送方发送错误代码为“Unknown object class”的PathErr。这会导致路径设置失败。发送方应通知管理层无法建立LSP，并可能采取措施在没有显式路由或通过不同显式路由的情况下继续保留。
Routes can be recorded via the RECORD_ROUTE object (RRO). Optionally, labels may also be recorded. The Record Route Class is 21. Currently one C_Type is defined, Type 1 Record Route. The RECORD_ROUTE object has the following format:
可以通过记录路由对象（RRO）记录路由。或者，也可以记录标签。创纪录的航线等级是21级。目前定义了一种C_类型，类型1记录路由。记录路由对象具有以下格式：
Class = 21, C_Type = 1
类别=21，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
子对象
The contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects. The subobjects are defined in section 4.4.1 below.
记录路由对象的内容是一系列称为子对象的可变长度数据项。子对象的定义见下文第4.4.1节。
The RRO can be present in both RSVP Path and Resv messages. If a Path message contains multiple RROs, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated. Similarly, if in a Resv message multiple RROs are encountered following a FILTER_SPEC before another FILTER_SPEC is encountered, only the first RRO is meaningful. Subsequent RROs SHOULD be ignored and SHOULD NOT be propagated.
RRO可以出现在RSVP Path和Resv消息中。如果路径消息包含多个RRO，则只有第一个RRO有意义。应忽略后续RRO，且不应传播。类似地，如果在Resv消息中，在遇到另一个筛选器规范之前，在筛选器规范之后遇到多个RRO，则只有第一个RRO有意义。应忽略后续RRO，且不应传播。
The contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects. Each subobject has its own Length field. The length contains the total length of the subobject in bytes, including the Type and Length fields. The length MUST always be a multiple of 4, and at least 4.
记录路由对象的内容是一系列称为子对象的可变长度数据项。每个子对象都有自己的长度字段。长度包含子对象的总长度（字节），包括类型和长度字段。长度必须始终为4的倍数，且至少为4。
Subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of RRO is considered the top. The last subobject is considered the bottom. When a new subobject is added, it is always added to the top.
子对象被组织为后进先出堆栈。相对于RRO开头的第一个子对象被视为顶部。最后一个子对象被视为底部。添加新子对象时，它始终添加到顶部。
An empty RRO with no subobjects is considered illegal.
没有子对象的空RRO被视为非法。
Three kinds of subobjects are currently defined.
当前定义了三种类型的子对象。
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 | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | 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 | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
0x01 IPv4 address
0x01 IPv4地址
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 8.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为8。
IPv4 address
IPv4地址
A 32-bit unicast, host address. Any network-reachable interface address is allowed here. Illegal addresses, such as certain loopback addresses, SHOULD NOT be used.
32位单播主机地址。此处允许任何网络可访问的接口地址。不应使用非法地址，例如某些环回地址。
Prefix length
前缀长度
32
32
Flags
旗帜
0x01 Local protection available
0x01本地保护可用
Indicates that the link downstream of this node is protected via a local repair mechanism. This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE object of the corresponding Path message.
指示此节点下游的链路通过本地修复机制受到保护。只有在相应路径消息的会话_属性对象中设置了本地保护标志时，才能设置此标志。
0x02 Local protection in use
0x02正在使用的本地保护
Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over).
表示正在使用本地修复机制来维护此隧道（通常在其先前路由的链路中断时）。
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 | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | 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 | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
0x02 IPv6 address
0x02 IPv6地址
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 20.
长度包含子对象的总长度（字节），包括类型和长度字段。长度始终为20。
IPv6 address
IPv6地址
A 128-bit unicast host address.
128位单播主机地址。
Prefix length
前缀长度
128
128
Flags
旗帜
0x01 Local protection available
0x01本地保护可用
Indicates that the link downstream of this node is protected via a local repair mechanism. This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE object of the corresponding Path message.
指示此节点下游的链路通过本地修复机制受到保护。只有在相应路径消息的会话_属性对象中设置了本地保护标志时，才能设置此标志。
0x02 Local protection in use
0x02正在使用的本地保护
Indicates that a local repair mechanism is in use to maintain this tunnel (usually in the face of an outage of the link it was previously routed over).
表示正在使用本地修复机制来维护此隧道（通常在其先前路由的链路中断时）。
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 | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
0x03 Label
0x03标签
Length
长
The Length contains the total length of the subobject in bytes, including the Type and Length fields.
长度包含子对象的总长度（字节），包括类型和长度字段。
Flags
旗帜
0x01 = Global label This flag indicates that the label will be understood if received on any interface.
0x01=全局标签此标志表示如果在任何接口上接收到标签，将理解标签。
C-Type
C型
The C-Type of the included Label Object. Copied from the Label Object.
包含的标签对象的C类型。从标签对象复制。
Contents of Label Object
标签对象的内容
The contents of the Label Object. Copied from the Label Object
标签对象的内容。从标签对象复制
Only the procedures for use in unicast sessions are defined here.
此处仅定义单播会话中使用的过程。
There are three possible uses of RRO in RSVP. First, an RRO can function as a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route. The exact procedure for doing so is described later in this document.
在RSVP中有三种可能的RRO用法。首先，RRO可以作为循环检测机制来发现L3路由循环，或者显式路由中固有的循环。本文档后面将描述执行此操作的确切步骤。
Second, an RRO collects up-to-date detailed path information hop-by-hop about RSVP sessions, providing valuable information to the sender or receiver. Any path change (due to network topology changes) will be reported.
其次，RRO逐跳收集有关RSVP会话的最新详细路径信息，为发送方或接收方提供有价值的信息。将报告任何路径更改（由于网络拓扑更改）。
Third, RRO syntax is designed so that, with minor changes, the whole object can be used as input to the EXPLICIT_ROUTE object. This is useful if the sender receives RRO from the receiver in a Resv message, applies it to EXPLICIT_ROUTE object in the next Path message in order to "pin down session path".
第三，RRO语法的设计使得，只需稍作修改，整个对象就可以作为显式路由对象的输入。如果发送方在Resv消息中从接收方接收到RRO，并将其应用于下一个Path消息中的EXPLICIT_ROUTE对象以“锁定会话路径”，则此选项非常有用。
Typically, a node initiates an RSVP session by adding the RRO to the Path message. The initial RRO contains only one subobject - the sender's IP addresses. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object.
通常，节点通过向路径消息添加RRO来启动RSVP会话。初始RRO仅包含一个子对象-发送方的IP地址。如果节点还需要标签记录，则会在会话属性对象中设置标签记录标志。
When a Path message containing an RRO is received by an intermediate router, the router stores a copy of it in the Path State Block. The RRO is then used in the next Path refresh event for formatting Path messages. When a new Path message is to be sent, the router adds a new subobject to the RRO and appends the resulting RRO to the Path message before transmission.
当中间路由器接收到包含RRO的路径消息时，路由器将其副本存储在路径状态块中。然后在下一个路径刷新事件中使用RRO格式化路径消息。当要发送新的路径消息时，路由器向RRO添加新的子对象，并在传输之前将结果RRO附加到路径消息。
The newly added subobject MUST be this router's IP address. The address to be added SHOULD be the interface address of the outgoing Path messages. If there are multiple addresses to choose from, the decision is a local matter. However, it is RECOMMENDED that the same address be chosen consistently.
新添加的子对象必须是此路由器的IP地址。要添加的地址应该是传出路径消息的接口地址。如果有多个地址可供选择，则决策是本地事务。但是，建议始终如一地选择相同的地址。
When the Label_Recording flag is set in the SESSION_ATTRIBUTE object, nodes doing route recording SHOULD include a Label Record subobject. If the node is using a global label space, then it SHOULD set the Global Label flag.
在SESSION_属性对象中设置Label_Recording标志时，执行路由记录的节点应包括Label Record子对象。如果节点使用全局标签空间，则应设置全局标签标志。
The Label Record subobject is pushed onto the RECORD_ROUTE object prior to pushing on the node's IP address. A node MUST NOT push on a Label Record subobject without also pushing on an IPv4 or IPv6 subobject.
在推送节点的IP地址之前，标签记录子对象被推送到记录路由对象上。如果不同时推送IPv4或IPv6子对象，则节点不得推送标签记录子对象。
Note that on receipt of the initial Path message, a node is unlikely to have a label to include. Once a label is obtained, the node SHOULD include the label in the RRO in the next Path refresh event.
请注意，在收到初始路径消息时，节点不太可能包含标签。获得标签后，节点应在下一个路径刷新事件中将标签包括在RRO中。
If the newly added subobject causes the RRO to be too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message and message processing continues as normal. A PathErr (or
如果新添加的子对象导致RRO太大，无法放入Path（或Resv）消息中，则应从消息中删除RRO对象，并继续正常处理消息。探路者
ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RRO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RRO notification".
ResvErr）消息应发送回发送方（或接收方）。使用错误代码“Notify”和错误值“RRO对于MTU太大”。如果接收者收到这样的回复，它应该发送一条PathErr消息，错误代码为“Notify”，错误值为“RRO notification”。
A sender receiving either of these error values SHOULD remove the RRO from the Path message.
收到这些错误值之一的发送方应从路径消息中删除RRO。
Nodes SHOULD resend the above PathErr or ResvErr message each n seconds where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent.
节点应每n秒重新发送上述PathErr或ResvErr消息，其中n是15和相关路径或RESV消息的刷新间隔中的较大值。节点可以应用限制和/或回退定时器来限制发送的消息的数量。
An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router changes or if this RRO is newly added to (or deleted from) the Path message.
如果下一条路径消息中的RRO与上一条不同，RSVP路由器可以在刷新时间之前决定发送路径消息。如果从上一跳路由器接收到的RRO的内容发生更改，或者如果此RRO是新添加到（或从）Path消息中删除的，则可能发生这种情况。
When the destination node of an RSVP session receives a Path message with an RRO, this indicates that the sender node needs route recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages. The only difference is that the RRO in a Resv message records the path information in the reverse direction.
当RSVP会话的目标节点接收到带有RRO的Path消息时，这表示发送方节点需要路由记录。目标节点通过向Resv消息添加RRO来启动RRO进程。处理镜像路径消息的处理。唯一的区别是Resv消息中的RRO以相反的方向记录路径信息。
Note that each node along the path will now have the complete route from source to destination. The Path RRO will have the route from the source to this node; the Resv RRO will have the route from this node to the destination. This is useful for network management.
请注意，路径上的每个节点现在都具有从源到目标的完整路由。路径RRO将具有从源到该节点的路由；Resv RRO将具有从此节点到目标的路由。这对网络管理很有用。
A received Path message without an RRO indicates that the sender node no longer needs route recording. Subsequent Resv messages SHALL NOT contain an RRO.
接收到的不带RRO的路径消息表示发送方节点不再需要路由记录。后续Resv消息不得包含RRO。
As part of processing an incoming RRO, an intermediate router looks into all subobjects contained within the RRO. If the router determines that it is already in the list, a forwarding loop exists.
作为处理传入RRO的一部分，中间路由器会查看RRO中包含的所有子对象。如果路由器确定它已经在列表中，则存在转发循环。
An RSVP session is loop-free if downstream nodes receive Path messages or upstream nodes receive Resv messages with no routing loops detected in the contained RRO.
如果下游节点接收到路径消息，或者上游节点接收到Resv消息，并且在包含的RRO中未检测到路由循环，则RSVP会话是无循环的。
There are two broad classifications of forwarding loops. The first class is the transient loop, which occurs as a normal part of operations as L3 routing tries to converge on a consistent forwarding path for all destinations. The second class of forwarding loop is the permanent loop, which normally results from network mis-configuration.
转发循环有两大类。第一类是瞬态循环，它作为正常操作的一部分出现，因为L3路由尝试在所有目的地的一致转发路径上收敛。第二类转发循环是永久性循环，这通常是由于网络配置不当造成的。
The action performed by a node on receipt of an RRO depends on the message type in which the RRO is received.
节点在收到RRO时执行的操作取决于接收RRO的消息类型。
For Path messages containing a forwarding loop, the router builds and sends a "Routing problem" PathErr message, with the error value "loop detected," and drops the Path message. Until the loop is eliminated, this session is not suitable for forwarding data packets. How the loop eliminated is beyond the scope of this document.
对于包含转发循环的路径消息，路由器构建并发送“路由问题”PathErr消息，错误值为“loop detected”，并丢弃路径消息。在消除循环之前，此会话不适合转发数据包。如何消除循环超出了本文档的范围。
For Resv messages containing a forwarding loop, the router simply drops the message. Resv messages should not loop if Path messages do not loop.
对于包含转发循环的Resv消息，路由器只需丢弃该消息。如果路径消息不循环，则Resv消息不应循环。
New subobjects may be defined for the RRO. When processing an RRO, unrecognized subobjects SHOULD be ignored and passed on. When processing an RRO for loop detection, a node SHOULD parse over any unrecognized objects. Loop detection works by detecting subobjects which were inserted by the node itself on an earlier pass of the object. This ensures that the subobjects necessary for loop detection are always understood.
可以为RRO定义新的子对象。处理RRO时，应忽略并传递未识别的子对象。在处理用于循环检测的RRO时，节点应解析任何无法识别的对象。循环检测的工作原理是检测在对象的早期过程中由节点本身插入的子对象。这样可以确保始终了解循环检测所需的子对象。
The RRO object is to be used only when all routers along the path support RSVP and the RRO object. The RRO object is assigned a class value of the form 0bbbbbbb. RSVP routers that do not support the object will therefore respond with an "Unknown Object Class" error.
只有当路径上的所有路由器都支持RSVP和RRO对象时，才能使用RRO对象。为RRO对象分配了一个0bbb形式的类值。因此，不支持对象的RSVP路由器将响应“未知对象类”错误。
In the processing described above, certain errors must be reported as either a "Routing Problem" or "Notify". The value of the "Routing Problem" error code is 24; the value of the "Notify" error code is 25.
在上述处理过程中，某些错误必须报告为“路由问题”或“通知”。“路由问题”错误代码的值为24；“通知”错误代码的值为25。
The following defines error values for the Routing Problem Error Code:
以下定义路由问题错误代码的错误值：
Value Error:
值错误：
1 Bad EXPLICIT_ROUTE object
1错误的显式路由对象
2 Bad strict node
2坏严格节点
3 Bad loose node
3不良松动节点
4 Bad initial subobject
4错误的初始子对象
5 No route available toward destination
5没有通往目的地的路线
6 Unacceptable label value
6不可接受的标签值
7 RRO indicated routing loops
7个RRO指示的路由环路
8 MPLS being negotiated, but a non-RSVP-capable router stands in the path
正在协商8个MPL，但路径中有一个不支持RSVP的路由器
9 MPLS label allocation failure
9 MPLS标签分配失败
10 Unsupported L3PID
10不受支持的L3PID
For the Notify Error Code, the 16 bits of the Error Value field are:
对于Notify错误代码，错误值字段的16位为：
ss00 cccc cccc cccc
ss00中交
The high order bits are as defined under Error Code 1. (See [1]).
高阶位的定义见错误代码1。（见[1]）。
When ss = 00, the following subcodes are defined:
当ss=00时，定义以下子代码：
1 RRO too large for MTU
1个RRO对于MTU太大
2 RRO notification
2错误通知
3 Tunnel locally repaired
3隧道局部修复
New C-Types are defined for the SESSION, SENDER_TEMPLATE and FILTER_SPEC objects.
为会话、发件人模板和筛选器规范对象定义了新的C类型。
The LSP_TUNNEL objects have the following format:
LSP_隧道对象具有以下格式：
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
类=会话，LSP\U隧道\U IPv4 C-Type=7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
IPv4隧道端点地址
IPv4 address of the egress node for the tunnel.
隧道出口节点的IPv4地址。
Tunnel ID
隧道ID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
会话中使用的16位标识符，在隧道的整个生命周期内保持不变。
Extended Tunnel ID
扩展隧道ID
A 32-bit identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv4 address here as a globally unique identifier.
会话中使用的32位标识符，在隧道的整个生命周期内保持不变。通常设置为全零。希望将会话范围缩小到入口-出口对的入口节点可将其IPv4地址作为全局唯一标识符放置在此处。
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
类=会话，LSP_隧道_IPv6C_类型=8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel end point address
IPv6隧道端点地址
IPv6 address of the egress node for the tunnel.
隧道出口节点的IPv6地址。
Tunnel ID
隧道ID
A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel.
会话中使用的16位标识符，在隧道的整个生命周期内保持不变。
Extended Tunnel ID
扩展隧道ID
A 16-byte identifier used in the SESSION that remains constant over the life of the tunnel. Normally set to all zeros. Ingress nodes that wish to narrow the scope of a SESSION to the ingress-egress pair may place their IPv6 address here as a globally unique identifier.
会话中使用的16字节标识符，在隧道的整个生命周期内保持不变。通常设置为全零。希望将会话范围缩小到入口-出口对的入口节点可将其IPv6地址作为全局唯一标识符放置在此处。
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
类=发送方\模板，LSP\隧道\ IPv4 C-Type=7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
IPv4隧道发送方地址
IPv4 address for a sender node
发送方节点的IPv4地址
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.
发送方模板和筛选器规范中使用的16位标识符，可以更改以允许发送方与其自身共享资源。
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
类=发送方\模板，LSP\隧道\ IPv6 C\类型=8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
IPv6隧道发送方地址
IPv6 address for a sender node
发送方节点的IPv6地址
LSP ID
LSP ID
A 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself.
发送方模板和筛选器规范中使用的16位标识符，可以更改以允许发送方与其自身共享资源。
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
类=筛选器规范，LSP_隧道_IPv4 C-Type=7
The format of the LSP_TUNNEL_IPv4 FILTER_SPEC object is identical to the LSP_TUNNEL_IPv4 SENDER_TEMPLATE object.
LSP_TUNNEL_IPv4 FILTER_SPEC对象的格式与LSP_TUNNEL_IPv4 SENDER_TEMPLATE对象的格式相同。
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
类=筛选器规范，LSP_隧道_IPv6 C_类型=8
The format of the LSP_TUNNEL_IPv6 FILTER_SPEC object is identical to the LSP_TUNNEL_IPv6 SENDER_TEMPLATE object.
LSP_TUNNEL_IPv6 FILTER_SPEC对象的格式与LSP_TUNNEL_IPv6 SENDER_TEMPLATE对象的格式相同。
This section describes how to setup a tunnel that is capable of maintaining resource reservations (without double counting) while it is being rerouted or while it is attempting to increase its bandwidth. In the initial Path message, the ingress node forms a SESSION object, assigns a Tunnel_ID, and places its IPv4 address in the Extended_Tunnel_ID. It also forms a SENDER_TEMPLATE and assigns a LSP_ID. Tunnel setup then proceeds according to the normal procedure.
本节介绍如何设置一个隧道，该隧道能够在重新路由或试图增加带宽时维护资源保留（无重复计数）。在初始路径消息中，入口节点形成一个会话对象，分配一个隧道ID，并将其IPv4地址放入扩展的隧道ID中。它还形成一个发送方模板并分配一个LSP ID。然后，隧道设置将按照正常过程进行。
On receipt of the Path message, the egress node sends a Resv message with the STYLE Shared Explicit toward the ingress node.
在接收到路径消息时，出口节点向入口节点发送具有显式共享样式的Resv消息。
When an ingress node with an established path wants to change that path, it forms a new Path message as follows. The existing SESSION object is used. In particular the Tunnel_ID and Extended_Tunnel_ID are unchanged. The ingress node picks a new LSP_ID to form a new SENDER_TEMPLATE. It creates an EXPLICIT_ROUTE object for the new route. The new Path message is sent. The ingress node refreshes both the old and new path messages.
当具有已建立路径的入口节点想要更改该路径时，它将形成一条新的路径消息，如下所示。使用现有会话对象。特别是隧道ID和扩展隧道ID保持不变。入口节点选择一个新的LSP_ID以形成一个新的发送方_模板。它为新路由创建一个显式的路由对象。将发送新路径消息。入口节点刷新旧路径消息和新路径消息。
The egress node responds with a Resv message with an SE flow descriptor formatted as:
出口节点响应一条Resv消息，其中SE流描述符的格式为：
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>
(Note that if the PHOPs are different, then two messages are sent each with the appropriate FILTER_SPEC and LABEL_OBJECT.)
（请注意，如果PHOP不同，则会发送两条消息，每条消息都带有相应的过滤器规格和标签对象。）
When the ingress node receives the Resv Message(s), it may begin using the new route. It SHOULD send a PathTear message for the old route.
当入口节点接收到Resv消息时，它可以开始使用新路由。它应该为旧路由发送PathTear消息。
The Session Attribute Class is 207. Two C_Types are defined, LSP_TUNNEL, C-Type = 7 and LSP_TUNNEL_RA, C-Type = 1. The LSP_TUNNEL_RA C-Type includes all the same fields as the LSP_TUNNEL C-Type. Additionally it carries resource affinity information. The formats are as follows:
会话属性类是207。定义了两种C_类型：LSP_TUNNEL，C-Type=7和LSP_TUNNEL_RA，C-Type=1。LSP_TUNNEL_RA C-Type包含与LSP_TUNNEL C-Type相同的所有字段。此外，它还携带资源关联信息。格式如下：
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
会话_属性类=207，LSP_隧道C型=7
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
设置优先级
The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
会话在获取资源方面的优先级，范围为0到7。值0是最高优先级。设置优先级用于决定此会话是否可以抢占另一个会话。
Holding Priority
持有优先权
The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
会话在保留资源方面的优先级，范围为0到7。值0是最高优先级。保持优先级用于决定此会话是否可以被另一个会话抢占。
Flags
旗帜
0x01 Local protection desired
0x01需要本地保护
This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration.
此标志允许传输路由器使用可能导致违反显式路由对象的本地修复机制。当在相邻的下游链路或节点上检测到故障时，传输路由器可以重新路由流量，以快速恢复服务。
0x02 Label recording desired
0x02需要标签记录
This flag indicates that label information should be included when doing a route record.
此标志表示在进行路线记录时应包括标签信息。
0x04 SE Style desired
需要0x04 SE样式
This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message.
此标志表示隧道入口节点可以选择重新路由此隧道，而无需将其拆除。隧道出口节点在响应Resv消息时应使用SE样式。
Name Length
名称长度
The length of the display string before padding, in bytes.
填充前显示字符串的长度，以字节为单位。
Session Name
会话名称
A null padded string of characters.
填充为空的字符串。
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
会话属性类=207，LSP隧道类型=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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
排除任何
A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link unacceptable.
一个32位向量，表示一组与隧道相关联的属性过滤器，其中任何一个都会导致链路不可接受。
Include-any
包括任何
A 32-bit vector representing a set of attribute filters associated with a tunnel any of which renders a link acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
一个32位向量，表示一组与隧道相关联的属性过滤器，其中任何一个都使链接可接受（关于此测试）。空集（所有位均设置为零）自动传递。
Include-all
包括所有
A 32-bit vector representing a set of attribute filters associated with a tunnel all of which must be present for a link to be acceptable (with respect to this test). A null set (all bits set to zero) automatically passes.
一个32位向量，表示一组与隧道相关联的属性过滤器，所有这些过滤器都必须存在，链接才能被接受（就本测试而言）。空集（所有位均设置为零）自动传递。
Setup Priority
设置优先级
The priority of the session with respect to taking resources, in the range of 0 to 7. The value 0 is the highest priority. The Setup Priority is used in deciding whether this session can preempt another session.
会话在获取资源方面的优先级，范围为0到7。值0是最高优先级。设置优先级用于决定此会话是否可以抢占另一个会话。
Holding Priority
持有优先权
The priority of the session with respect to holding resources, in the range of 0 to 7. The value 0 is the highest priority. Holding Priority is used in deciding whether this session can be preempted by another session.
会话在保留资源方面的优先级，范围为0到7。值0是最高优先级。保持优先级用于决定此会话是否可以被另一个会话抢占。
Flags
旗帜
0x01 Local protection desired
0x01需要本地保护
This flag permits transit routers to use a local repair mechanism which may result in violation of the explicit route object. When a fault is detected on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration.
此标志允许传输路由器使用可能导致违反显式路由对象的本地修复机制。当在相邻的下游链路或节点上检测到故障时，传输路由器可以重新路由流量，以快速恢复服务。
0x02 Label recording desired
0x02需要标签记录
This flag indicates that label information should be included when doing a route record.
此标志表示在进行路线记录时应包括标签信息。
0x04 SE Style desired
需要0x04 SE样式
This flag indicates that the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message.
此标志表示隧道入口节点可以选择重新路由此隧道，而无需将其拆除。隧道出口节点在响应Resv消息时应使用SE样式。
Name Length
名称长度
The length of the display string before padding, in bytes.
填充前显示字符串的长度，以字节为单位。
Session Name
会话名称
A null padded string of characters.
填充为空的字符串。
The support of setup and holding priorities is OPTIONAL. A node can recognize this information but be unable to perform the requested operation. The node SHOULD pass the information downstream unchanged.
设置和保持优先级的支持是可选的。节点可以识别此信息，但无法执行请求的操作。节点应将信息传递到下游，保持不变。
As noted above, preemption is implemented by two priorities. The Setup Priority is the priority for taking resources. The Holding Priority is the priority for holding a resource. Specifically, the
如上所述，抢占由两个优先级实现。设置优先级是获取资源的优先级。保持优先级是保持资源的优先级。具体来说
Holding Priority is the priority at which resources assigned to this session will be reserved. The Setup Priority SHOULD never be higher than the Holding Priority for a given session.
Holding Priority是分配给此会话的资源将被保留的优先级。设置优先级不得高于给定会话的保持优先级。
The setup and holding priorities are directly analogous to the preemption and defending priorities as defined in [9]. While the interaction of these two objects is ultimately a matter of policy, the following default interaction is RECOMMENDED.
设置和持有优先级直接类似于[9]中定义的抢占和防御优先级。虽然这两个对象的交互最终是策略问题，但建议使用以下默认交互。
When both objects are present, the preemption priority policy element is used. A mapping between the priority spaces is defined as follows. A session attribute priority S is mapped to a preemption priority P by the formula P = 2^(14-2S). The reverse mapping is shown in the following table.
当两个对象都存在时，将使用抢占优先级策略元素。优先级空间之间的映射定义如下。会话属性priority S通过公式P=2^（14-2S）映射到抢占优先级P。下表显示了反向映射。
Preemption Priority Session Attribute Priority
抢占优先级会话属性优先级
0 - 3 7 4 - 15 6 16 - 63 5 64 - 255 4 256 - 1023 3 1024 - 4095 2 4096 - 16383 1 16384 - 65535 0
0 - 3 7 4 - 15 6 16 - 63 5 64 - 255 4 256 - 1023 3 1024 - 4095 2 4096 - 16383 1 16384 - 65535 0
When a new Path message is considered for admission, the bandwidth requested is compared with the bandwidth available at the priority specified in the Setup Priority.
当考虑接纳新路径消息时，将请求的带宽与设置优先级中指定的优先级下的可用带宽进行比较。
If the requested bandwidth is not available a PathErr message is returned with an Error Code of 01, Admission Control Failure, and an Error Value of 0x0002. The first 0 in the Error Value indicates a globally defined subcode and is not informational. The 002 indicates "requested bandwidth unavailable".
如果请求的带宽不可用，则返回PathErr消息，错误代码为01，准入控制失败，错误值为0x0002。错误值中的第一个0表示全局定义的子代码，不是信息性的。002表示“请求的带宽不可用”。
If the requested bandwidth is less than the unused bandwidth then processing is complete. If the requested bandwidth is available, but is in use by lower priority sessions, then lower priority sessions (beginning with the lowest priority) MAY be preempted to free the necessary bandwidth.
如果请求的带宽小于未使用的带宽，则处理完成。如果请求的带宽可用，但被低优先级会话使用，则低优先级会话（从最低优先级开始）可能被抢占以释放必要的带宽。
When preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, passing a subcode that indicates the reason. A ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders.
当支持抢占时，每个抢占保留都会触发对本地客户端的TC_Preempt（）upcall，并传递一个子代码来指示原因。应向下游接收方和上游发送方发送代码为“策略控制失败”的ResvErr和/或PathErr。
The support of local-protection is OPTIONAL. A node may recognize the local-protection Flag but may be unable to perform the requested operation. In this case, the node SHOULD pass the information downstream unchanged.
本地保护的支持是可选的。节点可以识别本地保护标志，但可能无法执行请求的操作。在这种情况下，节点应该将信息不加更改地传递给下游。
The recording of the Label subobject in the ROUTE_RECORD object is controlled by the label-recording-desired flag in the SESSION_ATTRIBUTE object. Since the Label subobject is not needed for all applications, it is not automatically recorded. The flag allows applications to request this only when needed.
ROUTE_RECORD对象中标签子对象的录制由SESSION_属性对象中的标签录制所需标志控制。由于并非所有应用程序都需要标签子对象，因此不会自动记录它。该标志允许应用程序仅在需要时请求此操作。
The contents of the Session Name field are a string, typically of display-able characters. The Length MUST always be a multiple of 4 and MUST be at least 8. For an object length that is not a multiple of 4, the object is padded with trailing NULL characters. The Name Length field contains the actual string length.
会话名称字段的内容是一个字符串，通常为可显示字符。长度必须始终为4的倍数，并且必须至少为8。对于长度不是4的倍数的对象，该对象将用尾随的空字符填充。“名称长度”字段包含实际字符串长度。
Resource classes and resource class affinities are described in [3]. In this document we use the briefer term resource affinities for the latter term. Resource classes can be associated with links and advertised in routing protocols. Resource class affinities are used by RSVP in two ways. In order to be validated a link MUST pass the three tests below. If the test fails a PathErr with the code "policy control failure" SHOULD be sent.
[3]中描述了资源类和资源类亲缘关系。在本文档中，我们使用更简短的术语资源亲缘关系来表示后一个术语。资源类可以与链接关联，并在路由协议中公布。资源类亲缘关系由RSVP以两种方式使用。为了进行验证，链接必须通过以下三项测试。如果测试失败，则应发送代码为“策略控制失败”的PathErr。
When a new reservation is considered for admission over a strict node in an ERO, a node MAY validate the resource affinities with the resource classes of that link. When a node is choosing links in order to extend a loose node of an ERO, the node MUST validate the resource classes of those links against the resource affinities. If no acceptable links can be found to extend the ERO, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination".
当考虑通过ERO中的严格节点接纳新预约时，节点可验证与该链路的资源类的资源亲缘关系。当节点选择链接以扩展ERO的松散节点时，该节点必须根据资源亲缘关系验证这些链接的资源类。如果找不到可接受的链接来扩展ERO，则节点应发送一条PathErr消息，错误代码为“路由问题”，错误值为“没有通向目的地的可用路由”。
In order to be validated a link MUST pass the following three tests.
为了进行验证，链接必须通过以下三个测试。
To precisely describe the tests use the definitions in the object description above. We also define
要精确描述测试，请使用上述对象描述中的定义。我们还定义了
Link-attr A 32-bit vector representing attributes associated with a link.
Link attr表示与链接关联的属性的32位向量。
The three tests are
这三项测试是：
1. Exclude-any
1. 排除任何
This test excludes a link from consideration if the link carries any of the attributes in the set.
如果链接包含集合中的任何属性，则此测试不考虑该链接。
(link-attr & exclude-any) == 0
（链接属性和排除任何项）==0
2. Include-any
2. 包括任何
This test accepts a link if the link carries any of the attributes in the set.
如果链接包含集合中的任何属性，则此测试接受链接。
(include-any == 0) | ((link-attr & include-any) != 0)
(include-any == 0) | ((link-attr & include-any) != 0)
3. Include-all
3. 包括所有
This test accepts a link only if the link carries all of the attributes in the set.
此测试仅当链接包含集合中的所有属性时才接受链接。
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)
For a link to be acceptable, all three tests MUST pass. If the test fails, the node SHOULD send a PathErr message with an error code of "Routing Problem" and an error value of "no route available toward destination".
为了使链接可接受，所有三个测试都必须通过。如果测试失败，节点应发送一条PathErr消息，错误代码为“Routing Problem”，错误值为“no route available to destination”。
If a Path message contains multiple SESSION_ATTRIBUTE objects, only the first SESSION_ATTRIBUTE object is meaningful. Subsequent SESSION_ATTRIBUTE objects can be ignored and need not be forwarded.
如果路径消息包含多个会话_属性对象，则只有第一个会话_属性对象有意义。后续会话_属性对象可以忽略，无需转发。
All RSVP routers, whether they support the SESSION_ATTRIBUTE object or not, SHALL forward the object unmodified. The presence of non-RSVP routers anywhere between senders and receivers has no impact on this object.
所有RSVP路由器，无论是否支持SESSION_属性对象，都应转发未修改的对象。发送方和接收方之间的任何非RSVP路由器的存在对该对象没有影响。
The RSVP Hello extension enables RSVP nodes to detect when a neighboring node is not reachable. The mechanism provides node to node failure detection. When such a failure is detected it is handled much the same as a link layer communication failure. This mechanism is intended to be used when notification of link layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection.
RSVP Hello扩展使RSVP节点能够在无法访问相邻节点时进行检测。该机制提供节点到节点的故障检测。当检测到此类故障时，其处理方式与链路层通信故障大致相同。当链路层故障通知不可用且未使用未编号的链路时，或当链路层提供的故障检测机制不足以及时检测节点故障时，可使用此机制。
It should be noted that node failure detection is not the same as a link failure detection mechanism, particularly in the case of multiple parallel unnumbered links.
应该注意的是，节点故障检测与链路故障检测机制不同，特别是在多个并行未编号链路的情况下。
The Hello extension is specifically designed so that one side can use the mechanism while the other side does not. Neighbor failure detection may be initiated at any time. This includes when neighbors first learn about each other, or just when neighbors are sharing Resv or Path state.
Hello扩展是专门设计的，以便一方可以使用该机制，而另一方不能。邻居故障检测可随时启动。这包括邻居第一次相互了解的时间，或者邻居共享Resv或路径状态的时间。
The Hello extension is composed of a Hello message, a HELLO REQUEST object and a HELLO ACK object. Hello processing between two neighbors supports independent selection of, typically configured, failure detection intervals. Each neighbor can autonomously issue HELLO REQUEST objects. Each request is answered by an acknowledgment. Hello Messages also contain enough information so that one neighbor can suppress issuing hello requests and still perform neighbor failure detection. A Hello message may be included as a sub-message within a bundle message.
Hello扩展由Hello消息、Hello请求对象和Hello ACK对象组成。两个邻居之间的Hello处理支持独立选择（通常配置）故障检测间隔。每个邻居都可以自主地发出HELLO请求对象。每个请求都会得到确认。Hello消息还包含足够的信息，因此一个邻居可以抑制发出Hello请求，并且仍然执行邻居故障检测。Hello消息可以作为子消息包含在捆绑消息中。
Neighbor failure detection is accomplished by collecting and storing a neighbor's "instance" value. If a change in value is seen or if the neighbor is not properly reporting the locally advertised value, then the neighbor is presumed to have reset. When a neighbor's value is seen to change or when communication is lost with a neighbor, then the instance value advertised to that neighbor is also changed. The HELLO objects provide a mechanism for polling for and providing an instance value. A poll request also includes the sender's instance value. This allows the receiver of a poll to optionally treat the poll as an implicit poll response. This optional handling is an optimization that can reduce the total number of polls and responses processed by a pair of neighbors. In all cases, when both sides support the optimization the result will be only one set of polls and responses per failure detection interval. Depending on selected intervals, the same benefit can occur even when only one neighbor supports the optimization.
邻居故障检测是通过收集和存储邻居的“实例”值来完成的。如果发现值发生变化，或者邻居未正确报告本地公布的值，则假定邻居已重置。当发现邻居的值发生变化或与邻居的通信中断时，向该邻居播发的实例值也会发生变化。HELLO对象提供了轮询和提供实例值的机制。轮询请求还包括发送方的实例值。这允许轮询的接收者选择性地将轮询视为隐式轮询响应。此可选处理是一种优化，可以减少一对邻居处理的轮询和响应总数。在所有情况下，当双方都支持优化时，每个故障检测间隔的结果将只有一组轮询和响应。根据选定的时间间隔，即使只有一个邻居支持优化，也可以获得相同的好处。
Hello Messages are always sent between two RSVP neighbors. The IP source address is the IP address of the sending node. The IP destination address is the IP address of the neighbor node.
Hello消息始终在两个RSVP邻居之间发送。IP源地址是发送节点的IP地址。IP目标地址是邻居节点的IP地址。
The HELLO mechanism is intended for use between immediate neighbors. When HELLO messages are being the exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1.
HELLO机制用于直接邻居之间。当直接邻居之间交换HELLO消息时，所有传出HELLO消息的IP TTL字段应设置为1。
The Hello message has a Msg Type of 20. The Hello message format is as follows:
Hello消息的消息类型为20。Hello消息格式如下所示：
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
The HELLO Class is 22. There are two C_Types defined.
你好班是22号。定义了两种C_类型。
Class = HELLO Class, C_Type = 1
类=你好类，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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Class = HELLO Class, C_Type = 2
类=你好类，C_类型=2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance: 32 bits
Src_实例：32位
a 32 bit value that represents the sender's instance. The advertiser maintains a per neighbor representation/value. This value MUST change when the sender is reset, when the node reboots, or when communication is lost to the neighboring node and otherwise remains the same. This field MUST NOT be set to zero (0).
表示发送方实例的32位值。广告客户维护每个邻居的表示/值。当发送方重置、节点重新启动或与相邻节点失去通信时，此值必须更改，否则保持不变。此字段不能设置为零（0）。
Dst_Instance: 32 bits
Dst_实例：32位
The most recently received Src_Instance value received from the neighbor. This field MUST be set to zero (0) when no value has ever been seen from the neighbor.
最近从邻居接收的Src_实例值。当从未从邻居处看到任何值时，此字段必须设置为零（0）。
The Hello Message is completely OPTIONAL. All messages may be ignored by nodes which do not wish to participate in Hello message processing. The balance of this section is written assuming that the receiver as well as the sender is participating. In particular, the use of MUST and SHOULD with respect to the receiver applies only to a node that supports Hello message processing.
Hello消息是完全可选的。不希望参与Hello消息处理的节点可能会忽略所有消息。本节的剩余部分是在假定接收方和发送方都参与的情况下编写的。特别地，对于接收器必须和应该的使用仅适用于支持Hello消息处理的节点。
A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor who's status is being tracked. The periodicity is governed by the hello_interval. This value MAY be configured on a per neighbor basis. The default value is 5 ms.
节点周期性地生成一条Hello消息，其中包含跟踪其状态的每个邻居的Hello请求对象。周期性由hello_间隔控制。该值可以按每个邻居配置。默认值为5毫秒。
When generating a message containing a HELLO REQUEST object, the sender fills in the Src_Instance field with a value representing it's per neighbor instance. This value MUST NOT change while the agent is exchanging Hellos with the corresponding neighbor. The sender also fills in the Dst_Instance field with the Src_Instance value most recently received from the neighbor. For reference, call this variable Neighbor_Src_Instance. If no value has ever been received from the neighbor or this node considers communication to the neighbor to have been lost, the Neighbor_Src_Instance is set to zero (0). The generation of a message SHOULD be suppressed when a HELLO REQUEST object was received from the destination node within the prior hello_interval interval.
当生成包含HELLO请求对象的消息时，发送方用表示每个邻居实例的值填充Src_实例字段。当代理与相应的邻居交换hello时，此值不得更改。发送方还使用最近从邻居收到的Src_实例值填充Dst_实例字段。作为参考，将此变量称为Neighbor_Src_Instance。如果从未从邻居收到任何值，或者此节点认为与邻居的通信已丢失，则邻居_Src_实例将设置为零（0）。当在之前的HELLO_间隔内从目标节点接收到HELLO请求对象时，应抑制消息的生成。
On receipt of a message containing a HELLO REQUEST object, the receiver MUST generate a Hello message containing a HELLO ACK object. The receiver SHOULD also verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost.
在接收到包含HELLO请求对象的消息时，接收方必须生成包含HELLO ACK对象的HELLO消息。接收器还应验证邻居未重置。这是通过将发送方的Src_实例字段值与以前接收到的值进行比较来实现的。如果Neighbor_Src_实例值为零，且Src_实例字段为非零，则将使用新值更新Neighbor_Src_实例。如果值不同或Src_Instance字段为零，则节点必须将邻居视为通信已丢失。
The receiver of a HELLO REQUEST object SHOULD also verify that the neighbor is reflecting back the receiver's Instance value. This is done by comparing the received Dst_Instance field with the Src_Instance field value most recently transmitted to that neighbor. If the neighbor continues to advertise a wrong non-zero value after a configured number of intervals, then the node MUST treat the neighbor as if communication has been lost.
HELLO请求对象的接收者还应该验证邻居是否反射了接收者的实例值。这是通过比较接收到的Dst_实例字段与最近传输到该邻居的Src_实例字段值来实现的。如果邻居在配置的间隔数之后继续播发错误的非零值，则节点必须将邻居视为通信已丢失。
On receipt of a message containing a HELLO ACK object, the receiver MUST verify that the neighbor has not reset. This is done by comparing the sender's Src_Instance field value with the previously
在接收到包含HELLO ACK对象的消息时，接收方必须验证邻居没有重置。这是通过将发送方的Src_实例字段值与之前的值进行比较来实现的
received value. If the Neighbor_Src_Instance value is zero, and the Src_Instance field is non-zero, the Neighbor_Src_Instance is updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost.
收到的价值。如果Neighbor_Src_实例值为零，且Src_实例字段为非零，则将使用新值更新Neighbor_Src_实例。如果值不同或Src_Instance字段为零，则节点必须将邻居视为通信已丢失。
The receiver of a HELLO ACK object MUST also verify that the neighbor is reflecting back the receiver's Instance value. If the neighbor advertises a wrong value in the Dst_Instance field, then a node MUST treat the neighbor as if communication has been lost.
HELLO ACK对象的接收方还必须验证邻居是否正在反射接收方的实例值。如果邻居在Dst_实例字段中播发了错误的值，则节点必须将邻居视为通信已丢失。
If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it cannot communicate with the neighbor. The default for this number is 3.5.
如果在配置的hello_间隔内没有通过请求或ACK对象从邻居接收到实例值，则节点必须假定它无法与邻居通信。此数字的默认值为3.5。
When communication is lost or presumed to be lost as described above, a node MAY re-initiate HELLOs. If a node does re-initiate it MUST use a Src_Instance value different than the one advertised in the previous HELLO message. This new value MUST continue to be advertised to the corresponding neighbor until a reset or reboot occurs, or until another communication failure is detected. If a new instance value has not been received from the neighbor, then the node MUST advertise zero in the Dst_instance value field.
当如上所述通信丢失或假定丢失时，节点可以重新发起hello。如果节点确实重新启动，则它必须使用不同于上一条HELLO消息中公布的Src_实例值。在重置或重新启动之前，或者在检测到另一个通信故障之前，必须继续向相应的邻居播发此新值。如果尚未从邻居接收到新实例值，则节点必须在Dst_实例值字段中公布零。
As previously noted, the Hello extension is targeted at detecting node failures not per link failures. When there is only one link between neighboring nodes or when all links between a pair of nodes fail, the distinction between node and link failures is not really meaningful and handling of such failures has already been covered. When there are multiple links shared between neighbors, there are special considerations. When the links between neighbors are numbered, then Hellos MUST be run on each link and the previously described mechanisms apply.
如前所述，Hello扩展的目标是检测节点故障，而不是每链路故障。当相邻节点之间只有一条链路或一对节点之间的所有链路发生故障时，节点和链路故障之间的区别实际上没有意义，并且已经讨论了此类故障的处理。当邻居之间共享多个链路时，需要特别考虑。当邻居之间的链接编号时，必须在每个链接上运行Hellos，并且前面描述的机制适用。
When the links are unnumbered, link failure detection MUST be provided by some means other than Hellos. Each node SHOULD use a single Hello exchange with the neighbor. The case where all links have failed, is the same as the no received value case mentioned in the previous section.
当链路未编号时，必须通过Hellos以外的方法提供链路故障检测。每个节点都应该与邻居使用一个Hello交换。所有链接都失败的情况与上一节提到的无接收值情况相同。
The Hello extension does not affect the processing of any other RSVP message. The only effect is to allow a link (node) down event to be declared sooner than it would have been. RSVP response to that condition is unchanged.
Hello扩展不影响任何其他RSVP消息的处理。唯一的效果是允许一个link（node）down事件比它本来应该声明的要早。对该条件的RSVP响应不变。
The Hello extension is fully backwards compatible. The Hello class is assigned a class value of the form 0bbbbbbb. Depending on the implementation, implementations that do not support the extension will either silently discard Hello messages or will respond with an "Unknown Object Class" error. In either case the sender will fail to see an acknowledgment for the issued Hello.
Hello扩展完全向后兼容。Hello类被分配了一个形式为0bbb的类值。根据实现的不同，不支持扩展的实现将以静默方式放弃Hello消息，或者以“未知对象类”错误响应。在任何一种情况下，发送方都无法看到已发出Hello的确认。
In principle these extensions to RSVP pose no security exposures over and above RFC 2205[1]. However, there is a slight change in the trust model. Traffic sent on a normal RSVP session can be filtered according to source and destination addresses as well as port numbers. In this specification, filtering occurs only on the basis of an incoming label. For this reason an administration may wish to limit the domain over which LSP tunnels can be established. This can be accomplished by setting filters on various ports to deny action on a RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) or LSP_TUNNEL_IPv6 (8).
原则上，RSVP的这些扩展不会造成RFC 2205[1]以上的安全风险。然而，信任模型有一点变化。正常RSVP会话上发送的流量可以根据源地址、目标地址以及端口号进行过滤。在本规范中，仅根据传入标签进行过滤。因此，管理部门可能希望限制可以建立LSP隧道的领域。这可以通过在各种端口上设置筛选器来实现，以拒绝对具有LSP_TUNNEL_IPv4（7）或LSP_TUNNEL_IPv6（8）类型的会话对象的RSVP路径消息执行操作。
IANA assigns values to RSVP protocol parameters. Within the current document an EXPLICIT_ROUTE object and a ROUTE_RECORD object are defined. Each of these objects contain subobjects. This section defines the rules for the assignment of subobject numbers. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15].
IANA为RSVP协议参数赋值。在当前文档中定义了显式路由对象和路由记录对象。每个对象都包含子对象。本节定义了分配子对象编号的规则。本节使用BCP 26“在RFCs中编写IANA注意事项部分的指南”的术语[15]。
EXPLICIT_ROUTE Subobject Type
显式路由子对象类型
EXPLICIT_ROUTE Subobject Type is a 7-bit number that identifies the function of the subobject. There are no range restrictions. All possible values are available for assignment.
EXPLICIT_ROUTE子对象类型是标识子对象功能的7位数字。没有射程限制。所有可能的值都可用于赋值。
Following the policies outlined in [15], subobject types in the range 0 - 63 (0x00 - 0x3F) are allocated through an IETF Consensus action, codes in the range 64 - 95 (0x40 - 0x5F) are allocated as First Come First Served, and codes in the range 96 - 127 (0x60 - 0x7F) are reserved for Private Use.
按照[15]中概述的策略，0-63（0x00-0x3F）范围内的子对象类型通过IETF一致行动分配，64-95（0x40-0x5F）范围内的代码分配为先到先得，96-127（0x60-0x7F）范围内的代码保留供私人使用。
ROUTE_RECORD Subobject Type
路由记录子对象类型
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the function of the subobject. There are no range restrictions. All possible values are available for assignment.
ROUTE_RECORD子对象类型是一个8位数字，用于标识子对象的功能。没有射程限制。所有可能的值都可用于赋值。
Following the policies outlined in [15], subobject types in the range 0 - 127 (0x00 - 0x7F) are allocated through an IETF Consensus action, codes in the range 128 - 191 (0x80 - 0xBF) are allocated as First Come First Served, and codes in the range 192 - 255 (0xC0 - 0xFF) are reserved for Private Use.
按照[15]中概述的策略，0-127（0x00-0x7F）范围内的子对象类型通过IETF一致行动分配，128-191（0x80-0xBF）范围内的代码分配为先到先得，192-255（0xC0-0xFF）范围内的代码保留供私人使用。
The following assignments are made in this document.
本文件中有以下任务。
Message Message Number Name
消息编号名称
20 Hello
20你好
Class Class Number Name
类号名称
1 SESSION
1次会议
Class Types or C-Types:
类别类型或C类型：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSP隧道IPv4 8 LSP隧道IPv6
10 FILTER_SPEC
10过滤器规格
Class Types or C-Types:
类别类型或C类型：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSP隧道IPv4 8 LSP隧道IPv6
11 SENDER_TEMPLATE
11发送方/用户模板
Class Types or C-Types:
类别类型或C类型：
7 LSP Tunnel IPv4 8 LSP Tunnel IPv6
7 LSP隧道IPv4 8 LSP隧道IPv6
16 RSVP_LABEL
16 RSVP_标签
Class Types or C-Types:
类别类型或C类型：
1 Type 1 Label
1类1标签
19 LABEL_REQUEST
19标签要求
Class Types or C-Types:
类别类型或C类型：
1 Without Label Range 2 With ATM Label Range 3 With Frame Relay Label Range
1不带标签范围2带ATM标签范围3带帧中继标签范围
20 EXPLICIT_ROUTE
20号公路
Class Types or C-Types:
类别类型或C类型：
1 Type 1 Explicit Route
1类型1显式路由
21 ROUTE_RECORD
21路线记录
Class Types or C-Types:
类别类型或C类型：
1 Type 1 Route Record
1类1路线记录
22 HELLO
22你好
Class Types or C-Types:
类别类型或C类型：
1 Request 2 Acknowledgment
1请求2确认
207 SESSION_ATTRIBUTE
207会话属性
Class Types or C-Types:
类别类型或C类型：
1 LSP_TUNNEL_RA 7 LSP Tunnel
1号LSP_隧道\u RA 7号LSP隧道
The following list extends the basic list of Error Codes and Values that are defined in [RFC2205].
以下列表扩展了[RFC2205]中定义的错误代码和值的基本列表。
Error Code Meaning
错误代码含义
24 Routing Problem
24路由问题
This Error Code has the following globally-defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
1 Bad EXPLICIT_ROUTE object 2 Bad strict node 3 Bad loose node 4 Bad initial subobject 5 No route available toward destination 6 Unacceptable label value 7 RRO indicated routing loops 8 MPLS being negotiated, but a non-RSVP-capable router stands in the path 9 MPLS label allocation failure 10 Unsupported L3PID
1错误的显式路由对象2错误的严格节点3错误的松散节点4错误的初始子对象5没有通向目的地的路由6不可接受的标签值7错误指示路由环路8个正在协商的MPLS，但路径中有一个不支持RSVP的路由器9个MPLS标签分配失败10个不支持的L3PID
25 Notify Error
25通知错误
This Error Code has the following globally-defined Error Value sub-codes:
此错误代码具有以下全局定义的错误值子代码：
1 RRO too large for MTU 2 RRO Notification 3 Tunnel locally repaired
1个RRO对于MTU太大2个RRO通知3隧道局部修复
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
C类型为1的显式布线对象的子对象：
1 IPv4 prefix 2 IPv6 prefix 32 Autonomous system number
1 IPv4前缀2 IPv6前缀32自治系统编号
Subobjects of the RECORD_ROUTE object with C-Type 1:
C类型为1的记录路由对象的子对象：
1 IPv4 address 2 IPv6 address 3 Label
1 IPv4地址2 IPv6地址3标签
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
This document contains ideas as well as text that have appeared in previous Internet Drafts. The authors of the current document wish to thank the authors of those drafts. They are Steven Blake, Bruce Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex Mondrus for their comments on this document.
这份文件包含了在以前的互联网草稿中出现的想法和文本。本文件的作者谨感谢这些草案的作者。他们是史蒂文·布莱克、布鲁斯·戴维斯、罗奇·盖林、桑杰·卡马特、亚科夫·雷克特、埃里克·罗森和阿伦·维斯瓦纳坦。我们还要感谢Bora Akyol、Yoram Bernet和Alex Mondrus对本文件的评论。
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[1] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——版本1，功能规范”，RFC 22052997年9月。
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[2] Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[3] Awduche，D.，Malcolm，J.，Agogbua，J.，O'Dell和J.McManus，“MPLS上的流量工程要求”，RFC 2702，1999年9月。
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[4] Wroclawski，J.，“受控负荷网元服务规范”，RFC2211，1997年9月。
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[5] Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[7] Almquist，P.，“互联网协议套件中的服务类型”，RFC 1349，1992年7月。
[8] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[8] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和IPv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[9] Herzog，S.，“信号抢占优先权政策要素”，RFC 2751，2000年1月。
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001.
[10] Awduche，D.，Hannan，A.和Xiao，“LSP隧道RSVP扩展的适用性声明”，RFC 3210，2001年12月。
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[11] Wroclawski，J.，“RSVP与IETF综合服务的使用”，RFC 2210，1997年9月。
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[12] Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[13] Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[14] Conta，A.和S.Deering，“互联网协议版本6（IPv6）的互联网控制消息协议（ICMPv6）”，RFC 2463，1998年12月。
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[15] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
[16] Bernet，Y.，Smiht，A.和B.Davie，“空服务类型的规范”，RFC 2997，2000年11月。
Daniel O. Awduche Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703-298-5291 EMail: awduche@movaz.com
Daniel O.Awduche Movaz Networks，Inc.弗吉尼亚州麦克莱恩615室琼斯支路7926号语音：+1 703-298-5291电子邮件：awduche@movaz.com
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive, Suite 615 McLean, VA 22102 Voice: +1 703 847 1801 EMail: lberger@movaz.com
Lou Berger Movaz Networks，Inc.弗吉尼亚州麦克林615室琼斯支路7926号语音：+1 703 847 1801电子邮件：lberger@movaz.com
Der-Hwa Gan Juniper Networks, Inc. 385 Ravendale Drive Mountain View, CA 94043 EMail: dhg@juniper.net
加州山景城拉文代尔大道385号德华根Juniper Networks，Inc.94043电子邮件：dhg@juniper.net
Tony Li Procket Networks 3910 Freedom Circle, Ste. 102A Santa Clara CA 95054 EMail: tli@procket.com
Tony Li Procket Networks 3910 Freedom Circle，Ste。102A加利福尼亚州圣克拉拉95054电子邮件：tli@procket.com
Vijay Srinivasan Cosine Communications, Inc. 1200 Bridge Parkway Redwood City, CA 94065 Voice: +1 650 628 4892 EMail: vsriniva@cosinecom.com
Vijay Srinivasan Cosine Communications，Inc.加利福尼亚州红木市1200桥公园路94065语音：+1 650 628 4892电子邮件：vsriniva@cosinecom.com
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Voice: +1 978 244 8143 EMail: swallow@cisco.com
George Swallow Cisco Systems，Inc.马萨诸塞州切姆斯福德阿波罗大道250号语音：+1 978 244 8143电子邮件：swallow@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。