RSVP

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

RSVP协议介绍
RSVP概要
资源预约协议RSVP是用于建立 Internet上资源预留的网络控制协议,它支持端系统进行网络通信带宽的预约,为实时传输业务保留所需要的带宽。

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

RSVP请求一般将导致沿数据路径的每一个节点预约保留资源,其基本的工作原理如下图所示:
图: RSVP工作原理
RSVP运行在网络层 IPv4或 IPv6之上,但 RSVP并不传送应用数据,它不是网络传送协议,也不是路由选择协议,RSVP是一个 Internet控制协议,类似于 ICMP(互联网络控制报文协议)和IGMP(路由协议)。

为了执行RSVP协议,在接收端、发送端和路由器中都必需要有执行RSVP协议的软件。

RSVP的特征
1、可伸缩性(Scalability)。

RSVP的一个重要特性是具有较好的可伸缩性,不需要为多目标播送的每一个接收方都预约资源,当数据流在树状节点集上传输时会合并,只要满足最高QOS的资源请求就可。

在多目标广播情况下,各接收方根据自己的QOS要求提出资源预约,发出RSVP消息,RSVP
的RESV消息不是盲目的寻找发送方,只要沿着PA TH消息的路径反向发送。

在多目标树的分支节点处,RSVP将来自不同接收方的预约请求合并,只有QOS要求最要的预约请求才继续传送,如下图所示。

RSVP的可伸缩性有利于改善带宽、网络资源的管理和减少网络负荷,使得RSVP不但适合于点对点传输,也同样适合于大规模的多点传输的网络。

图:资源预留请求在节上传输时会合并
2、接收端导向
也就是RSVP由数据流的接收端启动和维护资源的保留,因此,对于一条连接RSVP 只在一个方向上为数据流保留资源。

接收端的资源需求以预留消息的形式传输,源宿之间所有相关通信设备依据此信息保留所需通信的资源。

这种接收端驱动的预留思想是RSVP协议区别于其他预留协议的主要特点和优势。

因为这使得RSVP协议在多播通信群组中能够支持不同接收端的异构需求,使接收端能够依据终端能力和应用需求,提出合适的预留资源的请求,有利于提高资源的利用率,同时也避免了组播时发端驱动易造成的发端瓶颈,有利于改善多播组成员的动态管理和提高群组扩充能力。

3、预约状态是“软状态”
在多点到多点应用中经常出现组成员变化的情况,网络中路由器也会动态改变,为了动态适应网络变化,增强鲁棒性,RSVP在路由器上建立的预约状态是“软状态”,而将维持预留的责任放到了终端用户。

所谓的“软状态”也就是终端系统必须周期性地发送RESV 消息和PATH消息来刷新路由器的状态,维护建立的预约状态。

在刷新报文丢失的情况下,路由器上的RSVP状态会因超时而被删掉,各节点可以及时回收资源。

选择合适的预约状态维护周期是很重要的,周期太短会因控制信息太频繁而加重负载,周期太长会延迟预约资源的回收。

4、独立于其它网络协议
RSVP采用模块化设计,协议尽量独立于路由协议、数据流描述、具体的服务质量参数以及管理控制部分,这使RSVP适应范围更广。

实际上 RSVP就是一个单独的用于资源预留的信令协议,它没有自己的路由算法,而是使用底层的路由协议为它的路由消息寻找路径、承载数据流描述和预留请求者要求的服务质量参数,并由它上层的策略机制来进行控制、管理以及安全保障工作。

RSVP的特性可用下图说明。

该图表示的是一个多目标广播树(multicast tree),它的数据流向是从树的顶部到6个主机。

虽然数据源来自发送端,但保留消息(reservation message)则发自接收端。

当路由器向上给发送端转发保留消息时,路由器可以合并来自下面的保留消息。

图: 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消息实现:PA TH消息和RESV消息。

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

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

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

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

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类型段指定对象内容的形式。

不同种类的接收器
用户接入因特网的速率是多种多样的,有的使用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的用户就接收不到广播。

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

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

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

[例1] 多目标实况广播
图:多目标实况广播举例
假设有一场体育比赛要在因特网上进行实况转播,多目标广播地址已经在因特网上事先发布,并且假设从发送端到接收端的多目标广播树已经确立,如下图所示。

此外,每个接收端的数据接收速率也已经在图上表示出,而且电视数据是按照接收端数据接收速率进行分层编码的。

RSVP的工作过程大致如下。

每个接收端逆向发送一个资源保留消息到多目标广播树,这个消息说明了接收端接收广播源的数据速率。

当保留消息到达一个路由器时,路由器就调整它的信息包调度程序来保留带宽,然后把这个消息送到上游路由器。

路由器逆向保留的带宽数量是根据下流的保留带宽的数量来确定的。

在本例中,接收端R1,R2,R3和R4分别保留20 kb/s, 120 kb/s, 3 Mb/s和3 Mb/s,因此路由器D下面的接收端请求的最大速率为3 Mb/s。

路由器D把保留消息发送给路由器B,请求路由器B在这两个路由器之间的链路上保留3 Mb/s的带宽,因为R3和R4观看同一个广播,因此不需要保留6 Mb/s的带宽。

依此类推,路由器C请求路由器B在路由器B和路由器C之间的链路上保留100 Kb/s的带宽。

分层编码的数据流保证接收端R1的20 Kb/s的数据流包含在100 Kb/s数据流中。

一旦路由器B接收到来自下面的路由器的保留消息之后就递送给它的调度程序,然后把新的保留消息递送给上一层的路由器A。

这个消息要求在从路由器A到路由器B的链路上保留3 Mb/s的带宽,这是接收端要求保留的最大带宽。

从上面的分析可以看到,RSVP是接收端导向的协议,也就是由接收数据流的终端提出资源保留请求。

每个路由器接收到的消息依次是从多目标广播树上的下流链路上发送来的,而且只有一个带宽保留消息。

[例2] 4人电视会议
假设每人在自己的计算机屏幕上开有3个窗口观看其他3人的情况,按照路由协议在4台计算机之间建立多目标广播树,他们都使用3 Mb/s的速率来接收电视,如图所示。

在这个多目标广播树上的每条链路上,RSVP就要在一个方向保留9 Mb/s的带宽,而在其他方向上保留3 Mb/s的带宽。

在这个例子中,RSVP不合并需要保留的带宽,因为每个人都想接收来自其他3台计算机的数据流。

图: 4人电视会议
RSVP的不足之处
RSVP虽然是一个比较简单高效的协议,但它也存在一些不足之处。

1、RSVP依靠在路由器间周期性地刷新来保持资源保留状态。

这种方法在有拥塞的网络中就会导致延迟和保留的资源不能从路由器上被释放。

2、可伸缩性是RSVP的一个优点,同时又是RSVP的一个缺点。

因为在骨干网上,为了传输RSVP控制信息所消耗的带宽太大。

在骨干路由器上,为了支持大数量的数据流资源预留,信息所占的存储空间也太大。

3、大量的RSVP信息保存在终端系统和路由器上,导致巨大的处理开销,影响了数据包转发的效率。

在骨干路由器上,这种复杂性将给路由器的性能造成显著的负面影响,并在网络边缘使防火墙的处理效率降低。

根据当前的RSVP规范建议,RSVP适合于小型的、私有的网络上的多媒体传输,在这种网络上,问题不会表现得很突出。

因此,RSVP协议适用于互联网的边缘区域,在互联网的骨干网上不适合采用RSVP协议。

多媒体数据实时传输
Internet上的多媒体实时传输可以通过RTP、RTCP、RSVP的配合实现。

首先,利用RSVP 建立并维护网络资源预约,然后,使用RTP在建立的预约路径上进行实时多媒体数据的传输,同时,周期性的发送RTCP控制报文监视实时数据的传输情况,及时反馈网络的传输信息,保证数据的实时传输。

相关文档
最新文档