资源预留协议查看源代码讨论查看历史
| 资源预留协议 |
|
中文名: 资源预留协议 外文名: Resource ReSerVation Protocol；RSVP 性 质: [[互联网[[上质量整合服务的协议 RSVP设计目标: 单播和组播选择协议同时运行 |
资源预留协议（Resource ReSerVation Protocol；RSVP）是一种用于互联网上质量整合服务的协议。RSVP 允许主机在网络上请求特殊服务质量用于特殊应用程序数据流的传输。路由器也使用 RSVP 发送服务质量（QOS）请求给所有结点（沿着流路径）并建立和维持这种状态以提供请求服务。
目录
资源预留协议,什么是资源预留协议
资源预留协议(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建立预留。[1]
资源预留协议
通常 RSVP 请求将会引起每个节点数据路径上的资源预留。
RSVP 只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。 RSVP 运行在 IPV4 或 IPV6 上层，占据协议栈中传输协议的空间。 RSVP 不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者路由选择协议。正如路由选择和管理类协议的实施一样， RSVP 的运行也是在后台执行，而并非在数据转发路径上。
RFC2205对RSVP的特征做出以下的描述：
（1）支持单播与组播；
（2）单向预留；
（3）接收者发起预留；
（4）维护Internet中的软状态。
RSVP设计目标
RSVP 本质上并不属于路由选择协议， RSVP 的设计目标是与当前和未来的单播（unicast）和组播（multicast）路由选择协议同时运行。 RSVP 进程参照本地路由选择数据库以获得传送路径。以组播为例，主机发送 IGMP 信息以加入组播组，然后沿着组播组传送路径，发送 RSVP 信息以预留资源。路由选择协议决定数据包转发到哪。 RSVP 只考虑根据路由选择所转发的数据包的 QOS 。为了有效适应大型组、动态组成员以及不同机种的接收端需求，通过 RSVP ，接收端可以请求一个特定的 QOS[RSVP93] 。 QOS 请求从接收端主机应用程序被传送至本地 RSVP 进程，然后 RSVP 协议沿着相反的数据路径，将此请求传送到所有节点（路由器和主机），但是只到达接收端数据路径加入到组播分配树中时的路由器。所以， RSVP 预留开销是和接受端的数量成对数关系而非线性关系。
RSVP是由接收者提出资源预留申请的，这种申请是单向的，也就是说为从主机a到主机b的数据流预留的资源，对于从主机b到主机a的数据流是不起作用的。因为在当前的internet中，双向的路由是不对称的：从主机a到主机b的路径并不一定是从主机b到主机a的路径的反向；另外一个，两个方向的数据传输特征和对应申请预留的资源也未必相同。
RSVP标准[RFC 2205]没有定义网络向数据流提供预约带宽的方法，它只是一个允许应用预约必要链路带宽的协议。一旦某预约付诸实施，英特网中的路由器就实际向数据流提供预约的带宽。
消息
有以下几种主要的消息：
路径消息
路径消息被沿着数据路径从发送方主机发送，并记录路径上每个节点的的路径状态。
路径状态包括先前节点的IP地址和一些数据对象：
sender template（发送方模板）是用于描述发送方数据格式
sender tspec（数据流的话务描述特征）是用于描述数据流传输特征
adspec携带广告数据
预留消息
预留消息(resv)是由接收方沿着反向路径发送到发送方。在每个节点上，预留消息的IP目的地址将会改成反向路径上下一节点的地址，同时IP源地址将会改成反向路径上前一节点的地址。预留消息包括流量说明(flowspec)数据对象，这个数据对象上用于确定流需要的资源。
RSVP消息的数据对象可以被按任何顺序进行传输。RSVP消息和其数据对象的所有列表可以在RFC 2205中看到。
拆除消息
拆除消息（Teardown）的作用是立刻删除预留的链路或状态。虽然没有必要显式地（Explicitly）删除一个原有的预留资源，IETF仍然建议所有的终端主机在应用结束时应该立即发送Teardown消息进行资源的显示释放。
Teardown消息有两种类型：路径拆除（PathTear）消息和预留请求拆除（ResvTear）消息。PathTear消息沿数据流的路由方向传递，删除沿途中的链路状态以及与其相关的所有预留链路的状态。ResvTear消息沿数据流路由的反方向传递，删除沿途中的资源预留状态。
差错消息
差错消息（Errors）消息有；两种类型：路径差错（PathErr）和预留请求差错（ResvErr）。
PathErr用来报告在处理Path消息中产生的错误。当网络中的几点在处理Path消息中产生的错误时，就会产生一个PathErr消息发送到发送方。PathErr消息在经过的网络结点时不改变包中的任何状态。
ResvErr消息用来报告在处理Resv消息中产生的错误。当网络中的结点在处理Resv消息中产生的错误时，就会产生一个ResvErr消息发送到接收方。它的转发依靠预留状态中保存的下一跳结点的地址。它在每一个结点上进行转发时，分组的IP目的地址就是下一跳的IP地址。这一点与ResvErr消息的转发有所不同。
证实消息
证实消息ResvConf是用来确认资源预留请求的。它是一个可选的功能；当Resv消息中带有RESV_CONFIRM参数值时才会要求返回确认的消息。
RSVP资源预留模式
RSVP中的资源预留请求通过流描述符来表示，包括“流规范（Flowspec）”和“过滤器规范（Filter spec）”。其中，Flowspec描述符所希望得到的QoS保证，它用来设置相应网络结点中分组调度部件或者链路层机制的参数；而Filter spec 用来设置分组流分类器的参数。Flowerspec一般由服务类型（Service Class）和参数“Rspec”、“Tspec”组成。“Rspec”用来定义所希望的QoS服务，而“Tspec”用来描述数据流。“Rspec”与“Tspec”的格式和内容对RSVP是透明的，它由IntServ的服务类型来描述。
RSVP资源预留消息由接收方发起并一次向上游传送，上游在这里是从接收方到发送方的方向。在途径的每一个结点上，资源预留请求会触发下面的两个动作：
（1）在链路上进行资源预留
每一个结点上的RSVP进程（RSVP Process）都会将 请求资源预留的消息传递给接纳控制部件（Admission Control）和策略控制部件（Policy Control）。只要这两个部件中任何一个在检测是否可接纳时失败，那么资源资源预留请求就会被拒绝；同时，RSVP进程产生一个错误消息发送给接收方。如果二者都能成功，结点就会同时对分组流分类器进行相应的设置，从而在实际数据流传输时能够将这个预留的数据分组从进入路由器中的所有分组中挑选出来，进而为它提供QoS保证。
（2）向上游结点转发资源预留请求
操作过程
一个需要按特定服务质量发送数据流的RSVP主机将会传输一个RSVP路径消息，这个路径消息将会沿单播或组播路由通过路由协议预先建立的路径传输。如果路径消息到达一个不理解RSVP的路由器，将会将这个消息转发并不对其内容进行分析而且不会为这个流进行资源预留。
当目的路由器接收到路径消息，它将会：
按照请求的参数进行资源预留。对此，许可控制和策略控制处理请求参数并通知分组分类以便正确处理选定的数据分组，或者和上层协商如何进行分组处理。
向上游转发请求（朝着发送方方向）。在每个节点上，预留消息的流量说明（flowspec）可以由前向节点更改。（例如：在多播流资源预留时，预留请求就可以被合并）
路径上的每个节点都可以接收或者拒绝请求。
其他特点
加密技术——往RSVP消息中添加信息摘要，这是通过一个信息摘要算法（一般是MD5）将消息内容和一个共享密钥结合。密钥可以通过2个消息类型被分配和确认：完整的挑战要求和完整的挑战响应。
错误报告——当一个节点侦听到一个错误，则会使用错误编码产生一个错误消息，并按相反的路径往上游发送直到源节点。
RSVP流信息：两种诊断信息允许网络管理者通过特定的流对RSVP状态信息进行请求。
诊断设备：这是规划的扩展部分，它使用户能够收集沿路径上的RSVP状态的信息。详见RFC2745 - RSVP Diagnostic Messages
RSVP是IntServ模型用于资源预留控制的一种协议，它本身并不是一个路由协议，而是Internet控制协议的一种，因此它的运行必须依赖于现有的路由协议提供的路由信息。RSVP工作在UDP和IP协议层之上，既支持IPV4，也支持IPV6，它也可以透明地通过不支持资源预留的路由器，但是只有当预留资源路径上的所有节点都支持RSVP协议时，才能进行有效的资源预留。
RSVP提供了不同的资源预留类型来适应多种不同的应用，它不仅可以为单播，也可以为组播进行资源预留，在组播应用中，它能根据组播成员与路由器的变化进行动态调整。
RSVP的资源预留是由接收方发起的单项操作，它只保证了从发送者到接受者的单向资源预留，并不保证从接收者到发送者的资源，因此RSVP提供的QoS服务只限于从发送者到接收者的路径上。