-
Qos
简介与
Qos
案
例分析
25.1
QoS
简介
在传统的
IP
网络
中
,
所有的报文都被无区别的等同对待
,
每个路由器对所有的报文均采用先入先
(FIFO)
的策略进行处理
.
它尽最大的努力
(Best-Effort)
将报文送到目的地
,
但对报文传送的可靠性
< br>,
传
送延迟等性能不提供任何保证
.
网
络
发展日新月异
,
随着
IP
网络
上新应用的不断出现
,
对
IP
网络
的服务质量也提出了新的要求
.
例
如
VoIP
等实时业务就对
报文的传输延迟提出了较高要求
.
如果报文传送延时太长
,
将是用户所不能接受
的
(
相对而言
E-Mail
和
FTP
业务对时
间延迟并不敏感
).
为了支持具有不同服务需求的语音
,
视频以及数
据等业
务
,
要求
网络
能够区分出不同的通信
,
进而为之提供相应的服务
.
传统
IP
网络
的尽力服务不可能识
别和区分出
网络
中的各种通信类别
,
而具
备通信类别的区分能力正是为不同的通信提供不同服务的前提
所以说传统
网络
的尽力服务模式已不能满足应用的需要
QoS(Quality of Service ,
服务质量技术<
/p>
)
的出
现便致力于解决这个问题
25.1.1
一个简单的
QoS
案例
下面用简单的例子对比
了在
网络
发生拥塞时报文在无
QoS<
/p>
保证和有
QoS
保证
网络
中的不同处理过
程
,
下图所示为发生拥塞时
网络
< br>设备的一个接口在不支持
QoS
的情况下报文的发送情况
所有要从该接口输出的报文
,
按照到达的先后顺序进入接口的<
/p>
FIFO
队列尾部。而接口在发送报文
时从
FIFO
先入先出队列的头部开始
依次发送报文。所有的报文在发送过程中没有任何区别也不对报文
传送的质量提供任何保证
当然
,
我们需要寻求更好的处理方式
,
下
图为一个优先级对列进行
Qos
处理的过程。
< br>
在报文到达接口后
,<
/p>
首先对报文进行分类
,
然后按照报文所属
的类别让报文进入所属队列的尾部。
在报文发送时
,
按照优先级总是在所有优先级较高的队列中的报文
,
发送完毕后再发送低优先级队列中
的报文。这样在每次发送报文时总是将优先级高的报文先发出去。保证了属于较高优先级队列的报文
有较低的时延报文的丢失率和时延。这两个性能指标在
< br>网络
拥塞时也可以有一定的保障。
.1.2
QoS
的作用
QoS
旨在针对各种应用的不同需求为其提供不同的服务质量例如提供专用带宽减少报文丢失率降
低报文传送时延及时延抖动等为实现上述目的
QoS
提供了下述功能
报文分类和着色
网络
拥塞管理
网络
拥塞避免
流量监管和流量整形
QoS
信令协议
QoS
可以控制各种
网络
应用和满足多种
网络
应
用要求如
控制资源：
如可以限制骨干网上
FTP
使用的带宽
,
也可以给数据库访问以较高优先级
可裁剪的服务：
对于
ISP
其用户可能传送语音视频
或其他实时业务
QoS
使
ISP
能区分这些不同的报文
并提供不同服务
多种需求并存：
可以为时间敏感的
多媒体业务提供带宽和低时延保证
,
而其他业务在使用
网络
时也不
会影响这些时间敏感的业务
在一个
网络
中需要以下的三个部分来完成端到端的
QoS
各
网络
元件路由器以太网交换机等支持
QoS
提供队列调度流量整形等功能
信令技术来协调端到端之间的
网络
元件
,
为报文提供
QoS
QoS
技术控制和管理端到端之间的报文在一个
网络
上的发送
而每个
网络
元件提供如下功能
报文分类
,
对不同类别的报文提供不同的处理
队列管理和调度来满足不同应用要求的不同服务质量
流量监管和流量整形限制和调整报文输出的速度
接入控制来确定是否允许用户信息流使用
< br>网络
资源
25.2
QoS
服务模式
网络
应用是端到端的通讯结构
,
比如两个不同
网络
的主机进行通讯
,
中
间可能跨越各种
router
和
核心
switch,
那么想整体的实现
所谓的
QOS,
就必须全局考虑
,QO
S
的服务模型的概念就是采用通过什么
模式全局实现服务质量保证
,
一共分成三种。
Best-Effort service
尽力而为服务模型
Integrated service
综合服务模型
简称
Intserv
Differentiated service
区分服务模型
简称
Diffserv 25.2.1
尽力而为的服务模型
Best-
Effort
是一个单一的服务模型
,
也是最简单的服务模型
,
应用程序可以在任何时候
,
发出任
意数量的报文
,
而且不需要事先获得批准
,
也不需要通知
网络
,
对
Best-Effort
服务
,<
/p>
网络
尽最大的可能
性来发送报文
,
但对时延、可靠性等性能不提供任何保证<
/p>
Best-Effort
服务是现在
I
nternet
的缺省服
务模型
,
它适用于绝大多数
网络
< br>应用
,
如
FTP
、
E-Mail
等。其实
best-effort
并非是什么
QOS,
就是互
联网的简单数据传输
方式而已
,
有什么传什么
,
阻塞也就阻塞了
,
丢且也就丢弃了。
25.2.2
集成服务模型
Intserv
：集成服务模型
,
它可以满足多种
QoS
需求。这种服务模型在发送报文前
,
需要向
网络
申
请特定的服务。应用程序首先通知
网络
它自己的流量参数和需要的特定服务质量
请求：包括带宽、
时延等。应用程序一般在收到
网络
的确认信息
< br>,
即确认
网络
已经为这个应用程
序的报文预留了资源后
,
才开始发送报文
,
同时应用程序发出的报文应该控
制在流量参数描述的范围以
内。
网络
在收到应用程序的资源请求后
,<
/p>
执行资源分配检查
Admission control
即基于应用程序的资
源申请和
网络
现有的资源情况
,
判断是否为应用程序分配资源
,
一旦
网络
确认为应用程序的报文分配了
资
源
,
则只要应用程序的报文控制在流量参数描述的范围内
,
网络
将承诺满足应用程序的
QoS
需求。而
网络
将为每个流
flow
由两端的
IP
地址、端口号、协议
号确定、维护一个状态
,
并基于这个状态执行
< br>
报文的分类、流量监管、
policing
、排队及其调度来实现对应用程序的承诺。
在
IntServ
服务模型中
,
负责传送
QoS
请求的信令是
RSVP(Resource Reservation
Protocol)
资源
预留协议<
/p>
,
它通知路由器应用程序的
QoS
需求。
RSVP
是在应用程序开始发送报文之前来为该应用申请
网络
资源的。
Intserv
实际上是一种对服务的预定机制
,
通过申请来
获取相应得服务
,
这里面主要依靠
<
/p>
的就是
RSVP
——
资源预留协议。
RSVP
是第一个标准
QoS
信令协议
,
它用来动态地建立端到端的
QoS,
它允许应用程序动态地申请网
络带宽等。
RSVP
协议不是一个路由协议
,
相反
,
它按照路由协议规定的报文流的路径为报
文申请预留资
源
,
< br>在路由发生变化后
,
它会按照新路由进行调整
,
并在新的路径上申请预留资源。
RSVP
只是在
网络
节
点之间传递
QoS
请求
,
它本身不完成这些
QoS
< br>的要求实现
,
而是通过其他技术来完成这些要求的实现。
(RSVP
只是一种用来预定的协议
)
RSVP
的处理是接收方发出资源请求
,
按照报文发送的反向路径发送资源请求
,
< br>所以它可以满足非
常大的多播组
,
多播组的成员也可以动态变化
,RSVP
协议是针对多播设计的
单播可以看作是多播的一
个特例。
由于
RSVP
在
Internet
上还没有得到
广泛的推广
,
在主机不支持
RSVP
的情况下
,
我们可以通过配
置
RSVP
代理<
/p>
,
即代替不支持
RSVP
的主机发送
RSVP
报文来获得这
种服务
,
对报文流路径上不支持
RSVP
的路由器
,
它只需要简单的
转发
RSVP
报文
< br>所以对
RSVP
协议不会有太大影响
,
但这些节点不会对报文提
供所要求的
QoS
。
(
这是
RSVP
的一个缺点
)
RSVP
信令在
网络
节点之间传送资源请求
,
而
网络
节点在收到这些
请求后
,
需要为这些请求分配资
源
,
这就是资源预留。
网络
节点比较资源请求和
网络
现有
的资源
,
确定是否接受请求
,
在资源不够的情况
下
,
这个请求可以被拒绝
,
可以对每个资
源请求设置不同的优先级。这样
,
优先级较高的资源请求可以在
网络
资源不够的情况下
,
抢占较低优先级的预留资源
,
来优先满足高优先级的资源请求。
资源预留判断是否
接受资源请求
,
并承诺对接受了的资源请求提供请求的服务
,
但资源预留本身
不实现承诺的服务
,
需要通过队列等其他技术来实现。
Intserv
有它的好处
,
但是也有严重缺点
,
首先就是
RSVP
协议数据太多
,
而且不断刷新
,
并且这种
给单一数据流的路径进行带宽预留的解决思路在浩瀚的
Internet
上实现简直是不可能的
,
而且
RSVP
的
部署
,
厂商之间设备的互联
,
业务管理方面
等存在着种种问题
,
所以这么模型在
1994
年推出之后就没
有获得任何规模的商业应用。
2.3
区分服务模型
DiffServ
是一个多服务模型
,
它可以满足不同的
QoS
需求
,
与
IntServ
不同
,
它不需要使用
RSVP
即应用程序在发出报文前
,
不需要通知路由器为其预留资源
,
对
DiffServ
服务模型
,
网络
不需要为每个
流维护状态
,
它根据每个报文指定的
QoS
来提供特定的服务
可以用不同的方法来指定报文的
QoS,
如
IP
报文的优先级位
IP
Precedence) ,
报文的源地址和
目的地址等
,
网络
通过这些
信息来进行报文的分类、流量整形、流量监管和队列调度。
DiffServ
一般用来为一些重要的应用提供端到端的
QoS
它通过下列技术来实现
CAR
：
它根据报文的
ToS
或
CoS
值
(
对于
IP
报文是指
IP
优先级或者
DSCP
等等
)IP
报文的五
元组
(
指源地址目的地址协议端口号
)
等
信息进行报文分类
,
完成报文的标记和流量监
< br>
管。
队列技术：
WRED
、
PQ
、
CQ
、
WFQ
、
CBWFQ
等队列技术对拥塞的报文进行缓存和调度
,
实现拥塞管理。
通常在配置
DiffServ
时<
/p>
,
边界路由器通过报文的源地址和目的地址等对报文进行分类
,
对不同的
报文
设置不同的
CoS
值
,
而其他路由器只需要用
CoS
值来进行报文的分类
在
MPLS
上
应用
DiffServ
用以下两种方法来解决：
在以太网等
网络
中
,MPLS
报文在二层链路层和三层
网络
层之间有
一个薄层
(shim).
我们扩展
<
/p>
薄层中未用的字段
---EXP.
由这几
个位来决定报文的队列调度及丢弃的优先级
.
在
ATM FR
等
网络
中
,
其
MPLS
报文没有薄层
(shim),
可针对
FEC ForwardingEquivalance
Class
转
发等价类和
QoS
请求的组合来分配标签
,
而不同于以前仅针对
FEC
分配标签
< br>.
这样在收到一个
MPLS
报文
后
,
根据收
到报文的标签就可以确定发出报文的标签及报文所要求的服务
.
25.2.4 Intserv
与
Diffserv
之间的互通
一般来讲
,
在提供
IP
网络
的
QoS
时
,
为了实现规模适应性
,<
/p>
在
IP
骨干网往往需要采用
Diffserv
体
系结构
,
在
IP
边缘网可以有两种选择
:
采用<
/p>
Diffserv
体系结构或采用
Intserv
体系结构
.
目前在<
/p>
IP
边
缘
网络
采用哪一种
QoS
体系结构还没有定论
,
也许这两种会同时并存于<
/p>
IP
边缘网中
.
在
IP
边缘网采用
Diffserv
体系结构的情况下
,IP
骨干网与
IP
边缘网之间的互通没有问题
.
在
IP
边缘网采用
In
tserv
体
系结构的情况下
,
需要解决
Intserv
与
Diffserv
之间的互通问
题
,
包括
RSVP
在
Diffserv
域的处理方
式
,Intserv
支持的业务与
Diffserv
支持的
PHB(Per-Hop Behavior,
< br>单中继段行为
)
之间的映射
.
RSVP
在
Diffserv
域的处理可以有多种可选择的方式
.
例如
1.
一种方式为
RSVP
对
Diffserv
域透
明
,RSVP
在
Intserv
域边界路由器终结
,Diffserv
域对<
/p>
Intserv
域采用静态资源提供方
式
:
2.
一种方式为
Diffserv
域参与
RSVP
协议处理
,Diffserv
域对
< br>Intserv
域采用动态资源提供
方式
.
前一种互通方式实现相对简
单
,
可能造成
Diffserv
域资源的浪费
.
后一种互通方式实现相对复杂
,
可以优化
Diffserv
域资源的使用
.
除此以外
,
还需要解决
Intserv
支持的业务与
Diffserv
支持的
PHB
之间的映射问题
.
映射标准为
两者支持的应用是否相同或相近
.
为了说明这个问题我们首先回顾一下
Intserv
支持的业务
,
它支持
的业务包括保证服务
(Guaranteed
Service)
负载控制服务
(Controlled-
Load Service).
前者可以为用
户应用提供严格的端到端时延及带宽保证
,
适用于实时
应用
.
后者在
网络
负荷较重的情况下为用户应用
提供与
网络
轻负荷情况下相近似的性能
,
不能保证端到端的时延
.
Diffserv
提供的
PHB
包括
EF (Expedited Forwarding
加速转发
)AF(Assured Forwarding
确保
转发
)
EF
用于支持低丢失率
,
低时延
,
确保带宽的应用
AF
可以保证在应用向
网络
发送的业
务流量没有超
过约定值的情况下
,<
/p>
该应用的报文丢失概率非常低
AF
有
4
类每一类可以设置
3
个不同的丢弃优先级
.
从上面的叙述
易于获得
Diffserv
与
Ints
erv
之间的映射关系
将
Intserv
中的保证服务映射为
Diff
serv
中的
EF
将
Intserv
中的负载控制服务映射为
Diffs
erv
中的
AF
25.3 Diffserv
服务模式
25.3.1
Diffserv
体系结构
用
来在
网络
中提供
QoS
的
Diffserv
方法应用了一组合理定义的小型基本部件，使用这些部件可
<
/p>
以构筑一系列的服务。其目标是在
IPv4
报头中定义区分服务
(DS)
字节和服务类型
(ToS)
字节，在
IPv6
中定义通信类
(TrafficClass)
字节，并标记分
组中的标准化
DS
字节，使分组在每一个
网络
节点得到特
定的转发处理或单
中继段行为
(PHB)
。