RSVP协议和资源预留

6.3.1综合服务Internet

第二章已述及，Internet是一个无连接网络，只提供一种承载业务：尽力传送(besteffort)业务。也就是说，网络并不保证向应用数据流提供所需的带宽，也不保证数据流的传送时延和丢失率等质量指标。对于FTP数据等非实时业务，尽力传送能够满足要求，但是对于音频或视频等实时通信应用，网络必须能支持具有一定QoS的端到端承载业务。为此，可有下述两种方法。

一种是超量工程法(overengineering)，即在网络规划时预留足够的带宽，使得任何时候都能获得可接受的QoS。这种方法十分简单，不需要资源预留协议和接纳控制功能，但是要求部署足够多的路由器和高速链路，保证即使在忙时网络资源也有足够的余最。它可用于网络资源便宜同时网络最大业务量又可预测的情况。

另一种方法就是综合服务Internet方法，由IETF综合服务(intserv)工作组定义。它需定义呼叫接纳控制功能和资源预留协议，如RSVP。利用RSVP消息，端点应用程序可以提出数据传送全程必须保留的网络资源（如带宽、缓冲区大小等），同时也确定了沿途各路由器的传输调度策略，藉此，可以对每个数据流的QoS逐个进行控制。不难看出，上述概念和面向连接的呼叫连接建立过程相似，RSVP类似于连接控制信令，因此，常称RSVP是Internet中的信令协议。

为了支持不同特性的应用，必须对其QoS进行分类。IETF提出了多种不同等级的QoS服务类型，包括：承诺速率服务、保护式尽力传送服务、QoS确保服务和负荷受控服务，目前只有后两种服务在网上真正实现。QoS确保服务必须确保数据流的可用带宽，保证其达到规定的端到端时延指标和丢失率指标，主要用于对实时性要求很高的音频和视频等应用。负荷受控服务并不提供严格的定鼠性能保证。当网络负荷很轻时，所有数据流都按尽力服务方式处理；当网络负荷增加时，应使请求负荷受控服务的数据流的QoS不出现明显的下降，而尽力传送的数据流的QoS将愈盖恶化。这种服务主要用于允许一定量时延和丢失率波动的应用，如各种自适应实时应用。两种服务方式都要求对应用数据流进行管制，对于超量部分原则上按尽力传送方式处理。

RSVP协议支持上述两种服务，在实用上，以支持QoS确保服务为主。

6.3.2  RSVP功能原理

RSVP的一般机理如图6.10所示。为了启动资源预留，发送方首先发出PATH消息，消息中包含数据流标识（即目的地地址）以及数据流业务特征，该消息沿着所选路由逐跳传送，通知沿途各路由器准备预留资源。接收方收到此消息后，根据业务特征和所需的QoS计算出所需的资源，回送RESV消息，消息中包含的主要参数就是请求预留的带宽。在多点到多点通信的一般情况下，还可指定预留请求对应的发送方以及多个预留请求在某路由器会聚后聚合数据流的预留方式(style)。RESV沿原路返回，沿途各路由器只有在收到RESV后才执行资源预留操作。发送方收到RESV消息后，开始发送用户数据流。由于可用资源有保证，该数据流的传送必能达到接收方要求的QoS。

图6.10   RSVP的一般机理

由上述过程可知，在RSVP中，真正的资源预留操作是由接收方启动的，这和电信网络中的呼叫建立方向正好相反。之所以这样设计的原因是在有许多叶节点的多播情况下，可使协议实现大为简化，可适应多播群成员动态增减变化，并可支持各接收方请求不同QoS的异质请求情况。

RSVP采用单向数据流资源预留机制，如果是双向数据流，则两个方向需独立执行上述过程。

       RSVP的工作原理可以概括为以下几个步骤：

  1.建立传输路径

发送端发送一个名为Path的消息，沿数据流的路径传播，沿途的路由器记录这个流的标识符，并为其预留资源。

   2.资源预留请求

接收端在收到Path消息后，发送一个Resv（Reservation）消息来回答，沿相同的路径返回给发送端。这个消息包含了接收端对服务质量的要求，如带宽、延迟等。

   3.资源分配

路由器在收到Resv消息时，会根据消息中的要求和自身的资源状况来决定是否能够满足预留请求。如果可以，路由器会分配资源，并将Resv消息继续向前传递；如果不可以，路由器会拒绝请求，并可能发送错误消息。

   4.状态维护

一旦资源预留建立，RSVP会定期维护这些预留状态，确保资源的可用性。当预留不再需要时，节点会发送撤销消息，释放预留的资源。

RSVP位于IP之上，其在协议栈中的地位与管理协议(ICMP、IGMP)和路由协议相当，分配的协议标识号为46。图6.11示出在综合业务Internet中端点主机和路由器中执行的协议栈。其中，RTP/UDP用于传送实时数据流，CSC/TCP用于传送通信控制信令。

图6.11  综合服务Internet中的协议栈

RSVP既支持点到点数据流，也支持点到多点和多点到多点数据流的资源预留。图6.12给出点到多点情况下的资源预留情况。图中，端点A向端点B、C_l、C₂、D₁、D₂发送数据流，为此，A利用和媒体数据流同样的多播地址向各接收端点发送PATH消息。C_l、C₂和D₁、D₂回送的RESV消息分别在路由器R₂和R₃聚合，端点B和局域网C、D回送的RESV消息在路由器R₁聚合成一个RESV消息送回发送端点A。

图6.12点到多点情况下的资源预留

由于装载RSVP消息的IP数据包是和用户数据包在同一路径上传送的，因此常称RSVP为带内信令。这就要求有安全措施防止RSVP消息遭受恶意攻击，包括预留消息发起者的鉴权和消息本身的完整性保护。

和传统电信网信令协议另一个不同之处是，电信网信令建立的连接状态都是硬状态，此状态在呼叫过程中保持不变，直至信令消息命令呼叫释放为止。而RSVP采用的是软状态，需要定期刷新。为此，要求端点周期性发送PATH和RFSV消息，以保证传送路径上的各路由器维持其预留状态。如果超时未收到RSVP消息，路由器中预留的资源就将释放。这样设计的原因一是简化出错处理，因为许多出错情况都可以通过超时机制予以克服；二是当路由发生变化时，不再使用的老路由上的路由器将由于超时而自动释放预留的资源。

通过资源预留保证QoS的实现机制统称为业务量控制(traffie control)，它由三部分组成；接纳控制和策略控制、分组分类器及分组调度器，如图6.13所示。当路由器收到RSVP预留请求时，首先向接纳控制和策略控制模块发出请求，前者确定本节点是否有足够的资源支持所请求的带宽，后者由运营部门设定，决定该用户是否允许进行资源预留，以防止尤权或过度占用资源。只有当两个控制模块均通过后，才能为指定的数据流保留资源。其后，分组分类器根据请求为该数据流设定类别；分组调度器设置在输出端口，根据分组类别调度各分组的传送，保证各类分组获得其分配的带宽。

图613  业务流控制机制

   由此可得RSVP的主要特点为：

．支持单播和多播数据流。

．单向资源预留。

．面向接收方，即由媒体流的接收方进行资源预留。

．基于软状态，因此可动态适应路由变化和多播组成员的变化。

．针对一个会话（即一对运输层地址）进行预留。

6.3.3  预留方式和聚合

在多点通信情况下，RSVP允许接收方规定不同的预留方式，预留方式将直接影响到同一会话的不同分支发起的资源预留会合后，路由器如何处理预留的聚合(aggregation)。

在RSVP中，预留方式称为“风格”(style)，它包括两类选项。一类是选择如何处理对同一会话中的不同发送方数据流的预留请求，可以是对每个发送方建立一个独立的资源预留，也可以是所有选定的发送方共享一个预留。另一类是选择发送方，可以采取显式列表的方式列出所有选定的发送方，也可以为通配(wildcani)方式，表示所有发送方都选中。二者组合，可以得到表6.5所示的三种预留方式。

表6.5 资源预留方式

其中，SE和WF方式适用于音频媒体，因为电话会议一般同时只有1个人在讲话，为了可靠起见，接收方请求预留的带宽可设为定发送方带宽的二倍，即可同时收听两个人的讲话。FF方式适用于视频媒体，因为多媒体会议中常要求同时展现多个会场的画面。

三种预留方式的常用标记方式为：

. WF(*{Q})：其中，＊表示通配，Q表示保证QoS需要预留的参数。

. FF(S{Q})或F(S₁{Q₁},S₂{Q₂}...)；其中，S表示指定的发送方。

. SE((S₁,S₂,…）{Q}）：其中，（S_1,S₂…）为选定的发送方列表。

现以图6.14所示路由器为例，说明对于三种预留方式如何进行预留聚合。假设，从任一发送方S_i发来的分组需复制送到(c)、(d)接口，（d）接口为广播式LAN接口，再经不同路由器送到接收方R₂和R₃。预留带宽基本单位为B。

1.WF预留方式

图6.14予留聚合的路由器示例

设，R₁、R₂、R₃分别发出带宽为4B、3B和2B的通配预留请求。则，路由器应为(C)接口链路预留带宽4B,(d)接口链路预留3B；然后经(a)、（b)接口向上一跳路由器转发RESV消息，请求通配预留4B的资源，以满足最高要求者R₁的需要。上述资源预留和转发请求的情况如表6.6所示。

表6.6 WF预留方式示例

2.FF预留方式

此时，路由器在为下游链路预留资源时，应为每个发送源单独进行预留，因为这些发送方可能同时发送数据流。如果在链路接口上收到多个对同一发送方的资源请求，则应根据最大请求值预留资源。在向上游节点转发RESV消息时，其预留请求值应取为所有下游节点对该发送方请求的最大值。表6.7为FF预留方式的示例。

表6.7    FF预留方式示例

3.SE预留方式

在SE方式中，路由器为下游链路预留资源时，预留的数量应为自该接口收到的所有预留请求的最大值，为之预留的发送方应为自该接口收到的所有预留请求指定的发送方的和集。在向上游节点转发RESV消息时，其指定的发送方应为这样一些端点的集合，这些端点既是该接口的上游发送方，又至少是某一下游预留请求指定的一个发送方。RESV的预留请求值应取为所有相关下游预留请求值的最大值，这些下游预留请求指定的发送方中至少应包含一个该接口的上游发送方。表6.8给出SE方式下的资源预留和请求转发情况示例。

表6.8    SE预留方式示例