IPQoS的体系结构和实现机制.doc

IPQoS的体系结构和实现机制-IPQoS正成为业界关注和研究的热点，IETF为之成立了专门的工作组，研究出一些初步的成果，但IPQoS的彻底解决还有待于更进一步的研究和发展。IPQoS的体系结构-到目前为止，业界的不同组织或单位已提出了一些QoS的体系结构，这包括IBM公司的HeidelbergQoS模型、美国哥伦比亚大学COMET研究组提出的XRM模型、美国宾夕法尼亚大学的OMEGA体系结构、加利福尼亚大学伯克利分校的Tenet模型等。但对于IPQoS则主要有以下两种体系结构。-IntServ集成业务体系结构-IntServ(IntegratedServicesArchitecture)由IETF的IntServ工作组于1994年在RFC1633中提出。Intserv定义了三种服务类型。 1. GuranteedServices(RFC2212)：对带宽、时延、分组丢失率提供定量的质量保证；2. Controlled-loadServices(RFC2211)：给用户提供一种类似在网络欠载情况下的服务，它是一种定性的指标；3. Best-Effort：类似于目前Internet网上提供的服务，是一种尽力而为的工作方式，基本上无任何质量保证。 -为了实现上面的服务，IntServ定义了4个功能部件，网络中的每个路由器皆需要实现这4个部件。 1. RSVP(RFC2205)：RSVP即资源预留协议，它是Internet上的信令协议。通过RSVP，用户可以给每个业务流(或连接)申请资源预留，要预留的资源可能包括缓冲区及带宽的大小。这种预留需要在路径上的每一跳都要进行，这样才能提供端到端的QoS保证。RSVP是单向的预留，适用于点到点以及点到多点的通信环境。2. 访问控制(AdmisionControl)：它基于用户和网络达成的服务协议，对用户的访问进行一定的监视和控制，有利于保证双方的共同利益。3. 分类器(Classifier)：根据预置的一些规则，它对进入路由器的每一个分组进行分类。这可能需要查看IP分组里的某些域：IP源地址、IP目的地址、上层协议类型、源端口号、目的端口号；分组经过分类以后被放到不同的队列中等待接收服务。这方面的技术还不很成熟，是一个有待研究的领域。4. 队伍调度器(Scheduler)：它主要是基于一定的调度算法对分类后的分组队列进行调度服务。这方面的技术目前已比较成熟，常见的调度算法有WFQ、WF2Q、SCFQ、VC、MD-SCFQ、WRR等。 -IntServ尽管能提供QoS保证，但扩展性较差。因为其工作方式是基于每个流的，这就需要保存大量的与分组队列数成正比的状态信息；此外，RSVP的有效实施必须依赖于分组所经过的路径上的每个路由器。在骨干网上，业务流的数目可能会很大，同时它还要求路由器的转发速率很高，这使得IntServ难于在骨干网上得到实施。目前，比较一致的看法是在企业网的边缘实施IntServ，或者对流(flow)的定义更加粗糙以使业务流的数目降低到可以承受的地步。-DiffServ区分业务体系结构-为了解决IntServ的一些缺点，IETF在RFC2475中提出DiffServ(DifferentiatedServicesArchitecture)体系结构，旨在定义一种实施IPQoS且更容易扩展的方式，以解决IntServ扩展性差的缺点。DiffServ简化了信令，对业务流的分类颗粒度更粗。它通过汇聚(aggregate)和PHB(PerHopBehavior)的方式来提供一定程度上的QoS保证。汇聚的含义在于路由器可以把QoS需求相近的各业务流看成一个大类，以减少调度算法所处理的队列数；PHB的含义在于逐跳的转发方式，每个PHB对应一种转发方式或QoS要求。-在DiffServ里，引入了DiffServ域(Domain)的概念，一个DiffServ域可以认为是一个能提供DiffServ业务的子网，如图所示。DiffServ域主要由一些路由器组成，并对这些路由器进行了区分，把位于DiffServ域边界的称为边界路由器(EdgeRouter)，而把DiffServ域内部的称为内部路由器(CoreRouter)。边界路由器需要具有的功能有：对业务流的分类(基于IP分组中一些字段的与IntServ类似的较细分类或者为基于汇聚的较粗分类)、整形(shaping)、标记(marking)和调度(sheduling)；内部路由器需要具有的功能有：分类(为基于汇聚的较粗的分类)、调度。DiffServ力图通过对业务流的分类、整形、标记、调度来实现对业务QoS一定程度上的保证。目前在DiffServ上主要提出了下面两种业务： ExpeditedServices(EF-RFC2598)：提供类似于专线或租用线的服务； AssuredServices(AF-RFC2597)：提供比Best-Effort尽量好的QoS； -DiffServ利用了IPv4分组头的TOS字段(或IPv6的COS字段)，作为DSCP(DiffServ编码点)使用。每一种DSCP对应一种PHB方式。路由器在转发分组时只需查看每个分组的DSCP值，从而对此分组提供相应的PHB转发方式。目前已定义的DSCP值有：000000为缺省(Best-Effort)、101100为EF及12个AFDSCP。-实际上，DiffServ仅提供了一种在一子网络域内实施QoS的框架结构，而具体的一些策略和相应的实现机制则由不同的厂商来决定。尽管DiffServ比较灵活，但同时提出的一个问题是它能否真正提供QoS保证。IPQoS的实现机制-队列管理机制(QueueManagementMechanism)-在网络发生拥塞时，路由器必须丢弃一些分组，这个问题的解决首先必须实施有效的队列管理机制(或缓冲区管理策略)。-目前，已经出现的队列管理机制有：PPD(PartialPacketDiscard)、EPD(EarlyPacketDiscard)、RED(RandomEarlyDiscard)、FRED(FlowRED)、RIO(REDwithInandOut)、BLUE等算法。比较起来，RED算法具有较低的排队时延、较高的分组通过度(Goodput)和较好的公平性，其主要思想是：路由器计算平均排队长度，当平均排队长度超过某一门限时，路由器按照一丢弃概率丢弃到达的分组，而这个丢弃概率是与平均排队长度成正比的函数。RED算法允许短时的分组突发，因而可以避免因为网络负荷变化造成的分组丢弃；RED能避免多个TCP连接同时的超时重传，从而保持高的带宽利用率；此外，RED算法还能较好的支持突发业务，且确定哪些连接使用了更多的带宽，并可以采取措施予以惩罚。-FRED和RIO都是在RED上的改进或变种，FRED对每一个业务流(或连接)都实施单独的一个RED算法，这样能保证更好的公平性；RIO在RED的基础上又增加了一个门限值，在对DiffServAF业务的研究中多采用此算法。-BLUE算法是IBM公司的研究人员最近才提出的另一种较新的队列管理机制，与其他算法不同的是：BLUE算法以“分组丢失率”和“链路有效利用率”作为判别拥塞是否发生的标准，而之前的算法都是以路由器中的“平均分组长度”作为拥塞是否发生的判别标准。-队列调度机制(QueueingSchedulingMechanism)-不论在IntServ还是在DiffServ里，都涉及到队列调度问题。简言之，队列调度的功能就是路由器如何从多个(或一个)队列中选择下一个待转发的分组，这与队列管理机制有着本质的区别。根据不同的服务规则，队列调度算法可以分为以下几种：先到先服务(FCFS)、循环调度(RoundRobin)、处理机共享(ProcessorSharing)、优先级服务、随机服务等。-目前已出现的队列调度算法主要有：基于循环调度的算法、基于GPS(GeneralizedProcessorSharing)的算法两大类。一个有效的队列调度算法应达到的性能指标主要有：公平性、时延特性、对恶意业务流的隔离能力、链路带宽的利用率、复杂性等，前4个指标与QoS密切相关。基于循环调度的算法是轮流地对每个队列进行服务，其实现简单，但不能对业务提供时延保证，目前主要有WeightedRR、DeficitRR等。基于GPS的调度算法目前主要有：加权公平排队(WFQ)、自时钟公平排队(SCFQ)、VC(VirtualClock)等，它们(尤其是WFQ)能提供较好的公平性、时延特性以及对恶意业务流的隔离能力，但当队列数较多时，其实现复杂度较大。-基于约束的路由(Constrained-BasedRouting)-基于约束的路由(CBR)源自QoSRouting，只是对QoS的限制参数进行了一定的扩充。CBR的有效实现需要各个路由器之间的相互配合，比如相互通知各自所知道的网络的一些状态信息(如链路的剩余带宽)。CBR的难点在于：如何在状态信息的精确发布和发布频率之间取得一个折衷。因为链路的剩余带宽在不断的变化，CBR既要避免状态信息发布的滞后性，又要避免不停地频繁发布状态信息。CBR的有效实现还有待进一步的研究。-业务量工程(TrafficEngineering)-业务量工程的主要目的在于尽量地避免网络拥塞的发生，以保证QoS。网络拥塞发生的原因可能有：网络资源(比如链路带宽、缓冲区)的不足、以及网络中业务的不均匀分布。当业务量不均匀分布时，则有的链路处于过载状态而有的链路可能处于欠载状态，此时如果我们能够对网络中的业务流进行适当引导，则不必增加网络资源也可能消除拥塞。业务量工程的目的就在于：如何有效地引导业务流通过网络以便消除由于业务量不均匀分布而造成的网络拥塞。多协议标记交换(MPLS)和基于受限的路由都是业务量工程的有用工具，也是目前有待进一步研究的课题。IPQoS有待解决的问题