承  彦  冯  径  顾伯萱  马小骏  顾冠群

1  引言
计算机网络系统是CIMS重要的支撑系统之一。支持企业CIMS应用的计算机网络主要提供异机数据访问、异机程序访问和增值通信三大类功能。包括支持实现文件和数据共享的企业管理信息系统、共享生产数据和过程管理的ERP（Enterprise Resources Planning；企业资源规划）系统，以及支持CAD（Computer Aided Design），CAM（Computer Aided Manufacturing）和CAPP（Computer Aided Process Planning）等应用集成的PDM（Product Data Management）系统。
上述的各种企业应用系统对支撑网络有着各不相同的传输与处理要求。例如，ERP对延迟的敏感程度非常高，它希望网络系统提供最低延迟的服务；另一方面，视频会议、协同工作等企业应用，都对网络有较高的实时请求或高带宽请求。因此，现代企业CIMS系统对支撑网络提出了很高的服务质量请求。
当前光纤传输技术的快速发展似乎能够向网络提供趋向于无限大的带宽，足以承载大量多媒体或实时应用的流量。但是，带宽的增大并不能避免传输突发带来的延迟抖动；网络带宽的增加也不意味着每个应用的每个数据流都能分配到相应增加的服务速率；另外，结点的处理能力到目前为止仍然是网络服务的瓶颈。
因此，当前有众多致力于有效管理带宽的各种服务质量（QoS）相关的协议与体系结构的研究。另外，由于Internet是基于TCP/IP协议簇的，而且较长的一段时间内不会改变，这样，通过Internet所能得到的QoS保证必然应由TCP/IP提供。基于IP的QoS控制的目的就是在尽力而为的IP的基础之上提供一定程度的预测与管理。
当前有两种对QoS的基本刻画方式[1]，一是资源预留，网络资源根据应用的请求，服从相应的管理策略进行分配；二是优先级，根据带宽管理标准对网络通信量进行分类并据此分配资源，对标识为较高要求的类别提供优先处理。前者主要体现在集成服务体系（IntServ）中，其QoS保证更为严格；后者则由区分服务（DiffServ）来实现，提供的是一种比较粗糙简单的服务分类。
IntServ/RSVP服务模式提供了与当前Internet上的各种应用类型及其传输要求比较匹配的服务类型；同时，已有的服务基本没有改变，因此已有的应用无需调整；当前的Internet转发机制也没有改变，因此，即使当前的系统未作任何升级，端系统仍然能够从IntServ体系中得到某一类别的服务，但得不到QoS保证。这种服务体系结构是能够提供Internet上的端-端服务质量保证的。
下面我们对IntServ/RSVP进行分析，并且就原型系统的实现展开详细的讨论。
2  IntServ/RSVP服务体系结构概述
针对各类应用的不同要求，在原来的服务之外，集成服务模型又另外定义了两类具有不同程度QoS保证的服务：确保服务（Guaranteed Service）和负载受控服务(Controlled Load Service)。
2.1  集成服务模型[3]
图1给出了在路由器上实现集成服务的框架示意图，它与主机的实现区别在于不需要进行路由处理。集成服务的实现框架包括4个部分：
?  分组调度器――使用队列及其他机制管理不同分组流的转发；
?  分组分类器――为了进行流量管理，每个到来的分组都应映射到一个类中，同一类的所有分组得到分组调度器的相同处理；
?  接纳控制――采用某个算法来决定路由器或主机是否能在不影响其他流的情况下，将所请求的QoS给予一个新流；
?  预留建立协议――在端系统和路由器创建并维护流状态。
 

图1  集成服务框架示意图

(1)  负载受控服务
负载受控服务[5]在网络重载情况下提供近似网络轻载时的QoS。这种服务的QoS是不精确的；它关心的是长期的服务结果。要想获得这种服务，应用应该向网络结点提供一个对其产生的流量的总体描述，用Tspec表示；收到这种服务请求的网络元素必须根据请求者提供的Tspec，保证在处理这一类流量时有适当的带宽和分组处理资源，例如路由器或交换机端口的缓冲空间。
(2)  确保服务
确保服务[6]提供确定的带宽与端―端延迟的保证，对于遵守规范的分组保证没有排队丢失。这种服务是专为严格的实时服务而设的。当数据流符合速率为r、深度为d的令牌桶时，如果R>r，则延迟的上界为b/R。为了允许对这个理想模型的偏离，WFQ调度器引入两个差错参数，C和D。下文将详细讨论这种调度规则。这样，延迟的上界变为
b/R+C/R+D                             (1)
在确保服务中，峰值速率p是有所限制的，以减小延迟的上界。另外，由于流是由分组组成的，因此还要考虑最大分组长度M。加上所有这些因素，确保服务的更精确的端－端排队延迟的上界如下：
    (2)
式(2)中， 和 分别表示端―端的数据路径上各路由器的差错参数C和D的累积和。
对于想要调用确保服务的路由器，它必须得到数据流的通信量特性（tspec）和预留特性(rspec)。
Tspec参数包括：p 流的峰值速率；b 令牌桶深度；r 令牌桶速率；m 最小管理单元；M 最大报文长度；
Rspec参数包括：R 带宽，即服务速率；S 松弛参数。
2.2  集成服务体系中基于应用的QoS服务
在QoS体系结构中，QoS究竟是一种基于应用的服务，还是一种传输层的行为，或者两者兼而有之。如果作为基于应用的服务，就意味着QoS体系结构有必要扩展到某种形式的应用程序接口（API），这样，应用可以与网络协商其QoS请求，并且根据网络的应答调整其行为。而如果作为一种传输层行为，任何应用程序都可以通过改变其主机配置或者其他网络控制点的配置，而对应用程序本身不做任何改变，来使其流量被某种形式的QoS网络服务承载。这种方式的优点是，应用程序行为不需要改变；缺点是，应用程序无法与网络或策略控制系统进行对网络管理有用的信息交互，缺乏这些信息，网络提供的服务应答极有可能远远超过应用程序的真实请求。另外，这种方式还有一个弱点，是关于那些可以调整其流量状态以适应网络可得资源的应用程序，在传输层机制下，网络资源信息有可能被传输层获得，却无法传给应用程序。
在集成服务体系结构中，显然不能用传输层的方式来实现QoS。应用程序要想在这种环境下正常工作，确实需要进行某种调整。应用必须向服务预留模块提供其预期流量的整体描述，换句话说，应用必须预报其流量负载。此外，应用必须能够与网络共享预留状态；如果网络状态出现故障，应用就能立即知道。更概括的说，如果应用程序自愿提供对其通信量特性的精确描述，并且为了使其通信量符合描述，愿意被控制（policing），则网络必须对应用的请求形成精确的应答。
因此，在IntServ/RSVP体系结构中，向应用程序提供QoS就是基于应用的方式。这种方式还有一个特点，就是接收方协商能力。当发送方建立一条穿越网络到达接收方的QoS路径时，如果接收方不能吸收随之而来的数据流，则这条路径是没有任何价值的。这意味着具有QoS能力的应用程序还需要某种形式的端―端能力协商，可能是通过某种协议，允许发送方将其QoS请求与网络能够提供的流资源与接收方能够处理的流资源这两者的较小值进行匹配。在RSVP中，就集成了这样的端―端应用程序协商的交互。
如果要提供高质量的服务，对于端―端服务传输，有必要在请求服务的应用程序级上进行扩展。因此，我们对RSVP API进行了研究与改进。
3  应用程序接口
3.1  资源预留协议及其应用程序接口实现模型
Internet上的应用程序通过API向网络提出QoS请求，然后本地的RSVP控制程序将使用RSVP协议沿数据流路径传播这个请求；各路由器依据其可用资源情况决定是否接收或拒绝请求。若预留未成功，本地RSVP控制程序将通过API把结果返回给提出请求的应用程序。
即RSVP API（简称RAPI）[10]，基于一个连接在应用上的客户段程序库，通过对这个库的调用完成上述功能。其执行模式如下：RSVP由一个用户级守护程序（daemon）在主机执行，RSVP客户程序库中的过程通过一个Unix域的socket与本地RSVP daemon交互。RAPI就是应用与客户程序库之间的接口，其实现模型如图2所示。
RAPI向应用程序提供了一组函数，接收应用的参数，并将这些参数转换为RSVP守护进程可以理解的信息；另一方面，把守护进程的信息向应用报告，这是通过一系列的事件上传过程（EVENT UPCALL）来实现的；任何消息的发送或接收都会在端系统引起一个事件的发生，通过相应的事件上传，应用程序能够立即得到消息的情况。
 

图2  RSVP及其API实现模型

3.2  应用程序接口存在的问题
在对RSVP API研究之后发现，对于试图通过应用程序接口启用资源预留功能的应用程序来说，如何提供QoS处理所需要的参数是一个难题，即使是向相对简单的RAPI也要提供一系列底层QoS保证所必须的参数。例如，会话的接收方可以通过调用下列函数向网络提出预留请求：
Int Rapi_reserve(int  Sid,  /
int  flags,
Struct Sockaddr   *Rhost,
int  StyleId,     /*预留风格代码*/
rapi_stylex_t   *style_Ext
rapi_policy_t   *Rcvr_Policy,
int  Filter_SpecNo,
rapi_filter_t   *Filterspec_list,
int  FlowspecNo,
rapi_flowspec_t  *Flowspec_list /*流规范列表*/
)
加粗的参数对于预留是至关重要的。预留风格是资源预留协议为容纳多点投递而设计的多路预留合并的风格；流规范列表中的各项就是应用希望从网络获得的集成服务类型（GS或CLS）的流描述，前文已经给出GS的7元参数。这些参数由应用程序在调用时提交是不合理的，也是不现实的。这些参数以令牌桶参数为代表，即令牌桶深度b和令牌桶速率r。当网络元素提供确保服务与负载受控服务时，这两个参数在流量整形与流量调度过程中起着重要的作用，直接影响到调度的效果与服务的质量。但是，要求应用去了解并给出网络元素底层处理所需的元素是不合理的，也是违背Internet网络设计原则的。
因此，我们对于改进应用程序接口作了深入的研究，主要是针对流量整形与调度的机制进行。我们认为，要使应用程序真正能够方便的利用应用程序接口与网络进行服务协商，网络底层的细节应该是对应用透明的；用户不需要关心网络元素使用的调度算法需要什么样的参数。另一方面，一个良好的透明的接口也可以有效的防止因应用提交数据不当而引起的服务协商失败。
4  集成服务原型系统实现
4.1  系统总体设计
要想通过资源预留和调度来提供QoS，则参与端―端通信的各系统与组成部分有必要依次执行下列步骤：
?  QoS规范描述：通信量数量及其请求的QoS都应该有一个明确的描述，以便系统决定是否提供以及提供何种QoS；
?  能力测试与QoS计算：应用提交其QoS请求后，系统的接纳控制必须检查，这些请求在考虑到已有的预留后是否能够得到满足；如果能够，计算出可提供最好的QoS，相应的，应用也得到一定级别的QoS保证。
?  资源预留：根据提供的QoS保证，预留适当的资源――传输或处理带宽等；
?  实现QoS确保：QoS确保必须由适当的资源调度来实现。
与这4个步骤相对应，并且参考集成服务实现框架，我们对集成服务原型系统进行了总体设计，如图3所示。QoS规范描述由应用程序接口完成；能力测试与QoS计算由接纳控制模块完成；QoS最终由资源调度模块实现。而RSVP作为在主机与路由器之间协商服务参数的信令协议，本身并不执行任何资源的预留。但是如果信令传递不当或发生故障，便会直接影响到预留的成败。
4.2  流量整形
我们采取典型的令牌桶机制进行流量整形。网络设备使用能容纳b字节令牌的令牌桶来衡量一个到达分组序列是否能满足参数要求；同时，设备以r字节/秒的速率向桶中添加令牌。如果桶中的令牌数大于或等于分组长度，就认为这个分组是符合令牌桶通信量描述的。具体说来，当分组到达时，设备检查在桶中的当前令牌数X与分组长度L，若  ，则分组符合描述；否则，认为分组违反描述，如图4所示。

图3  集成服务原型系统总体设计框图

图4 令牌桶整形示意图

4.3  PGPS调度策略[7,8]
真正向通信量提供QoS保证的是某种调度策略的有效实现。通过建立适当的流量模型，应用必要的排队理论，我们可以对通信量的网络行为进行分析，对于特定的调度策略，可以得到其端―端网络性能的分析。上层采用的服务体系结构，以及进行网络服务协商的内容，都是基于底层调度策略的模型分析的。因此，我们对集成服务使用的加权公平队列调度（Weighted Fair Queuing，WFQ，又称PGPS）进行相关分析，以便从中获得RSVP信令交互内容的依据。
设 为分组 在PGPS条件下的离开时刻，则对于所有的分组 ，有
                           (3)
式(3)中 是最大分组长度， 是服务器的恒定服务速率。
当进入的通信量经过整形，其平均到达速率为r，令牌桶深度为b，并且当前会话I的最大分组长度是L，则对于本地稳定的会话I来说，端－端的延迟有如下结果：
         （4）
4.4  对资源预留协议应用程序接口的改进
为了解决应用程序接口的问题，对照确保服务规范中提出的端-端延迟的上界，我们提出在PGPS调度的条件下，为应用程序确定通信量参数的方法。在所有参数中，令牌桶参数是难以确定的，却又是直接影响到调度效果的重要参数。根据公式(2)和(4)，我们可以做出如下假设
 ，即将令牌桶深度置为应用数据流的突发大小； 
 ，即服务器分配给会话的速率，就是应用程序请求预留的带宽对于每一类实时应用或多媒体应用都有一个相对固定的要求，例如MP3声频流的带宽是128kbps，MPEG-1视频流的正常工作带宽是1.5Mbps，MPEG-2视频流的一般质量要求带宽是5Mbps左右，高质量带宽要求是8Mbps左右；
令牌桶速率 根据 的值确定，保证 。为了处理方便，可以近似在数值上令 ，该值可以满足多数应用的要求。
其他参数，如 等，均可以在令牌桶参数确定的情况下，根据应用的不同要求比较方便的获得。
综上所述，我们对API进行了改进。按照应用数据流对预留的不同要求，我们研究了各种数据流的一般情况，按照令牌桶机制的要求，制定出符合一般规律的令牌桶参数及其他流特性参数的值，主要由以下方面决定：
?  集成服务模式（确保服务或负载受控服务）；
?  预留质量要求（高、中或低）；
?  数据流类型（MPEG视频流、音频流或其他类型的数据流）；
经过上述改进，接收双方在给定通讯地址和端口以后，只需要对上述要求进行选择，就可以发送消息，这样对应用程序比较合理。

5  对原型系统的测试及其结果
5.1  测试环境

图5

如图5所示，由一台双网卡PC机模拟路由器，连接两个子网，会话的双方分别位于不同网段内。选择FreeBSD 3.4作为端系统与路由器的操作系统，因为需要对操作系统内核进行修改。
5.2  协议一致性测试
我们首先需要测试的是系统与作为标准发布的ISI release 之间的协议一致性。发送方使用标准的API及其附带的测试程序，接收方使用我们改进的API及其测试程序。
?  双方通过指定一致的目的端（接收方）IP地址和端口建立会话；
?  发送方给出己方的地址与端口、发送流量特性（Tspec），发出PATH消息；在接收方显示PATH消息事件的输出信息，包括会话信息（接收方地址与端口）和路径信息（Tspec、ADSpec）；
?  在接收方显示PATH消息事件的输出信息，包括会话信息（接收方地址与端口）和路径信息（Tspec，ADSpec），表明接收方收到PATH消息；此时，接收方给出己方的地址与端口和用来过滤报文的发送方地址信息，选择服务模式、服务质量，发出RESV消息；
?  在发送方显示PATH消息事件的输出信息，包括会话信息（发送方地址与端口）和预留信息（Flowspec，Filterspec），表明发送方收到RESV消息；
?  此时，一次预留会话交互成功。
双方使用不同的API完成了此次会话，表明改进后的API与标准的API在协议的运行上是一致的。
5.3  视频应用的测试
我们使用一个MPEG-1视频点播应用程序进行系统服务质量测试。视频点播的客户方试图从服务器接收到高质量的MPEG-1视频数据，并进行实时播放。视频流使用UDP作为传输层协议。发送方与接收方均使用改进的API进行QoS协商与预留建立。对于参加测试的应用程序来说，正常工作的带宽需求是1.5Mbps。
测试包括2个步骤：
(1)  网络轻载条件下，无论点播客户端是否提交预留请求，所收到的视频播放正常。这表明只要提供足够的带宽，视频点播应用就能够正常工作；
(2)  与发送方在同一子网内的辅助主机A1产生用于干扰的UDP流量，并向与接收方在同一子网内的辅助主机A2发送。当干扰流量逐渐增加，直至剩余带宽接近1.5Mbps时，客户端的播放发生了变化：
?  没有预留的情况下，点到点的视频传输受到网络带宽的影响，客户端的播放出现严重的连续马赛克现象；
?  当应用请求建立预留时，客户端通过HPNAPI发出预留请求，指明其数据类型（MPEG视频流），服务质量请求（中等），请求服务类型（确保服务）。在预留建立之后的传输中，在同样的条件下，接收端仍然能够正常接收视频数据流，并进行清晰的播放。
上述测试表明，通过我们改进的应用程序接口，应用要求的带宽预留确实在网络结点上得到了适当的设置；通过套接口的进一步工作，应用的通信量参数被正确的传递到RSVP守护进程。一旦接纳控制接受了预留请求，应用所需的服务质量将在各结点的流量调度的作用下，依据通信量参数，获得应有的保证。这样，在API的帮助下，应用与网络协商服务，最终获得了面向应用的服务质量保证。
6  结论
借助于适当的理论分析和原型系统的实现测试，我们对集成服务体系下面向应用的服务质量保证进行了上述研究。针对实际的企业网络应用数据流特点，我们还需要作进一步的研究。勿庸置疑的是，这方面的研究对于确保企业网环境下的服务质量是有价值的。关于集成服务体系的研究目前仍在继续；更多的新型的QoS协议与体系结构不断的被提出来，要想获得真正可靠的服务质量保证，孤立的研究一个协议是不合适的。必须从整个网络的体系结构上进行自上而下的探索。