RSVP协议深入浅出

-----RSVP
一、概述
二、RSVP协议机制及原理
三、实例
一、概述
资源预约协议RSVP是用于建立Internet上资源预留的网络控制协议，它支持端系统进行网络通信带宽的预约，为实时传输业务保留所需要的带宽。

RSVP是为保证服务质量（QOS）而开发的，主机使用RSVP协议代表应用数据流向网络请求保留一个特定量的带宽，路由器使用RSVP协议向数据流沿途所有节点转发带宽请求，建立并且维护状态以提供所申请的服务。

RSVP对资源的申请是单向的，所以RSVP在申请资源的过程中发送端和接受端是逻辑上完全不同的两个部分。

（虽然发送端和接受端可以运行在同一个进程下）。

RSVP工作在IPv4或IPv6上，处于 OSI七层协议中的传送层，但是，RSVP并不处理传送层的数据，从本质上看，RSVP更象是网络控制协议，如ICMP （Internet Control Message Protocol），IGMP（Internet Group Management Protocol）或是路由协议。

和路由协议及管理协议的实现相同，RSVP的实现通常在后台执行，而不是出现在数据传送的路径上（图一）。

RSVP本身并不是路由协议，RSVP是和现在或是将来出现的点对点传播和多点组播协议一起工作的。

RSVP进程通过本地的路由数据库来获取路由信息，如在多点组播过程中，主机端送出IGMP报文来加入一个多点组播的组群，然后送出RSVP报文在组群的传送路径上保留网络资源，路由协议决定报文的走向，而RSVP仅关心这些报文在它将走的路径上能否获得满意的服务质量。

为了适应可能出现的大规模组群、动态组群、异类接受端的可能，RSVP
采取由接受端发起服务质量（QoS）申请的策略。

QoS请求从接受端的应用程序出发交给本地的RSVP驻留进程，再由该RSVP驻留进程将该请求递交给沿数据传送的反向路径（接受端至发送端）上的各个节点（路由器或是主机）进行资源的申请。

所以，RSVP协议在资源保留上花费一般是呈对数而不是线形幅度增长。

RSVP协议的框架结构和工作过程
RSVP协议的总体框架结构由5个模块组成，如图所示：
图：BSVP协议框架结构
1、决策控制(Policy Control)
决策控制用来判断用户是否拥有资源预留的许可权；
2、接纳控制(Admission Control)
接纳控制则用来判断可用资源是否满足应用的需求，主要用来减少网络负荷；
3、分类控制(Classifier Control)
分类控制器用来决定数据分组的通信服务等级，主要用来实现由filterspec指定的分组过滤方式；
4、分组调度器(Scheduler)
分组调度器则根据服务等级进行优先级排序，主要用来实现由flowspec指定的资源配置。

当一个主机请求获得具有特殊QOS的数据流传输时，RSVP就会对沿着数据流传输路径的每一个路由器发送此请求，并且使路由器和主机都保持各自的状态以便提供所需服务。

RSVP带着此请求经过传输路径上每一个节点，在各个节点上，RSVP都试着为数据流传输保留资源。

当RSVP处理模块收到预约资源的请求后，通过调用决策控制模块来检查用户预约资源的权限，调用接纳控制模块来检查是否有足够的资源来满足所请求的服务质量。

由于路由器在链路上保留的带宽不能超过链路本身的能力，因此每当路由器接收一个新的预约资源请求时，它必需首先判断多目标广播树下流链路的申请是否可以被接纳。

如果决策控制和接纳控制这两项检查成功，RSVP处理模块就启动分类控制模块和分组调度器设置相应的连接参数，建立资源预约。

同时，RSVP处理模块将预约资源的请求转发给数据路径的下一个节点。

其间如果有一步失败，RSVP处理模块将发送相应的出错信息给申请资源的端系统。

一旦资
源预约通过了数据路径上所有节点的检查，该数据流的网络传输便可以获得其请求的QOS 了。

分类控制模块和分组调度器为数据流提供预约资源后的服务。

分类控制模块查看数据包，分析包的IP和UDP/TCP头，确定其所在的流是否预约了资源、可获得何种QOS。

然后，分组调度器按照包的QOS做出转发决定，将包放入相应的传输队列。

应用程序在需要传输质量保证时调用RSVP，RSVP在数据传输路径上建立必要的状态，由分组调度器为数据报文实施具体操作。

应用程序发送的数据报文与RSVP无关，数据报文可以在预约还没有建立时发送，不过此时没有传输带宽的保证。

应用程序在需要传输质量保证时调用RSVP，RSVP在数据传输路径上建立必要的状态，由分组调度器为数据报文实施具体操作。

应用程序发送的数据报文与RSVP无关，数据报文可以在预约还没有建立时发送，不过此时没有传输带宽的保证。

RSVP协议具有下列特性：
1.RSVP可以在点对点传播和多点组播的网络通信应用中进行预留资源的申请，它可
以动态调节资源的分配以满足多点组播中组内成员的动态改变，和路由状态改变的
特殊需求。

2.RSVP比较简单，例如它只为单向的数据流申请资源。

3.RSVP是面向接受端的，由数据流的接受端进行资源申请并负责维护该数据流所申
请的资源。

4.RSVP在路由器和主机端维持“软”状态，解决了组群内成员的动态改变和路由的
动态改变所带来的问题。

5.RSVP并不是一种路由协议，它依赖于目前或将来出现的路由协议。

6.RSVP本身并不处理流量控制和策略控制的参数，而仅把它们送往流量控制和策略
控制模块。

7.RSVP提供几种资源预留的模式供选择以适应不同的应用需求。

8.RSVP对不支持它的路由器提供透明的操作。

9.RSVP支持IPv4和IPv6。

RSVP协议的数据流
RSVP把一次“对话”定义为在特定的目标地址和传送协议上的数据流。

RSVP的每次对话都是独立的。

一次RSVP对话可以由一个三元组（目的地址，协议号，[协议端口]）来表示。

这里的目的
地址，也就是IP 目的地址，既可以是多点组播地址，也可以是点对点传播地址。

协议号就是IP 协议号。

可选的协议端口就是目的地址的端口号（例如一些协议上所定义的多路复用点），它可以直接利用UDP 或TCP 的端口，或是其他协议中类似的域、甚至是应用层信息来定义。

虽然RSVP 是基于可扩展性提出和设计的，但是目前还是只能支持TCP/UDP 的协议端口，不过值得注意的是，由于不同的广播地址一般对应不同的对话连接，所以如果是广播地址的话，一般不必包含协议端口。

而单一接受端有多个点对点传播对话同时存在，这时必须使用协议端口。

图二说明了单个RSVP 进程中的数据包流动情况（假定为互联网上的多点组播通讯），箭头表示了数据从发送端S1、S2流向接受端R1、R2、R3。

中间的云代表了在分布环境下多点组播路由。

分布环境下的多点组播传送将任一发送端Si 送出的数据送往每一个接受端Rj ，而分布环境下的点对点传播只有一个接受端，每一个发送端是网上唯一标识的主机，而接受端可以通过协议端口的区分功能接受多个发送端的数据。

对点对点传播传送来说，一个接受端地址可以被多个发送端所共享，RSVP 可以处理这类“多对一”的传送模式。

资源保留模式
基本的RSVP 资源保留请求中包含一对域：“流规格域”和“筛选规格域”，这一对域也被称为“流描述”。

其中流规格域用来指定资源请求中的服务质量请求，筛选规格域同对话的规格说明一起定义了数据报是否能够接受流规格指定的服务质量。

流规格用来设定节点中的包调度器或是其他链路层相应机制中的一系列参数。

如果一个对话中的数据报不符合筛选规格，那么它就不能以服务质量的模式进行传送，而是由网络以BE （Best Effort ）模式传送。

在资源申请中的流规格说明中通常包含着服务等级和两个数字化的参量：Tspec 和Rspec 。

Rspec （R 代表保留Reserve ）用来定义需要保留的服务质量；Tspec （T 代表流量Traffic ）用来描述数据流。

Tspec 和Rspec 参数的具体内容由ISWG （Integrated Services Working Group)进行规格定义[RFC2210]，RSVP 对这些内容不做任何处理。

筛选规格的具体格式同TCP/IP 的版本有关（Ipv4或Ipv6）。

通常情况下，筛选规格用来选择对话中的数据报的一个子集，选择方式可以是通过发送端的一些特征常量：如发送端IP 地址，源端口等，当然原则上可以选择任何协议的任何域来进行筛选。

例如，可以用应用层协议中的域来区分不同的视频压缩流的不同压缩层面。

不过，处于简单化的目的，目前RSVP 中筛选格式的定义仅仅局限于发送端的IP 域和可选的UDP/TCP 端口号。

接受端S1
R1S2R2
R3图二、分布环境下的组播RSVP对话
RSVP协议在数据包接受端发起资源申请请求，并上行传送到发送端。

注意：在文章中将使用“上行”和“下行”、“上一跳”和“下一跳”、“入接口”和“出接口”来表示数据流的流向。

在每一个中间节点，一个资源申请请求将会导致两个操作：
1.在连接点上进行资源的保留。

RSVP进程将请求传送给接纳控制和策略控制，如果有一个控制进程返回错误，那
么请求将被拒绝，错误信息被送到提出该申请的应用中。

如果两个控制进程都返回
正确消息，就在包分类器中设置参数定义能够使用该服务质量的数据报筛选规格，
并由它来和正确的链路层进行通讯获取流规格所定义的服务质量。

具体的RSVP请求细节和接口板上所使用的链路层协议有着密切的关系。

ISSLL工
作组正在制定标准化的规范来把服务质量请求映射到链路层协议中去。

对于简单的
专用线上的数据传送，服务质量的获取是由链路层的包调度器实现的。

如果链路层
协议有自己的特定的服务质量的管理机制，那么RSVP进程必须和它进行协商来获
取所需的服务质量。

注意：虽然服务质量的请求发生在“下行”的接受端处，它的
实现却是在进入链路层的界面上，例如“上行”终点处的逻辑层或物理层。

2.“上行”传递服务质量的请求。

服务质量的请求由接受端进行传播送往相应的发送端。

从发送端到接受端的整个传
播路径称为该服务质量请求的“范围”。

“上行”的服务质量请求和“下行”的由发送端送往接受端的请求是不完全相同的，
有两个原因：1。

流量控制机制可能对流规范进行修改。

2。

更为重要的是，不同“广
播树”中的“下行”分支节点中的服务质量保留在“上行“过程中会进行合并。

当接受端进行服务质量请求的同时，它也可以进行请求一个确认信息来了解是否该请求已经在网络上被设定了。

一个已设定的请求就是在上行的某节点的所拥有的预留资源容量大于或等于该请求所需的资源容量。

在那个节点上，该请求就被合并入该节点中而不必再向前传递，这时，节点就可以发送资源保留确认信息返回接受端。

注意：这个收到的确认只是表示很大的可能性，而不是保证。

基本的RSVP请求是“单向”的：接受端发出“上行”资源预留请求，每个中间节点或是接受该请求或是拒绝，这样的方式使得接受端无法了解最终端到端系统的情况。

所以，RSVP提供一种增强的RSVP“单向”服务OPW A（One Pass With Advertisements）。

通过OPW A，RSVP控制报文沿着数据路径“下行”搜集那些端到端相关信息，然后把搜集到的信息（Advertisments）交给接受端或是接受端的应用程序。

这些信息将被用来构建或动态调整服务质量请求。

保留类型
包含一系列保留选项设置的资源保留请求被称为保留类型。

资源保留请求选项中定义了如何对待对话中不同发送端的不同的资源保留请求，如为每一个“上行”的资源保留请求申请特定的唯一的保留资源；或是为不同的发送端申请共享的资源使它们同时使用这段资源。

另一个选项定义了选择发送端的方式：可以是分别列出所涉及的发送端，或是利用通配符来选择对话中的所有发送端。

在前一种情况下，筛选规格说明必须完全符合其中的每个发送端，而在后一种情况下则不需要考虑规格说明。

目前定义了以下几种类型（见图三）：
1.WF类型
WF类型具有的特性是：共享式的保留模式和通配符式的发送端选择模式。

因此，
WF类型的保留模式创建单一的保留资源供所有的“上传”数据流使用。

这个保留
资源被认为是一个共享的资源，它的大小是所有接受端申请资源的最大值，而和发
送端的数量无关。

WF类型的保留将通知所有的发送端，当出现新的发送端时，这
个值将自动提供给它。

我们把WF类型的资源保留申请记作：
WF（*{Q}）
其中* 代表通配附，Q代表流规格。

2.FF类型
FF类型具有的特性是：独占的保留模式和分别列出的发送端选择模式。

因此，基
本的FF类型的为每个发送端创建唯一的保留资源。

而不和其他发送端共享。

我们把一个基本FF类型的资源保留申请记作：
FF（S{Q}）
其中S代表所选的发送端，Q代表流规格。

这两个符号代表了一个流
描述。

RSVP允许多个FF类型的资源保留同时进行，记为：
FF（S1{Q1}，S2{Q2}，……）
这样一个对话的资源保留的总数量为Q1，Q2，Q3……的总和。

3.SE类型
SE类型具有的特性是：共享的保留模式和分别列出的发送端选择模式。

因此，SE
类型的保留模式创建单一的保留资源供所有的“上传”数据流使用。

但和WF不同
的是，它允许以分别列出的方式来选择可以使用该保留资源的的发送端。

我们把一个具有Q的流描述和S1，S2，S3，……发送端的SE类型的资源保留记
作：
SE（（S1，S2，S3，……）{Q}）
共享的保留方式，象WF或SE类型，适合于那些基于广播并且广播的发送端不太可能同时发送数据的应用程序。

象分组音频就是一个非常适合这种类型的应用：由于很少有人会在会谈时同时说话，每个接受端可以为发送端申请一个WF或SE类型的双倍带宽保留（允许某些超载情况），另外，为每个发送端创建唯一的保留资源则十分适合于视频信号。

RSVP规定，不允许共享保留模式和独占保留模式进行合并，这是因为这两种模式在根本上是不兼容的。

同时，发送端的分别列出和通配附这两种模式也是不可以合并的，因为这样的合并会产生一些新的特殊的处理过程。

所以，WF、FF、SE这三种模式是互不兼容的。

我们可能会发现，似乎可以利用SE保留模式来完成WF保留模式，这只需在应用端发起WF申请时，由RSVP进程列出所有的发送端来创建一个等价的SE保留模式申请。

然而，SE模式在每个节点的包分类器中列出了每个发送端，而WF模式仅仅需要指出“这是一个通配附模式”就可以了。

所以在发送端数目巨大的时候，很显然WF模式在效率上大大超过SE模式，因为这个原因，这两个模式在协议中同时存在，而不用SE模式来仿真WF。

二、RSVP协议机制
RSVP 消息
资源预留由两类RSVP消息实现：PA TH消息和RESV消息。

当端系统的数据流需要在某条特定的网络路径上预约网络资源，它首先给目的地址发送一条PATH消息，描述发送源的数据格式、源地址、端口号和流量特性，该路径上的每个节点（路由器）都传递该消息，由于该消息运行的路径与发送方数据流的路径一样，因此，数据流接收者可以利用PATH消息了解到达发送源的反转路径，决定哪些资源应当预留。

然后接收者发送包含资源预留参数的RESV报文给上游路由器来建立和定期更新预留的状态，RESV报文由流规范和过滤规范组成，流规范决定路由器的包调度算法，过滤规范则指示包过滤器应当利用数据流中的那些包。

RESV消息依照PATH消息确定的路径上行，并在沿途节点设定资源预留参数，建立资
源预约。

之后，RSVP维护这些节点的状态以保证所请求的服务。

合并流规格
携带着所有经过路径的“最大”流规格的保留信息继续被发送到上一跳的节点上，我们说这个信息已经是被合并后的信息（章节5。

1中说明了这个过程），在这个新的节点上，我
们同样要将它和下一跳传来的其它保留信息进行合并，再次得出一个当前节点上合并后的“最大的流规格”。

由于流规格对于RSVP协议而言是“模糊”的，用来比较和计算流规格的过程必须定义在RSVP以外，如何定义这些过程在ISWG的文档中有详细说明，而RSVP进程只需调用这些过程来完成合并操作。

注意到流规格通常是多维的：它同时包含Tspec和Rspec，而且每个Tspec和Rspec也可能是多维的，所以对它们的比较是有严格规范的。

例如：如果一个请求是高带宽的而另一个希望是低延时的，就不能从这两个申请中挑选出一个大的来作为合并后的结果，而是需要产生一个新的流规格，这个规格必须大于其中任何一个申请，从数学角度上，这就是求一个最低的上边界（LUB Least Upper Bound），在某些情况下可能需要求的是比任何一个流规格小的值，称为最高的下边界（GLB Greatest Lower Bound）。

下面是用来计算接口上有效流规格的几个步骤（详见RFC2210）:
1．有效的流规格是在出接口上定义的，考虑到链路层的处理，需要把下几个节点的有效流规格进行合并，也就是计算这些节点有效流规格的LUB。

注意对流规格的合并是和链路层介质相关的，而如何进行合并是由服务模型定义的（见RFC2210）。

合并的结果是一个数对（Re,Resv_Te），其中Re是有效的Rspec，而Resv_Te是有效的Tspec。

2．使用一个服务相关的过程对Path_Te进行计算，把从前节点中得到的路径信息中的Tspecs进行总和计算。

3．把（Re,Resv_Te）和Path_Te交给流量控制，由它通过一个服务相关的过程来计算Path_Te和Resv_Te的最小值。

“软”状态
RSVP使用一种“软状态”的方式来管理和维护路由器和主机中的资源保留状态和路径状态，“软状态”是由保留信息和路径信息定期创建和刷新，如果在清除时间到期前没有合适的刷新信息到达，那么“软状态”信息就将被删除。

这个状态还可以由“卸载”命令直接删除。

每次过期情况发生或是状态改变后，RSVP将重新建立它的资源保留状态和路径状态并将它发往后继节点。

路径和保留状态是幂等的。

当一个路由变化时，下一个路径会建立新的路由的路径状态。

原来路径上的信息会由于超时而被删除。

因此一个节点的信息是否需要刷新是由各自节点依据本身情况决定的。

RSVP的信息是由无连接的数据报来发送的，周期性的刷新数据可能会在传送过程中丢失。

如果超时时间设置在K倍的刷新周期时间上，那么可以承受连续K-1次的传送错误而不错误删除有用的信息，所以需要手工配置网络以提供RSVP信息足够的带宽避免阻塞导致的RSVP信息丢失。

由RSVP维护的信息是动态变化的：改变某一个发送端服务质量的请求，主机端仅仅送出一个修改过的路径信息和保留信息，然后这个信息会沿着网络传送到所有相关节点，更新这些节点中的相应信息，而那些无用的状态或是被显式删除或是由于超时而删除。

在一个稳定中的系统下，状态刷新信息沿着传送路径一个接一个进行合并，当节点接收到的刷新信息和节点中存有的信息不同时，就将节点中存有的信息更新，如果更新同时需要改变后续节点的信息时，刷新信息必须立即产生并向下传送，如此，这些刷新信息就从端到端无延时地传送下去。

当刷新信息对该节点后续节点的刷新信息不产生影响时，该刷新信息
的传送就可以终止了。

这可以减少组群改变时刷新信息对网络带来的负载，对庞大的组群尤其有用。

清除消息
RSVP清除消息立即清除路径或预留状态，虽然明确的清除一个过时的资源预留状态并非必要，但仍然建议：一旦应用程序结束，终端应立即发送清除消息。

错误和确认信息
1.有两种RSVP出错消息，一种预留出错消息，另一种是路径出错消息。

2.为了请求对预留资源请求的确认，接收者在预留消息中必须包含一个确认请求对象。

RSVP 消息包格式
RSVP消息包由RSVP消息头段、RSVP对象段、对象内容3部分组成。

1、RSVP消息头段
RSVP消息头段的格式如下所示：（长度单位：bit）
版本号---4位，表示协议的版本号（当前版本为1）。

标志---4位，当前没有定义标志段。

类型---8位，表示消息的类型，下表是RSVP消息类型与其相对应的值：
校验和---16位，表示基于RSVP消息的内容上标准TCP/UDP校验和。

长度---16-位，表示RSVP包的字节长度，包括公共头和随后的可变长度对象。

如设置了MF标志，或片段偏移为非零值，这就是较大消息当前片段长度。

发送TTL---8位，表示消息发送的IP生存期。

消息ID---32位，提供下一RSVP跳/前一RSVP跳消息中所有片段共享标签。

更多片段(MF) 标志---占用一个字节的最低位，其它7位预订，除消息的最后一个片段外，都将设置MF。

片段偏移---24位，表示消息中片段的字节偏移量。

2、RSVP对象段
RSVP对象段的格式如下所示：（长度单位：bit）
长度---16-位，包含以字节计的总对象长度（必须是4的倍数，至少是4）。

分类号---表示对象类型，每个对象类型都有一个名称。

RSVP程序必须可识别分类，如没有识别出对象分类号，分类号高位决定节点采用什么行动。

C-类型---C类型，在分类号中唯一。

最大内容长度是65528个字节。

分类号和C-类型段(与标志位一起) 可用作定义每个对象唯一位的16位数。

3、对象内容
长度、类型号和C类型段指定对象内容的形式。

三、实例
通配符过滤器（WF）类型预留类型
不同种类的接收器
用户接入因特网的速率是多种多样的，有的使用28.8 Kb/s速率接收数据，有的使用128 Kb/s速率接收数据，而有的使用10 Mb/s甚至更高的速率接收数据。

这里就出现一个问题，向这些接收数据速率不同的用户广播时，发送端到底应该使用什么样的数据流速率对外广播，使用28.8 Kb/s还是使用10 Mb/s？如果使用28.8 Kb/s广播，使用10 Mb/s的用户就可能会嫌质量太低；如果使用10 Mb/s广播，使用28.8 Kb/s的用户就接收不到广播。

解决这个问题的一种方案是对声音或电视进行分层编码，每层的声音或电视的数据速率各不相同，以此来满足各种不同用户的要求。

在广播时，发送端并不一定要知道接收端的数据接收速率，而只需要知道这些用户中使用的最大数据接收速率即可。

发送端对声音或电视进行分层编码，并且把它们发送到广播树上，用户就根据自己的实际速率接收不同质量的广播。