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