QOS-QOS(服务质量)概述

QOS-QOS(服务质量)概述

2018年7月7日  20:29

 

概述及背景:

1.  引入:

    • 传统IP网络仅提供“尽力而为”的传输服务,网络有可用资源就转发,资源不足时就丢弃
    • 新一代IP网络承载了 语音、视频等实时互动信息,要求网络能提供有保证的服务质量
    • QOS允许用户在丢包、延迟、抖动和 带宽等方面获得可预期的服务水平

 

2.网络性能衡量的参数:

带宽:

    • 是链路上单位时间所能通过的最大数据流量,其单位为bps
    • 在一条端到端的链路中,最大 可用带宽等于路径上带宽最低的链路的带宽

   

延迟:是标识数据包穿越网络所用时间的指标

    • 处理延迟
      • 交换延迟:路由器查表时
      • 排队延迟:数据包在出接口排队的延迟
    • 传播延迟:数据在链路上传播的时间

 

抖动:

    • 是指数据包穿越网络时延迟的变化,是衡量网络延迟稳定性的指标
    • 是由于延迟的随机性造成的,主要原因是数据包排队延迟的不确定性

 

丢包率:

    • 丢包是指数据包扎传输过程中的丢失,是衡量网络可靠性的重要指标
    • 丢包的主要原因:
      • 网络拥塞时,当队列满了后,后续的报文将由于无法入队而被丢弃
      • 流量超过限制时,设备对其进行丢弃
    • 丢包以丢包率作为衡量指标
      • 丢包率=被丢包报文数量/全部报文数量

 

 

注意:

    • 语音需要低带宽,低延时,低抖动的网络
    • 数据流量需要高带宽,低丢包率的网络
    • 视频流量需要高带宽,低延时,低抖动的网络

 

 

QOS不能参加先有的带宽,只能将现有的带宽优化。

 

3.QOS提高服务质量的方法:

    •  提供物理带宽
    • 增加缓冲
    • 对数据包进行压缩
    • 优先转发某些数据流的包
    • 分片和叫错

 

4.QOS的功能:

    • 尽力避免网络拥塞
    • 在不能避免拥塞时对带宽进行有效管理
    • 降低报文丢包率
    • 调控IP网络流量
    • 为 特定用户 或特定业务提供专用带宽
    • 支撑网络上的实事业务
    • Qos不能创造带宽,只能是带宽的 分配更加合理

 

5.QOS模型:

Best  Effort模型介绍:

    • 是最简单的而服务模型,网络尽最大可能来发送报文 ,对延迟、丢包等不提供任何保证“尽力而为”。
    • 是Internet的缺省服务模型
    • 通过FIFO(先入先出)队列实现。

 

FIFO队列:

    • 所有数据进入同一队列,按先进先出原则调度
    • 队列满后,后续报文被丢弃

 

优点:

     实现简单

     节省处理资源,处理速度快

缺点:

     所有数据流同等对待

     所有数据流的带宽、延迟、抖动、丢包等都不可控

 

 

DiffServ模型:(区分服务类型)属于互联网部署最广泛的模型

    • 对网络中不同的业务进行分类
    • 不需要跟踪每一数据流,资源占用少,扩展性强
    • 不能提供精确的QoS,难以提供端到端的QoS

 

模型组件:

 

 

 

边界节点与内部节点:

 

 

  DS区:由多个DS域组成

  DS域:整条QOS流水线

  DS的边界节点

          分类

          标记

          丢弃

          整形

 

  DS的内部节点

          根据边界节点的行为聚合,做PHB(逐条行为)

          拥塞管理

          拥塞避免

          头部压缩

 

 

边界行为:

    • 分类器:
      • BA分类器(根据行为进行分类)
      • MF分类器(根据字符段进行分类,IP五元组,IP协议字段)
    • 调节器
      • 测量器(令牌桶)
      • 标记器器(CAR和 Map-table(QOS的映射表))
      • 整形器(GTS,LR)
      • 丢弃器(CAR)

 

令牌桶 :通过令牌桶算法对流量进行评估,以确定其实是否超出了承诺的速率。

令牌桶是网络设备的内部存储池,而令牌则是以给定速率填充令牌桶的虚拟信息包。每个到达的令牌都会从数据队列领出相应的数据包进行发送,发送完数据后令牌被删除。是网络设备衡量数据有没有超过额定带宽的工具,从而给出对数据的处理方式。

 

 

无突发令牌桶算法:

 

CIR(承诺信息速率):以承诺的每秒字节数来衡量

CBS(承诺突发尺寸):以字节数来衡量,取值大于0,并且至少应该等于最大的分组长度。

 

    • 每个报文进行一次评估,当报文长度大于Tc时标记为超出承诺速率流量,反之为承诺速率以内流量

 

 

带突发的单速率双令牌桶算法:(两个令牌桶,一个速率投放令牌)

CIR:以承诺的每秒字节数来衡量

CBS:以字节数来衡量,取值大于0,并且至少应该大于等于最大的分组长度。桶的容量,C桶=CBS

EBS(超额突发尺寸):以字节数来衡量,取值大于0,并且至少应该大于等于最大的分组长度。也是桶的容量,E桶=CBS+EBS

 

 

假设某一时刻一个大小为B字节的报文到达,在对其进行评估时:

    • 如果Tc>B,则报文被标记为“承诺突发内”,进行传输
    • 如果Tc<B<Te,则报文标记为“超额突发内”,进行传输
    • 如果Tc<Te<B,则报文被标记为“超出超额突发”,不进行传输,直接丢弃

 

带突发的双速率双令牌桶算法:

假设某一时刻一个大小为B字节的报文到达,在对其进行评估时,遵循以下规则:

    • TP<B,则报文被标记为“超出峰值速率”,直接丢弃
    • TC<B<Tp,报文被标记为“峰值速率内”,Tp桶传输
    • B<TC<Tp,报文被标记为“承诺速率内”,Tc和Tp都传输

 

 

 

    • PHB:是指DS节点对行为聚合应用的可由外部观测到的转发行为。PHB是DS节点对行为 聚合分配资源的方法。
      • Default PHB:称BE(尽力而为)是默认的PHB。提供尽力而为的服务,服务没有任何保证
      • Class Selector(类选择符)PHB:一个 Class Selector代码点的值越高,其重要性和优先级越高,也就应该获得更好、更及时的服务。
      • EF(加速转发):此类PHB提供低延迟、低抖动、低丢包率和保证带宽的优先转发服务,主要用于语音、视频等对延迟和抖动敏感的业务
      • AF(确保转发):PHB提供有保证的带宽服务

 

队列是PHB的核心,通过队列之间的调度来为其转发资源:

 

    • PQ(优先队列)PQ按照优先级从高到低提供了Top、Medium、Normal和Low4个队列
    • CQ:(定制队列)CQ给每个队列提供不同的权重,各队列之间采用轮询机制,CQ保证每个队列都能得到一定的调度机会,但不能保证任何一个队列优先获得调度
    • WFQ:(加权公平队列)依据IP五元组、ToS字段、MPLS EXP等参数区分数据流,为数据东泰监理队列;调度时依据不同的IP Precedence或DSCP值确定数据流的权重,并为其提供相应比例的资源
    • CBQ:(基于类的队列)CBQ允许用户根据IP优先级或者DSCP、输入接口、IP报文的五元组,以及用户定义的ACL等规则来对报文进行分类
    • WRR:(加权循环)允许以较小的计算开销在若干队列之间根据权重提供转发服务。

 

令牌桶默认大小是cir速率的一半,为什么呢?

答:因为1s内拿两次令牌,半秒拿一次,cir一秒投一次。

假设cir速率为1000kbps,那么cbs默认为62500Byte。一秒之后令牌桶内的令牌数回到初始状态

 

令牌桶(cbs)最小为CIR的6.25倍。

答:假如cir 为64kbps,那么CBS最小值为64*6.25=400Byte。

 

 

IntServ模型:(综合服务)

在这种模型中,节点在发送报文前需要向网路申请所需资源。这种请求是通过RSVP(资源预留协议)信令来完成的。

 

Intserv可以提供一下两种服务:

    • 保证服务:它提供保证的带宽和延迟来满足应用程序的需求
    • 负载控制服务:它保证即使在网络过载的情况下也能对对报文提供与网络未过载时类似的服务,即网络拥塞时也能保证某些应用程序报文的低延迟和优先通过

    • RSVP介绍:

用于在一条路径的各节点上进行资源预留。RSVP工作在传输层。

 

从第一跳路由器开始用Path消息逐跳进行资源请求,到达目的后再用Resv消息反向逐跳进行资源预留。由接收者发起对资源预留的请求,并维护资源预留信息。

 

优点:

    • 提供绝对的、准确的QOS保障,不会随网络状态的变化而受到影响
    • 提供端到端的QOS服务

缺点:

    • 需要跟踪 和记录每一个流的状态,因而扩展性很差

 

应用:

    • 和DiffServ模型相结合
      • 在网络的边缘利用IntServ模型进行精细的Qos控制
      • 在网络骨干部分则利用DiffServ模型进行简单高效的Qos控制
    • 和MPLS TE相结合
      • 可以根据网络拥塞情况,引导流量的均匀化分部

 

配置QoS边界行为:

分类:

     自动分类:根据入接口上配置的信任类型分类。包括信任端口优先级或者信任报文优先级。

     手动分类:通过ACL等手段匹配报文的IP地址、端口号、MAC地址、入接口、协议类型、Vlan号、CoS、EXP、IP Precedence、DSCP等

 

流量监管:

    • 定义:

          流量监管:为网络服务提供者提供了 一种对用户流量进行监督的 能力,以使其能严格地符合SLA。

 

          CAR(承诺访问速率)是一种基本的流量监管工具。CAR可以区分报文的类型,使用令牌桶技术对各类数据流量进行测量,测量后的报文可以采取放行、丢弃、重标记、转入下一级监管等多种操作。

 

    • 位置:

 

    • 工作于网络层,对网络层报文进行流量监管
    • 既可以应用在入方向,也可以应用在出方向

在入方向:CAR处理在转发模块之前,只有被CAR放行的报文才能进入转发,就CAR丢弃的报文将不能进入转发。

在出方向:CAR的处理在接口其他Qos机制之前。当拥塞未发生时,即用户队列为空且发送队列未满时,被CAR放行的报文将直接进入出接口的发送队列进行转发。当拥塞时,即发送队列已满,被CAR放行的报文将进入出接口的用户队列调度。

 

用户队列:由软件或硬件实现的队列 

发送队列:由接口硬件实现

 

最好用在入方向,如果用在出方向,要经过查表的过程,查到最后被丢了,不合理

 

CAR的原理:(减小CIR(投放令牌速率)可以限速)

 

当存在多条CAR规则时,报文被依次与每一规则的分类条件相对比,符合条件的即属于本规则确定的类。

    • 放行(PASS):指允许相应的报文通过CAR,进入下一步的队列调度或转发 处理
    • Didscard(丢弃):指丢弃相应的报文
    • Continue(继续):指将相应的报文提交给下一条CAR规则进行处理

 

CAR配置命令:

配置CARL:(匹配数据流)

 

subnet:子网网段

range:IP地址范围

pre-address   表示这个网段每个地址

shared-bandwidth:共享带宽

 

在接口应用基于CARL或ACL的CAR规则:

 

流量整形:

    • 用于保证输出到下游网络的流量符合某种限制标准,使流量更加平滑,会增加数据包的延迟。
    • 是一种主动调整流量输出速率的措施。一个典型应用是基于与下游网络节点的SLA/TCA协定来控制本地流量的输出
    • 流量整形通过GTS实现
      • 以令牌桶算法测量流量
      • 对于超出承诺速率的报文会放入一个队列缓存

 

    • GTS只能应用于接口的出方向
    • GTS位于队列调度机制之前

 

GTS的原理:

 

    • GTS对符合承诺速率的报文放行,将超出承诺速率的报文入队缓存,当有足够令牌时再进行发送
    • 当缓存队列未满时后续报文直接入队,缓存队列满时后续报文被直接丢弃

GTS将每一类报文分别送入各自的令牌桶中进行测量,评估其流量是否符合既定的限度,符合的报文放行,进入下一步的队列调度或转发处理,不符合被缓存在队列里,待有足够令牌时再继续发送。

 

基于ACL的GTS:

 

 

在接口上基于队列的GTS:(在交换机中,基于队列的GTE命令可对出接口的指定队列中的流量进行整形。其中queue queue-number表示对指定队列上的数据包进行流量整形,queue-number为指定队列号)

 

在接口上配置对接口上全部流量进行整形:

 

显示流量整形配置运行信息:

接口限速:

    • 接口限速(LR):限制了从一个接口发向下游的报文的总速率
    • LR在令牌桶中引入了队列缓存的机制,因而减小了丢包,平滑了流量,但同时也增大了延迟
    • LR位于链路层,在用户队列之后,发送队列之前,对从该接口发出的所有IP和非IP报文(紧急报文除外)均能生效,接口全局生效。
    • LR只能应用于接口的出方向,运用在接口链路层。

原理:

 

    • 由于令牌不够而不能发送的报文会被再次送到用户队列,经过队列调度后再进入令牌桶进行评估
    • 与GTS中简单缓存队列不同 ,LR的缓存几乎可以利用QoS拥塞管理中的所有队列机制

 

接口下的接口限速配置:

查看接口的LR配置和统计信息:

CAR:可以针对每个流量进行限速、标记、丢弃

LR:物理接口限速

GTS:减小流量的波动,使流量更加平滑(相当于限速)

 

常见错误:

    • 物理层接口混乱
    • 二层链路不通
    • 网络不通做QOS
    • 方向错误
    • 流抓错误
    • QOS功能理解错误

 

           

原文地址:https://www.cnblogs.com/good-study/p/9929664.html