本文全称应该是：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，如需转载请自行联系原作者
