计算机工程
COMPUTER ENGINEERING
1999年 第25卷 第12期 vol.25 No.12 1999



基于是RSVP的VoD的实际应用与系统性能分析
陆健贤　张　凌　冯穗力
1 综合业务网及RSVP协议
1.1 综合业务网(Integrated Service Internet)
　　大量基于IP网的多媒体应用表明传统的最好效果服务并不适用于实时业务的传输。因此，IETF正在考虑将传统IP网逐步改造为支持QoS的综合业务网的方法。综合业务网包括以下要素：(1) 新的服务类型; (2) 用于在网络中预留资源的控制协议; (3) 能够对不同IP流进行包分类(classification)和调度(scheduling)的路由器; (4) 一套能利用QoS服务的应用程序接口[4]。
1.2 RSVP协议
　　RSVP作为网络中预留资源的控制协议在综合业务网中具有重要意义。RSVP是一信号机制,并不用于传递业务数据。客户端可以用RSVP协议在发送端和接收端之间为业务流请求所需的QoS。RSVP资源预留机制如图1所示，发送端(Sender)在发送业务数据之前先向接收端(Receiver)发送路径消息。路径消息中包含发送端到接收端的路由信息以及对业务流的描述，如平均速率，峰值速率，包长，最大时延等，但RSVP协议并不解释这些参数。接收端在收到路径消息后将根据其中包含的路由信息逐跳向发送端回送预留消息。预留消息向其经过的每一网络元素请求所需的QoS。若网络元素支持RSVP协议，它将根据预留消息中的流量参数，用接入控制(access control)和策略(policy)模块判断是否能够提供预留消息请求的QoS。若网络元素能够提供请求的QoS，它将继续向下一跳发送预留消息，反之，通知接收端预留失败。RSVP是用传输期(session)的三元组(发送者，接收者，传输协议)以及过滤参数(filter specification，如TCP/UDP的端口)来标识每一IP流的。 

图1RSVP资源预留机制
　　RSVP本身并不是路由协议，也不能直接预留网络元素的资源，只是提供了一种信号机制。因此，要使用RSVP保障实时业务的QoS必须有以下支持：网络元素必须能解释RSVP消息中的流量描述参数，并将映射为适当的调度策略，如：Strict Priority,CBQ(Class-Based Queuing)、WFQ(Weight Fair Queuing)以及相应的拥塞控制策略，如：RED(Random Early Detection), WRED(Weighted Random Early Detection)[2]。同时，能根据RSVP对IP流的标识定义对IP包进行分类以保证业务的QoS。
2 基于RSVP的VoD实验系统
　　图2为一IP网上基于RSVP的VoD实验系统。图2各子网均为10M以太网。两个路由器由同步串行口相联，时钟频率为4M，实际带宽为2.7M。视频服务器Video Server位于202.112.18网段，客户机VoD Client位于202.112.20网段。视频服务器向客户机发送以UDP封装的MPEG1数据，以f1表示此数据流。f1需占用约1.5M的带宽。以f2,f3表示Host1,Host2发至Host3的数据流。Bi表示fi占用的带宽。f1模拟网络中的实时业务，f2、f3模拟一般数据业务。系统中的路由器采用CISCO IOS 11.2(7a)操作系统，并将其配置为支持RSVP协议。Video Server和VoD Client通过WinSock2 API调用RSVP在发送者与接收者之间预留资源。表1为路由器中有关RSVP的设置。路由器用WFQ保证RSVP请求的带宽。使3个数据流的总带宽 ΣiBi 大于串口的带宽，整个系统的瓶颈将出现在连接两个路由器的串口上。以下实验均基于此系统且系统设置相同。

图2基于RSVP的VoD实验系统
表 1 路由器设置

RSVP协议最大可预留带宽(发太网口)5Mbits/s
每一业务流最大可预留带宽(以太网口)5Mbits/s
RSVP协议最大可预留带宽(串口)1.7Mbits/s
每一业务流最大可预留带宽(串口)1.7Mbits
Fair queuingEnable


　　实验1. f2、f3使用TCP协议。实验表明，无论有无RSVP此时VoD的画面质量并无明显下降，f2、f3对实时业务流f1影响较小。表2为用TCPSpeed测试的结果。
表2 视频数据发送前后，使用TCP的业务流流量比较

　f2,f3独占信道
f1一发视频数据f1,f2,f3同时发送数据
B2+B32.174Mb/s1.49Mb/s


　　实验2. f2、f3使用UDP协议，包长为1024B。f2、f3均为1.6Mb/s的UDP数据流。f1包长为1024B。3个数据流总带宽Bi=4.7Mb/s，路由器上产生拥塞。若不使用RSVP为f1在两路由器上预留资源，从实验观察到VoD画面质量明显下降，有明显停顿和马赛克现象。若RSVP为f1在路由器上预留1.6Mb/s带宽，VoD画面质量有明显改善与网络轻载时基本相同。图3为VoD Client在使用RSVP和不使用RSVP时接收视频数据的流量比较。可见，即使在网络发生拥塞时，使用RSVP仍可以保证业务流的带宽；而不使用RSVP，业务流可使用带宽将比网络畅通时显著下降。
　　实验3. f2、f3使用UDP协议，包长为1024B。f2、f3均为1.6Mb/s的UDP数据流。f1包长为8192B。此时无论有无RSVP，VoD Client画面处于停顿状态，其接收的数据为0。因为链路层的最大包长MTU＝1500B,若IP包的包长大于链路层的最大包长，IP包将被分割封装在多个链路层数据包中。若以B表示路由器输出带宽，则在无RSVP的情况下经路由器的链路层数据包的平均丢失率为RLmac ，若IP包被分割为N个链路层数据包，则当其中任一链路层数据包丢失，IP包将无法重组。因此IP包的丢失率： 
　　　　　　　　　　　　　　　　　　　　RLip∝(RLmac)N。
与IP包的分割数成指数关系，较大的IP包在网络拥塞时更易丢失。
　　当路由器支持RSVP时，它将RSVP消息中的预留参数映射为WFQ中的权重w，保证预留资源的数据流获得不少于w%的输出带宽。RSVP是使用IP地址、端口号、协议三元组来标识一个流的。故f1可以(IP address, UDP port, UDP协议号)表示。以P表示VoD Server发送的IP包，包长为8192B;以pi表示分割后形成的第i个较小的IP包，pi<MTU。则仅有 p1含有UDP包头，pi(i>1)均不含有UDP包头。故除p1外，pi(i>1)均不能用(IP 地址,UDP包端口号,UDP协议号)标识；只有p1获得RSVP请求的QoS，pi(i>1)只是当作普通IP包。在此情况下P的丢失率RLip：
　　　　　　　　　　　　　　　　　　　RLip∝(RLmac)N－1。

*为网络畅通时的流量曲线，×为网络拥塞时使用RSVP的流 量曲线， o为网络拥塞时不使用RSVP的流量曲线
图 3 VoD系统流量比较图
　　结论1. TCP协议由于具有拥塞控制机制，因此在网络发生拥塞时发送窗口减小而使源发送速率迅速降低。相反，UDP由于无拥塞控制机制，此时将占用更多资源。在无优先级控制、资源预留等接入控制机制的情况下，TCP数据流在与UDP数据流竞争网络带宽时将处于不利地位。
　　结论2：在易于拥塞的网络，采用较小的IP包更利于保证传输带宽。
　　另一方面，较小的IP包将增加传输的延迟时间，影响MPEG1码流的播放质量。在实验中，当包长为1024B时,画面已产生可觉察的抖动。为解决这一矛盾可采取自适应算法。在网络畅通时用8192B的包传送视频数据，若客户端在门限T内未收到数据则通知服务器将包长降为1024B。在时间ti后进行试探，包长恢复为8192B。若n次试探均未发生接收超时，传送恢复正常状态，包长为8192B。若试探中有一次接收超时，系统重回拥塞状态，包长为1024B。为防止频繁试探引起的抖动，ti选择一递增序列。实验表明，采用自适应算法可改善画面质量。

图4 VoD系统自适应算法
3 结束语
　　RSVP 资源预留控制机制的引入, 为在IP网上实现具有QoS特征的实时业务的传输提供了可能性。正确地应用RSVP协议可以明显改善网络拥塞时实时业务的服务质量。本文根据具体的的实验，分析和研究了RSVP的功能和具体应用的效果, 并就在建立实时系统时可能出现的若干问题, 如包长设置, 传输质量的自适应调节等, 提出了具体的解决方法。以上实验是在同一子网畅通的情况下进行的，一个更完善的实时业务系统应包括链路层的802.1p协议，以保证实时业务在交换式的以太网上有传输的优先度, 在会话层上应用的RTP协议, 以保证实时业务传输的规范和各种时序特性的恢复, 等等。RSVP协议的普及应用将有力推动IP网上的实时业务多媒体传输业务的发展。
作者单位：华南理工大学网络中心，广州150641
参考文献 
1 Braden R, Zhang L,Berson S,et al. RFC 2205 Resource Reserv- ation Protocol (RSVP) Version 1 Functional Specification. 1997 -09
2 Guarene E, Fasano P, Vercellone V.IP and ATM Integration Perspectives.IEEE Communications,1998,36(1):74-80
3 Carde G,Biersark G W.Survey of Error Recovery Techniques for IP-based Audio-visual Multicast Application.IEEE Network,1997, 11(6):24-35
