Frame Relay Voice Traffic Shaping and Frament

本文全称应该是：Frame Relay Voice-Adaptive Traffic Shaping and Fragmentation，标题限制字数，没办法了

 

帧中继的流量整型向来是个头疼的地方，因为本身QOS就已经够乱，所以专门在这儿整理一下

 

QOS分为以下几类：

classification                  包分类，包标记（based on prec or dscp in ip packets' tos)

congestion management           队列(CQ/PQ/WFQ/CBWFQ/PQCBWFQ..)

congestion avoidance            随机早期检测（RANDOM DETECT）

policing and shaping            策略丢弃或流量整型，也称为congestion control

signalling                      RSVP

link efficiency mechanisms      压缩及多链路捆绑等

 

概念上易混的是congestion management 和 congestion control / policing and shaping

 

 

下面是本文的重点：帧中继语音自适应流量整型及分片

 

帧中继上的流量整型分传统方法（map-class）与MQC两种

 

传统方法只能做分片（语音包分片后获得更高效率），对不同类型数据无法给足够清晰的优先级，比如语音数据到达接口后，并不能优先于其它数据通过，只能在链路出现拥塞后，依据对端发来的BECN，将数据降速至MINCIR发送，从而给语音留出空余带宽，但此前的语音包肯定会受影响。

 

下面我们举例说明MQC在这里的应用及其优势：

 

int s0/0

  en fram

  frame-relay fragmentation voice-adaptive deactivation 50

  frame-relay interface-dlci 100

    class Jackson                         //调用map-class

    frame-relay fragment 80 end-to-end    //fragment is here

 

map-class frame-relay Jackson             //map-class在这儿只是个壳，主要是下面MQC

  service-policy output cracker

 

class-map voice

  match access-g 102

 

class-map data

  match access-g 101

 

policy-map QQ

  class voice

    priority 10                //高优先级队列

  class data

    bandwidth 10               //普通队列，基本带宽

 

policy-map cracker

  class class-default

    shape average 64000          //CIR

    shape adaptive 32000         //MINCIR

    shape fr-voice-adapt deactivation 50    //失效时间，如无语音通过，返回正常CIR速率

    service-policy QQ

 

 

注意上文中MQC的应用，套了几层而已，仔细区别一下就好

本文转自 ciscodocu51CTO博客，原文链接：http://blog.51cto.com/ciscodocu/74257，如需转载请自行联系原作者