基于Linux的QoS编程接口研究与分析（3）

第二章 QoS的协议与结构

标准Internet协议(IP)的网络提供尽力而为的数据传输。这种IP网络允许客户端主机的结构复杂一些，而网络端的结构可以保持相对的简单，因为Internet要支持自身的快速发展，所以这样的结构划分是有好处的。当越来越多的主机联在一起的时候，网络服务的需求最终会超过网
络的能力，而服务却不会停止，由此产生网络性能的逐渐恶化，进而造成传输迟延的变化(抖动)，甚至引起分组丢失，但不会影响常用的Internet应用(如，电子邮件，文件传输和Web应用)，而其它应用就不能适应有迟延的服务。传输迟延对有实时要求的应用(例如传送多媒体信息)及大多数双向通信(如电话)带来了问题。
增加带宽是满足这些实时应用必要的第一步。但是当业务量猛增的时候，仍难以避免传输迟延。甚至在一个负载相对较轻的IP网络上，传输迟延也能累积到影响实时应用的程度。为了提供能够满足要求的服务，必须补充制订有关服务数量、或服务质量水平的规定。规定中需要在网络方面增加一些协议，来区分具有严格定时要求的业务和能够容忍迟延、抖动和分组丢失的业务。这就是服务质量(QoS)协议要做的事情。QoS不是创造带宽，而是管理带宽，因此它能应用得更为广泛，能满足更多的应用需求。QoS的目标是要提供一些可预测性的质量级别，以及控制超过目前IP网络最大服务能力的的服务。
QoS协议要满足各种应用的需要。这篇文章将对这些协议做详尽的描述，然后说明它们在遵循端到端原则的不同的网络结构里是如何相互配合工作的。IPQoS技术所面临的挑战是要能把传输的服务从不同的数据流中区分开，或者在不中断网络工作的情况下将数据聚合起来。尽力而为服务的改进表明让Internet发挥其最大作用的设计思路发生了根本变化。
为了避免QoS协议用于网络时出现问题，端到端原则仍然是QoS设计者首要遵循的原则。所以，保持网络边缘复杂、核心简单这一基本原则是QoS结构设计的中心问题。这不是指单个QoS协议，而是指这些协议如何相互配合来实现端到端的QoS。

2.1 QoS协议

描述QoS的方法不只一种。通常情况下，QoS是一个网络部件(如一个应用、一台主机或一个路由器)提供的一些保证稳定传输网络数据的质量级别。某些应用对QoS的要求比其它应用更高，因此有下面两种基本的QoS：
资源预留(适于综合服务)：根据某个应用对QoS的要求来分配网络资源，并且服从带宽管理策略
按优先级排列(适于差分服务)：对网络的业务进行分类，并根据带宽管理策略的规范来分配网络资源。当所标识的业务类别有更强烈服务要求的需求时，网络部件会给予优先处理。
有两种其它方法描述QoS类型：
“流”型QoS：把一个'流'定义为一个信源和信宿之间、单个、单向、由传输协议唯一标识的数据流，其中包括数据流的源地址、源端口号、目的地址以及目的端口号
“聚合”型QoS：一个聚合是简单的两个或更多的“流”。最为突出的是，这些“流”会有相同的标记或者优先级号码，也许还有一些相同的认证信息。
应用、网络拓扑结构和策略决定了哪一种QoS最适合个别“流”，或者“流聚合”。
为满足对QoS不同的需要，有以下几种QoS协议和算法：
资源预留协议(RSVP)：提供网络资源预留的信令。尽管RSVP经常用于单个流，但也用于聚合流的资源预留
差分服务(DiffServ)：提供一个简单的分类和网络聚合流的优先级
多协议标记交换(MPLS)：根据分组头的标记，通过网络路径控制来提供聚合流的带宽管理
子网带宽管理(SBM)：负责OSI第二层(数据链路层)的分类和优先级排列，同IEEE802网络进行共享和交换。

2.1.1 RSVP－资源预留

RSVP是一个信令协议，它提供建立连接的资源预留，控制综合业务，往往在IP网络上提供仿真电路。RSVP是所有QoS技术中最复杂的一种，与尽力而为的IP服务标准差别最大，它能提供最高的QoS等级，使得服务得到保障、资源分配量化，服务质量的细微变化能反馈给支持QoS的应用和用户。
1）协议的工作情况
发送端依据高、低带宽的范围、传输迟延，以及抖动来表征发送业务。RSVP从含有“业务类别(TSpec)”信息的发送端发送一个路径信息给目的地址(单点广播或多点广播的接收端)。每一个支持RSVP的路由器沿着下行路由建立一个“路径状态表”，其中包括路径信息里先前的源地址(例如，朝着发送端的上行的下一跳)
为了获得资源预留，接收端发送一个上行的RESV(预留请求)消息。除了TSpec，RESV消息里有“请求类别(RSpec)”，表明所要求的综合服务类型，还有一个'过滤器类别'，表征正在为分组预留资源(如传输协议和端口号)。RSpec和过滤器类别合起来代表一个'流的描述符'，路由器就是靠它来识别每一个预留资源的
当每个支持RSVP的路由器沿着上行路径接收RESV的消息时，它采用输入控制过程证实请求，并且配置所需的资源。如果这个请求得不到满足(可能由于资源短缺或未通过认证)，路由器向接收端返回一个错误消息。如果这个消息被接受，路由器就发送上行RESV到下一个路由器
当最后一个路由器接收RESV，同时接受请求的时候，它再发送一个证实消息给接收端
当发送端或接收端结束了一个RSVP会话时，有一个明显的断开连接的过程。