姜明
1.IP QoS产生的背景
互联网源于美国国防部的ARPANET计划。在上世纪60年代中期，正是冷战的高峰，美国国防部希望有一个命令和控制网络能够在核战争的条件下幸免于难，而传统的电路交换的电话网络则显得太脆弱。国防部指定其下属的高级研究计划局（ARPA）解决这个问题，此后诞生的一个新型网络便称为ARPANET。当ARPANET与美国国家科学基金会（NSF）建成的NSFNET互联以后，其上的用户数以指数增长，并且开始与加拿大、欧洲和太平洋地区的网络连接。到了80年代中期，人们开始把互联的网络称为互联网。
早在70年代中期，ARPA为了实现异种网之间的互联与互通，推出了TCP/IP体系结构和协议规范。时至今日，TCP/IP协议也成为最流行的网际互联协议。它不是国际标准化组织制定的，却已成为网际互联事实上的标准，并由单纯的TCP/IP协议发展成为一系列以IP为基础的TCP/IP协议簇。TCP／IP协议簇为互联网提供了基本的通信机制。
随着互联网的指数增长，其体系结构也由ARPANET基于集中控制模型的网络体系结构演变为由ISP运营的分散的基于自治系统（Autonomous systems AS）模型的体系结构。互联网目前几乎覆盖了全球的每一个角落，其飞速发展充分说明了TCP/IP协议取得了巨大的成功。
但是互联网发展的速度和规模，也远远出乎于二十多年前互联网的先驱们制定TCP/IP协议时的意料之外，他们从未想过互联网会发展到如此的规模，并且仍在飞速增长。随着互联网的普及，网络同人们的生活和工作已经密切相关。同时伴随互联网用户数膨胀所出现的问题也越来越严重。除了我们众所周知的IP地址匮乏外，另外一个严重问题就是缺乏服务质量（Quality of Service QoS）保障。
现有的互联网所提供的是"尽力而为"（best-effort）的服务，在这种服务模型下，所有的业务流被"一视同仁"地公平地竞争网络资源，路由器对所有的IP包都采用先来先处理（First Come First Service FCFS）的工作方式，它尽最大努力将IP包送达目的地。但对IP包传递地可靠性、延迟等不能提供任何保证。这很适合Email、Ftp、WWW等业务。
但随着互联网的高速增长，IP业务也得到了快速增长和多样化。特别是随着多媒体业务的兴起，计算机已经不是单纯的处理数据的工具，而是越来越贴近生活，计算机的交互越来越实时和生动，这对计算机互联网络也就相应地提出了更高的要求。对那些有带宽、延迟、延迟抖动等特殊要求的应用来说，现有的"尽力而为"的服务显然是不够的。尽管由于网络技术的发展，网络带宽以及网络速度都得到了极大的提高，但需要通过网络传输的数据却也几乎以与网络发展速度相同的速度增加，甚至超过网络发展的速度，这使得网络带宽与网络速度依然是一个瓶颈问题。同时，近年来发展起来的一些新的应用（如多媒体应用，组播应用等）不仅增加了网络流量，更因为这些应用改变了以往互联网上的流量性质，因而它们需要全新的服务要求。由于不具备服务质量保障特性，不能预留带宽，不能限定网络时延，因此，目前的因特网无法支持许多新的应用如远程教学、远程手术、远程会议和学术交流等。
2.IP QoS的定义及其实施方案
IP QoS的研究目标是有效地为用户提供端到端的服务质量控制或保证。QoS就是网络单元（例如，应用程序，主机或路由器）能够在一定级别上确保它的业务流和服务要求得到满足。QoS并没有创造带宽，只是根据应用程序的需求以及网络状况来管理带宽。IP QoS有一套性能参数，主要包括：
业务可用性：用户到Internet业务之间连接的可靠性。
传输延迟：指两个参照点之间发送和接收数据包的时间间隔。
可变延迟：也称为延迟抖动（Jitter），指在同一条路由上发送的一组数据流中数据包之间的时间差异。
吞吐量：网络中发送数据包的速率,可用平均速率或峰值速率表示。
丢包率：在网络中传输数据包时丢弃数据包的最高比率。数据包丢失一般是由网络拥塞引起的。
实现QoS的一种方法是按照服务水平的要求分配资源给每一个数据流。这种采用"资源预留"进行带宽分配的方法并不适合"尽力而为"型应用。由于带宽资源是有限的，QoS的设计者引入了优先级概念，使得在资源预留后"尽力而为"服务的数据流的传输也能得到一定的保障。因此，IP QoS可以分为两种基本类型：
基于资源预留：网络资源按照某个业务的QoS要求进行分配，制定资源管理策略。互联网工程任务组IETF（Internet Engineering Task Force）提出的综合服务（Integrated Services， IntServ）体系结构便是基于这种策略，资源预留协议（Resource reSerVation Protocol, RSVP）是其核心部分。
基于优先级：网络边界节点对业务流进行分类、整形、标记。核心节点按照资源管理策略分配资源，对QoS要求高的业务给以优先处理。IETF提出的区分服务（Differentiated Services，DiffServ）便是基于这种策略。
这些QoS方法可以被用于单个数据流或聚集的数据流（aggregate flow）。根据应用的数据流的不同，IPQoS可以分类为：
用于单数据流：单个数据流为在两个应用（发送者和接受者）之间的单个的、单向的数据流。可以用传输协议、源地址、源端口号码、目的地址和目的端口号码这五种参数来分类。
用于聚集流：综合流由两个或更多个单个数据流组成。这些流在一个或多个参数、标记或优先数以及一些认证信息方面有一些共同点。
为了解决IP QoS问题，IETF已经提出了几种服务模型和机制，主要有：
综合服务和资源预留协议IntServ/RSVP：以RSVP信令向网络提出业务流传输规格（Flowspec），并建立和拆除传输路径上的业务流状态。主机和路由器节点建立和保持业务流状态信息。尽管RSVP经常用于单个流，但也用于聚流的资源预留。
区分服务：在区分服务网络中，边界路由器根据用户的流规格（stream profile）将用户流划分为不同的级别，再聚合成流聚集，聚集信息存放在IP包头的DS标记域，称为DS标记（Differentiated Services CodePoint，DSCP）。内部节点则根据DSCP提供不同质量的调度转发服务。
多协议标记交换（MultiProtocol Lable Switch，MPLS）：根据分组头的标记，通过网络路径控制来提供流聚集的带宽管理子网带宽管理（Subnet Bandwidth Management，SBM）：负责OSI第二层（数据链路层）的分类和优先级排列，同IEEE 802网络进行共享和交换。
3.综合服务模型和资源预留协议
IntServ/RSVP简介
Int-Serv/RSVP服务模型在IETF RFC1633中进行了定义。RFC1633将资源预留协议RSVP作为IntServ结构中的主要信令协议。其基本思想就在于以资源预留的方式来实现QoS保障，RSVP是其核心部分。RSVP是主机用来从应用程序获得特定的QoS的一种控制协议，完成综合服务需要定义的呼叫接纳控制功能和资源预留功能。端点应用程序利用RSVP消息向网络提出完成数据传送必须保留的网络资源（如带宽及缓冲区大小等），同时也确定沿传送路径的各个节点传输处理策略，从而对每个业务流实现逐个控制。
在服务层次上，IntServ/RSVP提供了3种级别的业务：
端到端的质量保证型服务（Guaranteed Service）：保证带宽、限制延迟、无丢包。
可控负载型服务（Controlled－Load Service）：类似于在当前的一个负载较轻网络中实现的尽力而为业务的服务质量。
尽力而为的服务（Best Effort Service）：类似当前Internet在提供的尽力而为的服务。
在结构层次上，IntServ/RSVP服务模型主要由四个部分构成：信令协议RSVP，接入控制器（admission control routines），分类器（classifier）以及包调度器（packet scheduler）。
在实现层次上，综合服务需要所有路由器在控制路径上处理每个流的信令消息并维护每个流的路径状态和资源预留状态，在数据路径上执行流的分类、调度和缓冲区管理。具体而言，资源预留协议RSVP负责逐点（hop-by-hop）地建立或者拆除每个流的资源预留软状态（soft tate），也即建立或拆除数据传输路径；接入控制器将决定是否接受一个资源预留请求，其根据是链路和网络节点的资源使用情况以及QoS请求的具体要求；分类器则对传输的数据包进行分类成传输流， IntServ常用的分类器是多域（Multi-Field，MF）分类器，当路由器接收到数据包时，它根据数据包头部的多个域（如5元组：源IP地址，目的IP地址，源端口号，目的端口号，传输协议），将数据包放入相应的队列中；调度器则根据不同的策略对各个队列中的数据包进行调度转发。
资源预留协议RSVP
RSVP早在1993年就被提出，用于为IP网提供QoS能力。1997年初IETF批准RSVP成为RFC文件，在+IntServ工作组内进行标准制定工作。RSVP是一种提供预留设置和控制以实现综合服务合协议，是所有QoS协议中最复杂的。RSVP资源预留请求包括流规格说明（TSpec）、资源预留规格说明（RSpec）和过滤器规格说明（Filter Spec），它们一起称为"流描述符"（Flow Des-criptor）。资源预留请求中的流规格说明通常包含服务类型和数字参数集合。预留说明和业务流说明决定于综合服务模型并且对RSVP来说是透明的。过滤器规格说明的格式依赖于所使用的网络层协议，即IPv4或IPv6。目前所用的RSVP中定义的基本过滤器规格说明格式具有严格的形式：发送端IP地址和可选的TCP/UDP端口号。在服务保证、资源分配的粒度和对保证QoS应用及用户反馈的细节等方面RSVP都能提供最高级的QoS。归纳起来，RSVP有以下6个特点：
在每一个路由器中的预留是"软"的，这意味着需要由接收者周期地更新。
RSVP不是传输协议而是网络（控制）协议，它不携带数据，但是和TCP或UDP数据流并行工作。
应用要求API决定流的初始预留请求，并且接收在经过初始请求和全过程中预留成功或失败的通知。
为了能够容纳大量不同的接收者，预留是以接收端驱动的（Receiver-Driven)。
多播的预留在上行的数据流复制点上被结合。
RSVP数据流可以通过不支持RSVP的路由器，这会在QoS链上产生弱链路，在这些弱链路上无法提供QoS保证，因而此时的服务就是尽力而为型的。
使用RSVP信令建立数据发送路径以及为业务流预留资源的过程如下：
发送端向接收端发送一个包含业务流规格说明（TSpec）的PATH消息，其中包含了业务流标识(即目的地址)及其业务特征，包括所需要的带宽的上下限，延迟以及延迟抖动等。如图1中①所示。
该消息由沿路径的路由器逐跳传送，并且每个路由器都被告知准备预留资源，从而建立一个"路径状态"，该状态信息包含PATH消息中的前一跳源地址。如图1中②、③所示。
接收方收到此消息后从业务特征和所要求的QoS计算出所需要的资源，向其上游节点发送一个资源预留请求RESV消息，该消息中包含了TSpec、RSpec以及Filter Spec，其主要包含的参数就是要求预留的带宽。如图1中④所示。
RESV是沿PATH的发送路径原路返回的，沿途的路由器收到RESV消息后，调用自己的接入控制程序以决定是否接受该业务流，如果接受，则按要求为业务流分配带宽和缓存空间，并记录该流状态信息，然后将RESV消息继续向上游转发；如果拒绝，则向接收端返回一个错误信息给接收端以终止呼叫。如图1中⑤所示。
当最后的路由器收到RESV消息并且接受该请求时，它向接收端发回一个确认消息。如图1中⑥所示。
图1 RSVP建立传输路径以及预留资源的过程
在此过程中，我们注意到，和电信网络中的呼叫建立过程相反，RSVP是由接收端驱动的资源预留。其目的是考虑在组播的情况下，以接收端驱动，可以适应组播群成员的动态增减，以及各接收端要求不同QoS的异质请求情况。当通信结束或者一方退出会话后预留的资源可以由超时机制释放。RSVP还定义了显式的释放机制，通过PathTear由启动点沿下游方向传送至接收端，通知沿途各路由器释放资源。ResvTear则反向传送，功能相似。它们可由端系统发出，也可由路由器在状态超时时发送出。至此，业务流的传输路径已经建立起来了，数据流可以进行发送了。
RSVP可以看作是配置业务处理的机制，综合服务则是在RSVP信令基础上够用以提供端到端QoS保证的体系结构。IntServ设定网络设备支持业务的处理机制，保证每一个业务流严格独立于其他业务流的服务，并设定提供特定量化资源的服务。
从以上讨论可以看出，IntServ/RSVP服务模型对传统Internet体系结构的扩展主要包括在路由器中保存业务流状态信息以及明确的状态建立机制。这种模型在路由器中所保存的业务流状态信息是软状态信息，由于软状态信息在路由器发生错误时容易通过RSVP信令刷新而隐含地拆除并在另外路由器中重建业务流状态信息，而硬状态信息（hard state）需要明确地拆除状态信息，因而保持了网络体系结构的鲁棒性（robustness）。同时，由于这种模型有效地集成了各种实时应用和非实时应用，因而保持了网络的效率。另外，由于兼容了传统网络体系结构和协议栈，因此能对网络进行有效的管理。
IntServ/RSVP的缺陷
从理论上讲IntServ/RSVP模型完全可以保证为IP网络提供QoS保障。但随后在一些网上的实验表明这种服务模型有很明显的局限性，这些问题主要表现在：这不仅表现在扩展性差上，更大的问题是它要求核心路由器必须保持经过它的每一个单个数据流的状态，而核心路由器是不能这么做的。另一个大问题是这种方法因此，尽管主要的路由器生产商和主机都支持RSVP,它也被广泛接受，但是它始终没有成为主流，原因是ISP们不愿意采用它，很少有大型网络采用它。近来，人们认识到RSVP的出路在于与区分服务配合工作，相辅相成。
可扩展性差：可扩展性是IntServ/RSVP模型最致命的一个问题，其基于流的资源预留、调度处理以及缓冲区管理，有利于提供QoS保证，但状态信息随业务流数量的增长而增长，沿途的路由器要为每个数据流都维持一个"软状态"，而路由器的存储器容量有限,可以保存的软状态信息都是有限的，在一个运营商规模的网络中几乎不可能实现这一要求。
对路由器的要求过高，网络中所有的路由器都必须支持RSVP信令协议，接入控制程序，分类器以及调度器。
RSVP中引入每流状态（per-flow state）的概念，对于数据通信和实时应用通信而言，IP网络同时扮演了面向无连接和面向连接网络的两个不同角色，提供两种功能,这与其简化设计原则相抵触。
资源预留不适用于短时流，比如Web流等，而在因特网中Web流量超过了50％。
IntServ/RSVP还存在着资源预留和路由协议之间的矛盾。如图2所示，从路由角度来看它是一条好的路径，但从资源预留来看，由于没有足够的资源可以预留，不能为数据流建立起一条路径，因此这一进程只能停留在这里，等待上层超时拆除这个应用进程，再重新建立路径。
因此，要实现IntServ的QoS保证是很困难的，它需要基于流的、复杂的资源预留、接纳控制、QoS路由和调度机制。在诸如互联网这种复杂的、大规模的网络中，链路状态是不确定的，有效地预留带宽资源非常困难。而且资源预留本身就与IP网络的最大特点"无连接"相冲突。更重要地问题就是IntServ面临地可扩展性（scalability）问题和鲁棒性（rubustness）问题，这主要是因为在分布式网络环境中，很难维持动态的、可复制的传输流状态一致性。
早期的IntServ是面向单流的，在路由器配置和使用多域分类准则，这给路由器尤其是主干网络核心路由器带来了巨大负荷。为了增加IntServ的扩展性，近期RSVP已经开始支持流聚集，即将沿相同业务流传输路径流聚合成宏流（macro-flow），按宏流来预留资源。这虽然减轻了核心路由器的一些负担，但IntServ本身的体系结构已经决定了其高复杂性，而且由于路径数是边界节点数的平方，宏流数仍然很庞大。
由于IntServ/RSVP体系存在着诸多问题，一种新的体系结构便应运而生，这就是区分服务体系结构(Differentiated Services，DiffServ)。
摘自 赛迪网
