目录
大纲………………………………………………………………………………………4
观点………………………………………………………………………………………4
介绍………………………………………………………………………………………4
RSVP的发展 ……………………………………………………………………………7
运行总的看法：RSVP扩展以支持LSP隧道……………………………………………8
LSP隧道 …………………………………………………………………………………9
建立一条LSP隧道………………………………………………………………………10
RSVP PATH信息…………………………………………………………………………10
RSVP RESV信息…………………………………………………………………………11
预留类型 ………………………………………………………………………………11
RSVP隧道信息详细资料 ………………………………………………………………11
PATH信息 ………………………………………………………………………………12
LABEL_REQUEST对象 …………………………………………………………………12
EXPLICIT_ROUTE对象（ERO）…………………………………………………………13
RECORD_ROUTE对象（RRO）…………………………………………………………14
SESSION，SENDER_TEMPLATE，FLOW_SPEC，及FILTER_SPEC对象C型扩展…… 15
SESSION_ATTRIBUTE对象………………………………………………………………16
RSVP信息 ………………………………………………………………………………17
LABEL对象………………………………………………………………………………17
扩展的RSVP是如何建立一条LSP隧道…………………………………………………18
PATH信息 ………………………………………………………………………………19
LSR1（输入LSR）处的处理……………………………………………………………20
LSR2处的处理 …………………………………………………………………………20
LSR3处的处理 …………………………………………………………………………21
LSR4（输出LSR）处的处理 …………………………………………………………21
RSVP信息 ………………………………………………………………………………21
LSR4（输出LSR）出的处理……………………………………………………………21
LSR3处的处理 …………………………………………………………………………22
LSR2处的处理 …………………………………………………………………………22
LSR1（输入LSR）处的处理……………………………………………………………22
业务如何通过LSP进行传输……………………………………………………………23
现有的LSP隧道如何进行重路由………………………………………………………23
预留类型 ………………………………………………………………………………24
固定滤波器（FF）类型 ………………………………………………………………24
共享明确（SE）类型 …………………………………………………………………25
LSP隧道重路由处理……………………………………………………………………25
建立初始LSP隧道………………………………………………………………………26
将来重路由LSP隧道……………………………………………………………………26
为Internet核心而增强的 RSVP可扩展性………………………………………………27
捆绑信息扩展 …………………………………………………………………………28
MESSAGE_ID扩展 ………………………………………………………………………29
MESSAGE_ID对象 ………………………………………………………………………29
MESSAGE_ID_ACK对象…………………………………………………………………30
更新扩展的摘要 ………………………………………………………………………30
Hello协议扩展……………………………………………………………………………30
结论 ……………………………………………………………………………………31
参考 ……………………………………………………………………………………31
Internet草案 ……………………………………………………………………………31
RFC………………………………………………………………………………………32
参考书籍 ………………………………………………………………………………32
其它参考 ………………………………………………………………………………32
大纲
Internet服务提供商（ISP）们不断面临来自于在管理他们的网络高速增长的同时，维持一个用于重要任务应用的可靠基础结构方面的挑战。多协议标记交换（MPLS），由于其支持流量工程，而在新型公共网络中被作为一项重要的技术。流量工程是通过将大量的用户业务转移到经过服务提供商网络中特定节点的预先设定的路径来实现的。这些预先设定的路径被称作标记交换路径（LSP）。
这篇白皮书将阐述IETF的资源预留协议（RSVP）是如何被扩展而能够自动建立穿过服务提供商网络的LSP。白皮书的第一部分将讨论流量工程的方法，然后讨论传统的RSVP是如何被扩展一支持MPLS的LSP信令。白皮书的核心部分提供的详细的例子来说明如何使用RSVP建立LSP，用户业务如何通过LSP，及LSP在网络故障时如何进行重路由。白皮书总结了最新的RSVP扩展如何解决传统RSVP“软状态”模式所面临的扩展性和稳定性问题。同时，这篇白皮书还提供了一些RSVP的背景信息，它假设您对在RFC2205机RFC2209中定义的传统RSVP有一个基本的了解。
观点
由于手动配置一条LSP的开销非常大，许多服务提供商希望通过使用信令协议自动完成这一处理。LSP的明确路由可以通过定制的管理工具离线计算，或使用基于约束的路由在线计算。信令协议在由明确路由计算处理选定的网络节点分配标记及建立LSP转发状态。本白皮书中所描述的RSVP扩展允许服务提供商动态的建立通过其网络的LSP，使网络对不断变化的条件作出更为有效的反映，同时节约了时间并减少了运行费用。
介绍
流量工程参与将业务流映射到网络物理拓扑上的任务，它提供了将业务流重通过内部网关协议（IGP）计算出的最短路径转移到一条具有更少阻塞的路径上去的能力（图1）。流量工程的目的
图1：流量工程
在于在网络中的不同链路，路由器及交换机之间均衡业务流，使这些网络组成部分不会被过分使用或未被充分使用。流量工程使Internet服务提供商能够充分使用他们的网络基础结构。
关于Juniper网络公司流量工程结构的详细描述，请参考白皮书“新型公共网络中的流量工程”。
因为流量工程是一个极为有力的工具，通过将处理自动化及使服务提供商可以简单地在其骨干网中实施流量工程，可以获得许多好处：
· 减少了管理机运行的费用
· 网络运行最为有效
· 在网络压力及不稳定期间进行动态的流量工程
· 为增值业务及附加业务提供可靠的基础结构
Juniper网络公司的MPLS流量工程结构包括4个基本组成部分：
· 信息发布机制提供可用网络资源信息－－这一部分通过定义相关的IGP简单扩展来实现，使链路属性作为每个路由器链接状态广播的一部分。包括最大链接带宽，最大可预留带宽，当前预留带宽，当前带宽使用及链接着色等流量工程扩展被加到IGP链接状态广播中去。
· 路径选择处理部分使用IGP链接状态广播所发布的信息选择一条满足业务流特定需求的路径－－这一处理既可以通过离线计算来实现，也可以通过使用基于约束的路由在线完成。
· 信令部分用来预留资源及由LSP路由计算处理选择的网络节点上建立路径状态。在Juniper网络公司结构中，这一任务通过配置一些IETF认可的RSVP扩展来实现，这些扩展使RSVP能够在MPLS网络中作为信令协议工作。这篇白皮书将主要讨论这些扩展。
· 分组转发部分（MPLS）将业务沿由基于约束路由计算所得到的明确路径进行转发－－有关MPLS的详细讨论及其在服务提供商网络中的应用，请参考Juniper网络公司的白皮书“多协议标记交换：新型公共网络中的增强路由”。
很明显，负责建立穿过网络的LSP状态的信令协议在自动流量工程处理中扮演着重要的角色。一个成功的信令解决方案需要提供于LSP隧道运行有关的许多重要任务：
· 提供建立一条区别于“普通”IGP计算路径的明确路由LSP的机制。一条明确路由是一系列预先配置的作为LSP物理路径一部分的LSR。
· 提供下行标记分配，发布及按路径中的LSR需求进行捆绑，进而在网络节点中建立路径状态。
· 沿路径随机地提供资源预留或服务等级以满足业务流的需求。
· 为网络管理员提供LSP使用的实际路由信息。
· 支持全局及局部修复以动态重路由一条LSP，使其避开网络阻塞及故障。
· 重新分配以前分配的网络资源，通过管理策略控制抢占现存LSP，以建立新的、承载更为重要业务的LSP。
· 在LSP建立初始及重路由现有LSP时阻止循环形成。
· 监测及管理明确路由LSP的状态。
Juniper网络公司流量工程结构的信令部分基于一组IETF认可的RSVP扩展，以支持所有这些功能要求。
RSVP的发展
90年代中期，RSVP被开发以防止网络阻塞，它通过允许路由器事先决定它们是否能够满足应用流的需求，然后在可能的情况下预留所需资源来完成。最初，RSVP被设计成为主机间的特定业务流安装与资源预留有关的转发状态。穿过服务提供商网络业务流的物理路径通过传统的基于目的的路由（即，IGP）来确定。到1997，RSVP成为被建议的标准，现在被广泛配置在IP网络设备中。但是，RSVP并未在服务提供商网络中广泛应用，因为运行人员关心其需要潜在地支持数百万条主机－主机业务流的扩展性及开销。
图2：传统RSVP与扩展的RSVP的比较
最初的MPLS设备选择扩展RSVP成为信令系统以支持LSP的建立，使其能够自动地绕开网络故障及阻塞。RSVP通过自动进行流量工程处理提供了简化网络运行所需的重要部分。作为流量工程信令协议应用RSVP与其原本在90年代中期开发者的预想大不相同（见图2）：
· 在基本的RSVP规范（RFC2205和FRC2209）上增加了许多扩展以支持明确路由LSP的建立及管理。
· RSVP信令发生在一对作为业务中继输入及输出点的路由器（而不是主机对）之间。扩展的RSVP安装状态并应用于一组共享一条公用路径和共享网络资源的业务流的集合，而不是应用于单条的主机到主机的业务流。通过汇集许多主机到主机业务流至一条LSP隧道，扩展的RSVP明显地减少了服务提供商网络核心部分管理所需的RSVP状态数量。
· RSVP信令安装与分组转发有关的分布的状态，包括MPLS标记分配。
· RSVP的软状态模型的扩展性，迟延，及业务开销通过一系列扩展减少了刷新信息数量及相关的信息处理需求。
· 通过RSVP信令建立的路径并不被传统的基于目的的路由所限制，因此，它是建立流量工程中继的优秀工具。
在1997年初，最初的MPLS设备有许多原因选择扩展RSVP而不是设计一个全新的信令工具以支持流量工程需求。
· RSVP原来被设计成为Internet资源预留协议，为在一系列多点传送或单点传送传输路径中建立及管理分布的预留状态提供了一个通用的工具。资源预留是流量工程的一个重要的部分，因此，为这一目的继续使用RSVP而不是从头开始设计是有意义的。
· RSVP通过允许承载不透明对象的设计以支持扩展机制－－RSVP在其消息部分将对象作为一块不透明的信息承载而在路由器中提供适当的控制模块。这种基本的设计鼓励了对用于建立和维护信息分布状态的新RSVP对象的开发，而不是纯粹的资源预留。流量工程的设计者相信可以快速、简单地开发出一系列扩展以增强RSVP支持重要的流量工程需求－－明确路由及标记发布。
· 被推荐的扩展并未使扩展的RSVP实施与传统的RSVP实施不兼容－－RSVP的实施可以通过对消息部分所包含的对象进行简单地检验容易地区别LSP信令和标准的RSVP预留。
· 通过实施建议的扩展，RSVP提供了一个无与伦比的信令系统，它提供了网络管理人员动态建立LSP所需的所有需求：
· 扩展的RSVP沿一条明确路由建立LSP以支持大型服务提供商对流量工程的需求。
· 扩展的RSVP通过为在LSP中的LSR分配标记捆绑信息来建立LSP状态。
· 扩展的RSVP能够对在LSP中的LSR预留网络资源（传统RSVP的角色）。扩展的RSVP同时也允许LSP不做特殊的资源预留而承载最努力的业务。
运行上总的看法：RSVP扩展以支持LSP隧道
这一部分将提供一个概要的观点来阐述基本的RSVP规范是如何被扩展以支持LSP隧道的建立。它着重在以下要点：
· LSP隧道
· RSVP消息类型
· 预留类型
LSP隧道
在Juniper网络公司的流量工程体系结构中，输入LSR基于IBGP下一跳决定哪些分组被分配到特定的LSP。输入LSR通过输出LSR学习到远端的报头，在同一自治域（AS）内的路由器使用IBGP，而不是EBGP来交换路由信息。输出LSR使用EBGP与不同AS内的输入LSR进行通信。
图3：输入LSR基于IBGP下一跳选择输出LSR
服务提供商通常希望能够设计一条在输入和输出LSR之间的传输路径。依靠IBGP下一跳是实现这一任务的方便的方法，同时也提供了将潜在的数千条IP报头汇集到一个MPLS标记中的好处。这种实现方法可以明显地减少建立穿过服务提供商网络所需LSP隧道的数量。同时，这种实现方法提供了一个强有力的工具，减少了在大型服务提供商网络互联交换节点间通信的信息量。在图3中，到ISP的输入LSR通过使用单一的LSP将位于或可通过ISP1或ISP2到达的报头的所有业务转发至到输出LSR。
一旦输入LSR分配给分组一个标记，此标记将有效地定义业务流至穿过服务提供商骨干网的LSP。LSP通常是指一条LSP隧道，因为业务流通过它时对于LSP所包括的每个中间LSR是不透明的。为支持LSP隧道特性，扩展的RSVP定义了一个新的RSVP会话期对象，称作LSP_TUNNEL_Ipv4。这类对象通知每个LSR，属于特定LSP隧道的业务必须基于由此会话期中到上行发送者的本地LSR分配的带有特定标记的前一跳进行识别。这里，我们知道，基本的RSVP规范只定义了两个会话期C－类型，IPv4/UDP会话期对象和 IPv4/UDP会话期对象。
建立一条LSP隧道
为建立一条LSP隧道，输入LSR发送一个RSVPPATH消息下行至输出LSR。输出LSR通过向输入LSR发送一个上行RSVPRESV信息对接收到RSVPPATH消息作出反应。当输入LSR接收到RSVPRESV消息时，LSP被建立，输入LSR可以使用LSP隧道将业务转发至输出LSR（图4）。
图4：建立一条LSP隧道
RSVP PATH 消息
输入LSR产生一个带有LSP_TUNNEL_IPv4类型的会话期的RSVPPATH消息。PATH消息包含一个LABEL_REQUEST对象以请求中间LSR和输出LSR为此路径提供一个标记捆绑。如果路径中并不是每个LSR都支持LABEL_REQUEST对象，则此不支持LABEL_REQUEST对象路径中的第一个LSR会通知输入LSR。
除LABEL_REQUEST对象外，RSVPPATH消息中还包括其它一些可选对象：
· EXPLICIT_ROUTE对象（ERO）－－可被增加以为穿过服务提供商网络LSP指定一条的预先定义路径。当ERO出现时，RSVPPATH信息沿由ERO指定的路径向输出LSR方向被转发，不受IGP最短路径的约束。
· RECORD_ROUTE对象（RRO）－－允许输入LSR接收LSP隧道穿过服务提供商网络所经过的LSR列表。
· SESSION_ATTRIBUTE对象－－可被包含在RSVPPATH消息内以保证会话期鉴定及诊断。SESSION_ATTRIBUTE对象同时业控制路径建立优先级，支持优先级，和本地重路由特性。这些特性将在下面进行讨论。
RSVP RESV消息
当输出LSR接收到包含LABEL_REQUEST对象的PATH消息时，它通过传输一个包含LABEL对象的RESV消息作出反应。LABEL对象包含下行LSR与其上行邻居通信所用的标记捆绑。RESV消息向输入LSR的上行方向发送，其方向与PATH消息发送方向相反。每个处理带有LABEL对象的RESV消息的LSR对与特定LSP相关联的输出业务使用接收标记。当RESV消息到达输入LSR时，LSP被建立。
预留类型
每个LSP必须采用一个明确的预留类型被建立。预留类型通过输出LSR单独地被确定。但是，Juniper网络公司的实施方案可以通过设置或清除PATH消息内的SESSION_ATTRIBUTE对象所包含的“输入节点可以重路由位”来允许输入LSR向输出LSR表达其希望的预留类型（如下所述）。
输出LSR可以从RSVP固定滤波器（FF）或RSVP共享明确（SE）预留类型中选择。传统的RSVP通配符滤波器（WF）预留类型因为其合并规则及流量工程目的应用的缺陷而未被使用。正象我们将要在这篇白皮书后面看到的，预留类型是一个非常重要的角色，因为它决定了RSVP信令如何支持LSP的基本功能－－对一条已有的LSP隧道进行重路由。
RSVP隧道消息细节
这一部分将详细讨论为标准RSVPPATH及RESV消息支持流量工程所作的IETF认可的行令扩展。
PATH消息
当希望建立一条LSP隧道时，PATH消息将由输入LSR向输出LSR方向传送。PATH消息的地址被定义为指向输出LSR，但是其在IP报头中包含了路由器告警IP选项（RFC2113）以表示报文需要中间路由器对其进行特殊处理。PATH消息可以包括多种不同的RSVP对象：
· LABEL_REQUEST对象
· EXPLICIT_ROUTE对象
· RECORD_ROUTE对象
· SESSION_ATTRIBUTE对象
· CoS FLOWSPEC对象
LABEL_REQUEST对象
为建立一条LSP隧道，输入LSR将产生一条包含LABEL_REQUEST对象的PATH消息。 LABEL_REQUEST对象的存在表示这条LSP需要标记捆绑。LABEL_REQUEST对象同时也包含第三层协议ID（L3PID）用于识别将在LSP隧道中传输的第三层协议。需要L3PID是因为假设LSP隧道传输IPv4业务是不可能的－－L3协议不能够从L2报头获得，只能简单的识别MPLS为更高一层的协议。
共有3种可能的LABEL_REQUEST对象类型：
· 请求不定义特定标记范围的标记－－这是一种普通的情况，MPLS标记在位于数据链路层和网络层报头之间的标准MPLS添加报头中承载。
· 请求定义了带有最小和最大VPI及VCI值的ATM标记范围的标记－－这种类型的请求在MPLS标记由第二层ATM报头承载时十分有用。
· 请求定义了带有最小和最大DLCI值的帧中继标记范围的标记－－这种类型的请求在MPLS由第二层帧中继报头承载时十分有用。
当一条PATH消息到达一个LSR时，该LSR将LABEL_REQUEST对象存储在此LSP的本地路径状态模块中。如果定义了标记范围，则标记分配处理必须在这一范围内分配标记。
可能的错误条件包括：
· 如果接收到PATH消息的LSR识别出LABEL_REQUEST对象，但并不能分配标记，其将向输入LSR发送一条PathErr消息（表示一个路由问题或MPLS标记分配故障）。
· 如果接收方不支持L3PID，其将向输入LSR发送PathErr（路由问题/不支持L3PID）－－这个错误将导致LSP建立会话期失败。
· 如果收到信息的LSR未能识别出LABEL_REQUEST对象，其将向输入LSR发送PathErr（未知的对象类别）－－这个错误将导致LSP建立失败。
EXPLICIT_ROUTE对象（ERO）
通过对PATH消息增加EXPLICIT_ROUTE对象（ERO），输入LSR可以为LSP定义一条预先确定的明确路由，而与传统的IP路由独立。ERO只能用于单点传送应用及必须所有明确路由上的路由器都支持RSVP和ERO的情况。
一条明确路由通过一系列包含在ERO内的子对象进行编码。每个子对象能够识别明确路由中的一组节点或定义沿路径执行的一个操作。因此，一条明确路由是路径中一组规定的需要通过的节点和一组需要执行的操作。
每组节点被称作一个抽象节点。如果一个抽象节点只包括一个节点，它被称作简单抽象节点。例如，一条明确路由可只由AS号子对象组成。同时每个AS可能包含多个跳转点，对于明确路由，它们对源节点是不透明的。图5说明了每个子对象是如何在ERO中进行编码的。
图5：ERO子对象编码
如果设置了L位，子对象在明确路由中将描述成疏松跳转。如果L位被清除，则其在明确路由中为精确跳转。
目前共定义了4种类型的EXPLICIT_ROUTE子对象：
· IPv4报头－－识别一个抽象节点包含具有IP报头为IPV4的一系列节点。具有32位长度的报头表示一个IPV4节点。
· IPV6报头－－识别一个抽象节点包含具有IP报头为IPV6的一系列节点。具有128位长度的报头表示一个IPV6节点。
· 自治域号码－－识别一个节点包含一系列属于同一自治域的节点。
· MPLSLSP终止－－表明优先抽象节点应当从所有使用这一LSP隧道的分组中移去一级标记堆栈。
图6描述了使用32位IPV4报头定义的精确明确路由。
图6：明确路由例子
明确路由中疏松节点的存在意味着短时间内在覆盖型路由协议中可能会产生转发循环，LSP隧道中的循环可以通过RECORS_ROUTE对象检测到，如下面所讨论的。
RECORD_ROUTE对象（RRO）
通过对PATH消息增加RECORD_ROUTE对象（RRO），输入LSR可以接收到LSP隧道穿过的实际路由的信息。RRO的内容是一组被称作子对象的数据项。目前定义了两种类型的子对象，IPV4地址和IPV6地址。
在RSVP信令中，RRO共有3种可能的应用：
· 发现层3路由循环或明确路由的固有循环，这是因为RRO与路径向量类似。
· 一跳接一跳的收集LSP建立会话期的最新详细路径信息。
· 通过较小的改变，它可以输入到EXPLICIT_ROUTE对象中。其将被用于下一条PATH消息中的EXPLICIT_ROUTE对象以“锁定会话期路径”。如果LSP被锁定，其将不允许改变，即便有更好的路径出现。
当输入LSR试图建立一条LSP隧道时，它将产生一条包含LABEL_REQUEST对象的PATH消息。PATH消息也可以同时包含一个RRO对象。最初的RRO包含输入LSR的IP地址。当中间路由器接收到一个包含RRO的PATH消息时，路由器将在其路径状态模块中存储一个RRO的拷贝，并将自己的IP地址加到RRO中去。当输出LSR接收到一个带有RRO的PATH消息时，它将RRO加入到其后来的RESV消息中去。在交换了PATH和RESV消息之后，路径上每个路由器都将会有一个从输入到输出的LSP的完全的路由。能够对完全路由进行访问对网络管理的目的是非常有用的。
SESSION，SENDER_TEMPLATE,FLOW_SPEC，和FILTER_SPEC对象C－类型扩展
扩展的RSVP为SESSION，SENDER_TEMPLATE,FLOW_SPEC，和FILTER_SPEC对象定义了新的C－类型。C－类型在一个给定的对象级别内定义了特定的对象类型。例如，在SESSION对象级别内，共有3种对象C－类型：
· IPV4/UDP会话期（C－类型1）
· IPV6/UDP会话期（C－类型2）
· LSP_TUNNEL_IPV4会话期（C－类型7）
SESSION对象C－类型（LSP_TUNNEL_IPV4）
增加SESSION对象至PATH消息的目的是识别及诊断会话期。新的LSP_TUNNEL_IPV4C－类型包括隧道输出节点的IPV4地址和一个唯一的16位标识符，这一标识符在LSP隧道生命周期内持续保持不变。
SENDER_TEMPLATE对象C－类型（LSP_TUNNEL_IPV4）
PATH消息被要求承载SENDER_TEMPLATE对象，以描述改特定发送者产生此数据分组时使用的格式。这一模板位于FILTER_SPEC表格中，FILETER_SPEC通常用于在同一链路上的相同会话期中从其它发送者分组中选择出某一发送者的分组。扩展的RSVP定义了一个新的SENDER_TEMPLATEC－类型（LSP_TUNNEL_IPV4），它包含了发送节点的IPV4地址和一个唯一的16位标识符LSP_ID，此标识符可以改变以允许发送者共享自己的资源。这个LSP_ID将在对使用共享明确（SE）预留类型建立的LSP隧道进行重路由时使用（见“现有的LSP隧道如何进行重路由”）。
FLOWSPEC对象C类型（CLASS_OF_SERVICE）
FLOWSPEC是一个传统的RSVP对象，它定义了业务流所希望的QoS。FLOWSPEC通常包括：
· 服务号码－－定义控制负载及保证的服务
· TSPEC（业务指标）－－描述发送者希望产生的业务。TSPEC可选择令牌桶滤波器的形式或峰值速率的上缘。
· RSEPC（服务请求指标）－－定义希望的QoS。RSPEC的内容及形式只对应特定的服务。RSPEC可以包含分配给业务流的带宽，最大迟延，或分组丢失率等信息。
在许多情况下，LSP并不要求象在传统的综合业务模型中定义的特定带宽预留或QoS保证。当特定的资源并未分配给LSP时，服务等级FLOWSPEC将在RSVPPATH消息中显示。服务等级FLOWSPEC允许RSVP建立一条只提供最努力业务的LSP隧道，而无任何特定的资源预留。
当LSR在沿LSP隧道转发每个分组时，服务等级FLOWSPEC提供了应当使用的CoS值。值为0时表示相关的业务为最努力业务。这项工作已经在IETF内部开始以更新IPTOS位（现在被称作DS字节）。
FILTER_SPEC对象C－类型（LSP_TUNNEL_IPV4）
FILTER_SPEC连同SESSION对象定义了一系列由FLOWSPEC对象定义了服务的数据分组（业务流）。扩展的RSVP定义了一个新的FILTER_SPECC－类型（LSP_TUNNEL_IPV4），它包含了发送者节点的IPV4地址和一个唯一的16位标识符－－LSP_ID，此标识符可以被更改以允许发送者能够共享自己的资源。这个LSP_ID将在对使用共享明确（SE）预留类型建立的LSP隧道进行重路由时使用（见“现有的LSP隧道如何进行重路由”）。
SESSION_ATTRIBUTE对象
SESSION_ATTRIBUTR对象可被添加到PATH消息内以控制LSP优先级，抢占，及快速重路由功能。
目前在SESSION_ATTRIBUTE的8为标志位中定义了3位：
· 本地保护位－－如果设置，传输LSR可以使用本地修复机制，其可能导致妨碍EXPLICIT_ROUTE对象。通过对这一位进行设置，输入LSR通知传输LSR它们可以提供JUNOS“快速重路由”功能。
· 合并允许位－－如果设置，传输LSR能够将此会话期与其它RSVP会话期合并以减少下行传输LSR的资源消耗。这一位并未在当前的MPLS/RSVP实现中使用。
· 输入节点可以重路由位－－如果设置，输入节点可在不拆除LSP的情况下对其进行重路由。通过对这一位进行设置，输入LSR通知输出LSR当对相应的RESV消息作出反应时使用共享明确（SE）预留类型。
建立优先级定义了此LSP隧道在获取其它现有LSP资源时的优先级。该值的范围从0到7，0为最高优先级。建立优先级在决定一条LSP隧道是否能够抢占另外一条LSP时被使用。
保持优先级定义了此LSP隧道在其它LSP试图占用其资源时保持资源的优先级。该值范围从0到7，0为最高优先级。保持优先级在决定一条LSP隧道是否能够被另一条LSP抢占时使用。
RESV消息
RESV消息从输出LSR向输入LSR传输以响应PATH消息的接收。RESV消息通过发布标记捆绑，研路径请求资源预留，及定义预留类型（固定滤波器或共享明确）在每个LSR中建立路径状态。
RSVPRESV消息包含多种不同的RSVP对象：
· LABEL对象－－提供“按需上行”的标记分配处理
· RECORD_ROUTE对象－－将LSP路径还给PATH消息的发送者
· SESSION对象－－单独识别建立的LSP
· STYLE对象－－定义预留类型（固定滤波器或共享明确）
LABEL对象
LABEL对象在RESV消息中承载。这一对象可以包含单一的MPLS标记或标记堆栈。如果MPLS实施方案不支持标记堆栈，则只有顶端的标记被检验。对于FF和SE预留类型，标记将被提供给LSP的每个发送者。
图7描述了一个LSR是如何处理RESV消息中的LABEL对象的：
图7：LSR处理LABEL对象
· 当LSR收到一个与以前PATH消息相关的RESV消息时，它确定该RESV消息是由LSP下一跳发送。LSR将输入标记与接收接口进行捆绑，并使用这一捆绑将与LSP相关的业务转发到其下行邻居。图7中，LSR将所有通过LSP隧道的业务流由接口2转发出去，同时并带有标记值20。
· 当LSR接收到RESV消息时，它将一个本地分配的标记（在此例中为10）捆绑至LSP的输入接口（接口1）。输入接口是指LSR接收到与此LSP有关的PATH消息的接口。
· LSR使用值10建立一个新的LABEL对象，使用新的标记值替换接收到的RESV消息中的顶端标记，然后将RESV转发到LSP中的前一跳。LSR使用存储在LSP路径状态模块中的信息确定前一跳，路径状态模块是使用接收到的初始PATH消息建立的。
在不同接口上接收到的RESV消息中的标记通常被认为是不同的，即使标记值是相同的，因为每个标记都只有本地链接范围，而不是全局范围。
扩展RSVP如何建立LSP隧道
这一部分将讲述扩展的RSVP如何将来一条LSP隧道。图8描述了这一例子将使用的拓扑。
图8：网络拓扑
假设：
· LSR1，LSR2，LSR3，和LSR4上都配置了MPLS和RSVP并且都被使能。
· 通过某些机制，LSR1知道LSP需要遵循明确路由（LSR1至LSR2至LSR3至LSR4）。
· ERO的每个抽象节点的L位都被清除（明确路由中的精确跳转），并且是一个简单抽象节点（只由一个通过32位IPV4报头定义的节点组成）。
我们希望建立一条LSP以传输从LSR1进入服务提供商网络并由LSR4离开服务提供商网络的业务。传输的业务应当采用LSP的物理路径而不是通过IGP计算得到的路径（LSR1至路由器A至LSR4）通过网络。其结果是，所有从LSR1进入服务提供商网络的传输业务（LSR4作为IBGP下一跳）都将沿LSP进行转发。
LSP物理路径通过另一种处理被选择是为了：
· 减少IGP路由上的业务流总量。
· 优化网络资源的总体使用效率。
· 增强业务流的业务导向性能参数。
· 增强整个网络的业务导向性能参数。
PATH消息
LSR1负责初始化LSP的建立。遵从标志RSVP信令的过程，LSR1发送PATH消息至LSR4。PATH消息在去往LSR4的途中经过LSR2和LSR3。
LSR1（输入LSR）处的处理
1.为建立LSP，LSR1建立PATH消息，其包含：
· EXPLICIT_ROUTE对象（ERO）－－描述为建立LSR1与LSR4间的LSPPATH消息所应遵循的物理路径。
· LABEL_REQUEST－－表明路径上所有LSR都要求进行LSP的标记捆绑，及LSP需承载由L3PID定义的协议。
PATH消息同时也可包含下列RSVP信令扩展：
· RECORD_ROUTE对象（RRO）－－允许输入LSR接收实际路由路径的信息。这一信息对于循环检测及诊断很有用处。
· SESSION对象－－唯一定义此LSP隧道。
· SESSION_ATTRIBUTE－－控制LSP优先级，抢占，及快速重路由。
PATH消息同时也包括下面一些标准的RSVP对象：
· SENDER_TEMPLATE－－包含发送者的IP地址及可能的一些识别PATH消息发送者的信息。
· SENDER_TSPEC－－描述将沿LSP发送的业务流的业务参数。LSR4使用这一信息建立适当的RECEIVER_TSPEC（描述业务流）和RSPEC（定义希望的QoS）。TSPEC及RSPEC的格式和内容对RSVP不透明，其由IETF的综合业务工作组定义。
2.如果LSP希望承载最努力业务，不要求分配资源，则控制负责服务被要求具有零突发及零速率。
3.PATH消息将沿ERO定义的路由向LSR4传输。这里，PATH消息的目的为输出LSR，但其包含路由告警IP选项以表示此数据报需要中间路由器进行特殊处理。
LSR2处的处理
1.当PATH消息到达LSR2时，它在其路径状态模块中记录LABEL_REQUEST对象及ERO。路径状态模块同时也包括前一跳的IP地址，会话期，发送者，及TSPEC。这些信息用于将相关的RESV消息路由回LSR1。
2.LSR2沿ERO定义的路径将PATH消息向LSR4转发。
3.如果LSR2不能为LSP分配一个标记，它将通过发送一个带有“未知对象级别”的路径错误信息给LSR1作出反应。
LSR3处的处理
1.当PATH消息到达LSR3时，它在其路径状态模块中记录LABEL_REQUEST对象及ERO。路径状态模块同时业包含前一跳，会话期，发送者，和TSPEC。这些信息将用于把相关的RESV消息路由回LSR2。
2.LSR2沿ERO定义的路径将PATH消息向LSR4转发。
3.如果LSR3不能为LSP分配一个标记，它将通过发送一个路径错误消息给LSR1作出反应。
LSR4处的处理（输出LSR）
1.当PATH消息到达LSR4时，它将从LABEL_REQUEST对象中得知其为LSP的输出LSR。
RESV消息
遵循标准的RSVP处理过程，LSR4为会话期产生一个RESV消息以分配标记和为LSP隧道建立转发状态（图9）。RESV消息的IP目的地址是前一跳节点的单点传送地址，从LSR的本地路径状态模块中获得。
图9：RESV消息发布标记
在LSR4处的处理
1.LSR4分配给标记的值为0，并将其放置在RESV消息中的LABEL对象内。值为零对LSR4有特殊的意义。当LSR4接收到一个标记值为零的分组时，它知道其为LSP的输出LSR。LSR4简单地弹出标记并依据包含在IP报头内的目的IP地址对分组进行转发。
2.如果LSR1在PATH消息内插入了一个TSPEC，LSR4将使用这一信息建立一个适当的接收者TSPEC及RSPEC。
3.RESV消息通过LSR3向回传送。RESV消息并不承载一个“反向”ERO去寻找回到LSR1的路径。作为替代，RESV将依照RSVPPATH消息在路径状态模块中建立的反向路径进行传输。在某种程度上，PATH消息留下了一些痕迹以允许RESV消息循着此反向路径返回LSR1。
LSR3处的处理
1.LSR3接收到包含由LSR4分配的标记的RESV消息。
2.LSR3将标记（0）作为LSP预留状态的一部分存储。LSR3在沿LSP向LSR4转发输出业务时使用这一标记。
3.LSR3分配一个新的标记（20）并将其放置在RESV消息的LABEL对象中（替换接收到的标记），然后将其上行发送向LSR2。LSR3使用这个标记来识别LSP上来自LSR2的输入业务。
LSR2处的处理
1.LSR2接收到包含由LSR3分配的标记的RESV消息。
2.LSR2将标记（20）作为LSP预留状态的一部分进行存储。LSR2在沿LSP向LSR3转发输出业务时使用这一标记。
3.LSR2分配一个新的标记（10）并将其放置在RESV消息的LABEL对象中（替换接收到的标记），然后将其上行发送向LSR1。LSR2使用这一标记来识别LSP上来自LSR1的输入业务。
LSR1处的处理
1.LSR1接收到包含由LSR2分配的标记的RESV消息。它对所有映射到这一LSP的输出业务使用这个标记。
2.作为这些操作的结果，LSP依照ERO内定义的明确路由路径从LSR1到LSR4被建立。LSR1通过将从LSR2接收到的标记（10）压入标记报头对报头为X的业务转发向LSR2。
传输业务如何穿过一条LSP
假设LSP象例1中描述的那样被建立。这个例子描述了传输业务是如何通过LSP被转发的（图10）。
图10：通过LSP转发业务
1.一个标准IP分组到达LSR1的接口1。在其IP路由表中执行完最长匹配查询后，LSR1发现最佳的匹配为前缀X，而且所有与前缀X匹配的业务应在接口2进行转发并带有标记＝10。LSR1将IP分组封装至一个MPLS帧，将标记10压入标记头，然后将MPLS分组从接口2转发出去。
2.LSR2从接口1接收到一个标记＝10的MPLS分组。它基于（接口，标记）对进行固定长度查询，得到分组应被从接口2转发出去并带有标记＝20。LSR2交换现有的标记（10），从接口2将MPLS分组传送出去并带有标记＝20。
3.LSR3从接口1接收到标记＝20的MPLS分组。它基于（接口，标记）对进固定长度查询，得到分组应从接口2转发出去并带有标记＝0。LSR3交换现有的标记（20），从接口2将MPLS分组传送出去并带有标记＝0。
4.LSR4从接口1接收到标记＝0的MPLS分组。因为MPLS帧具有标记值为0，LSR4知道它为LSP隧道的输出LSR，它必须基于包含在分组IP报头内的目的地址作出转发决定，而不足执行MPLS查询。LSR4在其IP路由表中执行最长匹配查询，发现此IP目的地址最佳匹配为前缀Y，所有匹配前缀Y的业务都将作为普通的IP业务在接口2上进行转发。
如何对现存的LSP隧道进行重路由
流量工程的基本要求之一是对一条已建立的LSP隧道进行重路由。对于流量工程，可能有许多原因需要对LSP隧道进行重路由：
· 管理策略在一条“更优”的路由出现时可能需要一条LSP被重路由。
· LSP路径中的链路或路由器故障通常需要LSP被全局或本地重路由。
· 当发生故障的链路或路由器恢复运行时，管理策略可能要求一条曾被重路由的LSP恢复到原来的路径。
当一条LSP被重路由时，用户的业务流不被中断是非常重要的。平稳的转换要求对一个被称为“中断前产生”概念的支持－－新的LSP隧道必须被建立，业务必须在旧的LSP隧道被拆除前被转移。RSVP信令的好处之一就是传统的共享明确预留类型为这一具有挑战性的问题提供了极佳的解决方案。
在被旧的和新的LSP隧道共享的链路上，很基本的，由旧LSP隧道使用的资源不能在业务转换到新的LSP隧道前被释放。但是，至关重要的是，预留不能在共享链路上被计数两次，因为这样可能导致RSVP管理控制由于资源缺乏而拒绝新的LSP隧道。共享明确预留类型允许旧的和新的LSP隧道共享它们共同所在链路的单一预留，使新的LSP隧道不必要因为链路资源的缺乏而必须等到旧LSP隧道清除后才能完成。
预留类型
每个LSP必须使用一个明确的预留类型被建立，此预留类被输出LSR单独地确定。输出LSR可以从任何一种RSVP预留类型中选择。这一部分将阐述这些可选预留类型的操作参数。
固定滤波器（FF）类型
固定滤波器（FF）预留类型定义了一个明确的发送者列表，并对每个发送者定义单独的预留。每个发送者具有一个单独的预留，不与其它发送者共享。每个发送者通过IP地址及一个本地标识号码－－LSP_ID－－被定义。因为每个发送者有其自己的预留，可以为每个发送者－接收者对建立一个唯一的标记和一个单独的LSP。对于传统的RSVP应用，FF预留类型对于视频发送应用是非常理想的，在这种应用中，每个频道（或源）需要为每个不同的视频流提供单独的管道。
在扩展的RSVP中，不同的发送者这一术语可能是十分令人困惑，直到您意识到每个发送者和接收者指的是路由器上不同的接收者和发送者，而不是不同的终端系统（见图11）。FF预留类型允许建立多条，并行，单点传送，点对点LSP。如果LSP穿过一条公用链路，这条共享链路上的总的预留带宽是每个单独发送者所做预留的总和。FF预留类型适用于并行发生并相互独立的来自不同发送者的业务。
图11：固定滤波器（FF）预留类型
共享明确（SE）类型
共享明确（SE）预留类型在链路上建立一个单一预留，这一预留可被一系列明确列出的发送者共享。因为每个发送者都被明确地列在RESV消息中，不同的标记能够被分配到不同的发送者－接收者对，因此建立分离的LSP。
图12：共享明确（SE）预留类型
图12描述了SE预留类型在一条共享链路上的运行状况。每个LSP都有其穿过共享链接的自己的标识，但两条LSP共享了最大的带宽请求。如我们将在下一部分了解到的，SE预留类型的适用是一个非常重要的工具，因为它允许RSVP信令在对一个已建立的LSP隧道进行重路由时完美地支持“中断前产生”。
LSP隧道重路由过程
这一部分描述了RSVP如何在LSP被重路由时或在其被试图增加其可用带宽时建立一条维持资源预留（不双重计数）的LSP。
建立初始LSP隧道
在初始的PATH消息中，输入LSR：
· 组成一个LSP_TUNNEL_IPV4会话期对象，唯一地识别LSP隧道。LSP_TUNNEL_IPV4会话期对象包含：
· LSP隧道双重节点的IPV4地址
· 输入输出LSR间LSP隧道的TUNNEL_ID，其将在此LSP整个生命周期中保持不变。
· 识别隧道输入节点的Extended_Tunnel_ID。（即，输入LSR的IPV4地址）
· 在SESSION_ATTRIBUTE对象中设置“输入节点可以重路由位”以要求输出LSR适用SE预留类型。
· 组成SENDER_TEMPLATE对象，其包括：
· 发送者（输入）节点IPV4地址
· LSP_ID，其可在将来被更改以允许输入LSR以不同的发送者出现，因此其可以在如果或当LSP需要被重路由时共享自己的资源（见SENDER_TEMPLATE对象和FILTER_SPEC对象中LSP_TUNNEL_IPV4C类扩展所包含的LSP_ID部分）。
接收到PATH消息之后，输出LSR向输入节点发送一个带有SE预留类型的RESV消息。当输入LSR接收到RESV消息时，带有SE预留类型的初始LSP便被建立了。
建立重路由LSP隧道
当输入LSR想要对一条已有的LSP增加带宽或更改其路径时，它发送一个新的PATH消息。在重路由运行过程中，输入LSR必须以两个不同的发送者出现在RSVP会话期中。此种情况是通过在SENDER_TEMPLARE和FILTER_SPEC对象中包含新的LSP_ID实现的。
在新的PATH消息中，输入LSR：
· 为新的LSP隧道建立一个EXPLICIT_ROUTE对象（ERO）
· 适用已有的LSP_TUNNEL_IPV4会话期对象识别将要被重路由的LSP
· 选取新的LSP_ID并建立新的SENDER_TEMPLATE。通过为SENDER_TEMPLATE选择新的LSP_ID，输入LSR以不同的发送者出现在RSVP会话期中。
输入LSR向输出LSR发送新的PATH消息。但是，输入LSR继续使用旧的LSP隧道对业务进行转发并继续刷新原来的PATH消息。
输出LSR通过RESV消息对接收到的新PATH消息作出反应，RESV消息包括一系列
RSVP对象：
· 用来支持“按需上行”标记分配处理的LABEL对象
· SE预留类型对象
在未被旧的和新的LSP隧道共享的链路上，新的PATH/RESV消息对被作为常规的LSP建立对待。但是，在被旧的和新的LSP隧道共同穿过的链路上，LSP_TUNNEL_IPV4会话期对象及SE预留类型允许新的LSP隧道被建立，这样，它可以与旧的LSP隧道共享资源。这样便避免了在共享链路上的“双重计数”问题。在输入LSR接收到新LSP的RESV消息后，它可以开始使用新的LSP隧道转发业务。输入LSR应当为旧的LSP隧道发送一条PATH_TEAR消息以拆除中间LSR中就LSP隧道的状态。
增强RSVP扩展性，支持Internet核心网
一些Internet团体对在Internet核心网中使用RSVP作为信令协议的稳定性和扩展性表示关心。他们的关心主要表现在两个方面：
· LSR的开销（业务量和CPU使用量），因为RSVP是一个“软状态”协议，不是“硬状态”协议－－在软状态协议中，RSVPPATH及RESV消息必须在LSP隧道路径上的LSR中周期地进行刷新。如果刷新消息未被传输，LSP状态将自动超时而最终被删除。对RSVP持批评态度的团体关心当LSR试图处理经常的更新消息时，LSR将经历的开销。
· RSVP信令的时延及稳定性，因为RSVP并未运行在一个稳定的传输上（即，TCP）－－时延和稳定性问题可能在非刷新RSVP消息（PathErr，PathTear，ResvTear，或ResvConf）在传输过程中丢失时出现。如果这类消息丢失，基于LSR刷新间隔的RSVP信令端对端响应将经历丢失。当响应时间由刷新间隔限制时，建立或修改LSP的时间可能会超出特定应用所能接受的范围。这种关心可以通过降低刷新间隔来解决。但是，它将明显增加业务量及处理开销，进而引起刷新开销的问题。
为增强RSVP信令的扩展性，时延，和稳定性，定义了一系列扩展：
· 捆绑消息扩展
· MESSAGE_ID扩展
· 概要刷新扩展
· Hello协议扩展
这些扩展解决了用户所关心的问题，而无需对刷新间隔进行调整。它们有效地将RSVP从其传统的“软状态”模型转移到“固态”模型。在一个固态模型中，仍传输刷新消息，在支持稳定性的同时，业务量，CPU使用量，及响应时延都被降低。没有任何被建议的扩展导致与传统RSVP实施不兼容的问题。
捆绑消息扩展
捆绑消息扩展降低了必须周期的发送及接收的RSVP消息总量。捆绑消息包含一个捆绑报头，接下来是一个包含了多种标准RSVP消息的主体部分（见图13）。捆绑消息用于汇聚多条RSVP消息至一个单独的协议数据单元（PDU）内。
图13：RSVP捆绑消息
一条RSVP捆绑消息必须至少包含一个子消息。一个子消息可以包含除捆绑消息以外的其它RSVP消息。现在可用的子消息类型包括PATH，PathErr，RESV，ResvErr，ResvConf，ACK，或Hello。ACK及Hello消息将在下面讨论。
捆绑消息的地址被直接指向RSVP邻居，并使用协议号46（即，RSVP）作为“自然”IP数据报被发送。捆绑报头直接遵循IP报头，并没有中间传输报头。当RSVP路由器接收到一个并未指向其本地IP地址之一的捆绑消息时，它将转发此消息。非RSVP路由器对待RSVP捆绑消息就象对待其它IP数据报一样。
支持RSVP捆绑消息是可选的。当捆绑消息帮助扩展RSVP和减少处理开销及带宽占用时，节点并不需要使用捆绑消息传送每个RSVP消息。节点必须时刻准备接收及处理标准的RSVP消息。
MESSAGE_ID扩展
两个新的对象作为MESSAGE_ID扩展的一部分被定义：
· MESSAGE_ID对象
· MESSAGE_ID_ACK对象
这些对象通过实施承认机制以支持RSVP消息的可靠发送。而且，当刷新（使用PATH及RESV消息）被正常产生时，MESSAGE_ID可被用于对消息何时表现一个新的状态提供标识。接收节点可使用这一信息减少其花费在处理刷新消息上的时间总量。
MESSAGE_ID对象
MESSAGE_ID对象通过允许接收者简单地识别一个包含未改变状态信息的消息来降低刷新消息的处理。当路由器传送一个包含MESSAGE_ID的刷新消息时，其将传送相同的MESSAGE_ID值，该值在最初广播状态被刷新时放置在RSVP消息中。当一个节点需要传送一个表达了新的或修改了的状态的消息时，MESSAGE_ID的值被更改为一个比以前使用的值更大的值。如果一个LSR能够处理MESSAGE_ID_ACK对象，则在其传输包含MESSAGE_ID对象的刷新消息时，它可以选择设置ACK_DESIRED位。
当一个路由器接收到一条包含MESSAGE_ID的刷新消息时，它首先识别RSVP会话期，然后检验以前存储在它本地状态模块中的此RSVP会话期的值。如果在本地状态中不能发现有关MESSAGE_ID的值，则接收者必须对该消息进行完全的处理，因为它表示了一个新的或修改了的状态。但是，如果PATH或RESV消息中包含的MESSAGE_ID与同一会话期接收到的最近的消息所使用的相同 ，接收者则假设入站消息为一个状态刷新。
MESSAGE_ID_ACK对象
传输MESSAGE_ID_ACK对象用于通知所接收的含有MESSAGE_ID对象的消息在发送时设置了ACK_DESIRED位。ACK消息承载了一个或多个MESSAGE_ID_ACK对象，但可能不包含任何MESSAGE_ID对象。这种机制可以确保在网络丢失时对错误及确定消息可靠地传输，并支持快速刷新。
摘要刷新扩展
摘要刷新扩展支持在无需传输传统的PATH和RESV消息的情况下沿LSP隧道刷新RSVP状态。摘要刷新扩展的主要好处是它减少了为维持RSVP状态同步所需传输及处理的信息量。
摘要刷新消息承载了一系列MESSAGE_ID对象用于识别需要被刷新的PATH及RESV状态。当一个RSVP节点接收到一条摘要刷新消息时，它使用本地安装的PATH或RESV状态与每个接收到MESSAGE_ID对象进行匹配。如果MESSAGE_ID对象与绷带状态匹配，状态就象接收到一个标准的RSVP刷新消息那样被更新。但是，如果一个MESSAGE_ID对象未能与接收者本地状态匹配，接收者将发送一个刷新NACK来通知摘要刷新消息的发送者。一个刷新NACK通过在MESSAGE_ID_ACK对象中对REFRESH_NAK位进行设置来指出。
当使用摘要刷新消息更新RSVP会话期时，常规的刷新消息传输应被抑制。摘要刷新扩展不能用于包含与以前广播状态有改变的PATH或RESV消息。同时，只有那些在以前广播时包含哟MESSAGE_ID对象的PATH或RESV消息才能通过摘要刷新消息进行刷新。
Hello协议扩展
Hello协议用于检测邻居节点的丢失或重新设置邻居的RSVP状态信息。在标准的RSVP中，邻居监测作为RSVP软状态模型的一部分出现。预留状态向缓冲信息一样被维持，最初被安装，然后被输入和输出LSR周期性地进行刷新。如果状态未能在一个特定的时间间隔内被刷新，LSR将丢弃这个状态，因为它假设或者邻居节点丢失，或者它的RSVP状态信息被重新设置。
Hello协议扩展由Hello消息，HELLOREQUEST对象和HELLOACK对象组成。两个邻居间的Hello处理指出对故障检测间隔的独立选择。每个邻居可以自动发出HELLOREQUEST对象。每个HELLOREQUEST对象通过HELLOACK对象来回答。
结论
多年来，Juniper网络公司一直积极地参与IETF及和世界最大的IP网络运行商一起设计MPLS/流量工程应用的信令协议。这些服务提供商正是那些少数真正了解如何建设并管理大型IP基础结构，凭借他们在公共Internet上多年的实际经验。在通过IETF严格的测试及争论后，世界上最大和最具经验的ISP们确信扩展的RSVP已经足够成熟，可以在他们现在的实施计划中扮演重要的角色。
扩展的RSVP提供MPLS/流量工程应用信令所需支持的所有功能。它允许建立明确路由的LSP，提供标记分配功能，在LSP中支持资源预留或服务等级，并提供LSP穿过的物理路由信息。扩展的RSVP在对已有LSP进行重路由时可完美地支持“中断前产生”的概念，在建立一条新的LSP时允许对以前分配的网络资源进行重新分配，并在LSP建立时提供循环防止/检测。最后扩展的RSVP解决了由于传统RSVP的“软状态”模型所引出的扩展性，时延，及稳定性等问题。
参考
Internet Drafts
Awduche, D., J.Malcolm, J. Agogbua, M. O’Dell, and J. McManus, Requirements for Traffic Engineering over MPLS, draft-ietf-mpls-traffic-eng-01.txt, June 1999.
Awduche, D., L. Berger, D-H Gan, T. Li, G. Swallow, and V. Srinivasan, Extensions to RSVP for LSP Tunnnels, draft-itef-mpls-rsvp-lsp-tunnel-02.txt, March 1999.
Callon, R., A. Viswananthan, and E. Rosen, Multiprotocol Label Switching Architecture, draft-ietf-mpls-arch-05.txt, April 1999.
Callon, R., G. Swallow, N. Feldman, A. Viswanathan, P. Doolan, and A. Fredette, A Framework for Multprotocol Label Switching, draft-ietf-mpls-framework-03.txt, June 1999.
Yuhara, M and M. Tomikawa, RSVP Extensions for ID-based Refreshes, draft-yuhara-rsvp-refresh-00.txt, April 1999.
Request for Comments
RFC 2205, Resource ReserVation Protocol—Version 1 Functional Specification, R, Braden ED., L. Zhang, S. Berson, S. Herzog, and S. Jamin, Septerber 1997.
RFC 2207, RSVP Extensions for IPSEC Ipv4 Data Flows, L. Berger and T. O’Malley, September 1997.
RFC 2208, Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement – Some Guidelines on Deployment, A. Mankin, Ed., F. Backer, B. Braden, M. O’Dell, A. Romanow, A. Weinrib, L. Zhang, September 1997.
RFC 2209, Resource ReSerVation Protocol (RSVP) – Version 1 Message Processing Rules, R. Braden and L. Zhang, September 1997.
Textbooks
Davie, B., P. Doolan, and Y. Rekhter, Switching in IP Networks: IP Switching, Tag Switching, and Related Technologies, Morgan Kaufmann, 1998 (ISBN 1-55860-505-3).
Metz, Christopher, IP Switching: Protocols and Architectures, McGraw-Hill, New York, 1999 (ISBN 0-07-041953-1).
Other References
Zhang, L., S. Deering, D. Estrin, S. Shenker, and D. Zappala, RSVP: A New Resource ReSerVation Protocol, IEEE Network, September 1993.
