资源预留协议（Resource ReSerVation Protocol；RSVP）是一种用于互联网上质量整合服务的协议。RSVP 允许主机在网络上请求特殊服务质量用于特殊应用程序数据流的传输。路由器也使用 RSVP 发送服务质量（QOS）请求给所有结点（沿着流路径）并建立和维持这种状态以提供请求服务。
资源预留协议
通常 RSVP 请求将会引起每个节点数据路径上的资源预留。
RSVP 只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。 RSVP 运行在 IPV4 或 IPV6 上层，占据协议栈中
传输协议的空间。 RSVP 不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者
路由选择协议。正如
路由选择和管理类协议的实施一样， RSVP 的运行也是在后台执行，而并非在数据转发路径上。
RFC2205对RSVP的特征做出以下的描述：
（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]没有定义网络向
数据流提供预约
带宽的方法，它只是一个允许应用预约必要链路带宽的协议。一旦某预约付诸实施，英特网中的
路由器就实际向
数据流提供预约的
带宽。
消息
有以下几种主要的消息：
路径消息
路径消息被沿着数据路径从发送方
主机发送，并记录路径上每个节点的的路径状态。
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服务只限于从发送者到接收者的路径上。