QoS的协议与结构

　　标准Internet协议(IP)的网络提供尽力而为的数据传输。这种IP网络允许客户端主机的结构复杂一些，而网络端的结构可以保持相对的简单，因为Internet要支持自身的快速发展，所以这样的结构划分是有好处的。

　　当越来越多的主机联在一起的时候，网络服务的需求最终会超过网络的能力，而服务却不会停止，由此产生网络性能的逐渐恶化，进而造成传输迟延的变化(抖动)，甚至引起分组丢失，但不会影响常用的Internet应用(如，电子邮件，文件传输和Web应用)，而其它应用就不能适应有迟延的服务。传输迟延对有实时要求的应用(例如传送多媒体信息)及大多数双向通信(如电话)带来了问题。

　　增加带宽是满足这些实时应用必要的第一步。但是当业务量猛增的时候，仍难以避免传输迟延。甚至在一个负载相对较轻的IP网络上，传输迟延也能累积到影响实时应用的程度。为了提供能够满足要求的服务，必须补充制订有关服务数量、或服务质量水平的规定。规定中需要在网络方面增加一些协议，来区分具有严格定时要求的业务和能够容忍迟延、抖动和分组丢失的业务。这就是服务质量(QoS)协议要做的事情。QoS不是创造带宽，而是管理带宽，因此它能应用得更为广泛，能满足更多的应用需求。QoS的目标是要提供一些可预测性的质量级别，以及控制超过目前IP网络最大服务能力的的服务。

　　QoS协议要满足各种应用的需要。这篇文章将对这些协议做详尽的描述，然后说明它们在遵循端到端原则的不同的网络结构里是如何相互配合工作的。IPQoS技术所面临的挑战是要能把传输的服务从不同的数据流中区分开，或者在不中断网络工作的情况下将数据聚合起来。尽力而为服务的改进表明让Internet发挥其最大作用的设计思路发生了根本变化。

　　为了避免QoS协议用于网络时出现问题，端到端原则仍然是QoS设计者首要遵循的原则。所以，保持网络边缘复杂、核心简单这一基本原则是QoS结构设计的中心问题。这不是指单个QoS协议，而是指这些协议如何相互配合来实现端到端的QoS。

　　QoS协议

　　描述QoS的方法不只一种。通常情况下，QoS是一个网络部件(如一个应用、一台主机或一个路由器)提供的一些保证稳定传输网络数据的质量级别。某些应用对QoS的要求比其它应用更高，因此有下面两种基本的QoS：

　　资源预留(适于综合服务)：根据某个应用对QoS的要求来分配网络资源，并且服从带宽管理策略

　　按优先级排列(适于差分服务)：对网络的业务进行分类，并根据带宽管理策略的规范来分配网络资源。当所标识的业务类别有更强烈服务要求的需求时，网络部件会给予优先处理。

　　有两种其它方法描述QoS类型：

　　'流'型QoS：把一个'流'定义为一个信源和信宿之间、单个、单向、由传输协议唯一标识的数据流，其中包括数据流的源地址、源端口号、目的地址以及目的端口号

　　'聚合'型QoS：一个聚合是简单的两个或更多的'流'。最为突出的是，这些'流'会有相同的标记或者优先级号码，也许还有一些相同的认证信息。

　　应用、网络拓扑结构和策略决定了哪一种QoS最适合个别'流'，或者'流聚合'。

　　为满足对QoS不同的需要，有以下几种QoS协议和算法：

　　资源预留协议(RSVP)：提供网络资源预留的信令。尽管RSVP经常用于单个流，但也用于聚合流的资源预留

　　差分服务(DiffServ)：提供一个简单的分类和网络聚合流的优先级

　　多协议标记交换(MPLS)：根据分组头的标记，通过网络路径控制来提供聚合流的带宽管理

　　子网带宽管理(SBM)：负责OSI第二层(数据链路层)的分类和优先级排列，同IEEE802网络进行共享和交换。

　　RSVP－资源预留

　　RSVP是一个信令协议，它提供建立连接的资源预留，控制综合业务，往往在IP网络上提供仿真电路。RSVP是所有QoS技术中最复杂的一种，与尽力而为的IP服务标准差别最大，它能提供最高的QoS等级，使得服务得到保障、资源分配量化，服务质量的细微变化能反馈给支持QoS的应用和用户。

　　协议的工作情况如下：

　　发送端依据高、低带宽的范围、传输迟延，以及抖动来表征发送业务。RSVP从含有'业务类别(TSpec)'信息的发送端发送一个路径信息给目的地址(单点广播或多点广播的接收端)。每一个支持RSVP的路由器沿着下行路由建立一个'路径状态表'，其中包括路径信息里先前的源地址(例如，朝着发送端的上行的下一跳)

　　为了获得资源预留，接收端发送一个上行的RESV(预留请求)消息。除了TSpec，RESV消息里有'请求类别(RSpec)'，表明所要求的综合服务类型，还有一个'过滤器类别'，表征正在为分组预留资源(如传输协议和端口号)。RSpec和过滤器类别合起来代表一个'流的描述符'，路由器就是靠它来识别每一个预留资源的

　　当每个支持RSVP的路由器沿着上行路径接收RESV的消息时，它采用输入控制过程证实请求，并且配置所需的资源。如果这个请求得不到满足(可能由于资源短缺或未通过认证)，路由器向接收端返回一个错误消息。如果这个消息被接受，路由器就发送上行RESV到下一个路由器

　　当最后一个路由器接收RESV，同时接受请求的时候，它再发送一个证实消息给接收端

　　当发送端或接收端结束了一个RSVP会话时，有一个明显的断开连接的过程。

　　RSVP支持的综合业务有以下两种基本类型：

　　有保证业务：这种业务是，尽可能地仿真成一条专用虚电路。除了要根据TSpec参数的要求确保带宽的有效性外，它还可以用把一条路径里的不同网络部件的参数合并起来的方法来提供一个端到端的固定的队列延迟

　　受控负载：这相当于'无负载条件下尽力而为服务'。因此，它比'尽力而为'服务更好，但是不能提供'有保证业务'所承诺的，具有严格固定队列延迟的服务。

　　对于‘有保证业务’和受控负载，处理不同的(与类别无关)数据业务就象处理没有QoS的尽力而为数据业务那样。综合业务采用令牌筐模式来表征输入／输出排序算法。设计令牌筐是为了平滑输出的业务流，但不象泄露筐模式(也可以平滑输出的业务流)，令牌筐模式允许数据突发、在短时间内维持更高的发送速率。

　　RSVP协议机制要点：

　　每个路由器的预留资源是'软'的，即这些资源需要由接收端定期地刷新

　　RSVP不是传输协议，而是网络(控制)协议。作为这样的协议，它不传送数据，但是和TCP或者UDP的数据'流'是并行工作的

　　应用要求API详细说明数据流的需求，初始化预留资源请求，并且在发出初始化请求后，接收预留成功或失败的通知并贯穿于整个会话过程。为了更好地利用API，API也要包含那些描述在整个预留时间内的预留建立期间或之后，当条件发生变化时出现问题的RSVP错误信息

　　根据接收端的情况来预留资源，是为了有效的接纳相当复杂的(组播)接收端组

　　在上行方向的业务复制点处组播预留资源混合在一起(仍然有不易理解的复杂算法在里面)

　　尽管RSVP业务可以通过不支持RSVP的路由器，但是这会在QoS'链'上产生一条'弱链路'，于是，QoS'链'的服务质量降回到'尽力而为'的水平(即在这些链路上没有预留资源)

　　两种RSVP协议：一是纯RSVP，包含IP的46号协议(用于IP分组头的协议区)，RSVP的分组头和有效负载封装在IP分组头里。封装在UDP里的RSVP把它的分组头放在UDP数据报里。下文将描述只支持纯RSVP的802协议，即'子网带宽管理'。

　　上面提到RSVP提供最高的IPQoS等级。应用可以请求高量化程度的QoS，以及具有最佳传输质量保证的QoS。这听上去似乎万无一失，可让我们感觉疑惑的是，为什么我们还要考虑其它问题。这是由于RSVP协议存在着复杂性和开销的价格问题，因而许多应用和网络的一些组成部分并不采用它。简单地说，RSVP缺少微调的方法，而DiffServ却可以提供这种方法。

　　DiffServ－优先级排列

　　差分服务提供一种简单粗略的方法对各种服务加以分类。不过用其它方法也可以，目前有两个每跳(PHBs)的标准，其中对两个最有代表性的服务等级(业务类别)作了规定：

　　快速转发(EF)：有一个单独的码点(DiffServ值)。EF可以把延迟和抖动减到最小，因而能提供总合服务质量的最高等级。任何超过服务范围(由本地服务策略决定)的业务被删除

　　保证转发(AF)：有四个等级，每个等级有三个下降过程(总共有12个码点)。超过AF范围的业务不会象'业务范围内'的业务那样以尽可能高的概率传送出去。这意味着业务量有可能下降，但不是绝对的。

　　根据预定策略的标准，PHBs适用于网络入口的业务。业务在这点加以标记，然后根据这个标记进行路由指向，没有作标记的业务就放到了网络的出口。

　　DiffServ假定共享同一个网络边界的网络之间存在着服务等级协定(SLA)。SLA确定了策略标准和业务范围。按照SLA协议，业务会在网络出口接受监督，并得到平滑。任何在网络入口的超出范围的业务没有质量保证。(否则，按照SLA，要承担额外的成本。)

　　服务采用的协议机制在DS字节里是比特形式的，对IPv4是业务类别(TOS)的八位位组，对IPv6则是业务量类别的八位位组。

　　DiffServ对业务量优化的单一性同它本身的复杂性及强大的功能形成对比。当DiffServ利用RSVP的参数或特殊应用类别来标识和划分固定比特率(CBR)业务时，会形成具有严格定义的综合业务流，并直接指向具有固定带宽的通道。这样一来，资源库就能得到有效地共享，而且仍然可以提供可靠服务。

　　MPLS－标记交换

　　多协议标记交换在某些方面类似与DiffServ，因为它也在网络入口的边界处标记业务，而在出口没有标记。但与DiffServ(里的标记用于判别在路由器中的优先级)不同，MPLS的标记(20比特长的标签)是用于判别路由器的下一跳的。MPLS不是受控制的应用(它没有MPLS的API)，也不含最终主机协议的成份。MPLS不象这里所描述的其它QoS协议，它只存在于路由器上。MPLS也独立于协议(即多协议)，所以它可以和其它网络协议一同使用，而不仅仅是IP(象IPX，ATM，PPP，或帧中继)，还能直接用在数据链路层上。

　　MPLS更多的是一个业务量工程协议，而不只是一个QoS协议。MPLS路由是为建立固定带宽通道，类似于ATM或帧中继的虚电路。作用是服务得到了改善，增加了更为灵活的服务种类，还有基于策略的网络管理控制。以上这些功能其它QoS协议也可提供。

　　MPLS简化了路由过程(减小开销，提高性能)，同时增加了协议层迂回的灵活性。支持MPLS的路由器叫做标记交换路由器(LSR)，它们如下工作：

　　在MPLS网络中第一跳的路由器上，该路由器根据目的地址(或根据本地策略所规定的报头中的其它信息)做出转发的决定，接着判别合适的标签值(标识着平衡等级转发类别－FEC)并把它贴在分组上，再转发给下一跳

　　在下一跳，路由器把这个标签值作为一个索引放入一张表里，这张表指明了下一跳以及一张新表。LSR再贴上新标签，把分组转发到下一跳。

　　标有MPLS分组的路径叫做标记交换路径(LSP)。在有了MPLS之后的一个想法是通过采用一个标签来判定下一跳，路由器的工作量会少一些并且能处理更多的简单交换。这个标签表示一条路由，再利用策略来分配标签，网络管理者能更精确地控制业务量工程。

　　标签的处理过程实际上要比上面所描述的复杂得多，因为标签能够被堆在一起(为的是MPLS可以在路由之中包含路由。另外，MPLS更为复杂的地方在于，为了确保各种标签含义的一致性，还要负责MPLS路由器之间标签的分布和管理。标签分布协议(LDP)是专为这一目的设计的，但不只有这一种可能性。

　　即使象标签分布这样的网络结构细节被强调再三，但对于大多数网络管理者来说，这些将是透明的。大多数网络管理者们更为关心的是策略管理，即判别何种标签用于何地，以及如何分布标签。

　　SBM：子网带宽管理

　　QoS只能保证和最弱的链路一样的通信质量。QoS懥磼是发送端和接收端间的端到端,这就表明沿着路由的每一个路由器一定要支持现在使用的QoS技术。然而，QoS懥磼由顶至底也是要从下面两个方面认真考虑的：

　　发送端和接收端主机必须支持QoS，使得应用和系统能获得明显或不明显的好处。OSI的每一层向下的应用必须也要支持QoS，以保证在网络里具有高优先级别的发送和接收请求能获得高优先级别的处理

　　局域网(LAN)必须支持QoS，以便具有高优先级别的帧在网络媒介中传送(如：从主机到主机，主机到路由器，以及路由器到路由器之间)时可以获得高优先级别的处理。LAN位于OSI的第二层，即数据链路层，而前面所描述的QoS技术已经到了第三层(DiffServ)及以上层。

　　某些第二层的技术已经可以支持QoS了，例如异步转移模式ATM)。而其它更多的LAN技术(如以太网技术)最初并非为支持QoS设计的。以太网作为共享的广播媒介，或者，在它的交换方式中，提供了一种类似与标准的尽力而为的IP服务，这种服务中的各种迟延影响着有实时要求的应用。用于802LAN(如以太网)资源共享和交换的子网带宽管理(SBM)协议是一种信令协议，它允许网络节点之间的通信、协作，以及交换并使之能够映射到更高层的QoS协议。

　　QoS结构

　　这些QoS协议是不可能单独使用的，实际上，设计它们是为了在发送端和接收端之间同其它QoS技术一起，来提供顶到底、端到端的QoS。至今，大多数把这些QoS协议粘在一起的规范还没有标准化，但是搭建各种尽可能提供统一的端到端QoS结构框架的工作已经开始进行了。

　　RSVP和DiffServ的端到端模式：RSVP为网络业务预留资源，而DiffServ简单地标记业务并给业务分配优先等级。从路由器的要求来讲，RSVP比DiffServ更复杂，要求更高，由此可能会对骨干路由器的性能产生不良影响。这就是为什么最普通的方法恰恰会限制RSVP在骨干网上的应用。

　　DiffServ和RSVP结合能够支持端到端的QoS。终端主机可以采用高量化程度(如：带宽，抖动门限等)的RSVP请求。于是，骨干网入口的边界路由器就能把那些RSVP预留的资源映射到相应的服务级别上去。这个在网络边界处使用RSVP、核心处使用DiffServ的概念已经在IETF的DiffServ小组的工作进展中很快得到了支持，虽然最初的测试没有显示出明显的结果：

　　支持RSVP的MPLS：建议在RSVP里使用EXPLICIT_ROUTE对象，来判别由标记交换的RSVP流所携带的路径信息。这些RSVP流是利用虚拟通道，经过支持MPLS的路由器形成的。即使在RSVP内没有为EXPLICIT_ROUTE对象预留资源，根据这个RSVP流的说明，为MPLS分配标签也是可能的。无论哪种情况，作用都是在MPLS路由器上简单地支持RSVP

　　支持DiffServ的MPLS：由于DiffServ和MPLS在支持QoS方面有相似之处，把DiffServ的业务映射到MPLS'通道'上相对简单一些，但是仍然要专门为DiffServ考虑。为了支持DiffServ的'每跳'模式，MPLS网络运营商需要在每个MPLS路由器里，为每个DiffServ转发级分配一批综合转发资源并负责标签的分配。

　　QoS对多媒体的支持

　　如果Internet继续迅猛发展下去，那么IP组播就成为一个要求，而不是一种选择。它对于QoS在Internet上支持点对多点的音频和视频组播是一种自然地补充，所以支持组播已经是设计QoS协议的基本要求了。

　　尽管在QoS协议设计的最初已经有所考虑，但是，所有支持组播的QoS仍没有统一标准，或还没有完全被理解。最初对RSVP和综合服务的设计已经把对IP组播的支持考虑进去了(如，基于接收端的资源预留)。而要支持组播就会面临一个困难，那就是，构成组播组的接收端要可以在它们的下行带宽容量范围内较随意地变化。

　　差分业务的相对简单使得它能更好地适应组播支持，但仍存在问题。特别是由于组播组是动态变化的，另外尽管一个组播分布树可以有一个单独网络入口，但经常有多个网络出口(并随着组播组的变化而变化)，所以给业务量的估算带来困难。

　　MPLS支持组播是一个大家努力快速发展的主题，但至今还没有标准。SBM显然支持组播，并且采用IP组播作为协议的组成部分。