资源预留协议,什么是资源预留协议

资源预留协议,什么是资源预留协议

资源预留协议（RSVP）是一种用于互联网上质量整合服务的协议。 RSVP 允许主机在网络上请求特殊服务质量用于特殊应用程序数据流的传输。路由器也使用 RSVP 发送服务质量（QOS）请求给所有结点（沿着流路径）并建立和维持这种状态以提供请求服务。通常 RSVP 请求将会引起每个节点数据路径上的资源预留。 RSVP 只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。RSVP 运行在 IPV4 或 IPV6 上层，占据协议栈中传输协议的空间。RSVP 不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者路由选择协议。正如路由选择和管理类协议的实施一样，RSVP 的运行也是在后台执行，而并非在数据转发路径上。RSVP 本质上并不属于路由选择协议， RSVP 的设计目标是与当前和未来的单播（unicast）和组播（multicast）路由选择协议同时运行。 RSVP 进程参照本地路由选择数据库以获得传送路径。以组播为例，主机发送 IGMP 信息以加入组播组，然后沿着组播组传送路径，发送 RSVP 信息以预留资源。路由选择协议决定数据包转发到哪。 RSVP 只考虑根据路由选择所转发的数据包的 QOS 。为了有效适应大型组、动态组成员以及不同机种的接收端需求，通过 RSVP ，接收端可以请求一个特定的 QOS[RSVP93] 。 QOS 请求从接收端主机应用程序被传送至本地 RSVP 进程，然后 RSVP 协议沿着相反的数据路径，将此请求传送到所有节点（路由器和主机），但是只到达接收端数据路径加入到组播分配树中时的路由器。所以， RSVP 预留开销是和接受端的数量成对数关系而非线性关系。 协议结构

•Version ― 协议版本号，当前为1。

•Flags ― 还没有定义标志位。

•Message Type ― 可能值有：1 Path，2 Resv，3 PathErr，4 ResvErr，5 PathTear，6 ResvTear，7 ResvConf。

•RSVP Checksum ― 用于信息差错的校验和。

•Send TTL ― 信息发送时的 IP TTL 值。

•RSVP Length ― RSVP 信息二进制形式下的总长，包括通用头和可变长对象。

RSVP基本特点

RSVP是Resource ReSerVation Protocol的缩写，原来的研究背景是会议应用，现被IETF集成服务工作组认为是集成服务 中通用的资源预留解决方案。RSVP本身不是一个路由选择协议，它仅仅被用来沿着所选定 的路由预留资源。其预留建立在流的基础上，流由IPv4的地址字段或IPv6的流标识来指定 ，路由器根据为该流建立的预留来调度分组的转发。

作为一个新的信令协议，RSVP有以下基本特点：

预留请求由是接收方发起，由接收方根据自身系统的特定环境和接收愿望指定不同的资源 预留。这种接收方起动的模式原则上允许系统的异构性。既支持单点投递的资源预留，也支持多点间的群组通信资源预留，并且它的过滤机制允许预留的资源可以被多个发送者共享或对同一个发送者的预留进行合并。它既可以用于主机，也可以用于路由器。资源预留的建立在转发数据之前完成，其资源预留是单向的。 用软状态指示预留的存在状态，周期性地被刷新，从而支持动态的成员和路由变化。 RSVP在端系统和路由器上的开销通常与接收方数目的对数成正比。RSVP传输维护通信量控制以及策略控制的参数对RSVP来说是不透明的。RSVP支持几种预留模式（或风格），以适应各种应用，同时对不支持RSVP的路由器提供旁路作用。

RSVP协议机制

一个RSVP会话被定义成三元组：(DestAddress, ProtocolId [, DstPort])。 其中 DestAddress表示所传送数据分组的目的IP 地址； ProtocolId 表示 IP 协议标识；DstPort是一个选项，表示通用目的端口，如被 UDP/TCP 目的端口域定义。

RSVP的流描述由流规范"Flowspec" 和过滤规范 "Filterspec"组成。流规范说明流所需的QoS，设置在结点分组调度或其它链路层机制的参数，包括服务类别和两个参数集。一个是"Rspec"，定义流所需的QoS对网络资源的预留；另一个是"Tspec" ，定义相关的数据流特性。这些参数定义不是RSVP本身的工作，由IEFT其它研究组负责。

过滤规范定义特定的流，它们是一些数据分组集合，接收在同一个流规范里定义的QoS。通常，过滤规范与发送方地址相关，有严格的格式，如：发送方IP地址和可选的UDP/TCP 端口号。流规范和过滤规范通过相应的RSVP消息传递。

为了在结点上建立合适的预留，必须根据一定的接入策略和目前网络的接入能力来决定是否接收该预留请求。策略控制是回答这个用户是否允许使用该资源，而接入控制是回答是否有足够的可利用资源满足该请求。通常，RSVP要求在网络的边缘、来自多个发送方的数据汇聚点和上游的通信量可能大于下游预留量的分支点进行策略控制。由于Internet上不同的管理域可能有不同的预留策略，RSVP可以在相应的消息中传递策略数据，而对数据的处理不属于RSVP本身的功能。

RSVP靠两个时间参数来维护软状态（路径状态和预留状态），一是刷新周期R，另一个是本地状态的生命期L。每隔R时间间隔，发送方和接收方要发送相应的刷新消息，且R也决定了L的大小。

在每个中间结点，一个预留请求将触发两个动作：对链路产生一个预留和向上游转发请求。在路径上的结点可能支持RSVP或某种服务类别，也可能不支持，它们通过标志位标明，这被称为带广告的一次通过"One Pass With Advertising" (OPWA)。这个机制可以被接收方用来构造、调整一个合适的预留请求。

RSVP功能规范

RSVP通过结合目的地址、运输层协议类型和目的端口号标识一个通信会话，每个RSVP操作仅仅申请一个特殊的会话分组，每个RSVP消息必须包括它所申请的会话细节。在路由器和主机上要分类出属于同一个流的数据分组，并根据为该流制定的预留来处理。RSVP仅仅帮助路由器和主机建立软状态，而资源和通信量管理则在很大程度上取决于系统所支持的服务类别。

目前RSVP支持IETF的两类服务：确保服务GS（Guaranteed Service）和负载控制服务CS（Controlled-load Service）。GS确保数据报在确定的时间内到达接收端，并且当网络负载过重时，不被从队列中溢出。它要求应用指定通信量参数（如带宽、端端延迟等），常用于需要严格保证无丢失、准确达到的实时传输应用上。CS很象轻度载荷下的Internet尽力而为BE（Best Effort）服务。它与BE的主要区别在于当网络负载加重时，CS流不会明显的恶化，相反，BE流会有很大的延迟或丢失的可能。

RSVP会话通过Tspec说明流的通信量。Tspec包括：平均速率，峰值速率，最大突发尺寸。 对于GS来说，通信量应该被整形，以符合Tspec；而对于CS来说，在源端不强制整形，违规的分组允许通过一致性检查点。目前RSVP不建议在一个群组通信中各接收方使用异种服务，但参数可以不同。

RSVP把沿发送方到接收方传递路径上的结点称为“下一跳”，反方向的结点称为“上一跳”，它们是相对于一次连接而定义的。

RSVP有三种预留过滤风格：固定过滤FF（Fixed Filter），通配过滤WF（Wildcard Filter），共享过滤SE（Shared Explicit）。这三种风格定义了不同的过滤合并机制，即要将每个路由器接口上收到的预留量按某种规则选取最大的，然后再向发送方向的上一跳路由器转发。

设RS表示预留过滤说明，Flitestyle表示过滤风格，预留说明定义为：

RS::=Flitestyle（Fliterspec{Flowspec}）；Flitestyle::=FF|WF|SE

FF风格明确选择了发送方，即Fliterspec指示唯一的发送方标识。每个路由器的输入接口，根据在其上收到的所有FF风格的Fliterspec，把对同一Fliterspec预留的Flowspec最大值定为该接口收到的有效预留量。在输出端口上向上一跳转发的有效预留量是路由器上包含该发送方的最大FF预留量。

WF风格不指定发送方，即Fliterspec是一个通配符*。每个路由器的输入接口，将该接口上收到的所有WF风格的最大预留量定为该接口收到的有效预留量。向每个上一跳转发的有效预留量是路由器上所有输入接口的最大WF预留量。

SE风格指定一组发送方，即Fliterspec是一个发送方标识集合。每个路由器的输入接口，根据该接口上收到的所有SE风格的Fliterspec，取在Fliterspec并集上的最大预留量为该接口收到的有效预留量。向上一跳转发的有效预留量是路由器上包含该发送方的最大SE预留量。过滤合并只能在同样的预留风格中进行，其中SE和WF可用于群组通信的预留。

在请求预留时，一旦发生下面两种“预留杀手问题”之一，要尽量满足可能的预留。一种是如果已存在一个预留Q0，当一个新的预留Q1可能在与Q0合并后，不能通过上游某个结点的接入控制，那么，应当保留对Q0的预留，将Q1请求挂起。另一种是一个较大的请求Q1， 尽管在某些结点上未能通过接入控制，但还是坚持要预留，此时如果有一个较小的预留请求Q0发生了，且通过了路径上所有结点的接入控制，系统应当为Q0建立预留。

RSVP消息

RSVP有两类消息：PATH和RESV。PATH类从源到目的，RESV类从目的到源，它们与一个特殊的数据流相关联，并被封装在IP或UDP数据报中。PATH类消息包含：Path, PathTear, ResvErr, ResvConf4种消息，RESV消息包含 Resv, ResvTear, PathErr3种消息。其中 Path和 Resv是主要的消息。

Path消息包含上一跳地址（为回送Resv消息而设）；发送方模板（由发送方IP地址和发送端口组成）；发送方通信量说明（即Tspec）；与QoS类别相关的广播选项。在传输途中，被RSVP使能的路由器截获后，该路由器上为这个RSVP流建立路径软状态（包含上一跳和下一跳的地址和通信量特征），并修改Path消息的有关参数，再向下一跳转发。到达接收方后，若接收方想为其产生一个资源预留，则回答一个Resv消息。

Resv消息用三种预留风格之一指示预留请求，还包含下一跳地址（为返回确认或失败消息而设）。当被途中RSVP使能的路由器截获时，如有可利用的资源，就在路由器上建立一个预留软状态，经过过滤合并后，继续向上游转发。否则，产生一个ResvError消息，表示预留失败，送给接收方，导致下游各路由器删除已建立的预留软状态，同时终止转发Resv消息。一旦Resv消息到达发送方，意味着一个端到端的资源预留被成功建立。

RSVP接口

RSVP在网络和端系统上都要相应的接口来支持不同控制和处理功能，同时必须考虑到网络的各组成元素，其资源的能力是多样化的－从高速网络链路和快速工作站到经由窄带链路连接的低端个人计算机，要通过适当的数据流过滤支持异构系统的集成服务。在中继系统上要在UDP或IP包头中指示RSVP协议类型，然后安装一系列处理RSVP消息的程序，支持软状态的建立，并根据预留和数据之间的联系，在数据传输时执行预留。在端系统的主机上，要建立一个RSVP应用程序接口（RAPI）库，一个用户级的RSVP守护进程，和位于内核的QoS管理器。需要预留资源的应用通过RAPI与RSVP守护进程交互，RSVP守护进程负责将RAPI调用转换成RSVP信令消息和本地资源管理功能调用，本地资源管理通过QoS管理器完成。QoS管理器负责建立、改变、删除预留的控制信息。

RSVP 在路由器上的接口要为传递RSVP消息选择路由、建立状态并与相应的通信量控制（流分类、接入控制和分组调度）交互信息。RSVP和通信量控制的接口分与IP层、网络层和链路层驱动器的接口。对于有效的QoS链路层，如ATM，路由器负责与链路层协商，以保证链路层安装合适的QoS。这种向链路层映射QoS是与媒体相关的，近来，IETF的专门工作组正在定义映射的机制；对于无效的QoS链路层，如租用线路，映射到链路层的QoS不是十分重要，因为传输能力完全由路由器的分组调度所操纵。

在主机端的接口，负责与应用连接和进行相应的通信量控制。 应用和RSVP的接口要完成会话注册、定义发送者、预留请求和预留释放操作。