RSVP在数字视频网络传输中应用研究
发布时间:2006-10-14 4:14:46   收集提供:gaoqian
崔世强


1 引言

  由于Internet 的广泛流行,许多网络越来越不堪重负,网络带宽出现“供不应求”的局面,在共享媒体网络上(如以太网),这个问题尤为突出,即便一个非常简单的应用,也可能使网络的负荷量过大,造成整个网络的瘫痪,为此,人们提出了“服务质量”(QoS,Quality of Service)。 服务质量是多媒体网络中的一个重要概念,在传统的通信网中没有QoS的概念,这是因为传统的网络都是与专项业务相关的,例如电话由公用电话网传送,计算机数据用基于X.25的数据网传送,为某种业务服务的网是针对该业务的要求而设计的,1路电话占有固定的带宽(或时隙),当终端进行呼叫时,网络不需要再询问终端对带宽的要求,而且一旦网络将此呼叫接通,在整个会话过程中,终端一直拥有这一带宽,QoS就自然得到保障。在发展宽带综合业务网(B-ISDN)之后,要在同一个网络上支持不同的业务,而不同的业务对网络的功能又有不同的要求,因此有必要在信息传输之前将某项业务的特定要求告知网络,QoS的概念应运而生。在数字视频传输网络中,QoS更加受到重视。

2 QoS的描述

  IP本身不支持对数据传输的优先处理,而是将其交给网络管理者和服务的提供者,以使网络要素了解各个应用程序的不同需求。标准的Internet协议(基于IP)网络所提供的是“竭尽全力的”数据传输,IP将复杂的工作交给终端来完成。当要求因特网提高自身能力来支持其业务增长时,尚可以做到拥有较好的伸缩性,但是随着更多主机的加入,网络服务的要求最终超越了网络的承受能力,导致服务质量逐渐下降,由此产生的网络传输延时、包丢失并不会对因特网的典型应用(电子邮件、文件传输和Web应用等)造成严重的影响,但是与数字视频传输实时应用要求形成矛盾。

  增加带宽是解决矛盾的必要步骤,但仍不足以在通信高峰期间避免网络拥塞,即便在网络不拥挤的时候,传输的延时变化也会对实时应用造成严重的影响,这就需要对IP服务进行补充,给网络加入某种“灵性”来区分哪些通信是有严格的时间要求的,哪些是可以容忍延时、拥塞和包丢失的,这就是QoS协议设计的目的。QoS是通过对带宽的管理提高其利用效率,通常来讲QoS是一个网络要素(可能是一个应用、一个主机或者一个路由器)为网络数据传输一致性而提供的某种等级的保证。有两种基本的QoS类型:

  (1)资源预留(综合服务):网络资源按照应用的QoS需求来分配,并且服从于带宽管理原则。

  (2)优先级(有别服务):根据带宽管理策略标准对网络通信分类并分配相应的网络资源。

  国际电联(ITU)将QoS定义为决定用户对服务的满意程度的一组服务性能参数。这些参数可以用多种方式来描述,例如:

  确定性描述方法:

QoS_Parameter≤Upper_bound

QoS_Parameter≥Lower_bound

  统计描述方法:

Prob [QoS_Parameter≤Upper_bound]≥Prob_bound

Prob[QoS_Parameter≥Lower_bound]≥Prob_bound

  吞吐量、传输延时、延时抖动和错误率是常用的QoS参数,不同的多媒体应用对网络性能有不同的要求,在通信起始,用户向网络提交的QoS参数实际上描述了应用对网络资源的需求,网络可以此作为对内部共享资源(如带宽、处理能力、缓存空间等)进行管理的依据。如果网络资源不能满足用户的QoS要求,或者接纳一个新的呼叫要侵犯预留给正在进行通信的线路的资源,从而降低这些通信的QoS时,网络将不接纳这个新的呼叫,这种机制通常称为连接接纳控制(CAC,Connection Admission Control)。一旦网络接纳了用户的呼叫,它就有责任在整个会话过程中保障用户所提出的QoS要求。因此,网络要为这个呼叫预留资源,并在通信过程中进行性能监控,动态调整资源的分配,当资源不能保障用户的QoS要求时,通知有关的用户,直至终止相关的通信等。上述各种功能构成了网络的QoS保障机制,目前只有少数的网络实现了或部分地实现了这些功能。

3 RSVP协议

  IETF RFC 1633 提出了一个综合服务模型(Integrated Service Model),其基本思想是通过资源预留来实现QoS保障,该模型的核心部分为一个资源预留协议(RSVP)。RSVP是一个备受关注的IETF Internet草案(RFC 2205, 2208, 2209中作了规定),它是一种通过提供预留设置和控制来实现综合服务的信令协议,它从资源预留的角度允许无QoS技术(如以太网和IP网等)的网络提出QoS需求。例如,在视频会议应用中,其要求可能包括了最大帧传输率、最大延时抖动和最大端到端延时的定义。RSVP提供了以下功能:

(1)通信控制;

(2)禁止非适应性协议(如UDP)滥用网络资源;

(3)针对“竭尽全力”通信,以及高优先级或低优先级的通信,对资源进行明确划分;

(4)为冠名用户保留资源;

(5)为用户分派资源访问的优先级。

  RSVP本打算被用于在IP网络上提供一种类似于线路竞争的机制。对于应用程序(主机)和网络要素(路由器和交换机)来说,RSVP是所有QoS技术中最为复杂的,因此,它也最大程度地违背了“竭尽全力”的IP服务标准。同时从服务保障、资源分配粒度和对要求QoS的应用反馈内容等方面看,RSVP也提供了最高级别的QoS。

  接纳策略控制(Admission Policy Control)决定了QoS请求是否可以/应该得到满足;分类器(Classifier)则通过查找IP报头的内容将数据包映射到某一服务类别中;包调度程序(Packet Scheduler)进行基于服务类别的数据包传递。

RSVP的工作过程:

(1)发送者根据带宽、延时、抖动的上界和下界来规定发送端话务;

(2)发送端向接收端发送“PATH”检测;

(3)接收端向发送端发送“RESV”消息;

(4)路径上的路由器资源被保留(连接建立);

(5)数据沿着与Path和Resv消息相同的路径传送。

  当一个终端向某应用发出RSVP请求时,位于该终端和源主机之间的每个路由器都会响应这个QoS请求并试图满足它。如果该请求通过路由器到达源主机,它会与来自其他终端的请求合并。如果路由器不能满足该请求,即不能保证带宽或其他的性能指标,这时发送请求终端会收到一条错误信息,等同于话音网络上的占线信号。

4 RSVP在数字视频网络QoS保障中的应用分析

  首先要解决RSVP会话的建立这一核心问题。在典型的数字视频网络传输的应用中,通常是一个视频服务器与多个终端同时通信(如远程监控、远程教育、网上购物等),这时,对视频信息的需求都是由各个用户提出的,因此由各个终端各自申明自己所要求的服务质量,这比由服务器(发送端)向网络提出QoS要求更为合理一些。而RSVP的一个显著特点是在无连接的网络上实现由接收端启动(ReceiverDriven)的资源预留。当应用需要控制负荷服务或可保障的服务时,就会通过网络向发送端提出建立RSVP会话的请求,如果该请求被接受(不但被发送主机接受,还要被数据传输经过的所有路由器接受),则网络为该业务流分配带宽和缓存空间,并且将该流的状态信息记录下来。

  在Windows 2000操作系统上,可以使用Winsock提供的API函数来实现基本的RSVP功能,它为RSVP会话的建立提供了4个函数:

(1)WSAConnect:用于初始化一个服务器的单播QoS连接;

(2)WSAAccept:用于接收一个具备QoS功能的客户机的连接;

(3)WSAJoinLeaf:用于多点通信;

(4)WSAIoctl:既可用来在一个连接或未连接的套接字上首次请求QoS,又可用来在初次QoS请求完成之后对QoS的要求进行重新协商(当网络状态出现变化时)。

  有一种情况值得考虑,就是在无RSVP的网络上,视频应用程序可能会因为带宽得不到保障而运行得比较慢甚至很糟糕,出现马赛克或画面不连贯,但是它还能运行;而在有RSVP的网络上,如果没有达到要求的足够的带宽时,它可能就无法运行了,这是RSVP在QoS保障应用中的严重缺陷,解决方法是让视频应用程序在建立RSVP会话过程中以能够运行为最终目的,逐步降低要求直至得到满足。当然,如果要求已经降低到对视频应用程序失去了意义,我们就应该以网络能够提供的最低带宽作为应用程序所要求的目标,这样做的结果可能会导致应用程序回到无QoS的网络环境中,实际上这同无QoS的网络存在着根本差别,因为只要建立了RSVP会话并且数据能够传输,那么当网络可用带宽变化后,应用程序可以获得网络资源状况的通知,我们就可以通过程序控制重新协商对QoS的要求,而无需重新建立会话。

  另外,针对数字视频网络传输所用到的一些典型协议与方案,RSVP的应用要注意两方面的问题:

  (1)RSVP和套接字的类型选用针对基于IP多播(IP Multicast)的UDP方式:首先通过WSAJoinLeaf函数指定多播地址,构成RSVP会话对象。其次,由于QoS服务提供者并不禁止一个套接字同时加入多个多播组(如视频监控应用中客户端同时从多个视频服务器获得监控图像的情况),在这种情况下,若发送者将数据发给其中一个多播组,那么只有在发送者已经加入该组的前提下,才能使相应的QoS参数应用于那些数据;除此以外,假如一个套接字加入了一个多播组,并指定了一个特定的方向(接收或发送),那么QoS也只会在相应的方向上产生作用,这样我们就可以针对具体的视频应用(单向的VOD、远程教育、双向的视频会议等)来决定QoS应用的组以及传输方向,以免浪费宝贵的网络资源。   (2)QoS封装丢弃模式的选择:QoS对象定义了通信控制(TC)的包封装器(Packet Shaper)处理一个指定流的数据。在大多数视频传输情况下,对传输参数进行设置时,都会让一个数据包的大小正好等于一个影像帧的大小,假如出于某个方面的原因,数据包与建立RSVP会话过程中指定的参数发生了不相符的情况,那么在处理这个流时,就需要用到一种较为特殊的方式:在本地将当前帧丢弃,立即转移到下一帧,而不应该等到两者相符再发送,这样做是出于视频应用对实时性比较严格的要求。

5 结束语

  综上所述,RSVP在某种程度上能够对数字视频网络传输提供较好的QoS保障,但是,即使有RSVP这样的协议,在基于IP的网络上也没有什么绝对保证,相反,还会有一些不利的因素,有时RSVP可能会导致一些网络服务性能下降,例如,一个高优先权的请求如果消耗了全部分配到的带宽,那么路由器就会丢弃那些没有优先权的数据流。另一种不利因素是费用高,因为该协议要求每个路由器都支持QoS请求,这样就需要对固件乃至硬件进行升级来达到要求,而对于Internet这种“超级网络”来说,对所有硬件性能的要求是很难得到满足的。从技术角度讲,RSVP在目前的网络上是一种行之有效的QoS保障方法,而且随着网络基础建设的发展以及各个企业局域网的升级换代,RSVP将在数字视频网络传输中得到更广泛的应用。


摘自 中国有线电视
 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50