<reference title="RSVP-TE: Extensions to RSVP for LSP Tunnels" url="https://www.rfc-editor.org/rfc/rfc3209.txt" rfc="3209" lang="zh-Hans" translators="["AI"]" />
RFC 3209
用于流量工程 LSP 隧道的 RSVP 扩展 (RSVP-TE: Extensions to RSVP for LSP Tunnels)
本译文基于英文原文 https://www.rfc-editor.org/rfc/rfc3209.txt 逐段翻译，保留全部章节、位图、代码块与表格。
英文原文元信息
- 文档标题：RSVP-TE: Extensions to RSVP for LSP Tunnels
- 类别：Standards Track
- 状态：Proposed Standard
- 作者：D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow
- 日期：2001 年 12 月
文档头部信息（原文）
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
本备忘录的状态 (Status of This Memo)
本文档为互联网社区规定了一项 Internet 标准轨道协议，并请求大家对其进行讨论和提出改进建议。有关本协议的标准化状态与现状，请参阅当前版本的《Internet Official Protocol Standards》（STD 1）。本备忘录的分发不受限制。
版权声明 (Copyright Notice)
版权所有 (C) The Internet Society (2001)。保留所有权利。
摘要 (Abstract)
本文档描述了如何使用 RSVP（资源预留协议，Resource Reservation Protocol）——包括其中所有必要的扩展——来在 MPLS（多协议标签交换，Multi-Protocol Label Switching）中建立标签交换路径（LSP）。由于沿某条 LSP 的流完全由在该路径入口节点处所施加的标签来标识，因此这些路径可以被当作隧道来对待。LSP 隧道的一项关键应用是 RFC 2702 中所规定的基于 MPLS 的流量工程。
我们提出了若干对 RSVP 进行扩展的附加对象，使得能够以 RSVP 作为信令协议来建立显式路由的标签交换路径。其结果是实例化出一些标签交换隧道，这些隧道能够被自动地路由以绕开网络故障、拥塞和瓶颈。
目录 (Contents)
-
- 引言（Introduction）
- 1.1 背景（Background）
- 1.2 术语（Terminology）
-
- 概述（Overview）
- 2.1 LSP 隧道与流量工程隧道（LSP Tunnels and Traffic Engineered Tunnels）
- 2.2 LSP 隧道的运作（Operation of LSP Tunnels）
- 2.3 业务类别（Service Classes）
- 2.4 预留样式（Reservation Styles）
- 2.4.1 固定过滤 (FF) 样式（Fixed Filter (FF) Style）
- 2.4.2 通配过滤 (WF) 样式（Wildcard Filter (WF) Style）
- 2.4.3 共享显式 (SE) 样式（Shared Explicit (SE) Style）
- 2.5 流量工程隧道的重路由（Rerouting Traffic Engineered Tunnels）
- 2.6 路径 MTU（Path MTU）
-
- 与 LSP 隧道相关的消息格式（LSP Tunnel related Message Formats）
- 3.1 Path 消息（Path Message）
- 3.2 Resv 消息（Resv Message）
-
- 与 LSP 隧道相关的对象（LSP Tunnel related Objects）
- 4.1 Label 对象（Label Object）
- 4.1.1 在 Resv 消息中处理 Label 对象（Handling Label Objects in Resv messages）
- 4.1.2 不支持 Label 对象（Non-support of the Label Object）
- 4.2 Label Request 对象（Label Request Object）
- 4.2.1 不带标签范围的 Label Request（Label Request without Label Range）
- 4.2.2 带 ATM 标签范围的 Label Request（Label Request with ATM Label Range）
- 4.2.3 带帧中继标签范围的 Label Request（Label Request with Frame Relay Label Range）
- 4.2.4 LABEL_REQUEST 的处理（Handling of LABEL_REQUEST）
- 4.2.5 不支持 Label Request 对象（Non-support of the Label Request Object）
- 4.3 Explicit Route 对象（Explicit Route Object）
- 4.3.1 适用性（Applicability）
- 4.3.2 Explicit Route 对象的语义（Semantics of the Explicit Route Object）
- 4.3.3 子对象（Subobjects）
- 4.3.4 Explicit Route 对象的处理（Processing of the Explicit Route Object）
- 4.3.5 环路（Loops）
- 4.3.6 前向兼容性（Forward Compatibility）
- 4.3.7 不支持 Explicit Route 对象（Non-support of the Explicit Route Object）
- 4.4 Record Route 对象（Record Route Object）
- 4.4.1 子对象（Subobjects）
- 4.4.2 适用性（Applicability）
- 4.4.3 RRO 的处理（Processing RRO）
- 4.4.4 环路检测（Loop Detection）
- 4.4.5 前向兼容性（Forward Compatibility）
- 4.4.6 不支持 RRO（Non-support of RRO）
- 4.5 ERO 与 RRO 的错误码（Error Codes for ERO and RRO）
- 4.6 Session、Sender Template 与 Filter Spec 对象（Session, Sender Template, and Filter Spec Objects）
- 4.6.1 Session 对象（Session Object）
- 4.6.2 Sender Template 对象（Sender Template Object）
- 4.6.3 Filter Specification 对象（Filter Specification Object）
- 4.6.4 重路由与带宽增加规程（Reroute and Bandwidth Increase Procedure）
- 4.7 Session Attribute 对象（Session Attribute Object）
- 4.7.1 不带资源亲和性的格式（Format without resource affinities）
- 4.7.2 带资源亲和性的格式（Format with resource affinities）
- 4.7.3 适用于两种 C-Type 的规程（Procedures applying to both C-Types）
- 4.7.4 资源亲和性规程（Resource Affinity Procedures）
-
- Hello 扩展（Hello Extension）
- 5.1 Hello 消息格式（Hello Message Format）
- 5.2 HELLO 对象格式（HELLO Object formats）
- 5.2.1 HELLO REQUEST 对象（HELLO REQUEST object）
- 5.2.2 HELLO ACK 对象（HELLO ACK object）
- 5.3 Hello 消息的使用（Hello Message Usage）
- 5.4 多链路考虑（Multi-Link Considerations）
- 5.5 兼容性（Compatibility）
-
- 安全考虑（Security Considerations）
-
- IANA 考虑（IANA Considerations）
- 7.1 消息类型（Message Types）
- 7.2 类编号与 C-Type（Class Numbers and C-Types）
- 7.3 错误码与全局定义的错误值子码（Error Codes and Globally-Defined Error Value Sub-Codes）
- 7.4 子对象定义（Subobject Definitions）
-
- 知识产权考虑（Intellectual Property Considerations）
-
- 致谢（Acknowledgments）
-
- 参考文献（References）
-
- 作者地址（Authors' Addresses）
-
- 完整版权声明（Full Copyright Statement）
1. 引言
MPLS 架构 [2] 的第 2.9 节将标签分发协议定义为这样一组规程：借助于这些规程，一台标签交换路由器（LSR）把用于在它们之间以及穿过它们转发流量的标签的含义告知另一台 LSR。MPLS 架构并不假定只存在单一的标签分发协议。本文档是对 RSVP 的扩展的规范，用于在 MPLS 网络中建立标签交换路径（LSP）。
本文档中所描述的若干新特性，其提出源于 MPLS 流量工程的需求（参见 [3]）。特别地，扩展后的 RSVP 协议支持实例化显式路由的 LSP，这些 LSP 可以带有资源预留，也可以不带资源预留。它还支持 LSP 的平滑重路由、抢占（preemption）以及环路检测。
用 RSVP 建立的 LSP 可以用来承载 [3] 中所描述的"流量主干（Traffic Trunks）"。承载某个流量主干的 LSP 与该流量主干本身，是两个彼此不同却又密切相关的概念。例如，相同源和目的地之间的两条 LSP 可以通过负载分担来共同承载单个流量主干。反过来，如果例如某条 LSP 具有承载多个业务类别的能力，那么多个流量主干也可以由同一条 LSP 来承载。这些扩展的适用性将在 [10] 中作进一步的讨论。
由于沿标签交换路径流动的流量由在 LSP 入口节点处施加的标签所定义，这些路径可以被视为隧道，即在正常的 IP 路由和过滤机制之下进行隧道传输。当 LSP 以这种方式使用时，我们将其称为 LSP 隧道。
LSP 隧道使得与网络性能优化相关的多种策略得以实现。例如，LSP 隧道可以被自动地或手动地路由，以绕开网络故障、拥塞和瓶颈。此外，还可以在两个节点之间建立多条并行的 LSP 隧道，并根据本地策略把这两个节点之间的流量映射到这些 LSP 隧道之上。尽管流量工程（也就是对运营网络的性能优化）预计将是本规范的一项重要应用，但扩展后的 RSVP 协议也可以在比这广泛得多的场景中使用。
本文档的目的是描述如何使用 RSVP 来建立 LSP 隧道。其意图是完整地描述实现可互操作的实现所需的所有对象、分组格式和规程。本文档还定义了少量能够增强 LSP 隧道管理与诊断能力的新对象。
本文档还描述了通过一种新的 HELLO 消息实现快速节点故障检测的手段。
相对于 RSVP 而言，本规范所描述的所有对象和消息都是可选的。本文档讨论了当本文所描述的某个对象不被某节点支持时会发生什么。
在本文档中，讨论将仅限于单播标签交换路径。组播 LSP 留待进一步研究。
1.1 背景 (Background)
同时支持 RSVP [1] 与多协议标签交换 [2] 的主机和路由器，可以把标签与 RSVP 流关联起来。当 MPLS 与 RSVP 相结合时，流的定义可以变得更加灵活。一旦标签交换路径（LSP）建立起来，通过该路径的流量就由在 LSP 入口节点处施加的标签所定义。标签到流量的映射可以依据多种不同的准则来完成。由特定节点指派了相同标签值的那些分组的集合，被称为属于同一个转发等价类（FEC）（参见 [2]），并且实际上定义了"RSVP 流"。当流量以这种方式映射到标签交换路径上时，我们就把该 LSP 称为"LSP 隧道"。当标签与流量流相关联时，路由器就有可能基于分组的标签值来为该分组识别适当的预留状态。
该信令协议模型采用按需下游（downstream-on-demand）的标签分发方式。把标签绑定到某个特定 LSP 隧道的请求，由入口节点通过 RSVP Path 消息发起。为此，RSVP Path 消息被增加了一个 LABEL_REQUEST 对象。标签在下游一侧分配，并通过 RSVP Resv 消息进行分发（向上游传播）。为此，RSVP Resv 消息被扩展了一个特殊的 LABEL 对象。有关标签分配、分发、绑定和堆叠的规程，将在本文档的后续章节中描述。
该信令协议模型还支持显式路由能力。这是通过在 RSVP Path 消息中并入一个简单的 EXPLICIT_ROUTE 对象来实现的。EXPLICIT_ROUTE 对象封装了构成显式路由路径的逐跳串接。利用该对象，带标签的 RSVP-MPLS 流所经过的路径可以被预先确定，而不依赖于常规的 IP 路由。显式路由的路径既可以以管理方式指定，也可以由适当的实体基于 QoS 和策略要求、并考虑到当时的网络状态而自动计算得出。一般而言，路径计算可以是控制驱动的，也可以是数据驱动的。用于计算显式路由路径的机制、过程和算法超出了本规范的范围。
显式路由的一个有用的应用是流量工程。利用显式路由的 LSP，位于 MPLS 域入口边缘的一个节点可以控制流量从自身出发、穿过 MPLS 网络到达某个出口节点所经由的路径。显式路由可以用来优化网络资源的利用率，并增强面向流量的性能特性。
显式路由标签交换路径的概念可以通过抽象节点（abstract node）的概念加以推广。抽象节点是这样一组节点：其内部拓扑对于 LSP 的入口节点而言是不透明的。如果一个抽象节点只包含一个物理节点，则称它为简单（simple）的抽象节点。利用这种抽象的概念，一条显式路由的 LSP 可以被指定为 IP 前缀的序列，或者自治系统（Autonomous System）的序列。
该信令协议模型支持把显式路径指定为严格（strict）与松散（loose）路由的序列。抽象节点与严格/松散路由的结合显著增强了路径定义的灵活性。
使用 RSVP 来建立 LSP 隧道的一个优点在于：它使得沿路径分配资源成为可能。例如，可以使用标准的 RSVP 预留和综合业务（Integrated Services）业务类别 [4]，为某条 LSP 隧道分配带宽。
尽管资源预留很有用，但它们并不是强制性的。实际上，一条 LSP 完全可以在不带任何资源预留的情况下被实例化。这种不带资源预留的 LSP 可以用来承载例如尽力而为（best effort）的流量。它们还可以在许多其他的场景中使用，包括在故障条件下实现回退（fall-back）与恢复策略，等等。
1.2 术语 (Terminology)
本文档中的关键词"必须（MUST）"、"禁止（MUST NOT）"、"需要（REQUIRED）"、"将要（SHALL）"、"将不（SHALL NOT）"、"应当（SHOULD）"、"不应（SHOULD NOT）"、"推荐（RECOMMENDED）"、"可以（MAY）"和"可选（OPTIONAL）"应按 RFC2119 [6] 中的描述进行解释。
本文假定读者已经熟悉 [1]、[2] 和 [3] 中的术语。
Abstract Node（抽象节点）
内部拓扑对 LSP 的入口节点不透明的一组节点。如果一个抽象节点只包含一个物理节点，则称其为简单（simple）抽象节点。
Explicitly Routed LSP（显式路由 LSP）
其路径通过正常 IP 路由以外的手段建立的 LSP。
Label Switched Path（标签交换路径）
由一个或多个标签交换跳串联而成的路径，使分组能够通过交换标签从一个 MPLS 节点转发到另一个 MPLS 节点。更精确的定义参见 [2]。
LSP
一条标签交换路径（Label Switched Path）。
LSP Tunnel（LSP 隧道）
用于在正常 IP 路由和/或过滤机制之下进行隧道传输的 LSP。
Traffic Engineered Tunnel (TE Tunnel)（流量工程隧道）
承载某个流量主干的一条或多条 LSP 隧道的集合。
Traffic Trunk（流量主干）
按其业务类别聚合而成、然后被放置到一条称为流量工程隧道的 LSP 或 LSP 集合上的一组流。进一步的讨论参见 [3]。
2. 概述
2.1 LSP 隧道与流量工程隧道 (LSP Tunnels and Traffic Engineered Tunnels)
根据 [1]，"RSVP 将'会话（session）'定义为具有特定目的地和传输层协议的数据流"。然而，当 RSVP 与 MPLS 相结合时，流或会话可以用更大的灵活性和普遍性来定义。LSP 的入口节点可以使用多种手段来确定哪些分组被指派某个特定标签。一旦标签被指派给一组分组，该标签实际上就定义了通过该 LSP 的"流"。我们将这样的 LSP 称为"LSP 隧道"，因为通过它的流量对沿标签交换路径的中间节点而言是不透明的。
为了支持 LSP 隧道特性，已经定义了新的 RSVP SESSION、SENDER_TEMPLATE 和 FILTER_SPEC 对象，分别称为 LSP_TUNNEL_IPv4 和 LSP_TUNNEL_IPv6。从沿标签交换路径的节点的视角来看，这些对象的语义是：属于该 LSP 隧道的流量，仅凭从 PHOP（即"上一跳"，参见 [1]）到达的、带有本节点指派给去往该会话的上游发送者的特定标签值（一个或多个）的分组来识别。事实上，对象名称中出现的 IPv4(v6) 仅表示目的地地址是一个 IPv4(v6) 地址。当泛指这些对象时，我们使用限定词 LSP_TUNNEL。
在某些应用中，把 LSP 隧道成组地关联起来是有用的。这在重路由操作期间，或者为了把某个流量主干分散到多条路径上时，会很有用。在流量工程应用中，这样的集合被称为流量工程隧道（TE 隧道）。为了能够标识和关联这样的 LSP 隧道，需要携带两个标识符。隧道 ID（tunnel ID）是 SESSION 对象的一部分。SESSION 对象唯一地定义了一条流量工程隧道。SENDER_TEMPLATE 和 FILTER_SPEC 对象则携带一个 LSP ID。SENDER_TEMPLATE（或 FILTER_SPEC）对象与 SESSION 对象一起，唯一地标识一条 LSP 隧道。
2.2 LSP 隧道的运作 (Operation of LSP Tunnels)
本节概述由本文档扩展后的 RSVP 所支持的、与 LSP 隧道的运作相关的一些特性。这些特性包括：(1) 建立带或不带 QoS 要求的 LSP 隧道的能力；(2) 动态重路由已建立的 LSP 隧道的能力；(3) 观察已建立的 LSP 隧道实际经过的路由的能力；(4) 标识和诊断 LSP 隧道的能力；(5) 在管理策略控制下抢占已建立的 LSP 隧道的能力；以及 (6) 执行按需下游（downstream-on-demand）标签分配、分发和绑定的能力。在下面的段落中将简要描述这些特性。更详细的描述可以在本文档的后续章节中找到。
要创建一条 LSP 隧道，路径上的第一个 MPLS 节点——也就是相对于该路径的发送者节点——会创建一个会话类型为 LSP_TUNNEL_IPv4 或 LSP_TUNNEL_IPv6 的 RSVP Path 消息，并把一个 LABEL_REQUEST 对象插入该 Path 消息。LABEL_REQUEST 对象表明正在为此路径请求一个标签绑定，同时指明了将要在此路径上承载的网络层协议。之所以需要这样做，是因为沿 LSP 下行发送的网络层协议不能被假定为 IP，也不能从 L2 头部推断出来——L2 头部只是把上层协议标识为 MPLS。
如果发送者节点知道某条路由很有希望满足该隧道的 QoS 要求，或者能够高效地利用网络资源，或者满足某些策略准则，那么该节点可以决定把这条路由用于它的部分或全部会话。为了做到这一点，发送者节点在 RSVP Path 消息中加入一个 EXPLICIT_ROUTE 对象。EXPLICIT_ROUTE 对象把该路由指定为抽象节点的序列。
如果在某个会话成功建立之后，发送者节点发现了一条更好的路由，那么发送者只需更改 EXPLICIT_ROUTE 对象，就可以动态地重路由该会话。如果某个 EXPLICIT_ROUTE 对象遇到了问题——或者因为它导致了路由环路，或者因为某些中间路由器不支持它——发送者节点将得到通知。
通过在 Path 消息中加入一个 RECORD_ROUTE 对象，发送者节点可以接收到关于该 LSP 隧道实际经过的路由的信息。发送者节点还可以使用该对象，就路由路径的变更向网络请求通知。RECORD_ROUTE 对象类似于路径向量（path vector），因此可以用于环路检测。
最后，可以在 Path 消息中加入一个 SESSION_ATTRIBUTE 对象，以辅助会话的标识和诊断。该对象中还包括其他的控制信息，例如建立（setup）与保持（hold）优先级、资源亲和性（resource affinity，参见 [3]）以及本地保护（local-protection）。
路径沿途的路由器可以把建立与保持优先级、连同 Path 消息中包含的 SENDER_TSPEC 以及任何 POLICY_DATA 对象，用作策略控制的输入。例如，在流量工程应用中，非常有用的做法是：在抢占任何较低优先级的预留之前，先利用 Path 消息作为一种手段，验证沿整条路径在特定优先级上是否存在带宽。如果在资源不足的情况下仍然允许 Path 消息继续向前传递，那么就会存在这样的危险：该点下游的较低优先级预留，将为了满足这一请求而在徒劳的尝试中被不必要地抢占。
当 EXPLICIT_ROUTE 对象（ERO）存在时，Path 消息会沿着由 ERO 所指定的路径向其目的地转发。路径沿途的每一个节点都会把该 ERO 记录到它的路径状态块（path state block）之中。节点在转发 Path 消息之前也可以对 ERO 进行修改。在这种情况下，除了接收到的 ERO 之外，修改后的 ERO 也应当（SHOULD）被存储在路径状态块中。
LABEL_REQUEST 对象请求中间路由器和接收节点为该会话提供标签绑定。如果某个节点无法提供标签绑定，它就会发送一条带有"未知对象类（unknown object class）"错误的 PathErr 消息。如果 LABEL_REQUEST 对象得不到端到端的支持，发送者节点将会由第一个不提供这种支持的节点通知。
标签交换路径的目的地节点通过在其作为响应的 RSVP Resv 消息中包含一个 LABEL 对象，来响应 LABEL_REQUEST。LABEL 对象被插入到过滤说明（filter spec）列表之中、紧跟在它所对应的那个过滤说明之后。
Resv 消息沿着由 Path 消息所创建的路径状态，按相反的顺序向上游发回给发送者。注意，如果路径状态是借助 ERO 创建的，那么 Resv 消息将沿着 ERO 的反向路径行进。
每一个接收到包含 LABEL 对象的 Resv 消息的节点，都会把该标签用于与这条 LSP 隧道相关联的出向流量。如果该节点不是发送者，它会分配一个新的标签，并把该标签放入它向上游发送给 PHOP 的 Resv 消息中相应的 LABEL 对象之中。在 LABEL 对象中向上游发送的这个标签，就是该节点将用来识别与这条 LSP 隧道相关联的入向流量的标签。该标签还充当过滤说明（Filter Spec）的简写形式。此时，该节点就可以更新它的"入标签映射"（Incoming Label Map，ILM）；ILM 用于把入向的带标签分组映射到"下一跳标签转发条目"（Next Hop Label Forwarding Entry，NHLFE），参见 [2]。
当 Resv 消息向上游传播到达发送者节点时，一条标签交换路径即实际建立起来。
2.3 业务类别 (Service Classes)
本文档不限制用于预留的综合业务（Integrated Service）请求的类型。不过，一个实现应当（SHOULD）支持受控负载（Controlled-Load）业务 [4] 和空业务（Null Service）[16]。
2.4 预留样式 (Reservation Styles)
接收节点可以为每个会话从一组可能的预留样式之中进行选择，并且每个 RSVP 会话必须具有某个特定的样式。发送者对于预留样式的选择没有任何影响。接收者可以为不同的 LSP 选择不同的预留样式。
一个 RSVP 会话可以产生一条或多条 LSP，具体取决于所选的预留样式。
某些预留样式（例如 FF）把特定的预留专用于单个发送者节点。另一些预留样式（例如 WF 和 SE）可以在多个发送者节点之间共享一个预留。以下各节讨论不同的预留样式及其优缺点。关于预留样式更详细的讨论可在 [1] 中找到。
2.4.1 固定过滤 (FF) 样式 (Fixed Filter (FF) Style)
固定过滤（Fixed Filter，FF）预留样式为来自每个发送者的流量创建一个独特的、不被其他发送者共享的预留。这种样式常见于来自每个发送者的流量很可能是并发且相互独立的应用之中。对于使用 FF 的会话来说，一条链路上预留带宽的总量等于各个发送者各自预留之和。
由于每个发送者都拥有自己的预留，因此会为每个发送者指派一个唯一的标签。这可能导致在每一对发送者/接收者之间形成一条点到点的 LSP。
2.4.2 通配过滤 (WF) 样式 (Wildcard Filter (WF) Style)
采用通配过滤（Wildcard Filter，WF）预留样式时，一个共享的预留被用于去往某个会话的所有发送者。无论发送者的数量是多少，一条链路上的总预留量都保持不变。
为去往该会话的所有发送者创建一条单一的多点到点（multipoint-to-point）标签交换路径。在该会话的各个发送者所共享的链路上，为该会话分配一个单一的标签值。如果只有一个发送者，那么该 LSP 看起来就像一条普通的点到点连接。当存在多个发送者时，就会创建一条多点到点的 LSP（一棵反向树）。
这种样式适用于并非所有发送者都同时发送流量的应用。例如，电话会议就是一种并非所有发言者都同时讲话的应用。然而，如果所有发送者同时发送，那么就没有办法做出恰当的预留。此时，要么靠近目的地的链路上预留的带宽会少于所需的数量，要么靠近某些发送者的链路上预留的带宽会多于所需的数量。这限制了 WF 在流量工程目的方面的适用性。
此外，由于 WF 的合并规则，EXPLICIT_ROUTE 对象不能与 WF 预留一起使用。基于这一问题以及对流量工程缺乏适用性的原因，本文档不考虑使用 WF。
2.4.3 共享显式 (SE) 样式 (Shared Explicit (SE) Style)
共享显式（Shared Explicit，SE）样式允许接收者显式地指定要包括在某个预留之中的发送者。在一条链路上，对所有被列出的发送者只存在单一的预留。由于每个发送者都在 Resv 消息中被显式地列出，因此可以为不同的发送者指派不同的标签，从而创建出各自分离的 LSP。
SE 样式的预留可以通过多点到点的标签交换路径来提供，也可以每个发送者一条 LSP。当 Path 消息不携带 EXPLICIT_ROUTE 对象时，或者当各条 Path 消息具有相同的 EXPLICIT_ROUTE 对象时，可以使用多点到点的 LSP。在这两种情况中的任何一种情况下，都可以指派一个公共的标签。
来自不同发送者的 Path 消息可以各自携带自己的 ERO，并且这些发送者所经过的路径可以在网络拓扑中的任意一点汇聚和分叉。当各条 Path 消息具有不同的 EXPLICIT_ROUTE 对象时，必须为每一个 EXPLICIT_ROUTE 对象建立单独的 LSP。
2.5 流量工程隧道的重路由 (Rerouting Traffic Engineered Tunnels)
流量工程的需求之一是：能够基于管理策略，在若干种条件下对已建立的 TE 隧道进行重路由。例如，在某些场景下，管理策略可能规定：当一条更"优"的路由变得可用时，就应当对给定的 TE 隧道进行重路由。另一个通常需要进行 TE 隧道重路由的重要场景是：TE 隧道已建立路径上的某个资源发生了故障。在某些策略之下，当失效的资源重新被激活时，还可能需要把 TE 隧道恢复到它原来的路径上。
一般而言，在 TE 隧道重路由进行期间，非常希望不中断流量，也不对网络的运行造成不利影响。这种自适应且平滑的重路由要求：先建立一条新的 LSP 隧道，并在拆除旧的 LSP 隧道之前，把流量从旧的 LSP 隧道转移到新的 LSP 隧道之上。这一概念被称为"先建后断（make-before-break）"。可能出现的一个问题是：旧的与新的 LSP 隧道可能会在它们共同经过的网段上相互争夺资源。根据资源可用的情况，这种争夺可能导致准入控制（Admission Control）阻止新 LSP 隧道的建立。使用 RSVP 来建立 LSP 隧道的一个优点是：它非常优雅地解决了这个问题。
为了以平滑的方式支持先建后断，必须做到：在新旧 LSP 共同经过的链路上，旧 LSP 隧道所占用的资源在流量转移到新 LSP 隧道之前不应被释放，并且预留不应被重复计数，因为后者可能导致准入控制拒绝新的 LSP 隧道。
当想要增加某条 TE 隧道的带宽时，也会出现类似的情况。新的预留将是所需的全部数量，但实际需要分配的只是新带宽与旧带宽之间的差值。如果中间节点正在对 PATH 消息实施策略控制，那么请求了过多带宽的 PATH 消息将被拒绝。在这种情况下，如果不更改 SENDER_TEMPLATE 而只是简单地增加带宽请求，则视本地策略而定，可能导致隧道被拆除。
LSP_TUNNEL SESSION 对象与 SE 预留样式的组合，自然地适应了带宽和路由方面的平滑过渡。其思想是：旧的与新的 LSP 隧道在它们共同经过的链路上共享资源。LSP_TUNNEL SESSION 对象用于把 RSVP 会话的范围收窄到所讨论的特定 TE 隧道。为了唯一地标识一条 TE 隧道，我们使用目的地 IP 地址（作为隧道出口的那个节点的地址）、隧道 ID（Tunnel ID）以及隧道入口节点的 IP 地址（它被放置在扩展隧道 ID（Extended Tunnel ID）字段之中）这三者的组合。
在重路由或带宽增加操作期间，隧道入口需要在该 RSVP 会话中表现为两个不同的发送者。这是通过引入"LSP ID"来实现的，它携带在 SENDER_TEMPLATE 和 FILTER_SPEC 对象中。由于这些对象的语义发生了变化，因此分配了新的 C-Type。
为了实施重路由，入口节点会选取一个新的 LSP ID，并构造一个新的 SENDER_TEMPLATE。然后，入口节点创建一个新的 ERO 来定义新的路径。此后，该节点使用原有的 SESSION 对象以及新的 SENDER_TEMPLATE 和 ERO，发送一个新的 Path 消息。它继续使用旧的 LSP，并继续刷新旧的 Path 消息。在不为新旧隧道共同持有的链路上，新的 Path 消息会被当作常规的新 LSP 隧道建立来处理。在共同持有的链路上，共享的 SESSION 对象和 SE 样式使得新的 LSP 能够与旧的 LSP 共享资源地建立起来。一旦入口节点收到了针对新 LSP 的 Resv 消息，它就可以把流量转移到新 LSP 上，并拆除旧的 LSP。
为了实施带宽增加，可以使用一个带有新 LSP_ID 的新 Path 消息来尝试更大的带宽预留；与此同时，当前的 LSP_ID 继续被刷新，以确保在较大的预留失败时，原有的预留不会丢失。
2.6 路径 MTU (Path MTU)
标准的 RSVP [1] 和 Int-Serv [11] 为 RSVP 的发送者提供了发送者与接收者之间可用的最小 MTU。对于经由 RSVP 建立的 LSP，同样提供了这种路径 MTU 识别能力。
路径 MTU 信息根据其中所存在的对象，携带在综合业务（Integrated Services）对象或空业务（Null Service）对象之中。使用综合业务对象时，路径 MTU 按照 [11] 中定义的规程提供。使用空业务对象时的路径 MTU 识别则在 [16] 中定义。
在标准 RSVP 中，发送者使用路径 MTU 信息来检查哪些 IP 分组超过了路径 MTU。对于那些超过路径 MTU 的分组，发送者要么对这些分组进行分片，要么在 IP 数据报设置了"不分片（Don't Fragment）"比特的情况下，发出一条 ICMP 目的地不可达消息。经由 RSVP 建立的 LSP 也需要这种与路径 MTU 相关的处理。
以下算法适用于所有未打标签的 IP 数据报，以及节点已知为 IP 数据报、且在转发前需要添加标签的任何带标签分组。对于带标签的分组，需要找到栈底，并对 IP 头部进行检查。
使用 [5] 中定义的术语，LSR 必须执行以下算法：
-
令 N 为标签栈中的字节数（即标签栈条目数的 4 倍），其中包括本节点将要添加的标签。
-
令 M 为"初始最大带标签 IP 数据报大小"（Maximum Initially Labeled IP Datagram Size）与（路径 MTU − N）二者之中较小的一个。
当 IPv4 数据报（不含标签）的大小超过 M 的值时，
-
若 IPv4 头部中未设置 DF 比特，则
- (a) 该数据报必须被拆分为分片，每个分片的大小不大于 M，并且
- (b) 每个分片必须被打上标签，然后转发。
-
若 IPv4 头部中设置了 DF 比特，则
- (a) 禁止转发该数据报。
- (b) 构造一条 ICMP 目的地不可达（Destination Unreachable）消息：
- i. 把它的 Code 字段 [12] 设置为 "Fragmentation Required and DF Set"（需要分片且设置了 DF），
- ii. 把它的 Next-Hop MTU 字段 [13] 设置为 M。
- (c) 如果可能，把该 ICMP 目的地不可达消息发送给被丢弃数据报的源。
当 IPv6 数据报（不含标签）的大小超过 M 的值时，
- (a) 禁止转发该数据报。
- (b) 构造一条 ICMP 分组过大（Packet Too Big）消息，并把它的 Next-Hop 链路 MTU 字段 [14] 设置为 M。
- (c) 如果可能，把该 ICMP 分组过大消息发送给被丢弃数据报的源。
3. 与 LSP 隧道相关的消息格式 (LSP Tunnel related Message Formats)
本节定义了五个新对象：
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Path
同时还为 SESSION、SENDER_TEMPLATE 和 FILTER_SPEC 对象分配了新的 C-Type。
后续章节将给出这些新对象的详细描述。相对于 RSVP 而言，所有新对象都是可选的。一个实现可以选择只支持其中一部分对象。但是，就本规范而言，LABEL_REQUEST 与 LABEL 对象是强制性的。
LABEL 对象与 RECORD_ROUTE 对象是按发送者区分的。在 Resv 消息中，它们必须出现在与之关联的 FILTER_SPEC 之后、并位于任何后续 FILTER_SPEC 之前。
EXPLICIT_ROUTE、LABEL_REQUEST 与 SESSION_ATTRIBUTE 对象的相对位置仅仅是一种建议。这些对象的先后顺序并不重要，因此实现必须准备好以任意顺序接受这些对象。
3.1 Path 消息 (Path Message)
Path 消息的格式如下：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]
3.2 Resv 消息 (Resv Message)
Resv 消息的格式如下：
<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>
<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> ]
<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> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ]
注意：LABEL 与 RECORD_ROUTE（如果存在）绑定于其前面的 FILTER_SPEC。每个 FILTER_SPEC 之后跟随的 LABEL 和/或 RECORD_ROUTE 不得多于一个。
4. 与 LSP 隧道相关的对象 (LSP Tunnel related Objects)
4.1 Label 对象 (Label Object)
标签可以被携带在 Resv 消息之中。对于 FF 和 SE 样式，每个发送者都关联有一个标签。某个发送者的标签，在 Resv 消息中必须紧跟在该发送者的 FILTER_SPEC 之后。
LABEL 对象具有如下格式：
LABEL class = 16, C_Type = 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LABEL 的内容是单个标签，编码为 4 个八位组。每个通用 MPLS 标签都是一个取值范围在 0 到 1048575 之间的无符号整数。通用 MPLS 标签与 FR 标签按右对齐方式编码在 4 个八位组之中。ATM 标签的编码方式为：VPI 右对齐于比特 0-15，VCI 右对齐于比特 16-31。
4.1.1 在 Resv 消息中处理 Label 对象 (Handling Label Objects in Resv messages)
在 MPLS 中，一个节点可以支持多个标签空间，例如为每个入接口关联一个唯一的标签空间。为便于下文的讨论，"相同标签"一词指的是取自相同标签空间的相同标签值。此外，下面的内容仅适用于单播会话。
在不同接口上的 Resv 消息中接收到的标签，即使标签值相同，也总是被视为不同的标签。
4.1.1.1 下游 (Downstream)
下游节点选择一个标签来代表该流。如果在标签请求中指定了标签范围，那么该标签必须取自该范围。如果没有可用的标签，该节点将发送一条 PathErr 消息，其错误码为 "Routing problem"（路由问题），错误值为 "Label allocation failure"（标签分配失败）。
如果某个节点收到的 Resv 消息已把相同的标签值指派给多个发送者，那么该节点也可以向这些相同的发送者或它们的任意子集指派一个单一值。注意，如果该节点打算对某个会话中的各个发送者分别实施监管（policing），它必须为这些发送者指派唯一的标签。
就 ATM 而言，还有一个附加条件。某些 ATM 节点不具备合并流的能力。这些节点可以通过把标签请求中的一个比特置零来表明这一点。C-Type 2（带 ATM 标签范围的标签请求）的 LABEL_REQUEST 对象中的 M 比特正是为此目的而设。具备合并能力的节点应当设置 M 比特。如果对某些发送者而言 M 比特未被设置，下游节点必须为这些发送者指派唯一的标签。
一旦标签被分配，该节点就会构造一个新的 LABEL 对象。然后，节点把这个新的 LABEL 对象作为 Resv 消息的一部分发送给上一跳。节点应当在发送 Resv 消息之前，就准备好转发携带所分配标签的分组。LABEL 对象应当被保存在预留状态块（Reservation State Block）之中。随后，在下一个 Resv 刷新事件中，它将被用于构造 Resv 消息。
如果 LABEL 对象的内容发生变化，节点预计会在其刷新定时器到期之前就发送 Resv 消息。
4.1.1.2 上游 (Upstream)
节点把 LABEL 对象中携带的标签用作为该发送者所关联的出向标签。路由器分配一个新标签，并将其绑定到本会话/发送者的入接口。该接口正是路由器用来向各上一跳转发 Resv 消息的那个接口。
有若干种情形都可能导致出现不可接受的标签：
-
该节点是一台不具备合并能力的 ATM 交换机，而下游节点却把相同的标签指派给了两个发送者
-
被指派的是隐式空标签（implicit null label），但该节点不具备对相应的 L3PID 执行倒数第二跳弹出（penultimate pop）的能力
-
被指派的标签超出了所请求的标签范围
在发生上述任何一种事件时，该节点都会发送一条 ResvErr 消息，其错误码为 "Routing problem"（路由问题），错误值为 "Unacceptable label value"（不可接受的标签值）。
4.1.2 不支持 Label 对象 (Non-support of the Label Object)
在正常情况下，节点绝不应当（should never）在 Resv 消息中收到 LABEL 对象，除非它已经在对应的 Path 消息中包含过 LABEL_REQUEST 对象。然而，不识别 LABEL 对象的 RSVP 路由器会向接收者方向发送一条错误码为 "Unknown object class"（未知对象类）的 ResvErr。这将导致该预留失败。
4.2 Label Request 对象 (Label Request Object)
Label Request 类的编号是 19。目前存在三种可能的 C_Type。类型 1 是不带标签范围的标签请求。类型 2 是带 ATM 标签范围的标签请求。类型 3 是带帧中继（Frame Relay）标签范围的标签请求。LABEL_REQUEST 对象的格式如下所示。
4.2.1 不带标签范围的 Label Request (Label Request without Label Range)
Class = 19, C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
此字段为保留字段。发送时必须将其设置为零，接收时必须忽略。
L3PID
使用此路径的第 3 层协议的标识符。采用标准的 Ethertype 值。
4.2.2 带 ATM 标签范围的 Label Request (Label Request with ATM Label Range)
Class = 19, C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (Res)
此字段为保留字段。发送时必须将其设置为零，接收时必须忽略。
L3PID
使用此路径的第 3 层协议的标识符。采用标准的 Ethertype 值。
M
将此比特设置为 1，表示该节点在数据平面具备合并能力。
Minimum VPI（12 比特）
这个 12 比特字段指定了始发交换机所支持的一块虚拟路径标识符（Virtual Path Identifier）的下界。如果 VPI 不足 12 比特，它必须在此字段中右对齐，且其前面的比特必须被设置为零。
Minimum VCI（16 比特）
这个 16 比特字段指定了始发交换机所支持的一块虚拟连接标识符（Virtual Connection Identifier）的下界。如果 VCI 不足 16 比特，它必须在此字段中右对齐，且其前面的比特必须被设置为零。
Maximum VPI（12 比特）
这个 12 比特字段指定了始发交换机所支持的一块虚拟路径标识符（Virtual Path Identifier）的上界。如果 VPI 不足 12 比特，它必须在此字段中右对齐，且其前面的比特必须被设置为零。
Maximum VCI（16 比特）
这个 16 比特字段指定了始发交换机所支持的一块虚拟连接标识符（Virtual Connection Identifier）的上界。如果 VCI 不足 16 比特，它必须在此字段中右对齐，且其前面的比特必须被设置为零。
4.2.3 带帧中继标签范围的 Label Request (Label Request with Frame Relay Label Range)
Class = 19, C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
此字段为保留字段。发送时必须将其设置为零，接收时必须忽略。
L3PID
使用此路径的第 3 层协议的标识符。采用标准的 Ethertype 值。
DLI
DLCI 长度指示符（DLCI Length Indicator），即 DLCI 的比特数。支持以下取值：
Len DLCI bits
0 10
2 23
Minimum DLCI
这个 23 比特字段指定了始发交换机所支持的一块数据链路连接标识符（Data Link Connection Identifier，DLCI）的下界。DLCI 必须在此字段中右对齐，未使用的比特必须被设置为 0。
Maximum DLCI
这个 23 比特字段指定了始发交换机所支持的一块数据链路连接标识符（Data Link Connection Identifier，DLCI）的上界。DLCI 必须在此字段中右对齐，未使用的比特必须被设置为 0。
4.2.4 LABEL_REQUEST 的处理 (Handling of LABEL_REQUEST)
为了建立一条 LSP 隧道，发送者会创建一个带有 LABEL_REQUEST 对象的 Path 消息。LABEL_REQUEST 对象表明正在为该路径请求一个标签绑定，并指明了将要在此路径上承载的网络层协议。这使得非 IP 的网络层协议也可以沿一条 LSP 发送。这一信息在实际的标签分配中也很有用，因为某些保留标签是与协议相关的，参见 [5]。
LABEL_REQUEST 应当被存储在路径状态块（Path State Block）之中，这样 Path 刷新消息中也将包含 LABEL_REQUEST 对象。当 Path 消息到达接收者时，LABEL_REQUEST 对象的存在会触发接收者分配一个标签，并把该标签放入对应 Resv 消息的 LABEL 对象之中。如果指定了标签范围，则标签必须从该范围中分配。接受了 LABEL_REQUEST 对象的接收者，必须在与该 Path 消息相关的 Resv 消息中包含一个 LABEL 对象。如果 Path 消息中没有 LABEL_REQUEST 对象，那么节点禁止在与该 Path 消息的会话及 PHOP 对应的 Resv 消息中包含 LABEL 对象。
发送 LABEL_REQUEST 对象的节点，必须准备好接受并正确处理相应 Resv 消息中的 LABEL 对象。
识别出 LABEL_REQUEST 对象、但无法支持它的节点（可能因为标签分配失败），应当发送一条 PathErr，其错误码为 "Routing problem"（路由问题），错误值为 "MPLS label allocation failure"（MPLS 标签分配失败）。这包括指定了标签范围、但无法从该范围中分配标签的情形。
既接收又转发带有 LABEL_REQUEST 对象的 Path 消息的节点，必须把收到的 LABEL_REQUEST 对象中的 L3PID 复制到转发的 LABEL_REQUEST 对象之中。
如果接收者无法支持该协议 L3PID，它应当发送一条 PathErr，其错误码为 "Routing problem"（路由问题），错误值为 "Unsupported L3PID"（不支持的 L3PID）。这将导致该 RSVP 会话失败。
4.2.5 不支持 Label Request 对象 (Non-support of the Label Request Object)
不识别 LABEL_REQUEST 对象的 RSVP 路由器，会向发送者方向发送一条错误码为 "Unknown object class"（未知对象类）的 PathErr。识别 LABEL_REQUEST 对象、但不识别其 C_Type 的 RSVP 路由器，会向发送者方向发送一条错误码为 "Unknown object C_Type"（未知对象 C_Type）的 PathErr。这将导致路径建立失败。发送者应当把"无法建立 LSP"一事通知管理系统，并可能采取行动，在没有 LABEL_REQUEST 的情况下继续维持该预留。
RSVP 的设计使其能够优雅地应对发送者与接收者之间的任何非 RSVP 路由器。然而，显而易见，非 RSVP 路由器无法通过 RSVP 传递标签。这意味着，如果某台路由器存在一个已知不支持 RSVP 的邻居，那么在发送途经这些非 RSVP 路由器的消息时，该路由器禁止通告 LABEL_REQUEST 对象。此时，路由器应当向发送者回送一条 PathErr，其错误码为 "Routing problem"（路由问题），错误值为 "MPLS being negotiated, but a non-RSVP capable router stands in the path"（正在协商 MPLS，但路径上存在一台不支持 RSVP 的路由器）。如果路由器从不支持 RSVP 的路由器发来的消息中收到 LABEL_REQUEST 对象，也应当发送同样的消息。关于下游路由器如何判定非 RSVP 路由器的存在，参见 [1] 中的描述。
4.3 Explicit Route 对象 (Explicit Route Object)
显式路由通过 EXPLICIT_ROUTE 对象（ERO）来指定。Explicit Route 类的编号是 20。目前定义了一个 C_Type，即类型 1 Explicit Route。EXPLICIT_ROUTE 对象具有如下格式：
Class = 20, C_Type = 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
子对象（Subobjects）
EXPLICIT_ROUTE 对象的内容是一系列称为子对象（subobject）的可变长度数据项。这些子对象在下文第 4.3.3 节中定义。
如果一条 Path 消息包含多个 EXPLICIT_ROUTE 对象，则只有第一个对象是有意义的。后续的 EXPLICIT_ROUTE 对象可以被忽略，且不应被继续传播。
4.3.1 适用性 (Applicability)
EXPLICIT_ROUTE 对象只打算用于单播场景。把显式路由应用于组播，是进一步研究的课题。
EXPLICIT_ROUTE 对象只应当在显式路由沿途的所有路由器都支持 RSVP 和 EXPLICIT_ROUTE 对象时使用。EXPLICIT_ROUTE 对象被赋予形如 0bbbbbbb 的类编号。因此，不支持该对象的 RSVP 路由器将会以 "Unknown Object Class"（未知对象类）错误作出响应。
4.3.2 Explicit Route 对象的语义 (Semantics of the Explicit Route Object)
显式路由是网络拓扑中的一条特定路径。通常，显式路由由某个节点确定，其意图是让流量沿着该路径传送。
显式路由被描述为沿显式路由分布的若干节点组的列表。除了能够标识沿路径的具体节点之外，显式路由还能够标识路径上必须经过的一个节点组。这种能力为路由系统在满足显式路由请求方面提供了相当大的本地灵活性，也使得显式路由的生成者可以对路径细节持有不完全的信息。
显式路由被编码为包含在 EXPLICIT_ROUTE 对象中的一系列子对象。每个子对象标识显式路由中的一个节点组。因此，显式路由就是一组待遍历节点组的规范说明。
为使讨论形式化，我们把每个节点组称为一个抽象节点（abstract node）。于是，我们说显式路由是对一组待遍历抽象节点的规范说明。如果一个抽象节点只由一个节点组成，我们就称之为简单抽象节点。
作为抽象节点概念的一个例子，考虑一条仅由自治系统编号（Autonomous System number）子对象构成的显式路由。每个子对象对应于全局拓扑中的一个自治系统。在这种情况下，每个自治系统都是一个抽象节点，而这条显式路由就是一条包含所有被指明自治系统的路径。每个自治系统内部可能存在多跳，但这些都对显式路由的源节点是不透明的。
4.3.3 子对象 (Subobjects)
EXPLICIT_ROUTE 对象的内容是一系列称为子对象（subobject）的可变长度数据项。每个子对象具有如下形式：
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 比特是子对象的一个属性。如果该子对象表示显式路由中的一个松散跳（loose hop），则设置 L 比特。如果未设置该比特，则该子对象表示显式路由中的一个严格跳（strict hop）。
Type
Type 指明子对象内容的类型。当前定义的取值为：
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Length
Length 包含子对象的总长度（以字节为单位），其中包括 L、Type 和 Length 字段本身。Length 必须至少为 4，并且必须是 4 的倍数。
4.3.3.1 严格与松散子对象 (Strict and Loose Subobjects)
子对象中的 L 比特是一个单比特属性。如果设置了 L 比特，则该属性的取值为"松散（loose）"；否则，该属性的取值为"严格（strict）"。为行文简洁，若某子对象的属性取值为"松散"，我们就称它是一个"松散子对象"；否则，称它是一个"严格子对象"。进而，我们把严格子对象或松散子对象的抽象节点分别称为严格节点或松散节点。松散节点与严格节点总是相对于它们前面的抽象节点来解释的。
严格节点与其前一个节点之间的路径，必须只包含属于该严格节点及其前一个抽象节点的网络节点。
松散节点与其前一个节点之间的路径，可以包含既不属于该松散节点、也不属于其前一个抽象节点的其他网络节点。
4.3.3.2 子对象 1：IPv4 前缀 (Subobject 1: IPv4 prefix)
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 比特是子对象的一个属性。如果该子对象表示显式路由中的一个松散跳，则设置 L 比特。如果未设置该比特，则该子对象表示显式路由中的一个严格跳。
Type
0x01 IPv4 地址
Length
Length 包含子对象的总长度（以字节为单位），其中包括 Type 和 Length 字段。Length 总是 8。
IPv4 address（IPv4 地址）
一个 IPv4 地址。该地址依据下文的"前缀长度"取值被当作一个前缀来处理。超出前缀范围的比特在接收时被忽略，并且在发送时应当被设置为零。
Prefix length（前缀长度）
IPv4 前缀的长度（以比特为单位）。
Padding（填充）
发送时为零。接收时忽略。
IPv4 前缀子对象的内容是一个 4 八位组的 IPv4 地址、一个 1 八位组的前缀长度和一个 1 八位组的填充。该子对象所表示的抽象节点，就是其 IP 地址落在此前缀之内的所有节点的集合。注意，前缀长度为 32 表示单个 IPv4 节点。
4.3.3.3 子对象 2：IPv6 前缀 (Subobject 2: IPv6 Prefix)
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 比特是子对象的一个属性。如果该子对象表示显式路由中的一个松散跳，则设置 L 比特。如果未设置该比特，则该子对象表示显式路由中的一个严格跳。
Type
0x02 IPv6 地址
Length
Length 包含子对象的总长度（以字节为单位），其中包括 Type 和 Length 字段。Length 总是 20。
IPv6 address（IPv6 地址）
一个 IPv6 地址。该地址依据下文的"前缀长度"取值被当作一个前缀来处理。超出前缀范围的比特在接收时被忽略，并且在发送时应当被设置为零。
Prefix Length（前缀长度）
IPv6 前缀的长度（以比特为单位）。
Padding（填充）
发送时为零。接收时忽略。
IPv6 前缀子对象的内容是一个 16 八位组的 IPv6 地址、一个 1 八位组的前缀长度和一个 1 八位组的填充。该子对象所表示的抽象节点，就是其 IP 地址落在此前缀之内的所有节点的集合。注意，前缀长度为 128 表示单个 IPv6 节点。
4.3.3.4 子对象 32：自治系统编号 (Subobject 32: Autonomous System Number)
自治系统（AS）编号子对象的内容是一个 2 八位组的 AS 编号。该子对象所表示的抽象节点，就是属于该自治系统的所有节点的集合。
AS 编号子对象的长度为 4 个八位组。
4.3.4 Explicit Route 对象的处理 (Processing of the Explicit Route Object)
4.3.4.1 下一跳的选择 (Selection of the Next Hop)
接收到包含 EXPLICIT_ROUTE 对象的 Path 消息的节点，必须为该路径确定下一跳。这是必需的，因为显式路由上沿路的下一个抽象节点可能是一个 IP 子网或一个自治系统。因此，这一下一跳的选择可能需要从一组可行备选方案中作出决策。用于从可行备选方案中进行选取的准则是与实现相关的，也可能受到本地策略的影响，并且超出了本规范的范围。不过，我们假定每个节点都会尽力确定一条无环路径。注意，如此确定的路径可以被本地策略所覆盖。
为了确定该路径的下一跳，节点执行以下步骤：
-
接收到该 RSVP 消息的节点必须首先评估第一个子对象。如果该节点不属于由第一个子对象所描述的抽象节点，那么它收到了一条错误的消息，应当返回 "Bad initial subobject"（坏的初始子对象）错误。如果根本不存在第一个子对象，消息同样是错误的，系统应当返回 "Bad EXPLICIT_ROUTE object"（坏的 EXPLICIT_ROUTE 对象）错误。
-
如果不存在第二个子对象，则表明已到达显式路由的末端。此时应当把 EXPLICIT_ROUTE 对象从 Path 消息中移除。该节点可能是路径的末端，也可能不是。处理继续进入第 4.3.4.2 节，在那里可以（MAY）向 Path 消息加入一个新的 EXPLICIT_ROUTE 对象。
-
接下来，节点评估第二个子对象。如果该节点同时也属于由第二个子对象所描述的抽象节点，那么该节点删除第一个子对象，并转回上面的第 2 步继续处理。注意，这使得第二个子对象成为下一次迭代中的第一个子对象，从而允许该节点在可能重复应用第 2、3 步之后，识别出消息路径上的下一个抽象节点。
-
抽象节点边界情形（Abstract Node Border Case）：节点判断自己在拓扑上是否与由第二个子对象所描述的抽象节点相邻。如果是，节点选择一个属于该抽象节点的特定下一跳。然后，节点删除第一个子对象，并继续进入第 4.3.4.2 节的处理。
-
抽象节点内部情形（Interior of the Abstract Node Case）：否则，节点在第一个子对象的抽象节点（即该节点所属的抽象节点）内部，选择一个沿通往第二个子对象的抽象节点（即下一个抽象节点）的路径的下一跳。如果不存在这样的路径，则有两种情形：
-
5a. 如果第二个子对象是严格子对象，则存在错误，节点应当返回 "Bad strict node"（坏的严格节点）错误。
-
5b. 否则，如果第二个子对象是松散子对象，节点选择沿通往下一个抽象节点的路径的任意下一跳。如果不存在这样的路径，则存在错误，节点应当返回 "Bad loose node"（坏的松散节点）错误。
-
-
最后，节点把第一个子对象替换为任何表示"包含该下一跳的抽象节点"的子对象。这是必需的，以便当下一跳收到这条显式路由时能够接受它。
4.3.4.2 向 Explicit Route 对象中添加子对象 (Adding subobjects to the Explicit Route Object)
在选定下一跳之后，节点可以通过以下方式修改该显式路由。
如果在执行第 4.3.4.1 节算法的过程中，EXPLICIT_ROUTE 对象被移除了，节点可以加入一个新的 EXPLICIT_ROUTE 对象。
否则，如果该节点是第一个子对象的抽象节点的成员，那么一系列子对象可以被插入到第一个子对象之前，或者替换第一个子对象。这一系列子对象中的每一个都必须表示一个属于当前抽象节点子集的抽象节点。
或者，如果第一个子对象是松散子对象，则可以在第一个子对象之前插入任意的一系列子对象。
4.3.5 环路 (Loops)
虽然 EXPLICIT_ROUTE 对象的长度是有限的，但松散节点的存在意味着：在底层路由协议的过渡（transient）期间，有可能构造出转发环路。显式路由的发起者可以通过使用另一个不透明路由对象——RECORD_ROUTE 对象——来检测这种情况。RECORD_ROUTE 对象用于收集详细的路径信息，对环路检测和诊断都很有用。
4.3.6 前向兼容性 (Forward Compatibility)
预计随着时间的推移，可能会定义新的子对象。在正常的 ERO 处理过程中遇到未识别子对象的节点，会向发送者方向发送一条 PathErr，其错误码为 "Routing Error"（路由错误），错误值为 "Bad Explicit Route Object"（坏的显式路由对象）。EXPLICIT_ROUTE 对象会被包含在该错误之中，并被截断（从左侧截断）到引发问题的子对象处。对于未在节点 ERO 处理过程中遇到的未识别子对象，其存在应当被忽略，并随其余的 ERO 栈一起向下游传递。
4.3.7 不支持 Explicit Route 对象 (Non-support of the Explicit Route Object)
不识别 EXPLICIT_ROUTE 对象的 RSVP 路由器，会向发送者方向发送一条错误码为 "Unknown object class"（未知对象类）的 PathErr。这将导致路径建立失败。发送者应当把"无法建立 LSP"一事通知管理系统，并可能采取行动，在没有 EXPLICIT_ROUTE 的情况下或经由另一条显式路由继续维持该预留。
4.4 Record Route 对象 (Record Route Object)
路由可以通过 RECORD_ROUTE 对象（RRO）来记录。此外还可以选择性地记录标签。Record Route 类的编号是 21。目前定义了一个 C_Type，即 Type 1 Record Route。RECORD_ROUTE 对象具有如下格式：
Class = 21, C_Type = 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects（子对象）
RECORD_ROUTE 对象的内容是一系列称为子对象（subobject）的可变长度数据项。这些子对象在下文的第 4.4.1 节中定义。
RRO 可以同时出现在 RSVP 的 Path 消息和 Resv 消息之中。如果一条 Path 消息包含多个 RRO，则只有第一个 RRO 是有意义的。后续的 RRO 应当被忽略，且不应被继续传播。类似地，如果在一条 Resv 消息中，在某个 FILTER_SPEC 之后、遇到另一个 FILTER_SPEC 之前遇到了多个 RRO，则只有第一个 RRO 是有意义的。后续的 RRO 应当被忽略，且不应被继续传播。
4.4.1 子对象 (Subobjects)
RECORD_ROUTE 对象的内容是一系列称为子对象（subobject）的可变长度数据项。每个子对象都有自己的 Length 字段。该长度以字节为单位给出子对象的总长度，包括 Type 和 Length 字段在内。该长度必须始终是 4 的倍数，且至少为 4。
子对象按照后进先出（last-in-first-out）的栈方式组织。相对于 RRO 开头的第一个子对象被视为栈顶。最后一个子对象被视为栈底。当添加新的子对象时，它总是被添加到栈顶。
不含任何子对象的空 RRO 被视为非法。
目前定义了三种子对象。
4.4.1.1 子对象 1：IPv4 地址 (Subobject 1: IPv4 address)
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 地址
Length
Length 字段以字节为单位包含子对象的总长度，包括 Type 和 Length 字段在内。Length 恒为 8。
IPv4 address
一个 32 比特的单播主机地址。此处允许使用任何网络可达的接口地址。不应使用非法地址，例如某些环回（loopback）地址。
Prefix length
32
Flags
0x01 —— 本地保护可用 (Local protection available)
表示该节点下游的链路已通过本地修复机制受到保护。只有当对应的 Path 消息的 SESSION_ATTRIBUTE 对象中设置了 Local protection 标志时，才能够设置此标志。
0x02 —— 本地保护正在使用 (Local protection in use)
表示正在使用本地修复机制来维护此隧道（通常是在该隧道原先经过的链路发生中断的情况下）。
4.4.1.2 子对象 2：IPv6 地址 (Subobject 2: IPv6 address)
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 地址
Length
Length 字段以字节为单位包含子对象的总长度，包括 Type 和 Length 字段在内。Length 恒为 20。
IPv6 address
一个 128 比特的单播主机地址。
Prefix length
128
Flags
0x01 —— 本地保护可用 (Local protection available)
表示该节点下游的链路已通过本地修复机制受到保护。只有当对应的 Path 消息的 SESSION_ATTRIBUTE 对象中设置了 Local protection 标志时，才能够设置此标志。
0x02 —— 本地保护正在使用 (Local protection in use)
表示正在使用本地修复机制来维护此隧道（通常是在该隧道原先经过的链路发生中断的情况下）。
4.4.1.3 子对象 3：标签 (Subobject 3, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x03 —— 标签 (Label)
Length
Length 字段以字节为单位包含子对象的总长度，包括 Type 和 Length 字段在内。
Flags
0x01 = 全局标签 (Global label)
此标志表示：该标签无论在哪个接口上被接收，都会被理解。
C-Type
所包含的 Label 对象的 C-Type。从 Label 对象复制而来。
Contents of Label Object
Label 对象的内容。从 Label 对象复制而来。
4.4.2 适用性 (Applicability)
此处仅定义用于单播会话的过程。
RRO 在 RSVP 中有三种可能的用途。第一，RRO 可以作为一种环路检测机制，用于发现 L3 路由环路，或显式路由中固有的环路。执行这一操作的确切过程将在本文档后文描述。
第二，RRO 逐跳地收集有关 RSVP 会话的最新详细路径信息，为发送者或接收者提供有价值的信息。任何路径变化（由网络拓扑变化引起）都会被报告。
第三，RRO 的语法经过设计，只需稍加修改，整个对象就可以用作 EXPLICIT_ROUTE 对象的输入。当发送者在 Resv 消息中从接收者那里收到 RRO，并在下一条 Path 消息中把它应用到 EXPLICIT_ROUTE 对象上，以"固定会话路径"（pin down session path）时，这一点非常有用。
4.4.3 RRO 的处理 (Processing RRO)
通常，节点通过把 RRO 加入 Path 消息来发起一个 RSVP 会话。初始的 RRO 只包含一个子对象——发送者的 IP 地址。如果该节点还希望记录标签，它会在 SESSION_ATTRIBUTE 对象中设置 Label_Recording 标志。
当中间路由器收到包含 RRO 的 Path 消息时，路由器会把它的一个副本存储在路径状态块（Path State Block）中。随后，在下一个 Path 刷新事件中，该 RRO 将被用于构造 Path 消息。当要发送一条新的 Path 消息时，路由器会向 RRO 添加一个新的子对象，并在传输之前把得到的 RRO 附加到 Path 消息上。
新添加的子对象必须是这台路由器的 IP 地址。所添加的地址应当是出向 Path 消息的接口地址。如果有多个地址可供选择，如何决策属于本地事务。然而，建议（RECOMMENDED）始终一致地选择同一个地址。
当 SESSION_ATTRIBUTE 对象中的 Label_Recording 标志被设置时，执行路由记录的节点应当包含一个 Label Record 子对象。如果该节点使用的是全局标签空间，那么它应当设置 Global Label 标志。
Label Record 子对象应当在该节点的 IP 地址入栈之前，先被压入 RECORD_ROUTE 对象。节点禁止在压入 Label Record 子对象的同时不压入 IPv4 或 IPv6 子对象。
注意，在收到初始 Path 消息时，节点很可能还没有可包含的标签。一旦获得标签，节点应当在下一个 Path 刷新事件中把该标签包含在 RRO 里。
如果新添加的子对象导致 RRO 过大而无法装入一条 Path（或 Resv）消息，则该 RRO 对象应（SHALL）被从消息中丢弃，并且消息处理照常继续。应当向发送者（或接收者）回送一条 PathErr（或 ResvErr）消息，使用错误码 "Notify" 和错误值 "RRO too large for MTU"。如果接收者收到这样一条 ResvErr，它应当发送一条 PathErr 消息，错误码为 "Notify"，错误值为 "RRO notification"。
收到上述任一错误值的发送者，应当从 Path 消息中移除 RRO。
节点应当每隔 n 秒重发一次上述 PathErr 或 ResvErr 消息，其中 n 取 15 和相关 Path 或 RESV 消息的刷新间隔两者中的较大值。节点可以施加限制和/或退避定时器来限制发送的消息数量。
如果下一条 Path 消息中的 RRO 与前一条不同，RSVP 路由器可以决定在其刷新时刻到来之前提前发送 Path 消息。当从上一跳路由器收到的 RRO 内容发生变化，或该 RRO 新近被加入 Path 消息（或从中删除）时，就可能出现这种情况。
当 RSVP 会话的目的节点收到带有 RRO 的 Path 消息时，这表明发送者节点需要路由记录。目的节点通过向 Resv 消息添加 RRO 来启动 RRO 处理过程。其处理方式与 Path 消息的处理方式互为镜像。唯一的区别是，Resv 消息中的 RRO 以相反的方向记录路径信息。
注意，此时路径上的每个节点都将拥有从源到目的地的完整路由。Path RRO 将包含从源到本节点的路由；Resv RRO 将包含从本节点到目的地的路由。这对网络管理非常有用。
收到不带 RRO 的 Path 消息，表明发送者节点不再需要路由记录。后续的 Resv 消息中禁止（SHALL NOT）再包含 RRO。
4.4.4 环路检测 (Loop Detection)
作为处理入向 RRO 的一部分，中间路由器会检查 RRO 中包含的所有子对象。如果路由器判定自己已经在该列表之中，则存在转发环路。
如果下游节点收到的 Path 消息或上游节点收到的 Resv 消息中，其所含的 RRO 未检测到路由环路，则该 RSVP 会话是无环的。
转发环路大致可分为两类。第一类是瞬态环路（transient loop），它作为 L3 路由试图为所有目的地收敛到一致的转发路径这一正常运作过程的一部分而出现。第二类转发环路是永久环路（permanent loop），它通常由网络配置错误导致。
节点在收到 RRO 后执行的动作，取决于承载该 RRO 的消息类型。
对于包含转发环路的 Path 消息，路由器会构造并发送一条 "Routing problem" PathErr 消息，错误值为 "loop detected"（检测到环路），并丢弃该 Path 消息。在环路被消除之前，该会话不适合转发数据分组。环路如何被消除超出了本文档的范围。
对于包含转发环路的 Resv 消息，路由器只需丢弃该消息。如果 Path 消息不成环，Resv 消息就不应成环。
4.4.5 前向兼容性 (Forward Compatibility)
可以为 RRO 定义新的子对象。在处理 RRO 时，未识别的子对象应当被忽略并继续传递。在为环路检测而处理 RRO 时，节点应当跳过解析任何未识别的对象。环路检测的工作原理，是检测由节点自身在早前一次对象传递过程中插入的子对象。这确保了环路检测所必需的子对象总是能被理解。
4.4.6 不支持 RRO (Non-support of RRO)
RRO 对象只应在路径上所有路由器都支持 RSVP 和 RRO 对象时使用。RRO 对象被赋予形如 0bbbbbbb 的类编号。因此，不支持该对象的 RSVP 路由器会以 "Unknown Object Class"（未知对象类）错误作出响应。
4.5 ERO 与 RRO 的错误码 (Error Codes for ERO and RRO)
在上述处理过程中，某些错误必须以 "Routing Problem" 或 "Notify" 两者之一来报告。"Routing Problem" 错误码的值是 24；"Notify" 错误码的值是 25。
下面定义 Routing Problem 错误码的错误值：
-
坏的 EXPLICIT_ROUTE 对象 (Bad EXPLICIT_ROUTE object)
-
坏的严格节点 (Bad strict node)
-
坏的松散节点 (Bad loose node)
-
坏的初始子对象 (Bad initial subobject)
-
没有通往目的地的可用路由 (No route available toward destination)
-
不可接受的标签值 (Unacceptable label value)
-
RRO 指示存在路由环路 (RRO indicated routing loops)
-
正在协商 MPLS，但路径中存在一台不具备 RSVP 能力的路由器 (MPLS being negotiated, but a non-RSVP-capable router stands in the path)
-
MPLS 标签分配失败 (MPLS label allocation failure)
-
不支持的 L3PID (Unsupported L3PID)
（上述错误值依次对应 Value 1 至 10。）
对于 Notify 错误码，Error Value 字段的 16 个比特为：
ss00 cccc cccc cccc
高位比特的定义见错误码 1 之下的说明（参见 [1]）。
当 ss = 00 时，定义了以下子码：
-
RRO too large for MTU（RRO 相对 MTU 过大）
-
RRO notification（RRO 通知）
-
Tunnel locally repaired（隧道已在本地修复）
4.6 Session、Sender Template 与 Filter Spec 对象 (Session, Sender Template, and Filter Spec Objects)
为 SESSION、SENDER_TEMPLATE 和 FILTER_SPEC 对象定义了新的 C-Type。
LSP_TUNNEL 对象具有如下格式：
4.6.1 Session 对象 (Session Object)
4.6.1.1 LSP_TUNNEL_IPv4 Session 对象 (LSP_TUNNEL_IPv4 Session Object)
Class = SESSION, LSP_TUNNEL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel end point address
隧道出口（egress）节点的 IPv4 地址。
Tunnel ID
在 SESSION 中使用的一个 16 比特标识符，在隧道的生存期内保持不变。
Extended Tunnel ID
在 SESSION 中使用的一个 32 比特标识符，在隧道的生存期内保持不变。通常设置为全零。希望把 SESSION 的范围收窄到入口-出口对（ingress-egress pair）的入口节点，可以在此处放置自己的 IPv4 地址，作为一个全局唯一的标识符。
4.6.1.2 LSP_TUNNEL_IPv6 Session 对象 (LSP_TUNNEL_IPv6 Session Object)
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 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) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel end point address
隧道出口（egress）节点的 IPv6 地址。
Tunnel ID
在 SESSION 中使用的一个 16 比特标识符，在隧道的生存期内保持不变。
Extended Tunnel ID
在 SESSION 中使用的一个 16 字节标识符，在隧道的生存期内保持不变。通常设置为全零。希望把 SESSION 的范围收窄到入口-出口对（ingress-egress pair）的入口节点，可以在此处放置自己的 IPv6 地址，作为一个全局唯一的标识符。
4.6.2 Sender Template 对象 (Sender Template Object)
4.6.2.1 LSP_TUNNEL_IPv4 Sender Template 对象 (LSP_TUNNEL_IPv4 Sender Template Object)
Class = SENDER_TEMPLATE, LSP_TUNNEL_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 tunnel sender address
发送者节点的 IPv4 地址。
LSP ID
在 SENDER_TEMPLATE 和 FILTER_SPEC 中使用的一个 16 比特标识符，它可以被改变，以允许发送者与自身共享资源。
4.6.2.2 LSP_TUNNEL_IPv6 Sender Template 对象 (LSP_TUNNEL_IPv6 Sender Template Object)
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 tunnel sender address
发送者节点的 IPv6 地址。
LSP ID
在 SENDER_TEMPLATE 和 FILTER_SPEC 中使用的一个 16 比特标识符，它可以被改变，以允许发送者与自身共享资源。
4.6.3 Filter Specification 对象 (Filter Specification Object)
4.6.3.1 LSP_TUNNEL_IPv4 Filter Specification 对象 (LSP_TUNNEL_IPv4 Filter Specification Object)
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7
LSP_TUNNEL_IPv4 FILTER_SPEC 对象的格式与 LSP_TUNNEL_IPv4 SENDER_TEMPLATE 对象完全相同。
4.6.3.2 LSP_TUNNEL_IPv6 Filter Specification 对象 (LSP_TUNNEL_IPv6 Filter Specification Object)
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8
LSP_TUNNEL_IPv6 FILTER_SPEC 对象的格式与 LSP_TUNNEL_IPv6 SENDER_TEMPLATE 对象完全相同。
4.6.4 重路由与带宽增加过程 (Reroute and Bandwidth Increase Procedure)
本节描述如何建立一条能够在被重路由期间、或在试图增加其带宽期间，维持资源预留（不重复计数）的隧道。在初始 Path 消息中，入口节点构造一个 SESSION 对象，分配一个 Tunnel_ID，并把它的 IPv4 地址放入 Extended_Tunnel_ID。它还构造一个 SENDER_TEMPLATE 并分配一个 LSP_ID。随后，隧道的建立按照正常过程进行。
在收到 Path 消息后，出口节点向入口节点回送一条采用 Shared Explicit STYLE 的 Resv 消息。
当拥有已建立路径的入口节点想要改变该路径时，它按如下方式构造一条新的 Path 消息。沿用现有的 SESSION 对象；特别是 Tunnel_ID 和 Extended_Tunnel_ID 保持不变。入口节点选取一个新的 LSP_ID 来构成一个新的 SENDER_TEMPLATE。它为新的路由创建一个 EXPLICIT_ROUTE 对象。然后发送新的 Path 消息。入口节点同时刷新旧的和新的 Path 消息。
出口节点以一条 Resv 消息作出响应，其中的 SE 流描述符（flow descriptor）格式如下：
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>
（注意：如果各 PHOP 不同，则会发送两条消息，每条消息各自带有相应的 FILTER_SPEC 和 LABEL_OBJECT。）
当入口节点收到该 Resv 消息（或多条 Resv 消息）后，它就可以开始使用新路由了。它应当针对旧路由发送一条 PathTear 消息。
4.7 Session Attribute 对象 (Session Attribute Object)
Session Attribute 类的编号是 207。定义了两种 C_Type：LSP_TUNNEL，C-Type = 7；以及 LSP_TUNNEL_RA，C-Type = 1。LSP_TUNNEL_RA C-Type 包含与 LSP_TUNNEL C-Type 完全相同的所有字段，此外它还携带资源亲和（resource affinity）信息。格式如下：
4.7.1 不带资源亲和的格式 (Format without resource affinities)
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Setup Priority
会话在占用资源方面的优先级，取值范围为 0 到 7。值 0 是最高优先级。Setup Priority 用于决定本会话能否抢占另一个会话。
Holding Priority
会话在保持资源方面的优先级，取值范围为 0 到 7。值 0 是最高优先级。Holding Priority 用于决定本会话能否被另一个会话抢占。
Flags
0x01 —— 期望本地保护 (Local protection desired)
此标志允许中途（transit）路由器使用本地修复机制，这可能导致违反显式路由对象。当在相邻的下游链路或节点上检测到故障时，transit 路由器可以重路由流量，以快速恢复服务。
0x02 —— 期望记录标签 (Label recording desired)
此标志表示在进行路由记录时应当包含标签信息。
0x04 —— 期望 SE 样式 (SE Style desired)
此标志表示隧道入口节点可以选择在不拆除隧道的情况下重路由该隧道。隧道出口节点在以 Resv 消息作出响应时应当使用 SE 样式。
Name Length
填充之前显示字符串的长度，以字节为单位。
Session Name
一个以空字符（NULL）填充的字符串。
4.7.2 带资源亲和的格式 (Format with resource affinities)
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 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) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exclude-any
一个 32 比特向量，表示与隧道关联的一组属性过滤器：只要链路具有其中任意一个属性，该链路即不可接受。
Include-any
一个 32 比特向量，表示与隧道关联的一组属性过滤器：只要链路具有其中任意一个属性，该链路即可接受（就该测试而言）。空集（所有比特均为零）自动通过。
Include-all
一个 32 比特向量，表示与隧道关联的一组属性过滤器：链路必须具有其中的全部属性，才可接受（就该测试而言）。空集（所有比特均为零）自动通过。
Setup Priority
会话在占用资源方面的优先级，取值范围为 0 到 7。值 0 是最高优先级。Setup Priority 用于决定本会话能否抢占另一个会话。
Holding Priority
会话在保持资源方面的优先级，取值范围为 0 到 7。值 0 是最高优先级。Holding Priority 用于决定本会话能否被另一个会话抢占。
Flags
0x01 —— 期望本地保护 (Local protection desired)
此标志允许中途（transit）路由器使用本地修复机制，这可能导致违反显式路由对象。当在相邻的下游链路或节点上检测到故障时，transit 路由器可以重路由流量，以快速恢复服务。
0x02 —— 期望记录标签 (Label recording desired)
此标志表示在进行路由记录时应当包含标签信息。
0x04 —— 期望 SE 样式 (SE Style desired)
此标志表示隧道入口节点可以选择在不拆除隧道的情况下重路由该隧道。隧道出口节点在以 Resv 消息作出响应时应当使用 SE 样式。
Name Length
填充之前显示字符串的长度，以字节为单位。
Session Name
一个以空字符（NULL）填充的字符串。
4.7.3 适用于两种 C-Type 的过程 (Procedures applying to both C-Types)
对建立优先级（setup priority）和保持优先级（holding priority）的支持是可选的（OPTIONAL）。节点可以识别这一信息，却无法执行所请求的操作。此时节点应当把这些信息原样向下游传递。
如上所述，抢占（preemption）是通过两个优先级来实现的。Setup Priority 是占用资源的优先级。Holding Priority 是保持资源的优先级。具体地说，Holding Priority 就是分配给本会话的资源被预留时所采用的优先级。对于给定的会话，Setup Priority 禁止高于其 Holding Priority。
建立优先级和保持优先级与 [9] 中定义的抢占优先级（preemption priority）和防御优先级（defending priority）直接类似。虽然这两个对象之间的相互作用最终属于策略（policy）问题，但建议（RECOMMENDED）采用以下默认交互方式。
当两个对象同时存在时，使用抢占优先级策略元素（policy element）。两个优先级空间之间的映射定义如下：会话属性优先级 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
当一条新的 Path 消息接受准入考量时，会将所请求的带宽与 Setup Priority 所指定优先级下的可用带宽进行比较。
如果所请求的带宽不可用，则返回一条 PathErr 消息，错误码为 01（Admission Control Failure，准入控制失败），错误值为 0x0002。错误值中的第一个 0 表示这是一个全局定义的子码，不含信息量；002 表示 "requested bandwidth unavailable"（所请求的带宽不可用）。
如果所请求的带宽小于未使用的带宽，则处理完成。如果所请求的带宽可用，但正被较低优先级的会话使用，那么可以抢占较低优先级的会话（从最低优先级开始），以释放所需的带宽。
在支持抢占的情况下，每一个被抢占的预留都会触发一个发送给本地客户端的 TC_Preempt() 上叫（upcall），并传递一个指示原因的子码。应当向下游接收者和上游发送者发送带有 "Policy Control failure"（策略控制失败）代码的 ResvErr 和/或 PathErr。
对本地保护（local-protection）的支持是可选的（OPTIONAL）。节点可以识别 local-protection 标志，却无法执行所请求的操作。在这种情况下，节点应当把这些信息原样向下游传递。
ROUTE_RECORD 对象中是否记录 Label 子对象，由 SESSION_ATTRIBUTE 对象中的 label-recording-desired 标志控制。由于并非所有应用都需要 Label 子对象，因此它不会被自动记录。该标志允许应用只在需要时才请求记录。
Session Name 字段的内容是一个字符串，通常由可显示的字符组成。Length 必须始终是 4 的倍数，并且必须至少为 8。当对象长度不是 4 的倍数时，对象将以尾随的 NULL 字符填充。Name Length 字段包含字符串的实际长度。
4.7.4 资源亲和过程 (Resource Affinity Procedures)
资源类（resource class）和资源类亲和（resource class affinity）在 [3] 中描述。在本文档中，我们对后一术语使用更简短的称呼——资源亲和（resource affinity）。资源类可以与链路关联，并在路由协议中通告。RSVP 以两种方式使用资源类亲和。为了通过验证，一条链路必须通过以下三项测试。如果测试失败，应当发送一条错误码为 "policy control failure" 的 PathErr。
当考虑让一条新的预留通过 ERO 中某个严格节点准入时，节点可以针对该链路的资源类验证资源亲和。当节点为了扩展 ERO 中的某个松散节点而选择链路时，节点必须针对资源亲和验证那些链路的资源类。如果找不到可接受的链路来扩展 ERO，节点应当发送一条 PathErr 消息，错误码为 "Routing Problem"，错误值为 "no route available toward destination"。
为了通过验证，一条链路必须通过以下三项测试。
为了精确描述这些测试，使用上文对象描述中给出的定义。我们还定义：
Link-attr
一个 32 比特向量，表示与一条链路关联的属性。
这三项测试是：
-
Exclude-any
如果链路携带该集合中的任何属性，此测试将把该链路排除在考量之外。
(link-attr & exclude-any) == 0 -
Include-any
只要链路携带该集合中的任何属性，此测试就接受该链路。
(include-any == 0) | ((link-attr & include-any) != 0) -
Include-all
只有当链路携带该集合中的全部属性时，此测试才接受该链路。
(include-all == 0) | (((link-attr & include-all) ^ include-all) == 0)
对于一条链路而言，三项测试必须全部通过才是可接受的。如果测试失败，节点应当发送一条 PathErr 消息，错误码为 "Routing Problem"，错误值为 "no route available toward destination"。
如果一条 Path 消息包含多个 SESSION_ATTRIBUTE 对象，则只有第一个 SESSION_ATTRIBUTE 对象是有意义的。后续的 SESSION_ATTRIBUTE 对象可以被忽略，无需转发。
所有 RSVP 路由器，无论是否支持 SESSION_ATTRIBUTE 对象，都必须（SHALL）原样转发该对象。在发送者与接收者之间的任何位置存在非 RSVP 路由器，都不会对该对象产生影响。
5. Hello 扩展 (Hello Extension)
RSVP Hello 扩展使 RSVP 节点能够检测相邻节点何时不可达。该机制提供节点到节点的故障检测。当检测到这类故障时，其处理方式与链路层通信故障的处理方式基本相同。该机制适用于以下场景：链路层故障通知不可用且未使用无编号链路，或者链路层提供的故障检测机制不足以及时检测到节点故障。
应当注意，节点故障检测并不等同于链路故障检测机制，在存在多条并行无编号链路的情况下尤其如此。
Hello 扩展经过了专门设计，使得一侧可以使用该机制而另一侧不必使用。邻居故障检测可以在任何时刻发起，包括邻居初次相互发现之时，或者仅在邻居之间共享 Resv 或 Path 状态之时。
Hello 扩展由一条 Hello 消息、一个 HELLO REQUEST 对象和一个 HELLO ACK 对象组成。两个邻居之间的 Hello 处理支持对故障检测间隔（通常通过配置指定）的独立选择。每个邻居都可以自主发送 HELLO REQUEST 对象。每个请求都会得到一个确认作为应答。Hello 消息中还包含足够的信息，使得一个邻居可以抑制发送 Hello 请求，而仍然能够完成邻居故障检测。Hello 消息可以作为子消息包含在 bundle 消息之中。
邻居故障检测通过收集并存储邻居的 "instance"（实例）值来完成。如果观察到该值发生变化，或者邻居未能正确报告本地所通告的值，则推定该邻居已经复位。当观察到邻居的值发生变化，或者与邻居的通信丢失时，向该邻居通告的实例值也会随之改变。HELLO 对象提供了一种用于轮询和提供实例值的机制。轮询请求中同样携带发送者的实例值，这使得轮询的接收方可以选择将收到的轮询视为隐式的轮询响应。这种可选处理是一种优化，可以减少一对邻居所处理的轮询与响应的总数。在任何情况下，只要双方都支持该优化，其结果就是每个故障检测间隔内只有一组轮询与响应。根据所选间隔的不同，即使只有一方支持该优化，也可能获得同样的收益。
5.1 Hello 消息格式 (Hello Message Format)
Hello 消息总是在两个 RSVP 邻居之间发送。IP 源地址是发送节点的 IP 地址，IP 目的地址是邻居节点的 IP 地址。
HELLO 机制用于直接相邻的邻居之间。当 HELLO 消息在直接相邻的邻居之间交换时，所有发出的 HELLO 消息的 IP TTL 字段应当设置为 1。
Hello 消息的 Msg Type 为 20。Hello 消息格式如下：
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>
5.2 HELLO 对象格式 (HELLO Object formats)
HELLO Class 为 22。定义了两个 C_Type。
5.2.1 HELLO REQUEST 对象 (HELLO REQUEST object)
Class = HELLO Class, C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2.2 HELLO ACK 对象 (HELLO ACK object)
Class = HELLO Class, C_Type = 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Src_Instance（32 比特）
表示发送者实例（instance）的 32 位值。通告方为每个邻居维护一个对应的表示值/取值。当发送者复位、节点重启、或者与邻居节点的通信丢失时，该值必须改变；除此之外保持不变。该字段禁止设置为 0。
Dst_Instance（32 比特）
最近一次从邻居收到的 Src_Instance 值。当从未从邻居处收到过任何值时，该字段必须设置为 0。
5.3 Hello 消息的使用 (Hello Message Usage)
Hello 消息完全是可选的（OPTIONAL）。不希望参与 Hello 消息处理的节点可以忽略所有此类消息。本节其余内容的撰写均假定接收方与发送方都在参与处理。特别地，针对接收方使用的 MUST 与 SHOULD 仅适用于支持 Hello 消息处理的节点。
节点会周期性地为每个状态正被跟踪的邻居生成一条包含 HELLO REQUEST 对象的 Hello 消息。发送周期由 hello_interval 控制。该值可以按邻居逐个配置。默认值为 5 ms。
生成包含 HELLO REQUEST 对象的消息时，发送者在 Src_Instance 字段中填入代表其针对该邻居的实例值。只要本端仍在与对应邻居交换 Hello，该值就禁止改变。发送者同时在 Dst_Instance 字段中填入最近从邻居收到的 Src_Instance 值。为便于引用，将该变量称为 Neighbor_Src_Instance。如果从未从邻居收到过任何值，或者本节点认为与邻居的通信已经丢失，则将 Neighbor_Src_Instance 置为 0。如果在先前的一个 hello_interval 间隔内已经从目的节点收到过包含 HELLO REQUEST 对象的消息，则应当抑制该消息的生成。
收到包含 HELLO REQUEST 对象的消息时，接收方必须生成一条包含 HELLO ACK 对象的 Hello 消息。接收方还应当验证邻居没有复位。这通过比较发送者的 Src_Instance 字段值与先前收到的值来完成。如果 Neighbor_Src_Instance 的值为 0，而 Src_Instance 字段非 0，则用新值更新 Neighbor_Src_Instance。如果取值不同，或者 Src_Instance 字段为 0，则节点必须按照与邻居的通信已经丢失来处理。
HELLO REQUEST 对象的接收方还应当验证邻居是否正确地反射了接收方的 Instance 值。这通过将收到的 Dst_Instance 字段与最近发送给该邻居的 Src_Instance 字段值进行比较来完成。如果邻居在经过配置的若干间隔之后仍持续通告错误的非 0 值，则节点必须按照与邻居的通信已经丢失来处理。
收到包含 HELLO ACK 对象的消息时，接收方必须验证邻居没有复位。这通过比较发送者的 Src_Instance 字段值与先前收到的值来完成。如果 Neighbor_Src_Instance 的值为 0，而 Src_Instance 字段非 0，则用新值更新 Neighbor_Src_Instance。如果取值不同，或者 Src_Instance 字段为 0，则节点必须按照与邻居的通信已经丢失来处理。
HELLO ACK 对象的接收方还必须验证邻居是否正确地反射了接收方的 Instance 值。如果邻居在 Dst_Instance 字段中通告了错误的值，则节点必须按照与邻居的通信已经丢失来处理。
如果在配置的若干个 hello_interval 内，通过 REQUEST 或 ACK 对象都没有从邻居收到任何 Instance 值，则节点必须推定自己无法与该邻居通信。该数值的默认值为 3.5。
当通信丢失，或者按上述方式被推定为丢失时，节点可以重新发起 HELLO。如果节点确实重新发起，则它必须使用与先前 HELLO 消息中通告的值不同的 Src_Instance 值。这个新值必须持续向对应邻居通告，直到发生复位或重启，或者检测到另一次通信故障为止。如果尚未从邻居收到新的实例值，则节点必须在 Dst_Instance 值字段中通告 0。
5.4 多链路考虑 (Multi-Link Considerations)
如前所述，Hello 扩展的目标是检测节点故障，而不是逐条链路的故障。当相邻节点之间只有一条链路，或者一对节点之间的全部链路同时失效时，节点故障与链路故障的区分实际上并无意义，对此类故障的处理方式已经在前文有所论述。当邻居之间存在多条链路时，则有特殊的考虑。当邻居之间的链路是编号链路时，必须在每条链路上运行 Hello，前文描述的机制均适用。
当链路是无编号链路时，链路故障检测必须由 Hello 之外的其他手段提供。每个节点应当与邻居只进行单一的 Hello 交换。所有链路全部失效的情形，等同于上一节提到的未收到任何值的情形。
5.5 兼容性 (Compatibility)
Hello 扩展不影响任何其他 RSVP 消息的处理。其唯一的作用是允许更早地宣告链路（节点）down 事件。RSVP 对该状况的响应保持不变。
Hello 扩展是完全向后兼容的。Hello class 被赋予形如 0bbbbbbb 的 class 值。视实现而定，不支持该扩展的实现要么静默丢弃 Hello 消息，要么以 "Unknown Object Class" 错误作为响应。无论哪种情况，发送者都将收不到对其所发 Hello 的确认。
6. 安全考虑 (Security Considerations)
原则上，这些对 RSVP 的扩展不会带来超出 RFC 2205[1] 之外的安全风险。但是，信任模型有轻微的变化。在普通 RSVP 会话上发送的流量可以按照源地址、目的地址以及端口号进行过滤。而在本规范中，过滤仅基于入站标签进行。因此，管理方可能希望限制能够建立 LSP 隧道的域范围。这可以通过在各个端口上设置过滤器，拒绝处理带有 LSP_TUNNEL_IPv4 (7) 或 LSP_TUNNEL_IPv6 (8) 类型 SESSION 对象的 RSVP Path 消息来实现。
7. IANA 考虑 (IANA Considerations)
IANA 为 RSVP 协议参数分配取值。在本文档中定义了 EXPLICIT_ROUTE 对象和 ROUTE_RECORD 对象。这两个对象都包含子对象。本节定义子对象编号的分配规则。本节采用 BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15] 中的术语。
EXPLICIT_ROUTE 子对象类型 (EXPLICIT_ROUTE Subobject Type)
EXPLICIT_ROUTE 子对象类型是一个 7 位编号，用于标识子对象的功能。没有取值范围限制，所有可能的取值均可供分配。
遵循 [15] 中概述的策略，0 - 63（0x00 - 0x3F）范围内的子对象类型通过 IETF 共识（IETF Consensus）程序分配，64 - 95（0x40 - 0x5F）范围内的编码按先到先得（First Come First Served）分配，96 - 127（0x60 - 0x7F）范围内的编码保留供私有使用（Private Use）。
ROUTE_RECORD 子对象类型 (ROUTE_RECORD Subobject Type)
ROUTE_RECORD 子对象类型是一个 8 位编号，用于标识子对象的功能。没有取值范围限制，所有可能的取值均可供分配。
遵循 [15] 中概述的策略，0 - 127（0x00 - 0x7F）范围内的子对象类型通过 IETF 共识程序分配，128 - 191（0x80 - 0xBF）范围内的编码按先到先得分配，192 - 255（0xC0 - 0xFF）范围内的编码保留供私有使用。
本文档作出了以下分配。
7.1 消息类型 (Message Types)
Message Message
Number Name
20 Hello
7.2 类编号与 C-Type (Class Numbers and C-Types)
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel
7.3 错误码与全局定义的错误值子码 (Error Codes and Globally-Defined Error Value Sub-Codes)
以下列表对 [RFC2205] 中定义的错误码与错误值基本列表进行了扩展。
Error Code Meaning
24 Routing Problem
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
25 Notify Error
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
7.4 子对象定义 (Subobject Definitions)
C-Type 为 1 的 EXPLICIT_ROUTE 对象的子对象：
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
C-Type 为 1 的 RECORD_ROUTE 对象的子对象：
1 IPv4 address
2 IPv6 address
3 Label
8. 知识产权考虑 (Intellectual Property Considerations)
IETF 已被告知，本文档所含规范的部分或全部内容涉及已主张的知识产权。更多信息请查阅在线的权利主张列表。
9. 致谢 (Acknowledgments)
本文档包含曾出现在先前若干 Internet 草案中的想法与文本。本文档的作者谨向那些草稿的作者表示感谢，他们是 Steven Blake、Bruce Davie、Roch Guerin、Sanjay Kamat、Yakov Rekhter、Eric Rosen 以及 Arun Viswanathan。我们还要感谢 Bora Akyol、Yoram Bernet 和 Alex Mondrus 对本文档提出的意见。
10. 参考文献 (References)
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
[4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
[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.
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 2751, January 2000.
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels", RFC 3210, December 2001.
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[14] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
11. 作者地址 (Authors' Addresses)
Daniel O. Awduche
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703-298-5291
EMail: [email protected]
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703 847 1801
EMail: [email protected]
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
EMail: [email protected]
Tony Li
Procket Networks
3910 Freedom Circle, Ste. 102A
Santa Clara CA 95054
EMail: [email protected]
Vijay Srinivasan
Cosine Communications, Inc.
1200 Bridge Parkway
Redwood City, CA 94065
Voice: +1 650 628 4892
EMail: [email protected]
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8143
EMail: [email protected]
12. 完整版权声明 (Full Copyright Statement)
Copyright (C) The Internet Society (2001). All Rights Reserved.
本文档及其译文可以被复制并提供给他人，对其加以评注或解释、或者协助其实施的衍生作品可以被编写、复制、出版和分发，不受任何限制，前提是所有此类副本和衍生作品中均包含上述版权声明和本段文字。但是，本文档本身不得以任何方式修改，例如删除版权声明或对 Internet Society 及其他 Internet 组织的引用，除非是出于制定 Internet 标准的需要——此时必须遵循 Internet 标准制定过程中所定义的版权程序——或者是按将其翻译为英语以外其他语言的要求所必需。
上文授予的有限许可永久有效，Internet Society 及其继承者或受让人不会将其撤销。
本文档及其所含信息按 "AS IS"（按现状）基础提供。互联网学会（THE INTERNET SOCIETY）与互联网工程任务组（THE INTERNET ENGINEERING TASK FORCE）不提供任何明示或默示的保证，包括但不限于任何关于本文所含信息的使用不会侵犯任何权利的保证，以及任何关于适销性或适用于特定目的的默示保证。
致谢 (Acknowledgement)
RFC 编辑者职能的运作经费目前由 Internet Society 提供。