IP网络中的QoS研究

1　引言

QoS（Quality of Service）即服务质量是一个综合指标，用于衡量使用一个服务的满意程度。随着Internet规模的不断增长，IP网上出现了大量的实时业务。由于实时业务对网络的传输延时、延时抖动等特性较为敏感，因此这些实时业务的出现暴露了IP网络技术的两个重要缺陷：一个是传统IP路由技术的吞吐量不高，这可以随着ASIC技术的进步，通过设计专用硬件来解决；另一个就是传统IP没有服务质量QoS保证，这与计算机网络产生之初只是为传输简单的数据业务，因而采用面向无连接的服务有关。IP网络不能保证业务特定的QoS要求已经成为IP网络向宽带综合服务网络发展的巨大障碍。有人提出可以用增大带宽来解决QoS问题，然而由于应用的需求是无止境的，因此不管网络有多大的带宽都有可能耗尽，所以这种方法并不十分可行。因此如何解决IP网络的QoS要求，以使网络能够灵活地根据业务的具体特点提供给客户满意的服务，是IP业界亟待解决的问题。在这种情况下，各个研究团体纷纷开始组织大规模的QoS研究，一些大的通信厂商也联合成立了QoS论坛，协商各种QoS技术标准的实施方案。在当前的网络环境中，QoS的研究内容主要体现在确保实时业务的通信质量这一方面。

2　QoS技术的分类

Qos技术可分为保证型和尽力型两种。保证型的QoS在终端双方通信之前先要建立连接，确保通信过程中的网络带宽，如ATM业务类型、IP网络中的RSVP。一旦连接建立，通信中所需的带宽就能保证，与连接相关的应答时间、时延要求也能保证。如果网络不能提供所需的带宽，它就会拒绝建立连接。尽力型的QoS技术不能确保带宽，通常用在非连接型通信中，例如在IEEE802．1p／Q的标记帧或IP分组头中的TOS域有3位的优先级，供LAN交换机或路由器进行优先级控制，由于采用这种方法不能在通信中确保带宽只是按优先级顺序进行交换或转发，因此也称为COS（Class of Service）以区别能保证带宽的狭义的QoS技术。

3　IETF建议的QoS技术方案介绍

IETF建议的QoS技术方案主要有：综合服务／资源预留、差分服务、多协议标记交换、流量工程和基于约束的寻路。

综合服务模型（Int－serv：Integrated service）的主要特征就是资源预留，它使用RSVP作为信令协议来建立通道和进行资源预留。差分服务（Diff－Serv：Differentiated Services）通过给分组打上不同的标记，把分组分成不同的类别，对不同类别的分组ProtocolLabelSwitching）是一种转发方案，分组在进入MPLS域时被赋予一个标签，以后就根据这个标签对分组流进行分类、转发、服务。流量工程（TE：traffic engineering）的目标是让网络上的业务流量更加均衡。基于约束的寻路要解决的是根据带宽和延时要求等约束条件寻找一条合适的路径。

3．1　综合服务模型

综合服务模型在RFC（Request for Comments）1633中进行了定义。它的基本思想是将RSVP作为Int－Serv结构中的主要信令协议，“所有的流相关状态信息应该是在端系统上”，它基于每个流提供端到端的保证或是受控负载的服务。Int－Serv框架使IP网络能够提供具有QoS的传输，以用于对QoS要求较为严格的实时业务（声音／视频）。Int－Serv使用一种类似ATM的SVC的方法，它在发送方和接收方之间用RSVP作为每个流的信令。RSVP信息跨越整个网络，假定从接收方到发送方之间沿途的每个路由器都要为每一个要求QoS的数据流预留资源。路径沿途的各路由器包括核心路由器必须为RSVP数据流维护软状态。

为了实现上面的服务，Int－Serv定义了4个功能部件，网络中的每个路由器皆需要实现这4个部件。

（1）RSVP（RFC2205）：资源预留协议（RSVP：Resource Reservation Protocol），它是Internet上的信令协议。通过RSVP，用户可以给每个业务流（或连接）申请资源预留，要预留的资源可能包括缓冲区及带宽的大小。这种预留需要在路径上的每一跳都要进行，这样才能提供端到端的QoS保证。RSVP是单向的预留，适用于点到点以及点到多点的通信环境。

图1示出了RSVP的工作机理。首先，发送方应该向接收方发送一个RSVP信息。RSVP信息同其他IP包一样通过各个路由器到达目的站点；接收端接收到发送端发送的路径信息之后，由接收端逆向发起资源预留的过程；资源预留信息沿着原来信息包相反的方向对沿途的路由器进行逐个资源预留。

如图1所示，假设一个应用需要预留2Mbps的带宽，则资源预留信息逐个询问沿途的路由器，其现有资源是否可以完全满足该应用数据流的要求。如果资源预留信息成功地回到发送方，则发送方就可以成功地在这条已经预留资源的路径上发送应用数据了；否则，应用将无法进行。

（2）访问控制（Admission Control）：它基于用户和网络达成的服务协议，对用户的访问进行一定的监视和控制，有利于保证双方的共同利益。

（3）分类器（Classifier）：根据预置的一些规则，它对进入路由器的每一个分组进行分类。分组经过分类以后被放到不同的队列中等待接收服务。这方面的技术还不很成熟，是一个有待研究的领域。

（4）队伍调度器（Scheduler）：它主要是基于一定的调度算法对分类后的分组队列进行调度服务。这方面的技术目前已比较成熟，常见的调度算法有WFQ、WF2Q、SCFQ、VC、MD－SCFQ、WRR等。

Int－Serv定义了三种业务类型：

?有保证的业务（Guaranteed）：保证带宽、限制延迟、无丢包。

?控制负载的业务（Controlled Load）：在一个负载较轻的网络中实现类似尽力而为的业务。

?尽力而为的业务（Best Effort）：类似于Internet在多种负载环境（由轻到重）提供的尽力而为的业务。

Int－Serv的优点是它具有很好的QoS保证，使用RSVP的软状态特性可以支持网络状态的动态改变与组播业务中组员的动态加入，同时利用RSVPPATH与RESV的刷新，还可以判断网络中相邻节点的产生与退出节点，并实现网络资源的有效分配。

Int－Serv存在的问题一是网络的扩展性不好。一方面由于Int－Serv下的预留状态住处是与业务流的个数成正比，这使得路由器的负担会随着网络的扩大、业务流的增加而加重。另一方面资源预留协议还要求沿途的每个路由器为每一个数据流都维持一个“软状态（Per－flowsoftstate）”。这无疑也限制了这种结构的可扩展性，因为每个路由器的内存有限，可以保存的软状态信息都是有限的。其二是Int－Serv需要进行端到端的资源预留，必须要求从发送者到接收者之间的所有路由器都支持所实施的信令协议，因此所有路由器必须实现RSVP、许可控制、MF（Multi－Field）分类和包调度，这对路由器的实现要求太高。其三是Int－Serv还有一个目前很难解决的问题，那就是资源预留和路由协议之间的矛盾。

此外，如何为资源预留申请授权并确定优先权也是Int－Serv结构本身很难克服的问题。

3．2　差分服务模型

差分服务模型的基本思想是可以根据预先确定的规则对数据流进行分类，以便将多种应用数据流综合为有限的几种数据流等级。差分服务是由综合服务发展而来的，它采用了IETF的基于RSVP的服务分类标准，抛弃了分组流沿路节点上的资源预留。差分服务将会有效地取代跨越大范围的RSVP的使用。差分服务区域的主要成员有：核心路由器、边缘路由器、资源控制器。在差分服务中，网络的边缘设备对每个分组进行分类、标记DS域，用DS域来携带IP分组对服务的需求信息。在网络的核心节点上，路由器根据分组头上的DS码点选择码点所对应的转发处理。资源控制器配置了管理规则，为客户分配资源，它可以通过服务级别协定SLA（Service LevelAgreement）与客户进行相互协调以分享规定的带宽。

IPQoS的业务区分结构使用IPv4报头中的业务类型（ToS）字段，并将8位ToS字段重新命名，作为DS字段，其中6位可供目前使用，其余2位以备将来使用。该字段可以按照预先确定好的规则加以定义，使下行节点通过识别这个字段，获取足够的信息来处理到达输入端口的数据包，并将它们正确地转发给下一跳的路由器。这里需要注意的是，在IPv4网中所定义的ToS字段与在Diff－Serv中的DS字段不同。ToS字段的定义如图2所示。

Diff－Serv将整个网络分成若干个域。一个Diff－Serv域由一系列支持Diff－Serv机制的节点构成。在Diff－Serv域中，节点大致分为以下两类：边缘路由器和内部路由器。其中边缘路由器根据数据流的方向分为入口边缘路由器和出口边缘路由器。在入口处设有机制一件是用户是否遵守业务等级协定（SLA），分类机制以标志输入的每个业务包，对每个IP包指定一个类型以标志DSCP（Diff－Serv代码点），并分别将其分别排入相应的队列。内部路由器负责查看DSCP值，将进入的数据包按级别排队，并按事先设定的带宽、缓冲处理进行下一跳转发（PHB）。Diff－Serv模型机制的工作示意图如图3。

与Int－Serv类似，Diff－Serv也定义了三种业务类型：

（1）尽力而为的业务（Best Effort）：类似目前Internet中尽力而为的业务；

（2）最优的业务（Premium）：类似于传统运营商网络的专线业务；

（3）分等级的业务（Tiered）：这一类别的业务严格讲不仅仅是一种业务，而是一个大的类别，可以根据发展的需要制定不同的业务等级。

差分服务模型的优点一个是伸缩性较好DS字段只是规定了有限数量的业务级别，状态信息的数量正比于业务级别，而不是流的数量。另一个是便于实现只在网络